<?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!ENTITY RFC1918 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5569 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5569.xml">
<!ENTITY I-D.ietf-softwire-dual-stack-lite SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-softwire-dual-stack-lite-06.xml'>
<!ENTITY I-D.azinger-additional-private-ipv4-space-issues SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-azinger-additional-private-ipv4-space-issues-04.xml'>
<!ENTITY I-D.ford-shared-addressing-issues SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ford-shared-addressing-issues-02.xml'>
<!ENTITY I-D.shirasaki-nat444-isp-shared-addr SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-shirasaki-nat444-isp-shared-addr-04.xml'>
<!ENTITY I-D.shirasaki-nat444 SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-shirasaki-nat444-02.xml'>
<!ENTITY I-D.fuller-240space SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-fuller-240space-02.xml'>
<!ENTITY I-D.wilson-class-e SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-wilson-class-e-02.xml'>
]>

<rfc category="info" ipr="trust200902" docName="draft-weil-opsawg-provider-address-space-02">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>

  <front>
	<title abbrev="IPv4-prefix-for-IPv6-Transition">
			   IANA Reserved IPv4 Prefix for IPv6 Transition                   
	</title>

	<author initials='J.W.' surname="Weil" fullname='Jason Weil'>
		<organization>Cox Communications</organization>
		<address>
			<postal>
				<street>1400 Lake Hearn Drive</street>
				<city>Atlanta</city> <region>GA</region> 
				<code>30319</code>
				<country>USA</country>
			</postal>
			<email>jason.weil@cox.com</email>
		</address>
	</author>
	
	<author initials='V.K.' surname="Kuarsingh" fullname='Victor Kuarsingh'>
		<organization>Rogers Communications</organization>
		<address>
			<postal>
				<street>8200 Dixie Road</street>
				<city>Brampton</city> <region>ON</region> 
				<code>L6T 0C1</code>
				<country>Canada</country>
			</postal>
			<email>victor.kuarsingh@rogers.com</email>
		</address>
	</author>
	
	<author initials='C.D.' surname="Donley" fullname='Chris Donley'>
		<organization>CableLabs</organization>
		<address>
			<postal>
				<street>858 Coal Creek Circle</street>
				<city>Louisville</city> <region>CO</region> 
				<code>80027</code>
				<country>USA</country>
			</postal>
			<email>c.donley@cablelabs.com</email>
		</address>
	</author>
	

	<date month="September" year="2010"/>
	
	<abstract>
	  <t>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.
</t>
	</abstract>
</front>

<middle>
    <section title="Introduction">
      <t>   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 <xref target="RFC1918"/> address space and can currently only obtain sufficient address space through allocations from RIRs.</t>
     <t>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.</t>
     <t>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.</t>
    </section>
    
      <section title="Requirements Language">
        <t>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 <xref
        target="RFC2119">RFC 2119</xref>.</t>
      </section>
      
    <section title="Motivation">
    <t>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.</t>
   <t>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.</t>
   <t>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 <xref target="I-D.shirasaki-nat444"/> and Dual-Stack
   Lite <xref target="I-D.ietf-softwire-dual-stack-lite"/>.</t>
   <t>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.</t>
   <t>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. </t>
  </section>
	<section title="Shared Transition Space">
 	<t>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.</t>
	<t>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.
	</t>
   <t>A single shared IP block would also provide a common way for <xref target="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.</t>
	</section>
    <section title="Dual-Stack Home Gateway Transition Scenarios">
	<t>This section details two use cases where different transition technologies require IPv4 address space to support home network services post IPv4 depletion.</t>
	<section title="Legacy IPv4-only Home Gateway">
		<t>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 <xref target="I-D.shirasaki-nat444"/>. The challenges associated with these deployments are identified in <xref target="I-D.shirasaki-nat444-isp-shared-addr"/> and <xref target="I-D.ford-shared-addressing-issues"/>.</t>
		<t> 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 <xref target="I-D.azinger-additional-private-ipv4-space-issues"/> as well as
		<xref target="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.</t>
		</section>
		<section title="Dual-Stack Home Gateway">
		<t>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 <xref target="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.</t>
		<t>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.</t>
   <t>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 <xref target="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.</t>
	</section>
    </section>
		<section title="Benefits of a Single Large Allocation">
		<t>There are a number of benefits related to the use of a single /8 assignment from the IANA free pool.</t>
		<t><list style="symbols">
			<t>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 <xref target="RFC1918"/>. </t>
			<t>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 <xref target="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.</t> 
			<t>RFC1918 Overlap: Utilization of separate assignment can remove the challenge of <xref target="RFC1918"/> address overlap between the customer network and the provider network.</t>
			<t>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.</t>
			<t>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.</t>
			<t>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 <xref target="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.</t>
		</list></t>
	</section>
	<section title="Problems using Future Use Space">
	  <t>
	  <xref target="I-D.fuller-240space"/> and <xref target="I-D.wilson-class-e"/> suggest that 240.0.0.0/4 space could be used as Shared Transition Space. However, as discussed in <xref target="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.
	  </t>
  </section>
    <section title="Security Considerations">
	<t>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.</t>
    </section>
    <section title="IANA Considerations">
	<t>IANA is asked to reserve an IPv4 /8 from its remaining pool of unallocated IPv4 addresses for use as Shared Transition Space.</t>

    </section>
</middle>


<back>

    <references title="Informative References">
    
	&RFC1918;
	&RFC2119;
	&RFC5569;
	&I-D.azinger-additional-private-ipv4-space-issues;
	&I-D.ford-shared-addressing-issues;
	&I-D.shirasaki-nat444-isp-shared-addr;
	&I-D.shirasaki-nat444;
	&I-D.ietf-softwire-dual-stack-lite;
	&I-D.fuller-240space;
	&I-D.wilson-class-e;
	   
	   <reference anchor="CISCO" target="http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cwhubs/starvwug/83428.htm#xtocid74886">
      <front>
         <title>TCP/IP Overview</title>
         <author fullname="Cisco"><organization>Cisco Systems</organization></author>
      </front>
      </reference>
      
    </references>
    	<section title="Acknowledgements">
    <t>Thanks to the following people (in alphabetical order) for their guidance and feedback:
      <list style="hanging">
		<t>John Brzozowski</t>
		<t>Isaiah Connell</t>
		<t>Greg Davies</t>
		<t>Kirk Erichsen</t>
		<t>Wes George</t>
		<t>Tony Hain</t>
		<t>Philip Matthews</t>
		<t>John Pomeroy</t>
		<t>Barbara Stark</t>
	  <t>Jean-Francois Tremblay</t>
		<t>Leo Vegoda</t>
		<t>Steven Wright</t>
    <t>Ikuhei Yamagata</t>

	</list></t>
	</section>
</back>
</rfc>
