One document matched: draft-durand-v6ops-natv4v6v4-01.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-durand-v6ops-natv4v6v4-01" ipr="full3978">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="Abbreviated Title">Distributed NAT for broadband deployments post IPv4 exhaustion</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Alain Durand" initials="A.D." role=""
            surname="Durand">
      <organization>Comcast</organization>

      <address>
        <postal>
          <street>1500 Market st</street>

          <!-- Reorder these if your country does things differently -->

          <city>Philadelphia</city>

          <region>PA</region>

          <code>19102</code>

          <country>USA</country>
        </postal>


        <email>alain_durand@cable.comcast.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date month="February" year="2008" />

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>NAT</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>      The common thinking for the last 10+ years has been to say that dual stack was the answer to IPv6 transition and that most things would be converted to dual stack way before we ran out of IPv4.

Well, it has not happened. We are going to run out of IPv4 addresses soon, way before any significant IPv6 deployment will have occured. However, the quasi totality of the Internet and most of the computers in the home are still IPv4-only.  Several distributed NAT architectures, based on different possible flavors of a carrier-grade NAT, are presented as solutions to maintain some form of connectivity between those home environments and the legacy Internet.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>This memo will present a service provider view on deployments post IPv4 exhaustion and some of the necessary technologies to 
      achieve it.</t>

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

   <section title="IPv4 exhaustion coming sooner than expected">
<t>   Global public IPv4 addresses coming from the IANA free pool are running out faster than predicted a few years ago. The current model shows that exhaustion could happen as early as 2010. See http://ipv4.potaroo.net for more details.
Those projection are based on the assumption that tomorrow is going to be very similar to today, ie looking at recent address consumption figures is a good indicator of future consumption patterns. This of course, does not take into account any new large scale deployment of IP technology or any human reaction when facing an upcoming shortage. </t>

<t>
The prediction of the exact date of exhaustion of the IANA free pool is outside the scope of this document, however one conclusion must be drawn from that study: there will be in the near future a point where new global public IPv4 addresses will not be available and thus any new broadband deployment may have to consider the option of not provisioning any (global) IPv4 addresses to the WAN facing interface of edge devices. The classic IPv6 deployment model known as "dual stack" can be a non starter in such environments. </t>
   </section>

   <section title="Handling the legacy">
   <section title="Legacy edges of the Internet for broadband customers">
<t>
  Broadband customers have a mix and match of IP enable devices at home. 
  The most recent operating systems (eg Windows Vista or MacOS-X) can operate in an IPv6-only environment, however most of the legacy one can't. It has been reported, for example, that windows XP cannot process DNS requests over IPv6 transport. Expecting broadband customers to massively upgrade their software (and in most cases the corresponding hardware) to deploy IPv6 is a very tall order. </t>
   </section>

   <section title="Content and Services available on the Internet">
<t>
   IPv6 deployment has been very long to take off, so the current situation is that almost none of the content and services available on the Internet are accessible over IPv6. This will probably change in the future, but for now, one has to make the assumption that most of the traffic generated by (and to) broadband customers will be sent to (and originated by) IPv4 nodes. </t>
   </section>

   <section title="Burden on service providers">
<t>
  As a conclusion, broadband service providers may be faced with the situation where they have IPv4 customers willing to communicate with IPv4 servers on the Internet but may not have any IPv4 addresses left to assign to them... </t>
   </section>

   </section>

   <section title="Solution space">
  <t>A number of solutions can be studied: IPv6-only, double IPv4>IPv4->IPv4 NAT, double IPv4->IPv6->IPv4 NAT, and IPv4 over IPv6 tunneling plus carrier grade IPv4->IPv4 NAT. All of them are essentially a variation on the theme of a distributed NAT where instead of provisioning each broadband customer with a unique global IPv4 address, global IPv4 addresses are share among broadband customers. </t>

   <section title="IPv6-only">
   <t>
   The first solution that comes to mind is to simply provision new broadband customers with only IPv6 addresses. However, two immediate issues come to mind: </t>
  <t><list style="letters">
  <t>Legacy devices in the customer home will not be able to communicate with the outside.</t>
  <t>New IPv6-only capable devices will not be able to communicate with legacy IPv4-only servers in the Internet.</t>
  </list>
   </t>
   </section>

   <section title="Double IPv4->IPv4->IPv4 NAT">
   <t>This solution consists of provisioning broadband customers with a private [RFC1918] address on the WAN side of the home gateway, and then translate this private IPv4 address somewhere within the service provider network by a carrier grade NAT into a global IPv4 address.
Devices behind the home gateway will then be translated twice, once by the home gateway itself, and another time by the NAT within the service provider. </t>

<t>
This solution has the advantage of being simple to understand and is the easiest to deploy in the home. It has however a number of drawbacks. </t>

<t>
The first drawback is that some applications may have a more difficult time going through the two levels of NAT. Application relying on port mapping or port opening using UPnP may not work as expected as the carrier grade NAT may not allow those NAT traversal techniques. Note that this drawback is not specific to this solution, it is tied to the presence of a carrier-grade NAT in the architecture. </t>

<t>Another drawback is that this solution limits the number of customer within an access network to the size of net 10, ie somewhere between 10 and 16 million depending on address efficiency. Note that very large networks such as Comcast have already ran out of RFC1918 space a few years ago. A possible way to get around this problem is for the service provider to run several instances of net 10, one per "regional area". However, there are serious operational issues with this, especially if the service provider is running a unified backbone and a unified set of services.</t>

<t>
A third drawback of this solution is that it can potentially create a conflict on the home gateway if the same variant of RFC1918 space is used on the WAN port and the LAN port. For example, if both the WAN port and the LAN port are configured with 10.0.0.1/24, some NAT implementations may get confused.
</t>
</section>

  <section title="Double IPv4->IPv6->IPv4 NAT">
  <t>
  When private address space is running out and/or the service provider does not want to run multiple copies of net 10, the next step is to to provision the home gateway only with an IPv6 address and associated prefix and let that home gateway translate internal RFC1918 space into global IPv6 addresses. However, as the final destination may not be configured to accept IPv6 connections, those packets will have to be translated a second time into IPv4 packets.</t>

<t>
The first translation hapening in the home gateway can be very straightforward and in most cases stateless. This consists in header swapping and embedding the source & destination IPv4 addresses within source & destination IPv6 addresses. The prefix used to embed the source address can be any sub-prefix of the one delegated to the home gateway. The prefix used to embed the destination address is used to route the IPv6 packets to the local farm of IPv6->IPv4 translator within the service provider network. The discovery of that second prefix by the home gateway can be achive in many ways, for example through a DHCPv6 option yet to be defined.</t>

<t>
 The second translation will have to occur within the service provider network in a carrier-grade IPv6->IPv4 NAT. This translation is a traditional NAT that requires keeping track of IP addresses and port numbers allocated.
  </t>

 <t>
 The implications of this second level of translation are very similar to those in the model above of a double IPv4->IPv4->IPv4 translation. There will be a need for a farm of translators within the service provider network operating at line speed. Some applications may have a harder time working through the carrier-grade NAT. On top of that, some MTU adaptation will have to take place to accommodate for the longer IPv6 header.
 </t>

<t>
Another issue with this approach is the role of ALGs. Although IPv4->IPv4 ALGs are now fairly well understood, there is little experience with IPv4->IPv6 or IPv6->IPv4 ALGs. One of the questions raised is, should the first home NAT, translating from IPv4 to IPv6, also use IPv4->IPv6 ALGs to translate the payload addresses to IPv6, or should it leave them in IPv4 format, knowing that the carrier-grade NAT will anyway translate them back to IPv4?
</t>
  </section>

  <section title="IPv6 Tunneling plus carrier-grade IPv4->IPv4 NAT">
  <t>
  When IPv6-only connectivity is offered to the customer, one can look at IPv4 over IPv6 tunnels
  to re-establish connectivity for the legacy IPv4 hosts. The Softwire hub and spoke solution, based on L2TP tunnels
  could be the perfect candidate in that space.
  </t>

  <t>The caveat is that this technique alone is not enough, the service provider still needs to assign one IPv4 address per customer. One need to collocate a carrier-grade NAT with the tunnel concentrator within the service provider. In that solution, the IPv4 private addresses generated inside of the customer network would be transported (and not translated) within IPv6 packets across the service provider network to be decapsulated and then translated IPv4->IPv4 by the combined tunnel concentrator/carrier-grade NAT.</t>

<t>Note that, as in the above solutions, the presence of a carrier-grade NAT will break some NAT traversal techniques</t>
  </section>
   </section>

<section title="Carrier-grade NAT considerations">

<t>One constant element in the architecture of all the above solution is the presence of a carrier-grade NAT, either IPv4->IPv4 or IPv6->IPv4. As some traditional NAT traversal techniques will stop working, this will have consequences on the set of applications that can be run in IPv4 mode.</t>

<t>Also, because IPv4 addresses will be share among customers and potentially a large address space reduction factor may be applied, in average, only a limited number of TCP or UDP port numbers will be available per customer. This means that applications opening a very large number of TCP ports may have a harder time to work. For example, it has been reported that a very well know web site was using AJAX techniques and was opening up to 69 TCP ports per web page... If we make the hypothesis of an address space reduction of a factor 100 (one IPv4 address per 100 customers), a home with 10 PCs, and 65k ports per IPv4 addresses available, that makes a total of 65 ports available simultaneously for each PC, which is right on the edge of the number reported above for that well known application...</t>
</section>


<section title="Standardization considerations">
<t>
Any of the above solution could work. The double NAT IPv4>IPv4->IPv4 does not require any standard effort nor any new code in order to be deployed. However, dealing with multiple copies of net 10 may be a show stopper for large service providers, as the opex associated may be high. Both the double NAT IPv4->IPv6->IPv4 and IPv6 tunneling plus carrier-grade IPv4->IPv4 NAT may require some new code in the home gateways. Thus some standardization on a framework how to use these techniques is required. </t>
</section>

<section title="Multicast considerations">
<t>
This document only describes unicast IPv4. Some multicast IPv4 considerations need to be discussed as well. This section is a placeholder.
</t>
</section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>Send the author comments if you want your name listed here.
      </t>

    </section>


    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>

      <t>This draft does not request any IANA action.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Security issues associated with NAT have long been documented. A future version of this document may include some references here to previous work.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
      <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
      &RFC2119;

    </references>



  </back>
</rfc>