IANA Reserved IPv4 Prefix for IPv6 Transition
draft-weil-opsawg-provider-address-space-02

Abstract

This document specifies the use of a reserved IANA IPv4 address allocation to support the deployment of IPv6 transition technologies and IPv4 address sharing technologies post IPv4 exhaustion. Service providers are in the process of implementing IPv6 support by providing dual-stack IPv4 and IPv6 services to their end-users. One method for continued support of the IPv4 Internet post IANA IPv4 depletion is through the use of a carrier-provided NAT444 infrastructure. Another mechanism used to transition to IPv6 is an IPv6-in-IPv4 tunnel such as IPv6 Rapid Deployment (6RD). This document details the use of an IANA reserved address block for these purposes.

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

Copyright Notice

Copyright (c) 2010 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 Transition Space
5.  Dual-Stack Home Gateway Transition Scenarios
    5.1.  Legacy IPv4-only Home Gateway
    5.2.  Dual-Stack Home Gateway
6.  Benefits of a Single Large Allocation
7.  Problems using Future Use Space
8.  Security Considerations
9.  IANA Considerations
10.  Informative References
Appendix A.  Acknowledgements
§  Authors' Addresses

1.  Introduction

The majority of large network service providers are in the process of transitioning from IPv4 to IPv6 in response to the upcoming depletion of the IPv4 address pool. For large networks, this transition represents a multi-year project that will impact services and sectors in the network at various stages in the plan. Many of the strategies for the transition, including dual-stack, encapsulation, and translation protocols, require a large amount of IPv4 addresses. These addresses are internal to the service provider network, and need not be globally routable. Deployment of such technologies becomes increasingly more challenging for providers to acquire sufficient address space the closer the IANA global pool nears depletion, and is compounded by the fact that a number of these providers have depleted the use of the Private [RFC1918] (Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, “Address Allocation for Private Internets,” February 1996.) address space and can currently only obtain sufficient address space through allocations from RIRs.

While it is tempting to tell such operators to accelerate their plans and simply switch to IPv6, such a strategy is not practical, since many applications, content sites, and devices do not currently support IPv6, and are unlikely to do so prior to IPv4 exhaustion. Thus, service providers require additional address space to facilitate the transition to IPv6 while maintaining support for IPv4.

As IANA depletion is expected in early 2011, it is imperative that address space requirements for these transition strategies is reserved quickly for this purpose. This document requests that IANA reserve a portion of the remaining unallocated space as Shared Transition Space for the enablement of a clean transition strategy in large networks.

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

3.  Motivation

The Internet community is rapidly consuming the remaining supply of unallocated IPv4 addresses. At current projections, IANA will completely allocate its IPv4 address space during the second quarter of 2011. The solution to this IPv4 address consumption is to migrate Internet traffic to IPv6. However, during the transition to IPv6, it is imperative that Service Providers maintain IPv4 service for devices and networks that are incapable of upgrading to IPv6.

Mobile data access networks also have large sums of GPRS (2G) and UMTS (3G) UEs which have limited or no support of IPv6 operation. Although mobile data equipment is refreshed on a higher frequency then Wireline counterparts, many handsets and other mobile service termination equipment will remain IPv4 only for a long period of time. Even with the operators? best intentions, support for Roaming (visitor equipment) will demand continued support for IPv4 unti worldwide adoption reaches a certain threshold.

In order to provide IPv4 service to new customers and/or devices once the IPv4 address space is exhausted, Service Providers must multiplex several subscribers behind a single IPv4 address using one of several techniques including NAT444 [I‑D.shirasaki‑nat444] (Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., and H. Ashida, “NAT444,” July 2010.) and Dual-Stack Lite [I‑D.ietf‑softwire‑dual‑stack‑lite] (Durand, A., Droms, R., Woodyatt, J., and Y. Lee, “Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion,” August 2010.).

Deploying IPv6 into service provider core and metro networks is straightforward, and is progressing rapidly. The hardware that exists in this portion of the network generally requires new software only to route and forward both IPv4 and IPv6 datagrams. Moving outward from the core towards the edges of the network, hardware resources available tend to diminish relative to the expected forwarding capacity.

In broadband access provider networks, the move towards the edge of the network results in reduced hardware resources and less capability in the core. These changes are significant when looking beyond the edge aggregation layer and into the residential subscriber's home network. In this environment, hosts and CPE routers tend to be purpose built for efficiency, cost, and ease of use. Such devices have been optimized for IPv4 operation, and typically do not support IPv6. Furthermore, such home gateway router devices typically require replacement in order to fully support the transition to IPv6. The home gateway is a critical segment for any migration strategy. This device must implement a dual-stack environment facing the home LAN in order to enable IPv6 in the home. In addition, various consumer devices including IP- enabled televisions, gaming consoles, medical and family monitoring devices, etc. are IPv4-only, and cannot be upgraded. While these will eventually be replaced with dual-stack or IPv6 capable devices, this transition will take many years. As these are typically consumer-owned devices, service providers do not have control over the speed of their replacement cycle. However, consumers have an expectation that they will continue to receive IPv4 service, and that such devices will continue to have IPv4 Internet connectivity after the IPv4 pool is exhausted, even if the customer contracts for new service with a new provider.

4.  Shared Transition Space

This document proposes the assignment of a single /8 CIDR block as Shared Transition Space. Shared Transition Space is IPv4 address space reserved for Service Provider or large enterprise use with the purpose of facilitating IPv6 transition and IPv4 coexistence deployment. This space SHOULD only be used for the purpose of providing NAT'ed IPv4 access to subscriber networks or IPv6-in-IPv4 tunnels during the transition to full IPv6 deployment. These addresses MAY be used without any coordination with IANA or any other Internet registry. It is RECOMMENDED that they not be used to address LANs used by subscriber networks. It is RECOMMENDED that equipment vendors not use these addresses in the default configuration for CPEs. A single allocation that addresses all of the detailed Home Gateway transition scenarios presented in this document offers maximum utilization and flexibility to the Internet community.

Because Shared Transition addresses have no meaning outside of the Service Provider, routing information about shared transition space networks MUST NOT be propagated on Internet links, and packets with shared transition source or destination addresses SHOULD NOT be forwarded across such links. Internet service providers are expected filter out routing information about shared transition space networks on ingress links.

A single shared IP block would also provide a common way for [RFC1918] (Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, “Address Allocation for Private Internets,” February 1996.)-constrained environments to support IPv6 transition technologies without the need to select IP address space which is not assigned to them ("address squatting") or implement complex overlapping strategies that inevitably impacts customer connectivity and performance.

5.  Dual-Stack Home Gateway Transition Scenarios

This section details two use cases where different transition technologies require IPv4 address space to support home network services post IPv4 depletion.

5.1.  Legacy IPv4-only Home Gateway

In this model, the home gateway is unable to support dual-stack operation due to some combination of insufficient memory, processing power, or other operational limitations such as lack of vendor support. Also, many devices in the home will only support the IPv4 protocol. Until such customers replace their Home Gateways and all IPv4-only CPE devices with IPv6-capable devices Service Providers will be required to continue to offer IPv4 services through the use of an IPv4 address sharing technology such as NAT444, as described in [I‑D.shirasaki‑nat444] (Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., and H. Ashida, “NAT444,” July 2010.). The challenges associated with these deployments are identified in [I‑D.shirasaki‑nat444‑isp‑shared‑addr] (Shirasaki, Y., Miyakawa, S., Nakagawa, A., Yamaguchi, J., and H. Ashida, “NAT444 addressing models,” July 2010.) and [I‑D.ford‑shared‑addressing‑issues] (Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, “Issues with IP Address Sharing,” March 2010.).

Addressing solutions for dealing with the depletion of the IPv4 public address space and the lack of available private addresses within large providers are presented in [I‑D.azinger‑additional‑private‑ipv4‑space‑issues] (Azinger, M. and L. Vegoda, “Additional Private IPv4 Space Issues,” April 2010.) as well as [I‑D.shirasaki‑nat444‑isp‑shared‑addr] (Shirasaki, Y., Miyakawa, S., Nakagawa, A., Yamaguchi, J., and H. Ashida, “NAT444 addressing models,” July 2010.). For larger Service Providers who require more than the 16 million Net-10 addresses, or who have already assigned Net-10 addresses in their networks, the preferred method for addressing the problems presented in both draft documents is to direct IANA to reserve a /8 from its unassigned IPv4 address pool for Shared Transition Space.

5.2.  Dual-Stack Home Gateway

In this model, the Home Gateway supports dual-stack operation natively on the LAN interface. The Home Gateway may also support Dual-stack on the WAN interface, or alternatively could deploy native IPv6 service and tunnel IPv4 traffic over IPv6 using methods specified in [I‑D.ietf‑softwire‑dual‑stack‑lite] (Durand, A., Droms, R., Woodyatt, J., and Y. Lee, “Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion,” August 2010.). To maintain IPv4 operation on the WAN interface post IPv4 depletion, a CGN technology is required to offer NAT service, one within the Home Gateway and the other within the provider's network. The tunneling approach has the potential benefit of removing the Home Gateway NAT, but still relies on the service provider NAT.

Regardless of deployment model chosen, the deployment of the NAT will require new IPv4 public addressing. The preferred method for addressing either of the dual-stack Home Gateway models would be a unique IPv4 reservation of shared transition space from the IANA unassigned pool.

In some cases, due to limited equipment capabilities, budget, or deployment considerations, the service provider will not be able to enable native IPv6 on the access network prior to IPv4 depletion, and will need to use an IPv6-in-IPv4 encapsulation technology such as 6RD [RFC5569] (Despres, R., “IPv6 Rapid Deployment on IPv4 Infrastructures (6rd),” January 2010.) to offer IPv6 services. Such technologies require IPv4 address space between the dual-stack Home Gateway and the 6RD Border Relay. This IPv4 address space does not need to be globally-routable. As with the previous case, the preferred solution is to use IANA-reserved shared transition space to support 6RD deployments.

6.  Benefits of a Single Large Allocation

There are a number of benefits related to the use of a single /8 assignment from the IANA free pool.

• Flexibility: Allocating a /8 address pool as shared transition space allows flexibility in the type of transition mechanisms that can be deployed by Service Providers. Providers can expand the number of addresses available for transition technology deployment beyond those provided in [RFC1918] (Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, “Address Allocation for Private Internets,” February 1996.).
• Efficiency: A Number of large and mid-sized providers are actively analyzing the use of Carrier Network Address Translators. The demand for public IPv4 address space needed to number these carrier address realms for large providers who lack enough [RFC1918] (Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, “Address Allocation for Private Internets,” February 1996.) space exceeds the available supply. Reserving such space as Shared Transition Space should reduce the demand for public IPv4 space by Service Providers, and result in a net gain of available public IPv4 address space.
• RFC1918 Overlap: Utilization of separate assignment can remove the challenge of [RFC1918] (Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, “Address Allocation for Private Internets,” February 1996.) address overlap between the customer network and the provider network.
• Removes need for bogon space or IPv4 squatting: Providers can avoid the use of bogon and/or squatted space within their networks. This type of address usage can cause connectivity problems for customers and can be difficult to diagnose.
• Clear IP allocation for IPv6 transition technologies: A block reserved for transition usage can be well defined and provide best practices for transition technology deployment.
• Security: It is easier and more secure to build security polices for larger address blocks, rather than multiple smaller blocks. Larger blocks minimize the number of firewall rules or access list statements required to implement such a policy, and thereby reduce the number of errors. This results in better customer Internet experiences. In addition, service providers can filter [RFC1918] (Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, “Address Allocation for Private Internets,” February 1996.) space at the edge of their network, and creating separate policies for shared transition space, which ought to only be deployed between the customer premise router and the service provider NAT/Border Relay.

7.  Problems using Future Use Space

[I‑D.fuller‑240space] (Fuller, V., “Reclassifying 240/4 as usable unicast address space,” March 2008.) and [I‑D.wilson‑class‑e] (Wilson, P., Michaelson, G., and G. Huston, “Redesignation of 240/4 from "Future Use" to "Private Use",” September 2008.) suggest that 240.0.0.0/4 space could be used as Shared Transition Space. However, as discussed in [I‑D.azinger‑additional‑private‑ipv4‑space‑issues] (Azinger, M. and L. Vegoda, “Additional Private IPv4 Space Issues,” April 2010.), some existing network equipment does not support addresses in the 240.0.0.0/4 range. In particular, [CISCO] states that "no addresses are allowed with the highest-order bits set to 1111". It is likely that many home routers will not support this range, either. In order use this range, equipment vendors would need to update software code for existing routers and end users would need to upgrade their home devices. As many older home routers do not support automatic updates, it is unlikely that enough end users would upgrade to make the 240.0.0.0/4 range viable for Shared Transition Space use.

8.  Security Considerations

This memo does not define any protocol, and raises no security issues. Any /8 allocated for ISP use would not be routable on the Internet.

9.  IANA Considerations

IANA is asked to reserve an IPv4 /8 from its remaining pool of unallocated IPv4 addresses for use as Shared Transition Space.

10. Informative References

Appendix A.  Acknowledgements

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