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 (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
• 2. Requirements Language
• 3. Motivation
• 4. Shared CGN Space
• 4.1. Address-Based Scope Detection
• 5. Alternatives
• 5.1. RFC1918 Space
• 5.2. Globally Unique Space
• 6. Security Considerations
• 7. IANA Considerations
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Appendix A. Acknowledgments
• Authors' Addresses

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.

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

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

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

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.

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.

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

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]

8. References

8.1. Normative References

8.2. Informative References

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

Authors' Addresses