[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/