Network Working Group J. Weil
Internet-Draft Cox Communications
Intended status: Informational V. Kuarsingh
Expires: March 27, 2011 Rogers Communications
C. Donley
CableLabs
September 23, 2010
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 27, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Weil, et al. Expires March 27, 2011 [Page 1]
Internet-Draft IPv4-prefix-for-IPv6-Transition September 2010
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Shared Transition Space . . . . . . . . . . . . . . . . . . . 7
5. Dual-Stack Home Gateway Transition Scenarios . . . . . . . . . 8
5.1. Legacy IPv4-only Home Gateway . . . . . . . . . . . . . . 8
5.2. Dual-Stack Home Gateway . . . . . . . . . . . . . . . . . 8
6. Benefits of a Single Large Allocation . . . . . . . . . . . . 10
7. Problems using Future Use Space . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Informative References . . . . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Weil, et al. Expires March 27, 2011 [Page 2]
Internet-Draft IPv4-prefix-for-IPv6-Transition September 2010
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] 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.
Weil, et al. Expires March 27, 2011 [Page 3]
Internet-Draft IPv4-prefix-for-IPv6-Transition September 2010
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 27, 2011 [Page 4]
Internet-Draft IPv4-prefix-for-IPv6-Transition September 2010
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] and Dual-Stack
Lite [I-D.ietf-softwire-dual-stack-lite].
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
Weil, et al. Expires March 27, 2011 [Page 5]
Internet-Draft IPv4-prefix-for-IPv6-Transition September 2010
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.
Weil, et al. Expires March 27, 2011 [Page 6]
Internet-Draft IPv4-prefix-for-IPv6-Transition September 2010
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]-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.
Weil, et al. Expires March 27, 2011 [Page 7]
Internet-Draft IPv4-prefix-for-IPv6-Transition September 2010
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]. The challenges associated with these
deployments are identified in [I-D.shirasaki-nat444-isp-shared-addr]
and [I-D.ford-shared-addressing-issues].
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] as well as
[I-D.shirasaki-nat444-isp-shared-addr]. 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]. 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
Weil, et al. Expires March 27, 2011 [Page 8]
Internet-Draft IPv4-prefix-for-IPv6-Transition September 2010
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] 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.
Weil, et al. Expires March 27, 2011 [Page 9]
Internet-Draft IPv4-prefix-for-IPv6-Transition September 2010
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.
o 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].
o 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] 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.
o RFC1918 Overlap: Utilization of separate assignment can remove the
challenge of [RFC1918] address overlap between the customer
network and the provider network.
o 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.
o 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.
o 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]
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.
Weil, et al. Expires March 27, 2011 [Page 10]
Internet-Draft IPv4-prefix-for-IPv6-Transition September 2010
7. Problems using Future Use Space
[I-D.fuller-240space] and [I-D.wilson-class-e] 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],
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.
Weil, et al. Expires March 27, 2011 [Page 11]
Internet-Draft IPv4-prefix-for-IPv6-Transition September 2010
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.
Weil, et al. Expires March 27, 2011 [Page 12]
Internet-Draft IPv4-prefix-for-IPv6-Transition September 2010
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.
Weil, et al. Expires March 27, 2011 [Page 13]
Internet-Draft IPv4-prefix-for-IPv6-Transition September 2010
10. Informative References
[CISCO] Cisco Systems, "TCP/IP Overview", <http://www.cisco.com/
univercd/cc/td/doc/product/rtrmgmt/cwhubs/starvwug/
83428.htm#xtocid74886>.
[I-D.azinger-additional-private-ipv4-space-issues]
Azinger, M. and L. Vegoda, "Additional Private IPv4 Space
Issues",
draft-azinger-additional-private-ipv4-space-issues-04
(work in progress), April 2010.
[I-D.ford-shared-addressing-issues]
Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
Roberts, "Issues with IP Address Sharing",
draft-ford-shared-addressing-issues-02 (work in progress),
March 2010.
[I-D.fuller-240space]
Fuller, V., "Reclassifying 240/4 as usable unicast address
space", draft-fuller-240space-02 (work in progress),
March 2008.
[I-D.ietf-softwire-dual-stack-lite]
Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work
in progress), August 2010.
[I-D.shirasaki-nat444]
Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J.,
and H. Ashida, "NAT444", draft-shirasaki-nat444-02 (work
in progress), July 2010.
[I-D.shirasaki-nat444-isp-shared-addr]
Shirasaki, Y., Miyakawa, S., Nakagawa, A., Yamaguchi, J.,
and H. Ashida, "NAT444 addressing models",
draft-shirasaki-nat444-isp-shared-addr-04 (work in
progress), July 2010.
[I-D.wilson-class-e]
Wilson, P., Michaelson, G., and G. Huston, "Redesignation
of 240/4 from "Future Use" to "Private Use"",
draft-wilson-class-e-02 (work in progress),
September 2008.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
Weil, et al. Expires March 27, 2011 [Page 14]
Internet-Draft IPv4-prefix-for-IPv6-Transition September 2010
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.
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd)", RFC 5569, January 2010.
Weil, et al. Expires March 27, 2011 [Page 15]
Internet-Draft IPv4-prefix-for-IPv6-Transition September 2010
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
Weil, et al. Expires March 27, 2011 [Page 16]
Internet-Draft IPv4-prefix-for-IPv6-Transition September 2010
Authors' Addresses
Jason Weil
Cox Communications
1400 Lake Hearn Drive
Atlanta, GA 30319
USA
Email: jason.weil@cox.com
Victor Kuarsingh
Rogers Communications
8200 Dixie Road
Brampton, ON L6T 0C1
Canada
Email: victor.kuarsingh@rogers.com
Chris Donley
CableLabs
858 Coal Creek Circle
Louisville, CO 80027
USA
Email: c.donley@cablelabs.com
Weil, et al. Expires March 27, 2011 [Page 17]