Network Working Group J. Weil
Internet-Draft Cox Communications
Intended status: Informational V. Kuarsingh
Expires: January 7, 2011 Rogers Communications
C. Donley
CableLabs
July 6, 2010
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
Weil, et al. Expires January 7, 2011 [Page 1]
Internet-Draft isp-v4-prefix July 2010
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. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Dual-Stack Home Gateway Transition Scenarios . . . . . . . . . 5
3.1. Legacy IPv4-only Home Gateway . . . . . . . . . . . . . . 5
3.2. Dual-Stack Home Gateway . . . . . . . . . . . . . . . . . 5
4. Transition Address Requirements . . . . . . . . . . . . . . . 6
4.1. Benefits of a Single Large Allocation . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Informative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Weil, et al. Expires January 7, 2011 [Page 2]
Internet-Draft isp-v4-prefix July 2010
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.
Weil, et al. Expires January 7, 2011 [Page 3]
Internet-Draft isp-v4-prefix July 2010
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] and Dual-Stack
Lite [I-D.ietf-softwire-dual-stack-lite].
Weil, et al. Expires January 7, 2011 [Page 4]
Internet-Draft isp-v4-prefix July 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]. 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, 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]. 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.
Weil, et al. Expires January 7, 2011 [Page 5]
Internet-Draft isp-v4-prefix July 2010
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]-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.
o 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].
o 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] space
should result in a net gain of available address public address
space.
o RFC1918 Overlap: Utilization of separate assignment can remove the
challenge of [RFC1918] address overlap between the home network
environment and the provider network.
o 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.
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.
Weil, et al. Expires January 7, 2011 [Page 6]
Internet-Draft isp-v4-prefix July 2010
o 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] space
within their network separately from the newly assigned ISP Shared
Space which may have different security and policy needs.
Weil, et al. Expires January 7, 2011 [Page 7]
Internet-Draft isp-v4-prefix July 2010
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.
Weil, et al. Expires January 7, 2011 [Page 8]
Internet-Draft isp-v4-prefix July 2010
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] in regards to IANA policy requirements.
Weil, et al. Expires January 7, 2011 [Page 9]
Internet-Draft isp-v4-prefix July 2010
7. Informative References
[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.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",
draft-ietf-softwire-dual-stack-lite-04 (work in progress),
March 2010.
[I-D.shirasaki-nat444]
Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J.,
and H. Ashida, "NAT444", draft-shirasaki-nat444-01 (work
in progress), March 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-03 (work in
progress), March 2010.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
Weil, et al. Expires January 7, 2011 [Page 10]
Internet-Draft isp-v4-prefix July 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 January 7, 2011 [Page 11]