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, . 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]