One document matched: draft-arkko-dual-stack-extra-lite-02.xml

<?xml version="1.0" encoding="iso-8859-1" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<rfc ipr="trust200902"
     docName="draft-arkko-dual-stack-extra-lite-02"
     category="std">

<?rfc toc="no"?> <?rfc symrefs="yes"?> <?rfc autobreaks="yes"?>
<?rfc tocindent="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?>

<front>

<title abbrev="Scalable NATs">Scalable Operation of Address Translators with Per-Interface Bindings</title>

<author initials="J" surname="Arkko" fullname="Jari Arkko">
<organization>Ericsson</organization>
<address>
<postal>
<street/>
<city>Jorvas</city> <code>02420</code>
<country>Finland</country>
</postal>
<email>jari.arkko@piuha.net</email>
</address>
</author>

<author fullname="Lars Eggert" initials="L." surname="Eggert">
      <organization abbrev="Nokia">Nokia Research Center</organization>
      <address>
        <postal>
          <street>P.O. Box 407</street>
          <code>00045</code>
          <city>Nokia Group</city>
          <country>Finland</country>
        </postal>
        <phone>+358 50 48 24461</phone>
        <email>lars.eggert@nokia.com</email>
        <uri>http://research.nokia.com/people/lars_eggert/</uri>
      </address>
    </author>

<date month="October" year="2010" />

<keyword>NAT</keyword>
<keyword>IPv4</keyword>
<keyword>IPv6</keyword>

<abstract>
<t>This document explains how to employ address translation in
networks that serve a large number of individual customers without
requiring a correspondingly large amount of private IPv4 address
space.</t>
</abstract>

</front>
<middle>

<section anchor="intro" title="Introduction">

   <t>This document explains how to employ address translation without
   consuming a large amount of private address space.  This is
   important in networks that serve a large number of individual
   customers.  Networks that serve more than 2^24 (16 million) users
   cannot assign a unique private IPv4 address to each user, because
   the largest reserved private address block reserved is 10/8
   <xref target="RFC1918"/>. Many networks are already hitting these
   limits today, for instance, in the consumer Internet service
   market.  Even some individual devices may approach these limits,
   for instance, cellular network gateways or mobile IP home
   agents.</t>

   <t>If ample IPv4 address space was available, this would be a
   non-issue, because the current practice of assigning public IPv4
   addresses to each user would remain viable, and the complications
   associated with using the more limited private address space could
   be avoided. However, as the IPv4 address pool is becoming depleted,
   this practice is becoming increasingly difficult to sustain.</t>
   
   <t>It has been suggested that more of the unassigned IPv4 space
   should be converted for private use, in order to allow the
   provisioning of larger networks with private IPv4 address space. At
   the time of writing, the IANA "free pool" contained only 12
   unallocated unicast IPv4 /8 prefixes.  Although reserving a few of
   those for private use would create some breathing room for such
   deployments, it would not result in a solution with long-term
   viability, would result in significant operational and management
   overheads, and would further reduce the number of available IPv4
   addresses.</t>
   
   <t>Segmenting a network into areas of overlapping private address
   space is another possible technique, but it severely complicates
   the design and operation of a network.</t>
   
   <t>Finally, the transition to IPv6 will eventually eliminate these
   addressing limitations.  However, during the migration period when IPv4
   and IPv6 have to co-exist, there will be the need to reach IPv4
   destinations, which involves the use of address or protocol translation.</t>

   <t>The rest of this document is organized as
  follows. <xref target="outline"/> gives an outline of the solution,
  <xref target="terms"/> introduces some terms,
  <xref target="bindings"/> specifies the required behavior for
  managing NAT bindings and <xref target="ipv6"/> discusses the use of
  this technique with IPv6.</t>

</section>

<section anchor="outline" title="Solution Outline">

   <t>The need for address or protocol translation during the
   migration period to IPv6 creates the opportunity to deploy these
   mechanisms in a way that allows the support of a large user base
   without the need for a correspondingly large IPv4 address
   block.</t>

   <t>A Network Address Translator (NAT) is typically configured to connect
   a network domain that uses private IPv4 addresses to the public
   Internet. The NAT device - which is configured with a public IPv4 address -
   creates and maintains a mapping for each communication session from a device
   inside the domain it serves to devices in the public Internet. It does that
   by translating the packet flow of each session such that the externally
   visible traffic uses only public addresses.</t>
   
   <t>In most NAT deployments, the network domain connected by the NAT to the
   public Internet is a broadcast network sharing the same media, where each
   individual device must have a unique IPv4 address. In such deployments it is
   natural to also implement the NAT functionality such that it uses this
   unique IPv4 address when looking up which mapping should be used to
   translate a given communication session.</t>

   <t>It is important to note, however, that this is not an inherent requirement.
   When other methods of identifying the correct mapping are available,
   and the NAT is not connecting a shared-media broadcast network to the
   Internet, there is no need to assign each device in the domain a unique IPv4
   address.</t>
   
   <t>This is the case, for example, when the NAT connects devices to the Internet
   that connect to it with individual point-to-point links.  In this case, it
   becomes possible to use the same private addresses many times, making
   it possible to support any number of devices behind a NAT using very few
   IPv4 addresses.</t>

   <t>There are tunneling-based techniques to reach the same benefits,
   by establishing new tunnels over any IP network
   <xref target="I-D.ietf-softwire-dual-stack-lite"/>.  However, where
   the point-to- point links already exists, creating an additional
   layer of tunneling is unnecessary (and even potentially harmful due
   to effects to the Maximum Transfer Unit) MTU settings). The
   approach described in this document can be implemented and deployed
   within a single device and has no effect to hosts behind it.  In
   addition, as no additional layers of tunneling are introduced,
   there is no effect to the MTU. It is also unnecessary to implement
   tunnel endpoint discovery, security mechanisms or other aspects of
   a tunneling solution. In fact, there are no changes to the devices
   behind the NAT.</t>

   <t>Note, however, that existing tunnels are a common special case
   of point-to-point links. For instance, cellular network gateways
   terminate a large number of tunnels that are already needed for
   mobility management reasons. Implementing the approach described in
   this document is particularly attractive in such environments,
   given that no additional tunneling mechanisms, negotiation, or host
   changes are required. In addition, since there is no additional
   tunneling, packets continue to take the same path as they would
   normally take. Other commonly appearing network technology that may
   be of interest include Point-to-Point Protocol (PPP)
   <xref target="RFC1661"/> links, PPP over Ethernet (PPPoE)
   <xref target="RFC2516"/> encapsulation, Asynchronous Transfer Mode
   (ATM) Permanent Virtual Circuits (PVCs), and per-subscriber virtual
   LAN (VLAN) allocation in consumer broadband networks.</t>

   <t>The approach described here also results overlapping private
   address space, like the segmentation of the network to different
   areas. However, this overlap is applied only at the network edges,
   and does not impact routing or reachability of servers in a
   negative way.</t>

</section>

<section anchor="terms" title='Terms'>

   <t>In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
   "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
   described in <xref target='RFC2119' />.</t>

   <t>"NAT" in this document includes both "Basic NAT" and "Network
   Address/Port Translator (NAPT)" as defined by
   <xref target="RFC2663"/>. The term "NAT Session" is adapted from
   <xref target="RFC5382"/> and is defined as follows.</t>

   <t>NAT Session - A NAT session is an association between a transport layer session
   as seen in the internal realm and a session as seen in the
   external realm, by virtue of NAT translation. The NAT session will
   provide the translation glue between the two session representations.</t>

   <t>This document uses the term mapping as defined in
   <xref target="RFC4787"/> to refer to state at the NAT necessary for
   network address and port translation of sessions.</t>

</section>

<section anchor="bindings" title="Per-Interface Bindings">

   <t>To support a mode of operation that uses a fixed number of IPv4
   addresses to serve an arbitrary number of devices, a NAT MUST
   manage its mappings on a per-interface basis, by associating a
   particular NAT session not only with the five tuples used for the
   transport connection on both sides of the NAT, but also with the
   internal interface on which the user device is connected to the
   NAT. This approach allows each internal interface to use the same
   private IPv4 address range. Note that the interface need not be
   physical, it may also correspond to a tunnel, VLAN, or other
   identifiable communications channel.</t>

   <t>For deployments where exactly one user device is connected with
   a separate tunnel interface and all tunnels use the same IPv4
   address for the user devices, it is redundant to store this address
   in the mapping in addition to the internal interface
   identifier. When the internal interface identifier is shorter than
   a 32-bit IPv4 address, this may decrease the storage requirements
   of a mapping entry by a small measure, which may aid NAT
   scalability. For other deployments, it is likely necessary to store
   both the user device IPv4 address and the internal interface
   identifier, which slightly increases the size of the mapping
   entry.</t>

   <t>This mode of operation is only suitable in deployments where
   user devices connect to the NAT over point-to-point links. If
   supported, this mode of operation SHOULD be configurable, and it
   should be disabled by default in general-purpose NAT devices.</t>

</section>

<section anchor="ipv6" title="IPv6 Considerations">

   <t>Private address space conservation is important even during the
   migration to IPv6, because it will be necessary to communicate with
   the IPv4 Internet for a long time. This document specifies two
   recommended deployment models for IPv6. In the first deployment
   model the mechanisms specified in this document are useful. In the
   second deployment model no additional mechanisms are needed,
   because IPv6 addresses are already sufficient to distinguish
   mappings from each other.</t>

   <t>The first deployment model employs dual stack
   <xref target="RFC4213"/>. The IPv6 side of dual stack operates based
   on global addresses and direct end-to-end communication. However, on
   the IPv4 side private addressing and NATs are a necessity. The use of
   per-interface NAT mappings is RECOMMENDED for the IPv4 side under
   these circumstances. Per-interface mappings help the NAT scale,
   while dual stack operation helps reduce the pressure on the NAT device
   by moving key types of traffic to IPv6, eliminating the need for NAT
   processing.</t>

   <t>The second deployment model involves the use of address and
   protocol translation, such as the one defined in
   <xref target="I-D.ietf-behave-v6v4-xlate-stateful"/>. In this
   deployment model there is no IPv4 in the internal network at all.
   This model is applicable only in situations where all relevant devices
   and applications are IPv6-capable. In this situation, per-interface
   mappings could be employed as specified above, but they are
   generally unnecessary as the IPv6 address space is large enough to
   provide a sufficient number of mappings.</t>

</section>

<section anchor="seccons" title='Security Considerations'>

   <t>This practices outlined in this document do not affect the security
   properties of address translation.</t>

</section>

<section anchor="ianacons" title='IANA Considerations'>

   <t>This document has no IANA implications.</t>

</section>

</middle>
<back>

<references title="Normative References">
      <?rfc include="reference.RFC.2119.xml"?>
</references>

<references title="Informative References">
      <?rfc include="reference.RFC.1661.xml"?>
      <?rfc include="reference.RFC.1918.xml"?>
      <?rfc include="reference.RFC.2516.xml"?>
      <?rfc include="reference.RFC.2663.xml"?>
      <?rfc include="reference.RFC.4213.xml"?>
      <?rfc include="reference.RFC.4787.xml"?>
      <?rfc include="reference.RFC.5382.xml"?>
      <?rfc include="reference.I-D.ietf-softwire-dual-stack-lite.xml"?>
      <?rfc include="reference.I-D.arkko-townsley-coexistence.xml"?>
      <?rfc include="reference.I-D.ietf-behave-v6v4-xlate-stateful.xml"?>
      <?rfc include="reference.I-D.miles-behave-l2nat.xml"?>
      <reference anchor="TRILOGY">
        <front>
          <title>Trilogy Project</title>

          <author>
            <organization />
          </author>
        </front>

        <seriesInfo name="" value="http://www.trilogy-project.org/" />
      </reference>
</references>

<section title="Contributors">

   <t>The ideas in this draft were first presented in
   <xref target="I-D.ietf-softwire-dual-stack-lite"/>. This document
   also in debt to <xref target="I-D.arkko-townsley-coexistence"/> and
   <xref target="I-D.miles-behave-l2nat"/>. However, all of these
   documents focused on additional components, such as tunneling
   protocols or the allocation of special IP address ranges. We wanted
   to publish a specification that just focuses on the core
   functionality of a per-interface NAT mappings. However, Mark
   Townsley, David Miles, and Alain Durand should be credited with
   coming up with the ideas discussed in this memo.</t>

</section>

<section anchor="ack" title='Acknowledgments'>

   <t>The authors would also like to thank Randy Bush, Fredrik
   Garneij, Dan Wing, Christian Vogt, Marcelo Braun, Joel Halpern,
   Wassim Haddad, Alan Kavanaugh and others for interesting
   discussions in this problem space.</t>

   <t>Lars Eggert is partly funded by the Trilogy
   Project <xref target="TRILOGY"></xref>, a research project
   supported by the European Commission under its Seventh Framework
   Program.</t>

</section>

</back>
</rfc>