Network Working Group J. Weil
Internet-Draft Time Warner Cable
Updates: 1918, 5735 (if approved) V. Kuarsingh
Intended status: BCP Rogers Communications
Expires: March 29, 2012 C. Donley
CableLabs
C. Liljenstolpe
Telstra Corp
M. Azinger
Frontier Communications
September 26, 2011
IANA Reserved IPv4 Prefix for Shared CGN Space
draft-weil-shared-transition-space-request-06
Abstract
This document requests that an IPv4 /10 be reserved as Shared CGN
Space solely to facilitate deployment of IPv4 Carrier Grade NAT (CGN)
technologies after IPv4 exhaustion. This document updates RFC 1918
and RFC 5735 to reserve an additional special-use address range for
use between a CGN and home router.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 29, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Weil, et al. Expires March 29, 2012 [Page 1]
Internet-Draft Shared CGN Space Request September 2011
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Shared CGN Space . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Address-Based Scope Detection . . . . . . . . . . . . . . 6
5. Alternatives . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. RFC1918 Space . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Globally Unique Space . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Weil, et al. Expires March 29, 2012 [Page 2]
Internet-Draft Shared CGN Space Request September 2011
1. Introduction
IPv4 address space is nearly exhausted. Until the Internet fully
transitions to IPv6, Service Providers will be required to offer
continued support for legacy IPv4-only devices. In order to
facilitate the deployment of Carrier Grade NAT (CGN) technologies
[RFC6264] to support such legacy IPv4-only devices and services,
Service Providers require IPv4 address space that is separate from
the range of IPv4 addresses used by subscribers. This address space
need not be unique to each provider, but needs to be outside of
[RFC1918] space. This document requests that an IPv4 /10 be reserved
as Shared CGN Space solely to facilitate deployment of CGN
technologies in Service Provider networks. As Shared CGN Space is a
new special-use address range between a CGN and home router, this
document updates [RFC1918] and [RFC5735] to reflect its use.
Weil, et al. Expires March 29, 2012 [Page 3]
Internet-Draft Shared CGN Space Request September 2011
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Weil, et al. Expires March 29, 2012 [Page 4]
Internet-Draft Shared CGN Space Request September 2011
3. Motivation
The Internet community is rapidly consuming the remaining supply of
unallocated IPv4 addresses. During the transition period to IPv6, it
is imperative that Service Providers maintain IPv4 service for
devices and networks that are currently incapable of upgrading to
IPv6. In order to provide IPv4 service to customers and/or devices
once the IPv4 address space is exhausted, many Service Providers will
need to multiplex several subscribers behind a single IPv4 address
using a Carrier Grade NAT (CGN) [RFC6264]. Addresses between the CGN
and subscriber home routers need not be globally unique, only unique
inside the CGN. Thus, providers need sufficient non-[RFC1918]
address space to deploy such technologies and avoid overlap with
customer use of private address space.
Additional applicability and analysis of Shared CGN Space is
described in [I-D.bdgks-arin-shared-transition-space].
Weil, et al. Expires March 29, 2012 [Page 5]
Internet-Draft Shared CGN Space Request September 2011
4. Shared CGN Space
This document proposes the assignment of a /10 as Shared CGN Space.
Shared CGN Space is IPv4 address space reserved for Service Provider
use with the purpose of facilitating CGN deployment. The requested
block MUST NOT be utilized for any purpose other than as "inside"
addresses in a CGN environment (e.g., between the CGN and customer
premises equipment (CPE)). Network equipment manufacturers MUST NOT
use the assigned block in default or example device configurations.
Because Shared CGN Space addresses have no meaning outside of the
Service Provider, routing information about Shared CGN Space networks
MUST NOT be propagated on interdomain links, and packets with Shared
CGN Space source or destination addresses MUST NOT be forwarded
across such links, except where required based on business
relationships such as hosted CGN service. Service Providers SHOULD
filter out routing information about Shared CGN Space networks on
ingress links. DNS queries for Shared CGN Space addresses MUST NOT
be forwarded to the global DNS infrastructure. This is done to avoid
having to set up something similar to AS112.net for RFC 1918 private
address space that a host has incorrectly sent for a DNS reverse-
mapping queries on the public Internet [RFC6304].
Shared CGN Space is expected to be used in a Service Provider
Environment. Shared CGN Space MUST NOT be used in network
environments described in [RFC1918] as designed for private addresses
- namely, for hosts that do not require access to hosts in other
enterprises or the Internet at large, or hosts that need access to a
limited set of outside services (e.g., E-mail, FTP, netnews, remote
login) that can be handled by mediating gateways (e.g., application
layer gateways). Shared CGN Space MUST NOT be used inside a home
router NAT. With the exception of subscribers using bridged Internet
access (i.e., without a home router between the subscriber and
Service Provider networks), subscriber hosts SHOULD NOT use Shared
CGN Space addresses. Because CGN service requires non-overlapping
address space on each side of the home NAT and CGN, entities misusing
Shared CGN Space for purposes other than for CGN service, as
described in this document, are likely to experience problems
implementing or connecting to CGN service at such time as they
exhaust their supply of public IPv4 addresses.
4.1. Address-Based Scope Detection
Some CPE router devices make assumptions about their connectivity
scope based on their WAN-side IPv4 address. This is particularly
evident in their handling of 6to4 [RFC3056], [RFC3068]. As described
in [RFC6343], CPE routers do not attempt to initialize 6to4 tunnels
when they are configured with a [RFC1918] or [RFC5735] WAN address.
Weil, et al. Expires March 29, 2012 [Page 6]
Internet-Draft Shared CGN Space Request September 2011
When configured with a Shared CGN Space address (or other address
range not described in [RFC5735]), such devices may attempt to
initiate 6to4. Since 6to4 includes the WAN IPv4 address embedded in
its IPv6 address, should 6to4 traffic traverse a CGN, return traffic
could be misdirected and not reach the originating router. Service
Providers can mitigate this issue using a technology such as 6to4-PMT
[I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel]. When the address
range is well-defined, as with Shared CGN Space, home router vendors
can include Shared CGN Space in their list of special-use addresses
(e.g., [RFC5735]) and treat Shared CGN Space similarly to private
[RFC1918] space. When the WAN address is not well-defined, as in the
case of Globally Unique space, it will be more difficult for home
router vendors to mitigate against this issue.
CGN technologies impose additional impacts on applications (see
[RFC6269] and [I-D.donley-nat444-impacts]) that are not dependent on
the address space between the CGN and home router.
Weil, et al. Expires March 29, 2012 [Page 7]
Internet-Draft Shared CGN Space Request September 2011
5. Alternatives
As described in [RFC6319], there are two alternatives to Shared CGN
Space, considered below:
1. Use private [RFC1918] address space.
2. Use Globally-Unique address space.
5.1. RFC1918 Space
In some cases, it may be possible to instead use private [RFC1918]
address space between the CGN and CPE devices. In situations where
all endpoints in the network are managed by the service provider
(including customer LAN addressing), this may be a viable option.
However, when customers administer their own LANs or use default
addresses assigned to CPE devices, the possibility of address
conflict becomes a significant risk to operations. Private [RFC1918]
address space is not generally intended to be used for purposes which
cross administrative domains. Further, CGN service requires address
space in one administrative domain that extends to leaf networks that
are generally single-homed to the serving administrative domain.
This usage is outside of Category 1 and Category 2, defined in
[RFC1918] for use of private address space.
A study of DNS traffic [v6ops-msg06187] has shown that effectively
all of the existing private [RFC1918] address space is currently
being used by end-sites attached to the Internet. While individual
network environments may vary in this regard, most Service Providers
face the risk that their use of private address space will conflict
with their customer end-sites.
In the event of conflict, it is possible that the end-site CPE
routers will fail and/or not function correctly. While some CPE
implementations will support overlapping addresses on the "inside"
and "outside" interfaces, others are known to fail under such
circumstances. Also, the use of private [RFC1918] address space on
interfaces and hosts often causes default behaviors on such hosts
which may not be desirable when the endpoint is actually connected to
the Internet. For instance, one common home router warns customers
against enabling NAT when it detects private [RFC1918] addresses on
its WAN interface, and instead encourages bridge mode. If NAT mode
is enabled, the router turns the status light amber, indicating an
error.
Weil, et al. Expires March 29, 2012 [Page 8]
Internet-Draft Shared CGN Space Request September 2011
5.2. Globally Unique Space
If Shared CGN Space is not available, the total aggregate demand for
Globally-Unique space behind a CGN will be significantly higher than
the /10 requested as Shared CGN Space. In addition to use of
significant IPv4 addresses that could otherwise be offered to
subscribers, as described in
[I-D.bdgks-arin-shared-transition-space], if various organizations
use public address space to number CGN zones, it will be difficult
for other networks/hosts to deterministically know if the endpoints
are using Internet reachable addresses, or if they are leaking from
behind a CGN, as described above (Section 4.1). This situation would
likely lead to additional technical issues during various leakage
conditions, make it difficult to identify filter rule issues, and
pose challenges for Content Distribution Networks (CDNs) or other
third party providers.
Weil, et al. Expires March 29, 2012 [Page 9]
Internet-Draft Shared CGN Space Request September 2011
6. Security Considerations
Similar to other [RFC5735] special use IPv4 addresses, Shared CGN
Space as described in this document does not directly raise security
issues. However, the Internet does not inherently protect against
abuse of these addresses. Unless required for legitimate business
needs between directly-connected Service Providers, Service Providers
SHOULD filter incoming router advertisements for Shared CGN Space.
Attacks have been mounted that depend on the unexpected use of
similar special-use addresses. However, it should also be noted that
this address spaces may be used legitimately outside a single
administrative domain. Thus, network operators are encouraged to
review this document and determine what security policies should be
associated with this address block within their specific operating
environments. In many cases, Shared CGN Space will be appropriate to
include in Ingress Filter lists [RFC3704].
Weil, et al. Expires March 29, 2012 [Page 10]
Internet-Draft Shared CGN Space Request September 2011
7. IANA Considerations
IANA is asked to record the allocation of an IPv4 /10 for use as
Shared CGN Space.
The Shared CGN Space address range is: x.x.0.0/10. [Note to RFC
Editor: this address range to be added before publication]
Weil, et al. Expires March 29, 2012 [Page 11]
Internet-Draft Shared CGN Space Request September 2011
8. References
8.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
BCP 153, RFC 5735, January 2010.
[RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental
Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264,
June 2011.
8.2. Informative References
[I-D.bdgks-arin-shared-transition-space]
Barber, S., Delong, O., Grundemann, C., Kuarsingh, V., and
B. Schliesser, "ARIN Draft Policy 2011-5: Shared
Transition Space",
draft-bdgks-arin-shared-transition-space-01 (work in
progress), July 2011.
[I-D.donley-nat444-impacts]
Donley, C., Howard, L., Kuarsingh, V., Chandrasekaran, A.,
and V. Ganti, "Assessing the Impact of NAT444 on Network
Applications", draft-donley-nat444-impacts-01 (work in
progress), October 2010.
[I-D.kuarsingh-v6ops-6to4-provider-managed-tunnel]
Kuarsingh, V., Lee, Y., and O. Vautrin, "6to4 Provider
Managed Tunnels",
draft-kuarsingh-v6ops-6to4-provider-managed-tunnel-03
(work in progress), September 2011.
[I-D.shirasaki-nat444]
Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J.,
and H. Ashida, "NAT444", draft-shirasaki-nat444-04 (work
in progress), July 2011.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
Weil, et al. Expires March 29, 2012 [Page 12]
Internet-Draft Shared CGN Space Request September 2011
RFC 3068, June 2001.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification",
RFC 5969, August 2010.
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
Roberts, "Issues with IP Address Sharing", RFC 6269,
June 2011.
[RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations",
RFC 6304, July 2011.
[RFC6319] Azinger, M. and L. Vegoda, "Issues Associated with
Designating Additional Private IPv4 Address Space",
RFC 6319, July 2011.
[RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment",
RFC 6343, August 2011.
[v6ops-msg06187]
WIDE, "Re: [v6ops] IETF 79 Meeting minutes - Draft",
Nov 2010, <http://www.ietf.org/mail-archive/web/v6ops/
current/msg06187.html>.
Weil, et al. Expires March 29, 2012 [Page 13]
Internet-Draft Shared CGN Space Request September 2011
Appendix A. Acknowledgments
Thanks to the following people (in alphabetical order) for their
guidance and feedback:
John Brzozowski
Isaiah Connell
Greg Davies
Kirk Erichsen
Wes George
Tony Hain
Philip Matthews
John Pomeroy
Barbara Stark
Jean-Francois Tremblay
Leo Vegoda
Steven Wright
Ikuhei Yamagata
Weil, et al. Expires March 29, 2012 [Page 14]
Internet-Draft Shared CGN Space Request September 2011
Authors' Addresses
Jason Weil
Time Warner Cable
13820 Sunrise Valley Drive
Herndon, VA 20171
USA
Email: jason.weil@twcable.com
Victor Kuarsingh
Rogers Communications
8200 Dixie Road
Brampton, ON L6T 0C1
Canada
Email: victor.kuarsingh@gmail.com
Chris Donley
CableLabs
858 Coal Creek Circle
Louisville, CO 80027
USA
Email: c.donley@cablelabs.com
Christopher Liljenstolpe
Telstra Corp
7/242 Exhibition Street
Melbourne, VIC 316
Australia
Phone: +61 3 8647 6389
Email: cdl@asgaard.org
Marla Azinger
Frontier Communications
Vancouver, WA
USA
Phone: +1.360.513.2293
Email: marla.azinger@frontiercorp.com
Weil, et al. Expires March 29, 2012 [Page 15]
