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

Abstract

This document specifies the use of a Reserved IANA allocation for the purpose of dual-stack deployment 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. This document details the use of an IANA reserved block for this purpose.

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 January 7, 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.  Motivation
3.  Dual-Stack Home Gateway Transition Scenarios
    3.1.  Legacy IPv4-only Home Gateway
    3.2.  Dual-Stack Home Gateway
4.  Transition Address Requirements
    4.1.  Benefits of a Single Large Allocation
5.  Security Considerations
6.  IANA Considerations
7.  Informative References
§  Authors' Addresses

1.  Introduction

The majority of large network service providers are planning or are in the process of transitioning from IPv4 to IPv6 in repines 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 and a number of translation protocols require a large amount of dedicated or private IPv4 addresses for effective deployment in larger provider networks. This becomes increasingly more challenging the closer the IANA global pool nears depletion, as is compounded by the fact that a number of these providers are nearing or have depleted the use of the Private RFC1918 address space.

It is imperative that address space requirements for these transition strategies is reserved quickly for this purpose. This document specifies a requirement to IANA to reserve a portion of the remaining unallocated space to for the enablement of a clean transition strategy in large service provider networks.

2.  Motivation

Deploying IPv6 into service provider core and metro networks is a fairly straightforward task. 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 far edge results in reduced hardware resources and less capability in the operating environments. 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. Devices functioning in the home gateway router role 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 support the various entertainment devices including IP enabled televisions, gaming consoles, medical and family monitoring devices among many others that will remain IPv4-only. While these will eventually be replaced with dual-stack or IPv6 capable devices; this transition will take many years.

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 until 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,” March 2010.) and Dual-Stack Lite [I‑D.ietf‑softwire‑dual‑stack‑lite] (Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee, Y., and R. Bush, “Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion,” March 2010.).

3.  Dual-Stack Home Gateway Transition Scenarios

This section details two use cases that require different technologies to address the support of the home network post IPv4 depletion.

3.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. There are only two options in this model: replace the Home Gateway and IPv4-only CPE devices or continue to offer IPv4-only 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,” March 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,” March 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,” March 2010.). For larger Service Providers who require more than the 16 million Net-10 addresses, 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.

3.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., Haberman, B., Woodyatt, J., Lee, Y., and R. Bush, “Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion,” March 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 allocation out of the IANA unassigned pool.

4.  Transition Address Requirements

This document proposes the assignment of a single /8 CIDR block for use within large serve providers and large enterprises to enable an effective transition plan. 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.

A single common 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 which inevitably impacts customer connectivity and performance.

4.1.  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 Private Use allows flexibility in the type of transition mechanisms that can be deployed by Service Providers. Providers can expand the number of addresses available for internal network use 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 amount of 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 should result in a net gain of available address public 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 home network environment and the provider network.
• Removes need to use bogon/non-assigned Space: Providers can avoid the use of bogon and/or non-assigned space (to the local party) within their networks. This type of address usage can be problematic to customers.
• 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: Providers avoid the need to utilize smaller IP address space segments. Single, large blocks are easier to build security polices around and result in better customer Internet experiences. The provider can also treat long standing assigned [RFC1918] (Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, “Address Allocation for Private Internets,” February 1996.) space within their network separately from the newly assigned ISP Shared Space which may have different security and policy needs.

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

6.  IANA Considerations

IANA is asked to reserve a /8 from its remaining pool of unallocated IPv4 addresses for use by large service providers for NAT444 address sharing. This allocation exhibits the characteristics of Private Use as described in [RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) in regards to IANA policy requirements.

7. Informative References

Authors' Addresses