<pre>Internet Engineering Task Force (IETF)                         A. Durand
Request for Comments: 6333                              Juniper Networks
Category: Standards Track                                       R. Droms
ISSN: 2070-1721                                                    Cisco
                                                             J. Woodyatt
                                                                   Apple
                                                                  Y. Lee
                                                                 Comcast
                                                             August 2011


    <span class="h1">Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion</span>

Abstract

   This document revisits the dual-stack model and introduces the Dual-
   Stack Lite technology aimed at better aligning the costs and benefits
   of deploying IPv6 in service provider networks.  Dual-Stack Lite
   enables a broadband service provider to share IPv4 addresses among
   customers by combining two well-known technologies: IP in IP (IPv4-
   in-IPv6) and Network Address Translation (NAT).

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc6333">http://www.rfc-editor.org/info/rfc6333</a>.
















<span class="grey">Durand, et al.               Standards Track                    [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6333">RFC 6333</a>                     Dual-Stack Lite                 August 2011</span>


Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
   <a href="#section-2">2</a>. Requirements Language ...........................................<a href="#page-4">4</a>
   <a href="#section-3">3</a>. Terminology .....................................................<a href="#page-4">4</a>
   <a href="#section-4">4</a>. Deployment Scenarios ............................................<a href="#page-4">4</a>
      <a href="#section-4.1">4.1</a>. Access Model ...............................................<a href="#page-4">4</a>
      <a href="#section-4.2">4.2</a>. CPE ........................................................<a href="#page-5">5</a>
      <a href="#section-4.3">4.3</a>. Directly Connected Device ..................................<a href="#page-6">6</a>
   <a href="#section-5">5</a>. B4 Element ......................................................<a href="#page-7">7</a>
      <a href="#section-5.1">5.1</a>. Definition .................................................<a href="#page-7">7</a>
      <a href="#section-5.2">5.2</a>. Encapsulation ..............................................<a href="#page-7">7</a>
      <a href="#section-5.3">5.3</a>. Fragmentation and Reassembly ...............................<a href="#page-7">7</a>
      <a href="#section-5.4">5.4</a>. AFTR Discovery .............................................<a href="#page-7">7</a>
      <a href="#section-5.5">5.5</a>. DNS ........................................................<a href="#page-8">8</a>
      <a href="#section-5.6">5.6</a>. Interface Initialization ...................................<a href="#page-8">8</a>
      <a href="#section-5.7">5.7</a>. Well-Known IPv4 Address ....................................<a href="#page-8">8</a>
   <a href="#section-6">6</a>. AFTR Element ....................................................<a href="#page-9">9</a>
      <a href="#section-6.1">6.1</a>. Definition .................................................<a href="#page-9">9</a>
      <a href="#section-6.2">6.2</a>. Encapsulation ..............................................<a href="#page-9">9</a>
      <a href="#section-6.3">6.3</a>. Fragmentation and Reassembly ...............................<a href="#page-9">9</a>
      <a href="#section-6.4">6.4</a>. DNS .......................................................<a href="#page-10">10</a>
      <a href="#section-6.5">6.5</a>. Well-Known IPv4 Address ...................................<a href="#page-10">10</a>
      <a href="#section-6.6">6.6</a>. Extended Binding Table ....................................<a href="#page-10">10</a>
   <a href="#section-7">7</a>. Network Considerations .........................................<a href="#page-10">10</a>
      <a href="#section-7.1">7.1</a>. Tunneling .................................................<a href="#page-10">10</a>
      <a href="#section-7.2">7.2</a>. Multicast Considerations ..................................<a href="#page-10">10</a>
   <a href="#section-8">8</a>. NAT Considerations .............................................<a href="#page-11">11</a>
      <a href="#section-8.1">8.1</a>. NAT Pool ..................................................<a href="#page-11">11</a>
      <a href="#section-8.2">8.2</a>. NAT Conformance ...........................................<a href="#page-11">11</a>
      <a href="#section-8.3">8.3</a>. Application Level Gateways (ALGs) .........................<a href="#page-11">11</a>
      <a href="#section-8.4">8.4</a>. Sharing Global IPv4 Addresses .............................<a href="#page-11">11</a>
      <a href="#section-8.5">8.5</a>. Port Forwarding / Keep Alive ..............................<a href="#page-11">11</a>



<span class="grey">Durand, et al.               Standards Track                    [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6333">RFC 6333</a>                     Dual-Stack Lite                 August 2011</span>


   <a href="#section-9">9</a>. Acknowledgements ...............................................<a href="#page-12">12</a>
   <a href="#section-10">10</a>. IANA Considerations ...........................................<a href="#page-12">12</a>
   <a href="#section-11">11</a>. Security Considerations .......................................<a href="#page-12">12</a>
   <a href="#section-12">12</a>. References ....................................................<a href="#page-13">13</a>
      <a href="#section-12.1">12.1</a>. Normative References .....................................<a href="#page-13">13</a>
      <a href="#section-12.2">12.2</a>. Informative References ...................................<a href="#page-14">14</a>
   <a href="#appendix-A">Appendix A</a>. Deployment Considerations .............................<a href="#page-16">16</a>
     <a href="#appendix-A.1">A.1</a>. AFTR Service Distribution and Horizontal Scaling ...........<a href="#page-16">16</a>
     <a href="#appendix-A.2">A.2</a>. Horizontal Scaling .........................................<a href="#page-16">16</a>
     <a href="#appendix-A.3">A.3</a>. High Availability ..........................................<a href="#page-16">16</a>
     <a href="#appendix-A.4">A.4</a>. Logging ....................................................<a href="#page-16">16</a>
   <a href="#appendix-B">Appendix B</a>. Examples ..............................................<a href="#page-17">17</a>
     <a href="#appendix-B.1">B.1</a>. Gateway-Based Architecture .................................<a href="#page-17">17</a>
       <a href="#appendix-B.1.1">B.1.1</a>. Example Message Flow ...................................<a href="#page-19">19</a>
       <a href="#appendix-B.1.2">B.1.2</a>. Translation Details ....................................<a href="#page-23">23</a>
     <a href="#appendix-B.2">B.2</a>. Host-Based Architecture ....................................<a href="#page-24">24</a>
       <a href="#appendix-B.2.1">B.2.1</a>. Example Message Flow ...................................<a href="#page-27">27</a>
       <a href="#appendix-B.2.2">B.2.2</a>. Translation Details ....................................<a href="#page-31">31</a>

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   The common thinking for more than 10 years has been that the
   transition to IPv6 will be based solely on the dual-stack model and
   that most things would be converted this way before we ran out of
   IPv4.  However, this has not happened.  The IANA free pool of IPv4
   addresses has now been depleted, well before sufficient IPv6
   deployment had taken place.  As a result, many IPv4 services have to
   continue to be provided even under severely limited address space.

   This document specifies the Dual-Stack Lite technology, which is
   aimed at better aligning the costs and benefits in service provider
   networks.  Dual-Stack Lite will enable both continued support for
   IPv4 services and incentives for the deployment of IPv6.  It also
   de-couples IPv6 deployment in the service provider network from the
   rest of the Internet, making incremental deployment easier.

   Dual-Stack Lite enables a broadband service provider to share IPv4
   addresses among customers by combining two well-known technologies:
   IP in IP (IPv4-in-IPv6) and Network Address Translation (NAT).

   This document makes a distinction between a dual-stack-capable and a
   dual-stack-provisioned device.  The former is a device that has code
   that implements both IPv4 and IPv6, from the network layer to the
   applications.  The latter is a similar device that has been
   provisioned with both an IPv4 and an IPv6 address on its
   interface(s).  This document will also further refine this notion by
   distinguishing between interfaces provisioned directly by the service
   provider from those provisioned by the customer.



<span class="grey">Durand, et al.               Standards Track                    [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6333">RFC 6333</a>                     Dual-Stack Lite                 August 2011</span>


   Pure IPv6-only devices (i.e., devices that do not include an IPv4
   stack) are outside of the scope of this document.

   This document will first present some deployment scenarios and then
   define the behavior of the two elements of the Dual-Stack Lite
   technology: the Basic Bridging BroadBand (B4) element and the Address
   Family Transition Router (AFTR) element.  It will then go into
   networking and NAT-ing considerations.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Requirements Language</span>

   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 <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Terminology</span>

   The technology described in this document is known as Dual-Stack
   Lite.  The abbreviation "DS-Lite" will be used throughout this text.

   This document also introduces two new terms: the DS-Lite Basic
   Bridging BroadBand (B4) element and the DS-Lite Address Family
   Transition Router (AFTR) element.

   Dual-stack is defined in [<a href="./rfc4213" title="&quot;Basic Transition Mechanisms for IPv6 Hosts and Routers&quot;">RFC4213</a>].

   NAT-related terminology is defined in [<a href="./rfc4787" title="&quot;Network Address Translation (NAT) Behavioral Requirements for Unicast UDP&quot;">RFC4787</a>].

   CPE stands for Customer Premise Equipment.  This is the layer 3
   device in the customer premise that is connected to the service
   provider network.  That device is often a home gateway.  However,
   sometimes computers are directly attached to the service provider
   network.  In such cases, such computers can be viewed as CPEs as
   well.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Deployment Scenarios</span>

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Access Model</span>

   Instead of relying on a cascade of NATs, the Dual-Stack Lite model is
   built on IPv4-in-IPv6 tunnels to cross the network to reach a
   carrier-grade IPv4-IPv4 NAT (the AFTR), where customers will share
   IPv4 addresses.  There are a number of benefits to this approach:

   o  This technology decouples the deployment of IPv6 in the service
      provider network (up to the customer premise equipment or CPE)
      from the deployment of IPv6 in the global Internet and in customer
      applications and devices.



<span class="grey">Durand, et al.               Standards Track                    [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6333">RFC 6333</a>                     Dual-Stack Lite                 August 2011</span>


   o  The management of the service provider access networks is
      simplified by leveraging the large IPv6 address space.
      Overlapping private IPv4 address spaces are not required to
      support very large customer bases.

   o  As tunnels can terminate anywhere in the service provider network,
      this architecture lends itself to horizontal scaling and provides
      some flexibility to adapt to changing traffic load.  More
      discussion of horizontal scaling can be found in <a href="#appendix-A">Appendix A</a>.

   o  Tunnels provide a direct connection between B4 and the AFTR.  This
      can be leveraged to enable customers and their applications to
      control how the NAT function of the AFTR is performed.

   A key characteristic of this approach is that communications between
   end-nodes stay within their address family.  IPv6 sources only
   communicate with IPv6 destinations, and IPv4 sources only communicate
   with IPv4 destinations.  There is no protocol family translation
   involved in this approach.  This simplifies greatly the task of
   applications that may carry literal IP addresses in their payloads.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  CPE</span>

   This section describes home Local Area networks characterized by the
   presence of a home gateway, or CPE, provisioned only with IPv6 by the
   service provider.

   A DS-Lite CPE is an IPv6-aware CPE with a B4 interface implemented in
   the WAN interface.

   A DS-Lite CPE SHOULD NOT operate a NAT function between an internal
   interface and a B4 interface, as the NAT function will be performed
   by the AFTR in the service provider's network.  This will avoid
   accidentally operating in a double-NAT environment.

   However, it SHOULD operate its own DHCP(v4) server handing out
   [<a href="./rfc1918" title="&quot;Address Allocation for Private Internets&quot;">RFC1918</a>] address space (e.g., 192.168.0.0/16) to hosts in the home.
   It SHOULD advertise itself as the default IPv4 router to those home
   hosts.  It SHOULD also advertise itself as a DNS server in the DHCP
   Option 6 (DNS Server).  Additionally, it SHOULD operate a DNS proxy
   to accept DNS IPv4 requests from home hosts and send them using IPv6
   to the service provider DNS servers, as described in <a href="#section-5.5">Section 5.5</a>.









<span class="grey">Durand, et al.               Standards Track                    [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6333">RFC 6333</a>                     Dual-Stack Lite                 August 2011</span>


   Note: If an IPv4 home host decides to use another IPv4 DNS server,
   the DS-Lite CPE will forward those DNS requests via the B4 interface,
   the same way it forwards any regular IPv4 packets.  However, each DNS
   request will create a binding in the AFTR.  A large number of DNS
   requests may have a direct impact on the AFTR's NAT table
   utilization.

   IPv6-capable devices directly reach the IPv6 Internet.  Packets
   simply follow IPv6 routing, they do not go through the tunnel, and
   they are not subject to any translation.  It is expected that most
   IPv6-capable devices will also be IPv4 capable and will simply be
   configured with an IPv4 [<a href="./rfc1918" title="&quot;Address Allocation for Private Internets&quot;">RFC1918</a>]-style address within the home
   network and access the IPv4 Internet the same way as the legacy IPv4-
   only devices within the home.

   Pure IPv6-only devices (i.e., devices that do not include an IPv4
   stack) are outside of the scope of this document.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  Directly Connected Device</span>

   In broadband home networks, some devices are directly connected to
   the broadband service provider.  They are connected straight to a
   modem, without a home gateway.  Those devices are, in fact, acting as
   CPEs.

   Under this scenario, the customer device is a dual-stack-capable host
   that is provisioned by the service provider with IPv6 only.  The
   device itself acts as a B4 element, and the IPv4 service is provided
   by an IPv4-in-IPv6 tunnel, just as in the home gateway/CPE case.
   That device can run any combinations of IPv4 and/or IPv6
   applications.

   A directly connected DS-Lite device SHOULD send its DNS requests over
   IPv6 to the IPv6 DNS server it has been configured to use.

   Similarly to the previous sections, IPv6 packets follow IPv6 routing,
   they do not go through the tunnel, and they are not subject to any
   translation.

   The support of IPv4-only devices and IPv6-only devices in this
   scenario is out of scope for this document.










<span class="grey">Durand, et al.               Standards Track                    [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6333">RFC 6333</a>                     Dual-Stack Lite                 August 2011</span>


<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  B4 Element</span>

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  Definition</span>

   The B4 element is a function implemented on a dual-stack-capable
   node, either a directly connected device or a CPE, that creates a
   tunnel to an AFTR.

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  Encapsulation</span>

   The tunnel is a multipoint-to-point IPv4-in-IPv6 tunnel ending on a
   service provider AFTR.

   See <a href="#section-7.1">Section 7.1</a> for additional tunneling considerations.

   Note: At this point, DS-Lite only defines IPv4-in-IPv6 tunnels;
   however, other types of encapsulation could be defined in the future.

<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>.  Fragmentation and Reassembly</span>

   Using an encapsulation (IPv4-in-IPv6 or anything else) to carry IPv4
   traffic over IPv6 will reduce the effective MTU of the datagram.
   Unfortunately, path MTU discovery [<a href="./rfc1191" title="&quot;Path MTU discovery&quot;">RFC1191</a>] is not a reliable method
   to deal with this problem.

   A solution to deal with this problem is for the service provider to
   increase the MTU size of all the links between the B4 element and the
   AFTR elements by at least 40 bytes to accommodate both the IPv6
   encapsulation header and the IPv4 datagram without fragmenting the
   IPv6 packet.

   However, as not all service providers will be able to increase their
   link MTU, the B4 element MUST perform fragmentation and reassembly if
   the outgoing link MTU cannot accommodate the extra IPv6 header.  The
   original IPv4 packet is not oversized.  The packet is oversized after
   the IPv6 encapsulation.  The inner IPv4 packet MUST NOT be
   fragmented.  Fragmentation MUST happen after the encapsulation of the
   IPv6 packet.  Reassembly MUST happen before the decapsulation of the
   IPv4 packet.  A detailed procedure has been specified in <a href="./rfc2473#section-7.2">[RFC2473]
   Section&nbsp;7.2</a>.

<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>.  AFTR Discovery</span>

   In order to configure the IPv4-in-IPv6 tunnel, the B4 element needs
   the IPv6 address of the AFTR element.  This IPv6 address can be
   configured using a variety of methods, ranging from an out-of-band
   mechanism, manual configuration, or a variety of DHCPv6 options.




<span class="grey">Durand, et al.               Standards Track                    [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6333">RFC 6333</a>                     Dual-Stack Lite                 August 2011</span>


   In order to guarantee interoperability, a B4 element SHOULD implement
   the DHCPv6 option defined in [<a href="./rfc6334" title="&quot;Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite&quot;">RFC6334</a>].

<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a>.  DNS</span>

   A B4 element is only configured from the service provider with IPv6.
   As such, it can only learn the address of a DNS recursive server
   through DHCPv6 (or other similar method over IPv6).  As DHCPv6 only
   defines an option to get the IPv6 address of such a DNS recursive
   server, the B4 element cannot easily discover the IPv4 address of
   such a recursive DNS server, and as such will have to perform all DNS
   resolution over IPv6.

   The B4 element can pass this IPv6 address to downstream IPv6 nodes,
   but not to downstream IPv4 nodes.  As such, the B4 element SHOULD
   implement a DNS proxy, following the recommendations of [<a href="./rfc5625" title="&quot;DNS Proxy Implementation Guidelines&quot;">RFC5625</a>].

   To support a security-aware resolver behind the B4 element, the DNS
   proxy in the B4 element must also be security aware.  Details can be
   found in <a href="./rfc4033#section-6">[RFC4033] Section&nbsp;6</a>.

<span class="h3"><a class="selflink" id="section-5.6" href="#section-5.6">5.6</a>.  Interface Initialization</span>

   The B4 element can be implemented in a host and CPE in conjunction
   with other technologies such as native dual-stack.  The host and the
   CPE SHOULD select to start only one technology during initialization.
   For example, if the CPE selects to start in native dual-stack mode,
   it SHOULD NOT initialize the B4 element.  This selection process is
   out of scope for this document.

<span class="h3"><a class="selflink" id="section-5.7" href="#section-5.7">5.7</a>.  Well-Known IPv4 Address</span>

   Any locally unique IPv4 address could be configured on the IPv4-in-
   IPv6 tunnel to represent the B4 element.  Configuring such an address
   is often necessary when the B4 element is sourcing IPv4 datagrams
   directly over the tunnel.  In order to avoid conflicts with any other
   address, IANA has defined a well-known range, 192.0.0.0/29.

   192.0.0.0 is the reserved subnet address.  192.0.0.1 is reserved for
   the AFTR element, and 192.0.0.2 is reserved for the B4 element.  If a
   service provider has a special configuration that prevents the B4
   element from using 192.0.0.2, the B4 element MAY use any other
   addresses within the 192.0.0.0/29 range.

   Note: A range of addresses has been reserved for this purpose.  The
   intent is to accommodate nodes implementing multiple B4 elements.





<span class="grey">Durand, et al.               Standards Track                    [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6333">RFC 6333</a>                     Dual-Stack Lite                 August 2011</span>


<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  AFTR Element</span>

<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>.  Definition</span>

   An AFTR element is the combination of an IPv4-in-IPv6 tunnel endpoint
   and an IPv4-IPv4 NAT implemented on the same node.

<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>.  Encapsulation</span>

   The tunnel is a point-to-multipoint IPv4-in-IPv6 tunnel ending at the
   B4 elements.

   See <a href="#section-7.1">Section 7.1</a> for additional tunneling considerations.

   Note: At this point, DS-Lite only defines IPv4-in-IPv6 tunnels;
   however, other types of encapsulation could be defined in the future.

<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>.  Fragmentation and Reassembly</span>

   As noted previously, fragmentation and reassembly need to be taken
   care of by the tunnel endpoints.  As such, the AFTR MUST perform
   fragmentation and reassembly if the underlying link MTU cannot
   accommodate the encapsulation overhead.  Fragmentation MUST happen
   after the encapsulation on the IPv6 packet.  Reassembly MUST happen
   before the decapsulation of the IPv6 header.  A detailed procedure
   has been specified in <a href="./rfc2473#section-7.2">[RFC2473] Section&nbsp;7.2</a>.

   Fragmentation at the Tunnel Entry-Point is a lightweight operation.
   In contrast, reassembly at the Tunnel Exit-Point can be expensive.
   When the Tunnel Exit-Point receives the first fragmented packet, it
   must wait for the second fragmented packet to arrive in order to
   reassemble the two fragmented IPv6 packets for decapsulation.  This
   requires the Tunnel Exit-Point to buffer and keep track of fragmented
   packets.  Consider that the AFTR is the Tunnel Exit-Point for many
   tunnels.  If many devices simultaneously source a large number of
   fragmented packets through the AFTR to its managed B4 elements, this
   will require the AFTR to buffer and consume enormous resources to
   keep track of the flows.  This reassembly process will significantly
   impact the AFTR's performance.  However, this impact only happens
   when many clients simultaneously source large IPv4 packets.  Since we
   believe that the majority of the clients will receive large IPv4
   packets (such as watching video streams) instead of sourcing large
   IPv4 packets (such as sourcing video streams), reassembly is only a
   fraction of the overall AFTR's workload.







<span class="grey">Durand, et al.               Standards Track                    [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6333">RFC 6333</a>                     Dual-Stack Lite                 August 2011</span>


   When the AFTR's resources are running below a pre-defined threshold,
   the AFTR SHOULD generate a notification to the administrator before
   the resources are completely exhausted.  The threshold and
   notification procedures are implementation dependent and are out of
   scope for this document.

   Methods to avoid fragmentation, such as rewriting the TCP Maximum
   Segment Size (MSS) option or using technologies such as the
   Subnetwork Encapsulation and Adaptation Layer as defined in
   [<a href="./rfc5320" title="&quot;The Subnetwork Encapsulation and Adaptation Layer (SEAL)&quot;">RFC5320</a>], are out of scope for this document.

<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>.  DNS</span>

   As noted previously, a DS-Lite node implementing a B4 element will
   perform DNS resolution over IPv6.  As a result, DNS packets are not
   expected to go through the AFTR element.

<span class="h3"><a class="selflink" id="section-6.5" href="#section-6.5">6.5</a>.  Well-Known IPv4 Address</span>

   The AFTR SHOULD use the well-known IPv4 address 192.0.0.1 reserved by
   IANA to configure the IPv4-in-IPv6 tunnel.  That address can then be
   used to report ICMP problems and will appear in traceroute outputs.

<span class="h3"><a class="selflink" id="section-6.6" href="#section-6.6">6.6</a>.  Extended Binding Table</span>

   The NAT binding table of the AFTR element is extended to include the
   source IPv6 address of the incoming packets.  This IPv6 address is
   used to disambiguate between the overlapping IPv4 address space of
   the service provider customers.

   By doing a reverse lookup in the extended IPv4 NAT binding table, the
   AFTR knows how to reconstruct the IPv6 encapsulation when the packets
   come back from the Internet.  That way, there is no need to keep a
   static configuration for each tunnel.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Network Considerations</span>

<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>.  Tunneling</span>

   Tunneling MUST be done in accordance to [<a href="./rfc2473" title="&quot;Generic Packet Tunneling in IPv6 Specification&quot;">RFC2473</a>] and [<a href="./rfc4213" title="&quot;Basic Transition Mechanisms for IPv6 Hosts and Routers&quot;">RFC4213</a>].
   Traffic classes ([<a href="./rfc2474" title="&quot;Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers&quot;">RFC2474</a>]) from the IPv4 headers MUST be carried
   over to the IPv6 headers and vice versa.

<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>.  Multicast Considerations</span>

   Discussion of multicast is out of scope for this document.





<span class="grey">Durand, et al.               Standards Track                   [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6333">RFC 6333</a>                     Dual-Stack Lite                 August 2011</span>


<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  NAT Considerations</span>

<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>.  NAT Pool</span>

   The AFTR MAY be provisioned with different NAT pools.  The address
   ranges in the pools may be disjoint but MUST NOT be overlapped.
   Operators may implement policies in the AFTR to assign clients in
   different pools.  For example, an AFTR can have two interfaces.  Each
   interface will have a disjoint pool NAT assigned to it.  In another
   case, a policy implemented on the AFTR may specify that one set of
   B4s will use NAT pool 1 and a different set of B4s will use NAT
   pool 2.

<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>.  NAT Conformance</span>

   A Dual-Stack Lite AFTR MUST implement behavior conforming to the best
   current practice, currently documented in [<a href="./rfc4787" title="&quot;Network Address Translation (NAT) Behavioral Requirements for Unicast UDP&quot;">RFC4787</a>], [<a href="./rfc5508" title="&quot;NAT Behavioral Requirements for ICMP&quot;">RFC5508</a>], and
   [<a href="./rfc5382" title="&quot;NAT Behavioral Requirements for TCP&quot;">RFC5382</a>].  More discussions about carrier-grade NATs can be found in
   [<a href="#ref-LSN-REQS" title="&quot;Common requirements for Carrier Grade NAT (CGN)&quot;">LSN-REQS</a>].

<span class="h3"><a class="selflink" id="section-8.3" href="#section-8.3">8.3</a>.  Application Level Gateways (ALGs)</span>

   The AFTR performs NAT-44 and inherits the limitations of NAT.  Some
   protocols require ALGs in the NAT device to traverse through the NAT.
   For example, Active FTP requires the ALG to work properly.  ALGs
   consume resources, and there are many different types of ALGs.  The
   AFTR is a shared network device that supports a large number of B4
   elements.  It is impossible for the AFTR to implement every current
   and future ALG.

<span class="h3"><a class="selflink" id="section-8.4" href="#section-8.4">8.4</a>.  Sharing Global IPv4 Addresses</span>

   The AFTR shares a single IP with multiple users.  This helps to
   increase the IPv4 address utilization.  However, it also brings some
   issues such as logging and lawful intercept.  More considerations on
   sharing the port space of IPv4 addresses can be found in [<a href="./rfc6269" title="&quot;Issues with IP Address Sharing&quot;">RFC6269</a>].

<span class="h3"><a class="selflink" id="section-8.5" href="#section-8.5">8.5</a>.  Port Forwarding / Keep Alive</span>

   The PCP working group is standardizing a control plane to the
   carrier-grade NAT [<a href="#ref-LSN-REQS" title="&quot;Common requirements for Carrier Grade NAT (CGN)&quot;">LSN-REQS</a>] in the IETF.  The Port Control Protocol
   (PCP) enables applications to directly negotiate with the NAT to open
   ports and negotiate lifetime values to avoid keep-alive traffic.
   More on PCP can be found in [<a href="#ref-PCP-BASE" title="&quot;Port Control Protocol (PCP)&quot;">PCP-BASE</a>].







<span class="grey">Durand, et al.               Standards Track                   [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6333">RFC 6333</a>                     Dual-Stack Lite                 August 2011</span>


<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  Acknowledgements</span>

   The authors would like to acknowledge the role of Mark Townsley for
   his input on the overall architecture of this technology by pointing
   this work in the direction of [<a href="#ref-SNAT" title="&quot;Softwires Network Address Translation (SNAT)&quot;">SNAT</a>].  Note that this document
   results from a merging of [<a href="#ref-DURAND-DS-LITE">DURAND-DS-LITE</a>] and [<a href="#ref-SNAT" title="&quot;Softwires Network Address Translation (SNAT)&quot;">SNAT</a>].  Also to be
   acknowledged are the many discussions with a number of people
   including Shin Miyakawa, Katsuyasu Toyama, Akihide Hiura, Takashi
   Uematsu, Tetsutaro Hara, Yasunori Matsubayashi, and Ichiro Mizukoshi.
   The authors would also like to thank David Ward, Jari Arkko, Thomas
   Narten, and Geoff Huston for their constructive feedback.  Special
   thanks go to Dave Thaler and Dan Wing for their reviews and comments.

<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  IANA Considerations</span>

   Per this document, IANA has allocated a well-known IPv4 192.0.0.0/29
   network prefix.  That range is used to number the Dual-Stack Lite
   interfaces.  Reserving a /29 allows for 6 possible interfaces on a
   multi-home node.  The IPv4 address 192.0.0.1 is reserved as the IPv4
   address of the default router for such Dual-Stack Lite hosts.

<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>.  Security Considerations</span>

   Security issues associated with NAT have long been documented.  See
   [<a href="./rfc2663" title="&quot;IP Network Address Translator (NAT) Terminology and Considerations&quot;">RFC2663</a>] and [<a href="./rfc2993" title="&quot;Architectural Implications of NAT&quot;">RFC2993</a>].

   However, moving the NAT functionality from the CPE to the core of the
   service provider network and sharing IPv4 addresses among customers
   create additional requirements when logging data for abuse usage.
   With any architecture where an IPv4 address does not uniquely
   represent an end host, IPv4 addresses and timestamps are no longer
   sufficient to identify a particular broadband customer.  The AFTR
   should have the capability to log the tunnel-id, protocol, ports/IP
   addresses, and the creation time of the NAT binding to uniquely
   identify the user sessions.  Exact details of what is logged are
   implementation specific and out of scope for this document.

   The AFTR performs translation functions for interior IPv4 hosts using
   <a href="./rfc1918">RFC 1918</a> addresses or the IANA reserved address range (192.0.0.0/29).
   In some circumstances, an ISP may provision policies in the AFTR and
   instruct the AFTR to bypass translation functions based on &lt;IPv4
   Address, port number, protocol&gt;.  When the AFTR receives a packet
   with matching information of the policy from the interior host, the
   AFTR can simply forward the packet without translation.  The
   addresses, ports, and protocol information must be provisioned on the
   AFTR before receiving the packet.  The provisioning mechanism is out
   of scope for this specification.




<span class="grey">Durand, et al.               Standards Track                   [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6333">RFC 6333</a>                     Dual-Stack Lite                 August 2011</span>


   When decapsulating packets, the AFTR MUST only forward packets
   sourced by <a href="./rfc1918">RFC 1918</a> addresses, an IANA reserved address range, or any
   other out-of-band pre-authorized addresses.  The AFTR MUST drop all
   other packets.  This prevents rogue devices from launching denial-of-
   service attacks using unauthorized public IPv4 addresses in the IPv4
   source header field or an unauthorized transport port range in the
   IPv4 transport header field.  For example, rogue devices could
   bombard a public web server by launching a TCP SYN ACK attack
   [<a href="./rfc4987" title="&quot;TCP SYN Flooding Attacks and Common Mitigations&quot;">RFC4987</a>].  The victim will receive TCP SYN from random IPv4 source
   addresses at a rapid rate and deny TCP services to legitimate users.

   With IPv4 addresses shared by multiple users, ports become a critical
   resource.  As such, some mechanisms need to be put in place by an
   AFTR to limit port usage, either by rate-limiting new connections or
   putting a hard limit on the maximum number of ports usable by a
   single user.  If this number is high enough, it should not interfere
   with normal usage and still provide reasonable protection of the
   shared pool.  More considerations on sharing IPv4 addresses can be
   found in [<a href="./rfc6269" title="&quot;Issues with IP Address Sharing&quot;">RFC6269</a>].  Other considerations and recommendations on
   logging can be found in [<a href="./rfc6302" title="&quot;Logging Recommendations for Internet-Facing Servers&quot;">RFC6302</a>].

   AFTRs should support ways to limit service only to registered
   customers.  One simple option is to implement an IPv6 ingress filter
   on the AFTR's tunnel interface to accept only the IPv6 address range
   defined in the filter.

<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>.  References</span>

<span class="h3"><a class="selflink" id="section-12.1" href="#section-12.1">12.1</a>.  Normative References</span>

   [<a id="ref-RFC2119">RFC2119</a>]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-RFC2473">RFC2473</a>]   Conta, A. and S. Deering, "Generic Packet Tunneling in
               IPv6 Specification", <a href="./rfc2473">RFC 2473</a>, December 1998.

   [<a id="ref-RFC2474">RFC2474</a>]   Nichols, K., Blake, S., Baker, F., and D. Black,
               "Definition of the Differentiated Services Field (DS
               Field) in the IPv4 and IPv6 Headers", <a href="./rfc2474">RFC 2474</a>,
               December 1998.

   [<a id="ref-RFC4213">RFC4213</a>]   Nordmark, E. and R. Gilligan, "Basic Transition
               Mechanisms for IPv6 Hosts and Routers", <a href="./rfc4213">RFC 4213</a>,
               October 2005.







<span class="grey">Durand, et al.               Standards Track                   [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6333">RFC 6333</a>                     Dual-Stack Lite                 August 2011</span>


   [<a id="ref-RFC5625">RFC5625</a>]   Bellis, R., "DNS Proxy Implementation Guidelines",
               <a href="https://www.rfc-editor.org/bcp/bcp152">BCP 152</a>, <a href="./rfc5625">RFC 5625</a>, August 2009.

   [<a id="ref-RFC6334">RFC6334</a>]   Hankins, D. and T. Mrugalski, "Dynamic Host Configuration
               Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite",
               <a href="./rfc6334">RFC 6334</a>, August 2011.

<span class="h3"><a class="selflink" id="section-12.2" href="#section-12.2">12.2</a>.  Informative References</span>

   [<a id="ref-DURAND-DS-LITE">DURAND-DS-LITE</a>]
               Durand, A., "Dual-stack lite broadband deployments post
               IPv4 exhaustion", Work in Progress, July 2008.

   [<a id="ref-LSN-REQS">LSN-REQS</a>]  Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa,
               A., and H. Ashida, "Common requirements for Carrier Grade
               NAT (CGN)", Work in Progress, July 2011.

   [<a id="ref-PCP-BASE">PCP-BASE</a>]  Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R.,
               and P. Selkirk, "Port Control Protocol (PCP)", Work
               in Progress, July 2011.

   [<a id="ref-RFC1191">RFC1191</a>]   Mogul, J. and S. Deering, "Path MTU discovery", <a href="./rfc1191">RFC 1191</a>,
               November 1990.

   [<a id="ref-RFC1918">RFC1918</a>]   Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
               and E. Lear, "Address Allocation for Private Internets",
               <a href="https://www.rfc-editor.org/bcp/bcp5">BCP 5</a>, <a href="./rfc1918">RFC 1918</a>, February 1996.

   [<a id="ref-RFC2663">RFC2663</a>]   Srisuresh, P. and M. Holdrege, "IP Network Address
               Translator (NAT) Terminology and Considerations",
               <a href="./rfc2663">RFC 2663</a>, August 1999.

   [<a id="ref-RFC2993">RFC2993</a>]   Hain, T., "Architectural Implications of NAT", <a href="./rfc2993">RFC 2993</a>,
               November 2000.

   [<a id="ref-RFC4033">RFC4033</a>]   Arends, R., Austein, R., Larson, M., Massey, D., and S.
               Rose, "DNS Security Introduction and Requirements",
               <a href="./rfc4033">RFC 4033</a>, March 2005.

   [<a id="ref-RFC4787">RFC4787</a>]   Audet, F., Ed., and C. Jennings, "Network Address
               Translation (NAT) Behavioral Requirements for Unicast
               UDP", <a href="https://www.rfc-editor.org/bcp/bcp127">BCP 127</a>, <a href="./rfc4787">RFC 4787</a>, January 2007.

   [<a id="ref-RFC4987">RFC4987</a>]   Eddy, W., "TCP SYN Flooding Attacks and Common
               Mitigations", <a href="./rfc4987">RFC 4987</a>, August 2007.

   [<a id="ref-RFC5320">RFC5320</a>]   Templin, F., Ed., "The Subnetwork Encapsulation and
               Adaptation Layer (SEAL)", <a href="./rfc5320">RFC 5320</a>, February 2010.



<span class="grey">Durand, et al.               Standards Track                   [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6333">RFC 6333</a>                     Dual-Stack Lite                 August 2011</span>


   [<a id="ref-RFC5382">RFC5382</a>]   Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and
               P.  Srisuresh, "NAT Behavioral Requirements for TCP",
               <a href="https://www.rfc-editor.org/bcp/bcp142">BCP 142</a>, <a href="./rfc5382">RFC 5382</a>, October 2008.

   [<a id="ref-RFC5508">RFC5508</a>]   Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
               Behavioral Requirements for ICMP", <a href="https://www.rfc-editor.org/bcp/bcp148">BCP 148</a>, <a href="./rfc5508">RFC 5508</a>,
               April 2009.

   [<a id="ref-RFC5571">RFC5571</a>]   Storer, B., Pignataro, C., Ed., Dos Santos, M., Stevant,
               B., Ed., Toutain, L., and J. Tremblay, "Softwire Hub and
               Spoke Deployment Framework with Layer Two Tunneling
               Protocol Version 2 (L2TPv2)", <a href="./rfc5571">RFC 5571</a>, June 2009.

   [<a id="ref-RFC6269">RFC6269</a>]   Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
               Roberts, "Issues with IP Address Sharing", <a href="./rfc6269">RFC 6269</a>,
               June 2011.

   [<a id="ref-RFC6302">RFC6302</a>]   Durand, A., Gashinsky, I., Lee, D., and S. Sheppard,
               "Logging Recommendations for Internet-Facing Servers",
               <a href="https://www.rfc-editor.org/bcp/bcp162">BCP 162</a>, <a href="./rfc6302">RFC 6302</a>, June 2011.

   [<a id="ref-SNAT">SNAT</a>]      Droms, R. and B. Haberman, "Softwires Network Address
               Translation (SNAT)", Work in Progress, July 2008.




























<span class="grey">Durand, et al.               Standards Track                   [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6333">RFC 6333</a>                     Dual-Stack Lite                 August 2011</span>


<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>.  Deployment Considerations</span>

<span class="h3"><a class="selflink" id="appendix-A.1" href="#appendix-A.1">A.1</a>.  AFTR Service Distribution and Horizontal Scaling</span>

   One of the key benefits of the Dual-Stack Lite technology lies in the
   fact that it is a tunnel-based solution.  As such, tunnel endpoints
   can be anywhere in the service provider network.

   Using the DHCPv6 tunnel endpoint option [<a href="./rfc6334" title="&quot;Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite&quot;">RFC6334</a>], service providers
   can create groups of users sharing the same AFTR.  Those groups can
   be merged or divided at will.  This leads to a horizontally scaled
   solution, where more capacity is added with more AFTRs.  As those
   groups of users can evolve over time, it is best to make sure that
   AFTRs do not require per-user configuration in order to provide
   service.

<span class="h3"><a class="selflink" id="appendix-A.2" href="#appendix-A.2">A.2</a>.  Horizontal Scaling</span>

   A service provider can start using just a few centralized AFTRs.
   Later, when more capacity is needed, more AFTRs can be added and
   pushed closer to the edges of the access network.

<span class="h3"><a class="selflink" id="appendix-A.3" href="#appendix-A.3">A.3</a>.  High Availability</span>

   An important element in the design of the Dual-Stack Lite technology
   is the simplicity of implementation on the customer side.  An IP4-in-
   IPv6 tunnel and a default route over it in the B4 element are all
   that is needed to get IPv4 connectivity.  It is assumed that high
   availability is the responsibility of the service provider, not the
   customer devices implementing Dual-Stack Lite.  As such, a single
   IPv6 address of the tunnel endpoint is provided in the DHCPv6 option
   defined in [<a href="./rfc6334" title="&quot;Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite&quot;">RFC6334</a>].  Specific means to achieve high availability on
   the service provider side are outside the scope of this
   specification.

<span class="h3"><a class="selflink" id="appendix-A.4" href="#appendix-A.4">A.4</a>.  Logging</span>

   DS-Lite AFTR implementation should offer the functionality to log NAT
   binding creations or other ways to keep track of the ports/IP
   addresses used by customers.  This is both to support
   troubleshooting, which is very important to service providers trying
   to figure out why something may not be working, and to meet region-
   specific requirements for responding to legally binding requests for
   information from law enforcement authorities.







<span class="grey">Durand, et al.               Standards Track                   [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc6333">RFC 6333</a>                     Dual-Stack Lite                 August 2011</span>


<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>.  Examples</span>

<span class="h3"><a class="selflink" id="appendix-B.1" href="#appendix-B.1">B.1</a>.  Gateway-Based Architecture</span>

   This architecture is targeted at residential broadband deployments
   but can be adapted easily to other types of deployment where the
   installed base of IPv4-only devices is important.

   Consider a scenario where a Dual-Stack Lite CPE is provisioned only
   with IPv6 in the WAN port, not IPv4.  The CPE acts as an IPv4 DHCP
   server for the LAN (wireline and wireless) handing out [<a href="./rfc1918" title="&quot;Address Allocation for Private Internets&quot;">RFC1918</a>]
   addresses.  In addition, the CPE may support IPv6 Auto-Configuration
   and/or a DHCPv6 server for the LAN.  When an IPv4-only device
   connects to the CPE, that CPE will hand out a [<a href="./rfc1918" title="&quot;Address Allocation for Private Internets&quot;">RFC1918</a>] address to
   the device.  When a dual-stack-capable device connects to the CPE,
   that CPE will hand out a [<a href="./rfc1918" title="&quot;Address Allocation for Private Internets&quot;">RFC1918</a>] address and a global IPv6 address
   to the device.  Besides, the CPE will create an IPv4-in-IPv6 softwire
   tunnel [<a href="./rfc5571" title="&quot;Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2)&quot;">RFC5571</a>] to an AFTR that resides in the service provider
   network.

   When the device accesses IPv6 service, it will send the IPv6 datagram
   to the CPE natively.  The CPE will route the traffic upstream to the
   IPv6 default gateway.

   When the device accesses IPv4 service, it will source the IPv4
   datagram with the [<a href="./rfc1918" title="&quot;Address Allocation for Private Internets&quot;">RFC1918</a>] address and send the IPv4 datagram to the
   CPE.  The CPE will encapsulate the IPv4 datagram inside the IPv4-in-
   IPv6 softwire tunnel and forward the IPv6 datagram to the AFTR.  This
   is in contrast to what the CPE normally does today, which is to NAT
   the [<a href="./rfc1918" title="&quot;Address Allocation for Private Internets&quot;">RFC1918</a>] address to the public IPv4 address and route the
   datagram upstream.  When the AFTR receives the IPv6 datagram, it will
   decapsulate the IPv6 header and perform an IPv4-to-IPv4 NAT on the
   source address.

   As illustrated in Figure 1, this Dual-Stack Lite deployment model
   consists of three components: the Dual-Stack Lite home router with a
   B4 element, the AFTR, and a softwire between the B4 element acting as
   softwire initiator (SI) [<a href="./rfc5571" title="&quot;Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2)&quot;">RFC5571</a>] in the Dual-Stack Lite home router
   and the softwire concentrator (SC) [<a href="./rfc5571" title="&quot;Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2)&quot;">RFC5571</a>] in the AFTR.  The AFTR
   performs IPv4-IPv4 NAT translations to multiplex multiple subscribers
   through a pool of global IPv4 addresses.  Overlapping address spaces
   used by subscribers are disambiguated through the identification of
   tunnel endpoints.








<span class="grey">Durand, et al.               Standards Track                   [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc6333">RFC 6333</a>                     Dual-Stack Lite                 August 2011</span>


                   +-----------+
                   |    Host   |
                   +-----+-----+
                         |10.0.0.1
                         |
                         |
                         |10.0.0.2
               +---------|---------+
               |         |         |
               |    Home router    |
               |+--------+--------+|
               ||       B4        ||
               |+--------+--------+|
               +--------|||--------+
                        |||2001:db8:0:1::1
                        |||
                        |||&lt;-IPv4-in-IPv6 softwire
                        |||
                 -------|||-------
               /        |||        \
              |   ISP core network  |
               \        |||        /
                 -------|||-------
                        |||
                        |||2001:db8:0:2::1
               +--------|||--------+
               |        AFTR       |
               |+--------+--------+|
               ||   Concentrator  ||
               |+--------+--------+|
               |       |NAT|       |
               |       +-+-+       |
               +---------|---------+
                         |192.0.2.1
                         |
                 --------|--------
               /         |         \
              |       Internet      |
               \         |         /
                 --------|--------
                         |
                         |198.51.100.1
                   +-----+-----+
                   | IPv4 Host |
                   +-----------+

                   Figure 1: Gateway-Based Architecture




<span class="grey">Durand, et al.               Standards Track                   [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc6333">RFC 6333</a>                     Dual-Stack Lite                 August 2011</span>


   Notes:

   o  The Dual-Stack Lite home router is not required to be on the same
      link as the host.

   o  The Dual-Stack Lite home router could be replaced by a Dual-Stack
      Lite router in the service provider network.

   The resulting solution accepts an IPv4 datagram that is translated
   into an IPv4-in-IPv6 softwire datagram for transmission across the
   softwire.  At the corresponding endpoint, the IPv4 datagram is
   decapsulated, and the translated IPv4 address is inserted based on a
   translation from the softwire.

<span class="h4"><a class="selflink" id="appendix-B.1.1" href="#appendix-B.1.1">B.1.1</a>.  Example Message Flow</span>

   In the example shown in Figure 2, the translation tables in the AFTR
   are configured to forward between IP/TCP (10.0.0.1/10000) and IP/TCP
   (192.0.2.1/5000).  That is, a datagram received by the Dual-Stack
   Lite home router from the host at address 10.0.0.1, using TCP DST
   port 10000, will be translated to a datagram with IPv4 SRC address
   192.0.2.1 and TCP SRC port 5000 in the Internet.





























<span class="grey">Durand, et al.               Standards Track                   [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc6333">RFC 6333</a>                     Dual-Stack Lite                 August 2011</span>


                   +-----------+
                   |    Host   |
                   +-----+-----+
                      |  |10.0.0.1
      IPv4 datagram 1 |  |
                      |  |
                      v  |10.0.0.2
               +---------|---------+
               |         |         |
               |    home router    |
               |+--------+--------+|
               ||        B4       ||
               |+--------+--------+|
               +--------|||--------+
                      | |||2001:db8:0:1::1
       IPv6 datagram 2| |||
                      | |||&lt;-IPv4-in-IPv6 softwire
                 -----|-|||-------
               /      | |||        \
              |   ISP core network  |
               \      | |||        /
                 -----|-|||-------
                      | |||
                      | |||2001:db8:0:2::1
               +------|-|||--------+
               |      | AFTR       |
               |      v |||        |
               |+--------+--------+|
               ||  Concentrator   ||
               |+--------+--------+|
               |       |NAT|       |
               |       +-+-+       |
               +---------|---------+
                      |  |192.0.2.1
      IPv4 datagram 3 |  |
                      |  |
                 -----|--|--------
               /      |  |         \
              |       Internet      |
               \      |  |         /
                 -----|--|--------
                      |  |
                      v  |198.51.100.1
                   +-----+-----+
                   | IPv4 Host |
                   +-----------+

                        Figure 2: Outbound Datagram



<span class="grey">Durand, et al.               Standards Track                   [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc6333">RFC 6333</a>                     Dual-Stack Lite                 August 2011</span>


           +-----------------+--------------+-----------------+
           |        Datagram | Header field | Contents        |
           +-----------------+--------------+-----------------+
           | IPv4 datagram 1 |     IPv4 Dst | 198.51.100.1    |
           |                 |     IPv4 Src | 10.0.0.1        |
           |                 |      TCP Dst | 80              |
           |                 |      TCP Src | 10000           |
           | --------------- | ------------ | -------------   |
           | IPv6 datagram 2 |     IPv6 Dst | 2001:db8:0:2::1 |
           |                 |     IPv6 Src | 2001:db8:0:1::1 |
           |                 |     IPv4 Dst | 198.51.100.1    |
           |                 |     IPv4 Src | 10.0.0.1        |
           |                 |      TCP Dst | 80              |
           |                 |      TCP Src | 10000           |
           | --------------- | ------------ | -------------   |
           | IPv4 datagram 3 |     IPv4 Dst | 198.51.100.1    |
           |                 |     IPv4 Src | 192.0.2.1       |
           |                 |      TCP Dst | 80              |
           |                 |      TCP Src | 5000            |
           +-----------------+--------------+-----------------+

                         Datagram Header Contents

   When datagram 1 is received by the Dual-Stack Lite home router, the
   B4 element encapsulates the datagram in datagram 2 and forwards it to
   the Dual-Stack Lite carrier-grade NAT over the softwire.

   When the tunnel concentrator in the AFTR receives datagram 2, it
   forwards the IPv4 datagram to the NAT, which determines from its NAT
   table that the datagram received on the softwire with TCP SRC
   port 10000 should be translated to datagram 3 with IPv4 SRC address
   192.0.2.1 and TCP SRC port 5000.

   Figure 3 shows an inbound message received at the AFTR.  When the NAT
   function in the AFTR receives datagram 1, it looks up the IP/TCP DST
   information in its translation table.  In the example in Figure 3,
   the NAT changes the TCP DST port to 10000, sets the IP DST address to
   10.0.0.1, and forwards the datagram to the softwire.  The B4 in the
   home router decapsulates the IPv4 datagram from the inbound softwire
   datagram and forwards it to the host.











<span class="grey">Durand, et al.               Standards Track                   [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc6333">RFC 6333</a>                     Dual-Stack Lite                 August 2011</span>


                   +-----------+
                   |    Host   |
                   +-----+-----+
                      ^  |10.0.0.1
      IPv4 datagram 3 |  |
                      |  |
                      |  |10.0.0.2
               +---------|---------+
               |       +-+-+       |
               |    home router    |
               |+--------+--------+|
               ||        B4       ||
               |+--------+--------+|
               +--------|||--------+
                      ^ |||2001:db8:0:1::1
      IPv6 datagram 2 | |||
                      | |||&lt;-IPv4-in-IPv6 softwire
                      | |||
                 -----|-|||-------
               /      | |||        \
              |   ISP core network  |
               \      | |||        /
                 -----|-|||-------
                      | |||
                      | |||2001:db8:0:2::1
               +------|-|||--------+
               |       AFTR        |
               |+--------+--------+|
               ||   Concentrator  ||
               |+--------+--------+|
               |       |NAT|       |
               |       +-+-+       |
               +---------|---------+
                      ^  |192.0.2.1
      IPv4 datagram 1 |  |
                      |  |
                 -----|--|--------
               /      |  |         \
              |       Internet      |
               \      |  |         /
                 -----|--|--------
                      |  |
                      |  |198.51.100.1
                   +-----+-----+
                   | IPv4 Host |
                   +-----------+

                        Figure 3: Inbound Datagram



<span class="grey">Durand, et al.               Standards Track                   [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc6333">RFC 6333</a>                     Dual-Stack Lite                 August 2011</span>


           +-----------------+--------------+-----------------+
           |        Datagram | Header field | Contents        |
           +-----------------+--------------+-----------------+
           | IPv4 datagram 1 |     IPv4 Dst | 192.0.2.1       |
           |                 |     IPv4 Src | 198.51.100.1    |
           |                 |      TCP Dst | 5000            |
           |                 |      TCP Src | 80              |
           | --------------- | ------------ | -------------   |
           | IPv6 datagram 2 |     IPv6 Dst | 2001:db8:0:1::1 |
           |                 |     IPv6 Src | 2001:db8:0:2::1 |
           |                 |     IPv4 Dst | 10.0.0.1        |
           |                 |     IPv4 Src | 198.51.100.1    |
           |                 |      TCP Dst | 10000           |
           |                 |      TCP Src | 80              |
           | --------------- | ------------ | -------------   |
           | IPv4 datagram 3 |     IPv4 Dst | 10.0.0.1        |
           |                 |     IPv4 Src | 198.51.100.1    |
           |                 |      TCP Dst | 10000           |
           |                 |      TCP Src | 80              |
           +-----------------+--------------+-----------------+

                         Datagram Header Contents

<span class="h4"><a class="selflink" id="appendix-B.1.2" href="#appendix-B.1.2">B.1.2</a>.  Translation Details</span>

   The AFTR has a NAT that translates between softwire/port pairs and
   IPv4-address/port pairs.  The same translation is applied to IPv4
   datagrams received on the device's external interface and from the
   softwire endpoint in the device.

   In Figure 2, the translator network interface in the AFTR is on the
   Internet, and the softwire interface connects to the Dual-Stack Lite
   home router.  The AFTR translator is configured as follows:

   Network interface:  Translate IPv4 destination address and TCP
      destination port to the softwire identifier and TCP destination
      port

   Softwire interface:  Translate softwire identifier and TCP source
      port to IPv4 source address and TCP source port

   Here is how the translation in Figure 3 works:

   o  Datagram 1 is received on the AFTR translator network interface.
      The translator looks up the IPv4-address/port pair in its
      translator table, rewrites the IPv4 destination address to
      10.0.0.1 and the TCP source port to 10000, and forwards the
      datagram to the softwire.



<span class="grey">Durand, et al.               Standards Track                   [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc6333">RFC 6333</a>                     Dual-Stack Lite                 August 2011</span>


   o  The IPv4 datagram is received on the Dual-Stack Lite home router
      B4.  The B4 function extracts the IPv4 datagram, and the Dual-
      Stack Lite home router forwards datagram 3 to the host.

        +------------------------------------+--------------------+
        |         Softwire-Id/IPv4/Prot/Port | IPv4/Prot/Port     |
        +------------------------------------+--------------------+
        | 2001:db8:0:1::1/10.0.0.1/TCP/10000 | 192.0.2.1/TCP/5000 |
        +------------------------------------+--------------------+

            Dual-Stack Lite Carrier-Grade NAT Translation Table

   The Softwire-Id is the IPv6 address assigned to the Dual-Stack Lite
   CPE.  Hosts behind the same Dual-Stack Lite home router have the same
   Softwire-Id.  The source IPv4 address is the [<a href="./rfc1918" title="&quot;Address Allocation for Private Internets&quot;">RFC1918</a>] address
   assigned by the Dual-Stack home router and is unique to each host
   behind the CPE.  The AFTR would receive packets sourced from
   different IPv4 addresses in the same softwire tunnel.  The AFTR
   combines the Softwire-Id and IPv4 address/port [Softwire-Id, IPv4+
   Port] to uniquely identify the host behind the same Dual-Stack Lite
   home router.

<span class="h3"><a class="selflink" id="appendix-B.2" href="#appendix-B.2">B.2</a>.  Host-Based Architecture</span>

   This architecture is targeted at new, large-scale deployments of
   dual-stack-capable devices implementing a Dual-Stack Lite interface.

   Consider a scenario where a Dual-Stack Lite host device is directly
   connected to the service provider network.  The host device is dual-
   stack capable but only provisioned with an IPv6 global address.
   Besides, the host device will pre-configure a well-known IPv4
   non-routable address; see <a href="#section-10">Section 10</a> (IANA Considerations).  This
   well-known IPv4 non-routable address is similar to the 127.0.0.1
   loopback address.  Every host device that implements Dual-Stack Lite
   will pre-configure the same address.  This address will be used to
   source the IPv4 datagram when the device accesses IPv4 services.
   Besides, the host device will create an IPv4-in-IPv6 softwire tunnel
   to an AFTR.  The carrier-grade NAT will reside in the service
   provider network.

   When the device accesses IPv6 service, the device will send the IPv6
   datagram natively to the default gateway.









<span class="grey">Durand, et al.               Standards Track                   [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc6333">RFC 6333</a>                     Dual-Stack Lite                 August 2011</span>


   When the device accesses IPv4 service, it will source the IPv4
   datagram with the well-known non-routable IPv4 address.  Then, the
   host device will encapsulate the IPv4 datagram inside the IPv4-in-
   IPv6 softwire tunnel and send the IPv6 datagram to the AFTR.  When
   the AFTR receives the IPv6 datagram, it will decapsulate the IPv6
   header and perform IPv4-to-IPv4 NAT on the source address.

   This scenario works on both wireline and wireless networks.  A
   typical wireless device will connect directly to the service provider
   without a CPE in between.

   As illustrated in Figure 4, this Dual-Stack Lite deployment model
   consists of three components: the Dual-Stack Lite host, the AFTR, and
   a softwire between the softwire initiator B4 in the host and the
   softwire concentrator in the AFTR.  The Dual-Stack Lite host is
   assumed to have IPv6 service and can exchange IPv6 traffic with the
   AFTR.

   The AFTR performs IPv4-IPv4 NAT translations to multiplex multiple
   subscribers through a pool of global IPv4 addresses.  Overlapping
   IPv4 address spaces used by the Dual-Stack Lite hosts are
   disambiguated through the identification of tunnel endpoints.

   In this situation, the Dual-Stack Lite host configures the IPv4
   address 192.0.0.2 out of the well-known range 192.0.0.0/29 (defined
   by IANA) on its B4 interface.  It also configures the first
   non-reserved IPv4 address of the reserved range, 192.0.0.1, as the
   address of its default gateway.























<span class="grey">Durand, et al.               Standards Track                   [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc6333">RFC 6333</a>                     Dual-Stack Lite                 August 2011</span>


               +-------------------+
               |                   |
               |  Host 192.0.0.2   |
               |+--------+--------+|
               ||        B4       ||
               |+--------+--------+|
               +--------|||--------+
                        |||2001:db8:0:1::1
                        |||
                        |||&lt;-IPv4-in-IPv6 softwire
                        |||
                 -------|||-------
               /        |||        \
              |   ISP core network  |
               \        |||        /
                 -------|||-------
                        |||
                        |||2001:db8:0:2::1
               +--------|||--------+
               |       AFTR        |
               |+--------+--------+|
               ||  Concentrator   ||
               |+--------+--------+|
               |       |NAT|       |
               |       +-+-+       |
               +---------|---------+
                         |192.0.2.1
                         |
                 --------|--------
               /         |         \
              |       Internet      |
               \         |         /
                 --------|--------
                         |
                         |198.51.100.1
                   +-----+-----+
                   | IPv4 Host |
                   +-----------+

                     Figure 4: Host-Based Architecture

   The resulting solution accepts an IPv4 datagram that is translated
   into an IPv4-in-IPv6 softwire datagram for transmission across the
   softwire.  At the corresponding endpoint, the IPv4 datagram is
   decapsulated, and the translated IPv4 address is inserted based on a
   translation from the softwire.





<span class="grey">Durand, et al.               Standards Track                   [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc6333">RFC 6333</a>                     Dual-Stack Lite                 August 2011</span>


<span class="h4"><a class="selflink" id="appendix-B.2.1" href="#appendix-B.2.1">B.2.1</a>.  Example Message Flow</span>

   In the example shown in Figure 5, the translation tables in the AFTR
   are configured to forward between IP/TCP (192.0.0.2/10000) and IP/TCP
   (192.0.2.1/5000).  That is, a datagram received from the host at
   address 192.0.0.2, using TCP DST port 10000, will be translated to a
   datagram with IPv4 SRC address 192.0.2.1 and TCP SRC port 5000 in the
   Internet.











































<span class="grey">Durand, et al.               Standards Track                   [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc6333">RFC 6333</a>                     Dual-Stack Lite                 August 2011</span>


               +-------------------+
               |                   |
               |Host 192.0.0.2     |
               |+--------+--------+|
               ||        B4       ||
               |+--------+--------+|
               +--------|||--------+
                      | |||2001:db8:0:1::1
       IPv6 datagram 1| |||
                      | |||&lt;-IPv4-in-IPv6 softwire
                      | |||
                 -----|-|||-------
               /      | |||        \
              |   ISP core network  |
               \      | |||        /
                 -----|-|||-------
                      | |||
                      | |||2001:db8:0:2::1
               +------|-|||--------+
               |      | AFTR       |
               |      v |||        |
               |+--------+--------+|
               ||  Concentrator   ||
               |+--------+--------+|
               |       |NAT|       |
               |       +-+-+       |
               +---------|---------+
                      |  |192.0.2.1
      IPv4 datagram 2 |  |
                 -----|--|--------
               /      |  |         \
              |       Internet      |
               \      |  |         /
                 -----|--|--------
                      |  |
                      v  |198.51.100.1
                   +-----+-----+
                   | IPv4 Host |
                   +-----------+

                        Figure 5: Outbound Datagram










<span class="grey">Durand, et al.               Standards Track                   [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc6333">RFC 6333</a>                     Dual-Stack Lite                 August 2011</span>


           +-----------------+--------------+-----------------+
           |        Datagram | Header field | Contents        |
           +-----------------+--------------+-----------------+
           | IPv6 datagram 1 |     IPv6 Dst | 2001:db8:0:2::1 |
           |                 |     IPv6 Src | 2001:db8:0:1::1 |
           |                 |     IPv4 Dst | 198.51.100.1    |
           |                 |     IPv4 Src | 192.0.0.2       |
           |                 |      TCP Dst | 80              |
           |                 |      TCP Src | 10000           |
           | --------------- | ------------ | -------------   |
           | IPv4 datagram 2 |     IPv4 Dst | 198.51.100.1    |
           |                 |     IPv4 Src | 192.0.2.1       |
           |                 |      TCP Dst | 80              |
           |                 |      TCP Src | 5000            |
           +-----------------+--------------+-----------------+

                         Datagram Header Contents

   When sending an IPv4 packet, the Dual-Stack Lite host encapsulates it
   in datagram 1 and forwards it to the AFTR over the softwire.

   When it receives datagram 1, the concentrator in the AFTR hands the
   IPv4 datagram to the NAT, which determines from its translation table
   that the datagram received on the softwire with TCP SRC port 10000
   should be translated to datagram 3 with IPv4 SRC address 192.0.2.1
   and TCP SRC port 5000.

   Figure 6 shows an inbound message received at the AFTR.  When the NAT
   function in the AFTR receives datagram 1, it looks up the IP/TCP DST
   in its translation table.  In the example in Figure 6, the NAT
   translates the TCP DST port to 10000, sets the IP DST address to
   192.0.0.2, and forwards the datagram to the softwire.  The B4 inside
   the host decapsulates the IPv4 datagram from the inbound softwire
   datagram, and forwards it to the host's application layer.

















<span class="grey">Durand, et al.               Standards Track                   [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc6333">RFC 6333</a>                     Dual-Stack Lite                 August 2011</span>


               +-------------------+
               |                   |
               |Host 192.0.0.2     |
               |+--------+--------+|
               ||        B4       ||
               |+--------+--------+|
               +--------|||--------+
                      ^ |||2001:db8:0:1::1
      IPv6 datagram 2 | |||
                      | |||&lt;-IPv4-in-IPv6 softwire
                      | |||
                 -----|-|||-------
               /      | |||        \
              |   ISP core network  |
               \      | |||        /
                 -----|-|||-------
                      | |||
                      | |||2001:db8:0:2::1
               +------|-|||--------+
               |       AFTR        |
               |      | |||        |
               |+--------+--------+|
               ||  Concentrator   ||
               |+--------+--------+|
               |       |NAT|       |
               |       +-+-+       |
               +---------|---------+
                      ^  |192.0.2.1
      IPv4 datagram 1 |  |
                 -----|--|--------
               /      |  |         \
              |       Internet      |
               \      |  |         /
                 -----|--|--------
                      |  |
                      |  |198.51.100.1
                   +-----+-----+
                   | IPv4 Host |
                   +-----------+

                        Figure 6: Inbound Datagram










<span class="grey">Durand, et al.               Standards Track                   [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc6333">RFC 6333</a>                     Dual-Stack Lite                 August 2011</span>


           +-----------------+--------------+-----------------+
           |        Datagram | Header field | Contents        |
           +-----------------+--------------+-----------------+
           | IPv4 datagram 1 |     IPv4 Dst | 192.0.2.1       |
           |                 |     IPv4 Src | 198.51.100.1    |
           |                 |      TCP Dst | 5000            |
           |                 |      TCP Src | 80              |
           | --------------- | ------------ | -------------   |
           | IPv6 datagram 2 |     IPv6 Dst | 2001:db8:0:1::1 |
           |                 |     IPv6 Src | 2001:db8:0:2::1 |
           |                 |     IPv4 Dst | 192.0.0.2       |
           |                 |     IPv4 Src | 198.51.100.1    |
           |                 |      TCP Dst | 10000           |
           |                 |      TCP Src | 80              |
           +-----------------+--------------+-----------------+

                         Datagram Header Contents

<span class="h4"><a class="selflink" id="appendix-B.2.2" href="#appendix-B.2.2">B.2.2</a>.  Translation Details</span>

   The AFTR translation steps are the same as in <a href="#appendix-B.1.2">Appendix B.1.2</a>.  One
   difference is that all the host-based B4s will use the same well-
   known IPv4 address 192.0.0.2.  To uniquely identify the host-based
   B4, the AFTR will use the host-based B4's IPv6 address, which is
   unique for the host.

       +-------------------------------------+--------------------+
       |          Softwire-Id/IPv4/Prot/Port | IPv4/Prot/Port     |
       +-------------------------------------+--------------------+
       | 2001:db8:0:1::1/192.0.0.2/TCP/10000 | 192.0.2.1/TCP/5000 |
       +-------------------------------------+--------------------+

            Dual-Stack Lite Carrier-Grade NAT Translation Table

   The Softwire-Id is the IPv6 address assigned to the Dual-Stack host.
   Each host has a unique Softwire-Id.  The source IPv4 address is one
   of the well-known IPv4 addresses.  The AFTR could receive packets
   from different hosts sourced from the same IPv4 well-known address
   from different softwire tunnels.  Similar to the gateway
   architecture, the AFTR combines the Softwire-Id and IPv4 address/port
   [Softwire-Id, IPv4+Port] to uniquely identify the individual host.










<span class="grey">Durand, et al.               Standards Track                   [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc6333">RFC 6333</a>                     Dual-Stack Lite                 August 2011</span>


Authors' Addresses

   Alain Durand
   Juniper Networks
   1194 North Mathilda Avenue
   Sunnyvale, CA  94089-1206
   USA

   EMail: adurand@juniper.net


   Ralph Droms
   Cisco
   1414 Massachusetts Avenue
   Boxborough, MA  01714
   USA

   EMail: rdroms@cisco.com


   James Woodyatt
   Apple
   1 Infinite Loop
   Cupertino, CA  95014
   USA

   EMail: jhw@apple.com


   Yiu L. Lee
   Comcast
   One Comcast Center
   Philadelphia, PA  19103
   USA

   EMail: yiu_lee@cable.comcast.com















Durand, et al.               Standards Track                   [Page 32]
</pre>