One document matched: draft-ietf-softwire-dual-stack-lite-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC1191 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1191.xml">
<!ENTITY RFC1700 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1700.xml">
<!ENTITY RFC1918 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2385 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2385.xml">
<!ENTITY RFC2460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY RFC2473 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2473.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3315 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY RFC3646 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3646.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
<!ENTITY I-D.bound-dstm-exp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bound-dstm-exp.xml">
<!ENTITY I-D.droms-softwires-snat SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.droms-softwires-snat.xml">
<!ENTITY I-D.durand-dual-stack-lite SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.durand-dual-stack-lite.xml">
<!ENTITY RFC4966 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4966.xml">
<!ENTITY RFC2766 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2766.xml">
<!ENTITY RFC2663 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2663.xml">
<!ENTITY RFC2993 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2993.xml">
<!ENTITY RFC4787 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4787.xml">
<!ENTITY RFC5571 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5571.xml">
<!ENTITY I-D.ietf-dnsext-dnsproxy SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dnsext-dnsproxy.xml">
<!ENTITY I-D.ietf-behave-tcp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-behave-tcp.xml">
<!ENTITY I-D.ietf-behave-nat-icmp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-behave-nat-icmp.xml">
<!ENTITY I-D.cheshire-nat-pmp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.cheshire-nat-pmp.xml">
<!ENTITY I-D.dhankins-softwire-tunnel-option SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.dhankins-softwire-tunnel-option.xml">
<!ENTITY I-D.bajko-v6ops-port-restricted-ipaddr-assign SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bajko-v6ops-port-restricted-ipaddr-assign.xml">
<!ENTITY I-D.ymbk-aplusp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ymbk-aplusp.xml">
<!ENTITY I-D.despres-sam SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.despres-sam.xml">
<!ENTITY I-D.nishitani-cgn SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.nishitani-cgn.xml">
<!ENTITY I-D.ford-shared-addressing-issues SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ford-shared-addressing-issues.xml">
<!ENTITY I-D.ietf-tcpm-tcp-auth-opt SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tcpm-tcp-auth-opt.xml">
<!ENTITY I-D.ietf-softwire-hs-framework-l2tpv2 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-softwire-hs-framework-l2tpv2.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-softwire-dual-stack-lite-01" ipr="trust200811">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Dual-stack lite">Dual-stack lite broadband deployments post IPv4 exhaustion</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Alain Durand" initials="A.D." role="editor"
surname="Durand">
<organization>Comcast</organization>
<address>
<postal>
<street>1, Comcast center</street>
<!-- Reorder these if your country does things differently -->
<city>Philadelphia</city>
<region>PA</region>
<code>19103</code>
<country>USA</country>
</postal>
<email>alain_durand@cable.comcast.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2009" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>NAT</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t> The common thinking for more than 10 years has been that the transition to IPv6 will be based on the dual stack model and that most things would be converted this way before we ran out of IPv4.</t>
<t>It has not happened. The IANA free pool of IPv4 addresses will be depleted soon, well before any significant IPv6 deployment will have occurred.</t>
<t>
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. Dual-stack lite will provide the necessary bridge between the two protocols, offering an evolution path of the Internet post IANA IPv4 depletion.</t>
<t>
Dual-Stack lite enable a brodband service provider to share IPv4 addresses among customers by combining two well-known technologies: IP in IP (IPv4/IPv6) and NAT.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document presents views on IP deployments after the exhaustion of IPv4 addresses and some of the necessary technologies to
achieve it. The views expressed are the authors' personal opinions and in no way imply that Comcast plans to deploy or that Cisco will implement the technologies described here.</t>
<section title="Requirements language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Terminology">
<t>
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 later 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.
</t>
</section>
<section title="IPv4 exhaustion coming sooner than expected">
<t>
Global public IPv4 addresses coming from the IANA free pool are running out faster than many predicted a few years ago. The current model shows that exhaustion could happen as early as 2010 or 2011. See http://ipv4.potaroo.net for more details.
Those projection are based on the assumption that tomorrow is going to be very similar to today, i.e., looking at recent address consumption figures is a good indicator of future consumption patterns. This of course, does not take into account any new large scale deployment of IP technology or any human reaction when facing an upcoming shortage. </t>
<t>
The prediction of the exact date of exhaustion of the IANA free pool is outside the scope of this document, however one conclusion must be drawn from that study: there will be in the near future a point where new global public IPv4 addresses will not be available in large enough quantity thus any new broadband deployment may have to consider the option of not provisioning any (global) IPv4 addresses to the WAN facing interface of edge devices. However, the classic IPv6 deployment model known as "dual stack provisioning" can be a non starter in such environments. </t>
</section>
</section>
<section title="The two long tails">
<t>The dual-stack lite technology is intended for maintaining
connectivity to legacy IPv4 devices and networks after the
exhaustion of the IPv4 address space while service
provider networks make a transition to IPv6-only deployments.
This section describes some of the specific legacy scenarios
addressed by dual-stack lite.</t>
<section title="The long tail of IPv4-only devices in the home">
<t>
Broadband home customers have a mix and match of IP enabled devices.
The most recent operating systems (e.g., Windows Vista, Mac OS X and
various versions of Linux) can operate in an IPv6-only environment;
however most of the legacy devices can't. Windows XP, for example, cannot process DNS requests over IPv6 transport. More, having an operating system that support IPv6 does npot garantee that all the application will support IPv6. Many are still only supporting IPv4.
</t>
<t>
Consumer electronic devices (non traditional PCs) are now more and more conected to home networks. Large TVs with a MOCA or ethernet connection, point-and-shoot camera with a Wifi interface to push pictures on the Web, and many others are now comom and most have been reported to only support IPv4. Those devices are generally not upgradables to support IPv6. Expecting broadband customers to massively upgrade their software (and in most cases the corresponding hardware) to deploy IPv6 is a very tall order. </t>
</section>
<section title="The long tail of content and services available on the Internet">
<t>
IPv6 deployment has taken a very long time to take off, so the current
situation is that almost none of the content and services available on
the Internet are accessible over IPv6. This situation will probably change in the future, but for now, one has to make the assumption that most of the traffic generated by (and to) broadband customers will be sent to (and originated by) IPv4 nodes. Even when the majority of the most popular content will be accessible via IPv6, there will still be a need to access the long tail of content only reachable with IPv4.</t>
</section>
<section title="Additional impact on new broadband deployment">
<t>
Even when considering new, green field, broadband deployments, such as always-on 4G, service providers have to face the same situation as described above, that is, content and services available on the Internet are, today, generally accessible only over IPv4 and not IPv6. This makes adoption of IPv6 for green field deployment difficult. Solutions like NAT-PT, now deprecated, do not provide, as of today, a satisfying and scalable answer.</t>
</section>
<section title="Burden on service providers">
<t>
As a conclusion, broadband service providers may be faced with the
situation where they have IPv4 customers who need to communicate with
IPv4 servers on the Internet but may not have any IPv4 addresses left
to assign to those customers. A service providers may also be in a
situation where it wants to deploy IPv6 in its core network, avoiding
the use of scarce IPv4 addresses. However, without some form of
backward compatibility with IPv4, the cost and the benefits of
deploying IPv6 are not aligned, making incremental IPv6 deployment
very difficult.</t>
</section>
<section title="Dual-prong strategy for broadband">
<t>
Facing the reality of the upcoming completion of the IPv4 address space on pne side and the two long IPv4 tails on the other side, broadband providers can implement a dual-prong strategy when they will face a shortage of IPv4 addresses. First prong is to deploy IPv6 natively. Second is to use a transition bridge to offer an IPv4 service without relying on a unique IPv4 adress per customer. That means haring IPv4 addresses among customers and implementing some form of NAT inside the provider network. This documment proposes a scalable way of doing so by combining two well-known technologies, IP in IP (IPv4/IPv6) tunneling and NAT.
</t>
</section>
</section>
<section title="Expectations for dual-stack lite deployment">
<section title="Expectations for home gateway based scenarios">
<t>
This section mainly address home style networks characterized by the presence of a home gateway.</t>
<t>
Legacy, unmodified, IPv4-only devices inside the home network are expected to keep using
<xref target="RFC1918"/> address space, a-la 192.168.0.0/16 and should be able to access the IPv4 Internet in a similar way they do it today through a home gateway IPv4 NAT.</t>
<t>Unmodified IPv6 capable devices are expected to be able to reach directly the IPv6 Internet, without going through any translation. It is expected that most IPv6 capable devices will also be IPv4 capable and will simply be configured with an IPv4 RFC1918 style address within the home network and access the IPv4 Internet the same way as the legacy IPv4-only devices within the home.</t>
<t>IPv6-only devices that do not include code for an IPv4 stack are outside of the scope of this document.</t>
<t>It is expected that the home gateway is either software upgradable, replaceable or provided by the service provider as part of a new contract. Outside of early IPv6 deployments done prior to IPv4 exhaustion using some form of tunnel, this is pretty much a requirement to deploy any IPv6 service to the home. It is expected that this home gateway will be a dual stack capable device that would only be provisioned with IPv6 on its WAN side. IPv4 and IPv6 are expected to be locally provisioned on any LAN interfaces of such devices. IPv4 addresses on such interfaces are expected to be RFC1918. The key point here is that the service provider will not provision any IPv4 addresses for those home gateway devices.
</t>
</section>
<section title="Expectations for devices directly connected to the broadband service provider network">
<t>
Under this deployment model, devices directly connected to the broadband service provider network without the presence of a home gateway will have to be dual stack capable devices. The service provider facing interface(s) of such device will only be provisioned with IPv6. IPv4 may or may not be provisioned locally on other interfaces of such devices. Similarly to the above section, the key point here is that the service provider will not provision any IPv4 addresses for those directly connected devices.
</t>
<t>It is expected that directly connected devices will implement code to support the dual-stack lite functionality. The minimum support required is an IPv4-in-IPv6 tunnel <xref target="RFC2473"/>.</t>
<t>IPv4-only devices and IPv6-only devices are specifically left out of scope for this document. It is expected that most modern device directly connected to the service provider network would not have memory constraints to implement both stack. </t>
</section>
<section title="Expectations for IP-enabled wireless devices scenario">
<t>
Simialr to host devices directly connected to the broadband servie provider network, the
wireless device will have dual-stack implemented. When the wireless device requests IP
connectivity from the service provider, the service provider will only provision an IPv6
address to the WAN facing interface of the wireless device. No IPv4 (public or RFC1918) address
will be given to the device. When the wireless device accesses IPv4 services, it will be
implemented the dual-stack lite functionality described in section 4.
</t>
</section>
<section title="Application expectations">
<t>
Most applications that today work transparently through an IPv4 home gateway NAT should keep working the same way. However, it is not expected that applications that requires specific port assignment or specific port mapping from the NAT box will keep working. Details and recommendations for application behavior are outside the scope of this document and should be discussed in the behave working group.
</t>
</section>
<section title="Service provider network expectations">
<t>
The dual-stack lite deployment model is based on the notion that IPv4 addresses will be shared by several customers. This implies that the NAT functionality will move from the home gateway to a device hosted within the service provider network. It is important to observe that this functionality does not have to be performed deep in the core of the network and that it might be better implemented close to the aggregation point of customer traffic.
</t>
</section>
</section>
<section title="Dual-stack lite">
<t>
The core ideas behind dual-stack lite are:
<list style="symbols">
<t>Move from a deployment model where a globally unique IPv4
address is provisioned per customer and shared among several
devices within that customer premise to a deployment model where
that globally unique IPv4 address is shared among many customers</t>
<t>Provide transport of IPv4 traffic to customers over a core
network that uses only IPv6
</t>
</list>
Instead of relying on a cascade of NATs or NAT-PT, the dual-stack lite
model is built on IPv4-in-IPv6 tunnels to cross the network to reach
a carrier-grade IPv4-IPv4 NAT. As such, it simplifies the management of
the service provider network by using only IPv6 and provides the
customer the benefit of having only one layer of NAT. The additional
benefit of this model is to gradually introduce IPv6 in the Internet
by making it virtually backward compatible with IPv4.
</t>
<t>
Details about IPv6 tunneling can be found on <xref target="RFC2473"/>,
where the next header is simply 4, for IPv4, as explained in
<xref target="RFC2460"/> and in <xref target="RFC1700"/>.
</t>
<section title="Domain of application">
<t>
The dual-stack lite deployment model has been designed with broadband
networks in mind. It is certainly applicable to other domains although
the authors do not make any specific claim of suitability.
</t>
</section>
<section title="Dual-stack lite interface">
<t>
A dual-stack lite interface on a dual-stack capable device is modeled as a point to point IPv4-in-IPv6
tunnel. Its configuration requires that the device is provisioned with
IPv6 but does not require it to be provisioned with a global IPv4 by the service provider.
</t>
<t>
Any locally unique IPv4 address can be configured on the subscriber
network end of the dual-stack lite tunnel. In the case of dual-stack
lite in which the tunnel endpoint is in a host <xref
target="host-based-arch"/>, it is recommended that dual-stack lite
implementations use any address a.b.c.d in the well known range e.f.g.h/p (to be defined by
IANA) but the first one (all-zero address in the reserved subnet) as the IPv4 host side of the tunnel
and the last one of the same range as the address of the IPv4 default gateway, with a netmask to
cover a /p network.
</t>
<t><list style="symbols">
<t>Note 1: on a multi-home node, several dual-stack like interfaces could end-up being configured.
Each of those interfaces should be configured with a different IPv4 address taken out of the
reserved range.
</t>
<t>Note 2: because of this static configuration using well known values, there is no need to run a
DHCPv4 client on a dual-stack lite interface.</t>
</list></t>
<t>
The service provider network end point of a dual-stack lite interface
is the IPv6 address of a dual-stack lite carrier-grade NAT within the
service provider network.
</t>
</section>
<section title="Dual-stack lite device">
<t>
A dual-stack lite device is a dual-stack capable device implementing a dual-stack lite interface. In the absence of better routing information, a dual-stack lite device will configure a static IPv4 default route over the dual-stack lite interface.</t>
</section>
<section title="Dual-stack lite home router">
<t>
A dual-stack lite home router is a dual-stack capable home router implementing a dual-stack lite interface layered on top of its WAN interface. In the absence of better routing information, a dual-stack lite home router will configure a static IPv4 default route over the dual-stack lite interface. The dual-stack lite home router can use any IPv4 address a.b.c.d out of the e.f.g.h/p prefix (TBD by IANA) to source its own IPv4 packets, embedded into the IPv6 tunnel. If the dual-stack lite home router need to configure a router pointing to an IPv4 default router, it can use the last address in the e.f.g.h/p (TBD by IANA) range for that purpose, with a netmask to cover a /p (TBD by IANA) network.
</t>
<t>
For normal IPv4 packets, a dual-stack lite home router MUST NOT perform any IPv4 address translation.
From egress traffic, the home router passes packets from the LAN interface to the dual-stack lite
interface for IPv6 encapsulation. For ingress traffic, the home router receives packets from the
dual-stack lite interface, decapsulates the IPv6 header, and routes the packets to the target
based on the destination address in the IPv4 header. Either case, the dual-stack lite home router
will not perform address translation.
</t>
<t>
For IPv4 packets fallen into the A+P address space, the A+P enabled home router MUST perform the A+P
mechanism described in <xref target="I-D.ymbk-aplusp"/>. For egress traffic, the home router
references the A+P table using the source IPv4 address and transport port number, and
passes the packets from the LAN interface to the dual-stack lite interface for IPv6 encapsulation.
For ingress traffic, the home router receives packets from the dual-stack lite interface, decapsulates
the IPv6 header, finds the targeted host using the A+P table, and routes the packets accordingly
to the host. The A+P enabled home router handles the A+P table. The dual-stack lite carrier-grade
NAT simply forwards the packets to the IPv4-in-IPv6 tunnel.
</t>
<t>
Besides, the dual-stack lite router must account the tunnel overhead which
reduces the effective MTU size. As such, the router may perform IPv6 fragmentation. More details can be
found in <xref target="mtu"/>.
</t>
</section>
<section title="Dual-stack lite router">
<t>
The concept of a dual-stack lite home router can be extended to any IPv4 router serving as a gateway between a leaf IP domain and the rest of the Internet.
</t>
</section>
<section title="Discovery of the dual-stack lite carrier-grade NAT device">
<t>
The IPv6 address of a dual-stack lite carrier-grade NAT device can be
configured on a dual-stack lite interface using a variety of methods,
ranging from an out-of-band mechanism, manual configuration, a
to-be-defined DHCPv6 option <xref target="I-D.dhankins-softwire-tunnel-option" /> or a to-be-defined IPv6 router
advertisement. It is expected that over time some or all the above
methods, as well as others, will be defined. The requirements and specifications of such methods are out of scope for this document.
</t>
</section>
<section title="Dual-stack lite carrier-grade NAT">
<t>
A dual-stack lite carrier grade NAT is a special IPv4 to IPv4 NAT deployed within the service provider network. It is reachable by customers via a series of point to point IPv4-in-IPv6 tunnels.
</t>
<t>
A dual-stack lite carrier-grade NAT uses a combination of the IPv6 source address of the tunnel and the inner IPv4 source address to establish and maintain the IPv4 NAT mapping table.
</t>
<t>
A dual-stack lite carrier-grade NAT does not have to perform any IPv6-IPv6, IPv6-IPv4 or IPv4-IPv6 NAT.
</t>
<t>A dual-stack lite carrier-grade NAT can use the last IPv4 address of the range e.f.g.h/p (TBD by IANA) in the IPv4 ICMP packets it will originate toward a dual-stack lite client to enable meaningful ping and traceroute results.</t>
<t>A dual-stack lite carrier-grade NAT forwards packets without NAT for those fallen in the A+P address
space.</t>
</section>
</section>
<section title="Example architectures">
<t>The underlying technology behind dual-stack lite is the combination of two
well-known technologies: NAT and tunneling. This combination can be best described using the
terminology developed in the softwire working group as Softwire NAT, or SNAT.</t>
<t>Two architectures can be deployed for dual-stack lite. One is
targeting the legacy installed base of IPv4 only hosts (and dual-stack capable hosts) sitting
behind a gateway. The second is targeting dual-stack capable hosts initiating the tunnel
themselves. </t>
<section title="Router-based architecture">
<t>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 device is important.</t>
<t>
Consider a scenario where a Dual-Stack lite home gateway is provisioned only with IPv6 in the WAN port, no IPv4. The home gateway acts as an IPv4 DCHP server for the LAN network (wireline and wireless) handing out RFC1918 addresses. In addition, the home gateway may support IPv6 Auto-Configuration and/or DHCPv6 server for the LAN network. When an IPv4-only device connects to the home gateway, the gateway will hand it out a RFC1918 address. When a dual-stack capable device connects to the home gateway, the gateway will hand out a RFC1918 address and a global IPv6 address to the device. Besides, the home gateway will create an IPv4-in-IPv6 softwire tunnel <xref target="RFC5571"/>to a Carrier-Grade NAT. The Carrier-Grade NAT will reside in
the service provider network.
</t>
<t>
When the device accesses IPv6 service, it will send the IPv6 datagram to the home gateway natively. The home gateway will route the traffic upstream to the default gateway.</t>
<t>
When the device accesses IPv4 service, it will source the IPv4 datagram with the RFC1918 address and send the IPv4 datagram to the home gateway. The home gateway will encapsulate the IPv4 datagram inside the IPv4-over-IPv6 softwire tunnel and forward the IPv6 datagram to the Carrier-Grade NAT. This contrasts what the home gateways normally do today which will NAT the RFC1918 address to the public IPv4 address and route the datagram upstream. When the Carrier-Grade NAT receives the IPv6 datagram, it will de-capsulate the IPv6 header and perform an IPv4-to-IPv4 NAT on the source address.
</t>
<t>As illustrated in <xref target="gnat-arch"/>, this dual-stack
lite deployment model consists of three components: the
dual-stack lite home router, the dual-stack lite carrier-grade
NAT and a softwire between the softwire initiator (SI) <xref target="RFC5571"/> in the
dual-stack lite home router and the softwire concentrator (SC) <xref target="RFC5571"/> in
the dual-stack lite carrier-grade NAT. The dual-stack lite
carrier-grade NAT performs IPv4-IPv4 NAT translations to
multiplex multiple subscribers through a single global IPv4
address. Overlapping address spaces used by subscribers are
disambiguated through the identification of tunnel endpoints.</t>
<figure align="center" anchor="gnat-arch" title="SNAT gateway-based architecture">
<preamble></preamble>
<artwork align="left"><![CDATA[
+-----------+
| Host |
+-----+-----+
|10.0.0.1
|
|
|10.0.0.2
+---------|---------+
| | |
|dual-stack lite home router
|+--------+--------+|
|| SNAT SI ||
|+--------+--------+|
+--------|||--------+
|||2001:0:0:1::1
|||
|||<-IPv4-in-IPv6 softwire
|||
-------|||-------
/ ||| \
| ISP core network |
\ ||| /
-------|||-------
|||
|||2001:0:0:2::1
+--------|||--------+
|dual-stack lite carrier-grade NAT
|+--------+--------+|
|| SNAT SC ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
|129.0.0.1
|
--------|--------
/ | \
| Internet |
\ | /
--------|--------
|
|128.0.0.1
+-----+-----+
| IPv4 Host |
+-----------+
]]></artwork>
<postamble></postamble>
</figure>
<t>Notes:
<list style='symbols'>
<t>The dual-stack lite home router is not required to be on the
same link as the host</t>
<t>The dual-stack lite home router could be replaced by a
dual-stack lite router in the service provider network</t>
</list>
</t>
<t>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.</t>
<section title="Example message flow">
<t>In the example shown in <xref target="outbound-dg" />, the
translation tables in the dual-stack lite carrier-grade NAT is
configured to forward between IP/TCP (10.0.0.1/10000) and IP/TCP
(129.0.0.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 a datagram with IP SRC address
129.0.0.1 and TCP SRC port 5000 in the Internet.</t>
<figure align="center" anchor="outbound-dg" title="Outbound Datagram">
<preamble></preamble>
<artwork align="left"><![CDATA[
+-----------+
| Host |
+-----+-----+
| |10.0.0.1
IPv4 datagram 1 | |
| |
v |10.0.0.2
+---------|---------+
| | |
|dual-stack lite home router
|+--------+--------+|
|| SNAT SI ||
|+--------+--------+|
+--------|||--------+
| |||2001:0:0:1::1
IPv6 datagram 2| |||
| |||<-IPv4-in-IPv6 softwire
| |||
-----|-|||-------
/ | ||| \
| ISP core network |
\ | ||| /
-----|-|||-------
| |||
| |||2001:0:0:2::1
+------|-|||--------+
|dual-stack lite carrier-grade NAT
| v ||| |
|+--------+--------+|
|| SNAT SC ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
| |129.0.0.1
IPv4 datagram 3 | |
| |
-----|--|--------
/ | | \
| Internet |
\ | | /
-----|--|--------
| |
v |128.0.0.1
+-----+-----+
| IPv4 Host |
+-----------+
]]></artwork>
<postamble></postamble>
</figure>
<texttable title="Datagram header contents">
<ttcol align="right">Datagram</ttcol>
<ttcol align="right">Header field</ttcol>
<ttcol align="left">Contents</ttcol>
<c>IPv4 datagram 1</c>
<c>IPv4 Dst</c>
<c>128.0.0.1</c>
<c></c>
<c>IPv4 Src</c>
<c>10.0.0.1</c>
<c></c>
<c>TCP Dst</c>
<c>80</c>
<c></c>
<c>TCP Src</c>
<c>10000</c>
<c>---------------</c>
<c>------------</c>
<c>-------------</c>
<c>IPv6 Datagram 2</c>
<c>IPv6 Dst</c>
<c>2001:0:0:2::1</c>
<c></c>
<c>IPv6 Src</c>
<c>2001:0:0:1::1</c>
<c></c>
<c>IPv4 Dst</c>
<c>128.0.0.1</c>
<c></c>
<c>IPv4 Src</c>
<c>10.0.0.1</c>
<c></c>
<c>TCP Dst</c>
<c>80</c>
<c></c>
<c>TCP Src</c>
<c>10000</c>
<c>---------------</c>
<c>------------</c>
<c>-------------</c>
<c>IPv4 datagram 3</c>
<c>IPv4 Dst</c>
<c>128.0.0.1</c>
<c></c>
<c>IPv4 Src</c>
<c>129.0.0.1</c>
<c></c>
<c>TCP Dst</c>
<c>80</c>
<c></c>
<c>TCP Src</c>
<c>5000</c>
</texttable>
<t>When datagram 1 is received by the dual-stack lite home router, the SI function
encapsulates the datagram in datagram 2 and forwards it to
the dual-stack lite carrier-grade NAT over the softwire.</t>
<t>When it receives datagram 2, the SC in the dual-stack lite carrier-grade NAT hands the
IPv4 datagram to the NAT, which determines from its translation
table that the datagram received on Softwire_1 with TCP SRC port
10000 should be translated to datagram 3 with IP SRC address
129.0.0.1 and TCP SRC port 5000.</t>
<t><xref target="inbound-dg" /> shows an inbound message received
at the dual-stack lite carrier-grade NAT. When the NAT function
in the dual-stack lite carrier-grade NAT receives datagram 1, it
looks up the IP/TCP DST in its translation table. In the example
in Figure 3, the NAT translates the TCP DST port to 10000, sets
the IP DST address to 10.0.0.1 and hands the datagram to the SC
for transmission over Softwire_1. The SI in the dual-stack lite
home router decapsulates IPv4 datagram from the inbound softwire
datagram, and forwards it to the host.</t>
<figure align="center" anchor="inbound-dg" title="Inbound Datagram">
<preamble></preamble>
<artwork align="left"><![CDATA[
+-----------+
| Host |
+-----+-----+
^ |10.0.0.1
IPv4 datagram 3 | |
| |
| |10.0.0.2
+---------|---------+
| +-+-+ |
|dual-stack lite home router
|+--------+--------+|
|| SNAT SI ||
|+--------+--------+|
+--------|||--------+
^ |||2001:0:0:1::1
IPv6 datagram 2 | |||
| |||<-IPv4-in-IPv6 softwire
| |||
-----|-|||-------
/ | ||| \
| ISP core network |
\ | ||| /
-----|-|||-------
| |||
| |||2001:0:0:2::1
+------|-|||--------+
|dual-stack lite carrier-grade NAT
|+--------+--------+|
|| SNAT SC ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
^ |129.0.0.1
IPv4 datagram 1 | |
| |
-----|--|--------
/ | | \
| Internet |
\ | | /
-----|--|--------
| |
| |128.0.0.1
+-----+-----+
| IPv4 Host |
+-----------+
]]></artwork>
<postamble></postamble>
</figure>
<texttable title="Datagram header contents">
<ttcol align="right">Datagram</ttcol>
<ttcol align="right">Header field</ttcol>
<ttcol align="left">Contents</ttcol>
<c>IPv4 datagram 1</c>
<c>IPv4 Dst</c>
<c>129.0.0.1</c>
<c></c>
<c>IPv4 Src</c>
<c>128.0.0.1</c>
<c></c>
<c>TCP Dst</c>
<c>5000</c>
<c></c>
<c>TCP Src</c>
<c>80</c>
<c>---------------</c>
<c>------------</c>
<c>-------------</c>
<c>IPv6 Datagram 2</c>
<c>IPv6 Dst</c>
<c>2001:0:0:1::1</c>
<c></c>
<c>IPv6 Src</c>
<c>2001:0:0:2::1</c>
<c></c>
<c>IPv4 Dst</c>
<c>10.0.0.1</c>
<c></c>
<c>IP Src</c>
<c>128.0.0.1</c>
<c></c>
<c>TCP Dst</c>
<c>10000</c>
<c></c>
<c>TCP Src</c>
<c>80</c>
<c>---------------</c>
<c>------------</c>
<c>-------------</c>
<c>IPv4 datagram 3</c>
<c>IPv4 Dst</c>
<c>10.0.0.1</c>
<c></c>
<c>IPv4 Src</c>
<c>128.0.0.1</c>
<c></c>
<c>TCP Dst</c>
<c>10000</c>
<c></c>
<c>TCP Src</c>
<c>80</c>
</texttable>
</section>
<section title="Translation details">
<t>The dual-stack lite carrier-grade NAT 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.</t>
<t>In <xref target="outbound-dg"/>, the translator network
interface in the dual-stack lite carrier-grade NAT is on the
Internet, and the softwire interface connects to the dual-stack
lite home router. The dual-stack lite carrier-grade NAT
translator is configured as follows:
<list style="hanging">
<t hangText="Network interface:">Translate IPv4 destination
address and TCP destination port to the softwire identifier
and TCP destination port</t>
<t hangText="Softwire interface:">Translate softwire
identifier and TCP source port to IPv4 source address and TCP
source port</t>
</list>
</t>
<t>Here is how the translation in <xref target="inbound-dg"/>
works:
<list style="symbols">
<t>Datagram 1 is received on the dual-stack lite carrier-grade NAT 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 hands the
datagram to the SE to be forwarded over the softwire.</t>
<t>The IPv4 datagram is received on the dual-stack lite home router SI. The SI
function extracts the IPv4 datagram and the dual-stack lite home router forwards
datagram 3 to the host.</t>
</list>
</t>
<texttable title="Dual-Stack lite carrier-grade NAT translation table">
<ttcol align="right">Softwire-Id/IPv4/Port</ttcol>
<ttcol align="left">IPv4/Port</ttcol>
<c>2001:0:0:1::1/10.0.0.1/TCP 10000</c>
<c>129.0.0.1/TCP 5000</c>
</texttable>
<t> The Softwire-Id is the IPv6 address assigned to the Dual-Stack lite home gateway. Hosts behind
the same Dual-Stack lite home router have the same Softwire-Id. The source IPv4 is the RFC1918
addressed assigned by the Dual-Stack home router which is unique to each host behind the home gateway.
The Dual-Stack lite carrier-grade NAT would receive packets sourced from different IPv4 addresses
in the same softwire tunnel. The carrier-grade NAT 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. </t>
</section>
</section>
<section anchor="host-based-arch" title="Host based architecture">
<t>
This architecture is targeted at new, large scale deployments of dual-stack capable devices implementing a dual-stack lite interface.
</t>
<t>
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 an IPv6 global address. Besides, the host device will pre-configure a well-known IPv4 non-routable address (see IANA section). This well-known IPv4 non-routable address is similar to the 127.0.0.1 loopback address. Every host device implemented 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-over-IPv6 softwire tunnel to a Carrier Grade NAT. The Carrier Grade NAT will reside in the service provider network.</t>
<t>
When the device accesses IPv6 service, the device will send the IPv6 datagram natively to the default gateway. </t>
<t>
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-over-IPv6 softwire tunnel and send the IPv6 datagram to the Carrier-Grade NAT. When the Carrier-Grade NAT receives the IPv6 datagram, it will de-capsulate the IPv6 header and perform IPv4-to-IPv4 NAT on the source address.</t>
<t>
This scenario works on both wireline and wireless networks. A typical wireless device will connect directly to the service provider without home gateway in between.
</t>
<t>As illustrated in <xref target="gnat-arch2"/>, this dual-stack
lite deployment model consists of three components: the
dual-stack lite host, the dual-stack lite carrier-grade NAT and a
softwire between the softwire initiator (SI) in the host and the
softwire concentrator (SC) in the dual-stack lite carrier-grade
NAT. The dual-stack lite host is assumed to have IPv6 service and
can exchange IPv6 traffic with the dual-stack lite carrier-grade
NAT.</t>
<t>The dual-stack lite carrier-grade NAT performs IPv4-IPv4 NAT
translations to multiplex multiple subscribers through a single
global IPv4 address. Overlapping IPv4 address spaces used by the
dual-stack lite hosts are disambiguated through the
identification of tunnel endpoints.</t>
<t>In this situation, the dual-stack lite host configures the
IPv4 address a.b.c.d out of the well-known range e.f.g.h/p (TBD by IANA) on it dual-stack
lite interface acting as the SI. It also configure the last IPv4 address of the
reserved range as the address of its default gateway, with a netmask to
cover a /p (TBD by IANA) network.</t>
<figure align="center" anchor="gnat-arch2" title="SNAT host-based architecture">
<preamble></preamble>
<artwork align="left"><![CDATA[
+-------------------+
| |
|Host a.b.c.d |
|+--------+--------+|
|| SNAT SI ||
|+--------+--------+|
+--------|||--------+
|||2001:0:0:1::1
|||
|||<-IPv4-in-IPv6 softwire
|||
-------|||-------
/ ||| \
| ISP core network |
\ ||| /
-------|||-------
|||
|||2001:0:0:2::1
+--------|||--------+
|dual-stack lite carrier-grade NAT
|+--------+--------+|
|| SNAT SC ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
|129.0.0.1
|
--------|--------
/ | \
| Internet |
\ | /
--------|--------
|
|128.0.0.1
+-----+-----+
| IPv4 Host |
+-----------+
]]></artwork>
<postamble></postamble>
</figure>
<t>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.</t>
<section title="Example message flow">
<t>In the example shown in <xref target="outbound-dg2" />, the
translation tables in the dual-stack lite carrier-grade NAT is
configured to forward between IP/TCP (a.b.c.d/10000) and IP/TCP
(129.0.0.1/5000). That is, a datagram received from the host at
address a.b.c.d, using TCP DST port 10000 will be translated a
datagram with IP SRC address 129.0.0.1 and TCP SRC port 5000 in
the Internet.</t>
<figure align="center" anchor="outbound-dg2" title="Outbound Datagram">
<preamble></preamble>
<artwork align="left"><![CDATA[
+-------------------+
| |
|Host a.b.c.d |
|+--------+--------+|
|| SNAT SI ||
|+--------+--------+|
+--------|||--------+
| |||2001:0:0:1::1
IPv6 datagram 1| |||
| |||<-IPv4-in-IPv6 softwire
| |||
-----|-|||-------
/ | ||| \
| ISP core network |
\ | ||| /
-----|-|||-------
| |||
| |||2001:0:0:2::1
+------|-|||--------+
|dual-stack lite carrier-grade NAT
| v ||| |
|+--------+--------+|
|| SNAT SC ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
| |129.0.0.1
IPv4 datagram 2 | |
-----|--|--------
/ | | \
| Internet |
\ | | /
-----|--|--------
| |
v |128.0.0.1
+-----+-----+
| IPv4 Host |
+-----------+
]]></artwork>
<postamble></postamble>
</figure>
<texttable title="Datagram header contents">
<ttcol align="right">Datagram</ttcol>
<ttcol align="right">Header field</ttcol>
<ttcol align="left">Contents</ttcol>
<c>IPv6 Datagram 1</c>
<c>IPv6 Dst</c>
<c>2001:0:0:2::1</c>
<c></c>
<c>IPv6 Src</c>
<c>2001:0:0:1::1</c>
<c></c>
<c>IPv4 Dst</c>
<c>128.0.0.1</c>
<c></c>
<c>IPv4 Src</c>
<c>a.b.c.d</c>
<c></c>
<c>TCP Dst</c>
<c>80</c>
<c></c>
<c>TCP Src</c>
<c>10000</c>
<c>---------------</c>
<c>------------</c>
<c>-------------</c>
<c>IPv4 datagram 2</c>
<c>IPv4 Dst</c>
<c>128.0.0.1</c>
<c></c>
<c>IPv4 Src</c>
<c>129.0.0.1</c>
<c></c>
<c>TCP Dst</c>
<c>80</c>
<c></c>
<c>TCP Src</c>
<c>5000</c>
</texttable>
<t>When sending an IPv4 packet, the dual-stack lite host
encapsulates it in datagram 1 and forwards it to
the dual-stack lite carrier-grade NAT over the softwire.</t>
<t>When it receives datagram 1, the SC in the dual-stack lite
carrier-grade NAT hands the IPv4 datagram to the NAT, which
determines from its translation table that the datagram received
on Softwire_1 with TCP SRC port 10000 should be translated to
datagram 3 with IP SRC address 129.0.0.1 and TCP SRC port
5000.</t>
<t><xref target="inbound-dg2" /> shows an inbound message
received at the dual-stack lite carrier-grade NAT. When the NAT
function in the dual-stack lite carrier-grade NAT receives
datagram 1, it looks up the IP/TCP DST in its translation table.
In the example in Figure 3, the NAT translates the TCP DST port
to 10000, sets the IP DST address to a.b.c.d and hands the
datagram to the SC for transmission over Softwire_1. The SI in
the dual-stack lite home router decapsulates IPv4 datagram from
the inbound softwire datagram, and forwards it to the host.</t>
<figure align="center" anchor="inbound-dg2" title="Inbound Datagram">
<preamble></preamble>
<artwork align="left"><![CDATA[
+-------------------+
| |
|Host a.b.c.d |
|+--------+--------+|
|| SNAT SI ||
|+--------+--------+|
+--------|||--------+
^ |||2001:0:0:1::1
IPv6 datagram 2 | |||
| |||<-IPv4-in-IPv6 softwire
| |||
-----|-|||-------
/ | ||| \
| ISP core network |
\ | ||| /
-----|-|||-------
| |||
| |||2001:0:0:2::1
+------|-|||--------+
|dual-stack lite carrier-grade NAT
| | ||| |
|+--------+--------+|
|| SNAT SC ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
^ |129.0.0.1
IPv4 datagram 1 | |
-----|--|--------
/ | | \
| Internet |
\ | | /
-----|--|--------
| |
| |128.0.0.1
+-----+-----+
| IPv4 Host |
+-----------+
]]></artwork>
<postamble></postamble>
</figure>
<texttable title="Datagram header contents">
<ttcol align="right">Datagram</ttcol>
<ttcol align="right">Header field</ttcol>
<ttcol align="left">Contents</ttcol>
<c>IPv4 datagram 1</c>
<c>IPv4 Dst</c>
<c>129.0.0.1</c>
<c></c>
<c>IPv4 Src</c>
<c>128.0.0.1</c>
<c></c>
<c>TCP Dst</c>
<c>5000</c>
<c></c>
<c>TCP Src</c>
<c>80</c>
<c>---------------</c>
<c>------------</c>
<c>-------------</c>
<c>IPv6 Datagram 2</c>
<c>IPv6 Dst</c>
<c>2001:0:0:1::1</c>
<c></c>
<c>IPv6 Src</c>
<c>2001:0:0:2::1</c>
<c></c>
<c>IPv4 Dst</c>
<c>a.b.c.d</c>
<c></c>
<c>IP Src</c>
<c>128.0.0.1</c>
<c></c>
<c>TCP Dst</c>
<c>10000</c>
<c></c>
<c>TCP Src</c>
<c>80</c>
</texttable>
</section>
<section title="Translation details">
<t>The translations happening in the dual-stack lite
carrier-grade NAT are the same as in the previous examples. The
well known IPv4 address a.b.c.d out of the e.f.g.h/p (TBD by IANA) range used by all the hosts are
disambiguated by the IPv6 source address of the softwire.
</t>
<texttable title="Dual-Stack lite carrier-grade NAT translation table">
<ttcol align="right">Softwire-Id/IPv4/Port</ttcol>
<ttcol align="left">IPv4/Port</ttcol>
<c>2001:0:0:1::1/a.b.c.d/TCP 10000</c>
<c>129.0.0.1/TCP 5000</c>
</texttable>
<t> The Softwire-Id is the IPv6 address assigned to the Dual-Stack host. Each host has an unique
Softwire-Id. The source IPv4 address is one of the well-known IPv4 address (TBD by INAN). The
carrier-grade NAT
could receive packets from different hosts sourced from the same IPv4 well-known address from different
softwire tunnels. Similar to the SNAT gateway architecture, the Dual-Stack lite carrier grade NAT
combines the Softwire-Id and IPv4
address/Port [Softwire-Id, IPv4+Port] to uniquely identify the individual host.
</t>
</section>
</section>
</section>
<section title="Encapsulations">
<t>In its simplest deployment model, dual-stack lite only requires IPv4 in IPv6 encapsulation. In more complex scenario where a site gateway would play the role of the softwire initiator, more complex encapsulation might be desired. Thus dual-stack lite hosts, dual-stack lite home gateway and dual-stack lite NAT devices MUST at minimum implement IPv4 in IPv6 encapsulation. On top of that, dual-stack lite NAT devices MAY also support other encapsulation, like L2TPv2/v3, GRE, MPLS,... If they do, they SHOULD support L2TPv2 as defined in the IETF softwire hub & spoke framework.
</t>
</section>
<section title="DNS considerations">
<t>
A dual-satck lite home gateway is only provision on the WAN interface with IPv6. As such, all configuration information have to be passed by the broadband service provider over IPv6. This means that the home gateway will typically use DHCPv6 <xref target="RFC3315"/> to learn the address of the DNS recursive server as in <xref target="RFC3646"/>. However, DHCPv6 only defines an option to pass an IPv6 address of a DNS resolver, not an IPv4 address.
IPv6 node inside the home network may very well use this IPv6 address to reach the DNS resolver, but IPv4 nodes can't. They need to be configured with an IPv4 address of a recursive DNS server.
</t>
<t>
The recommended way to solve this issue is to configure the home gateway to act as a DNS proxy, advertizing itself internally with DHCPv4 as an IPv4 DNS resolver and forwarding the DNS request over IPv6 to the IPv6 DNS resolver address it has received over DHCPv6. If the home gateway is also acting as a DHCPv6 server for internal host and is implementing the DHCPv6 DNS option, it can either also act as a DNS proxy or simply pass through the IPv6 address of the service provider DNS recursive server. While implementing a DNS proxy, the home gateway should follow recommendations in <xref target="I-D.ietf-dnsext-dnsproxy"/>.
</t>
</section>
<section title="Carrier-grade NAT considerations">
<t>
A dual-stack lite carrier-grade NAT SHOULD implement behavior conforming to the best current practice, currently documented in <xref target="RFC4787"/>, <xref target="I-D.ietf-behave-tcp"/> and <xref target="I-D.ietf-behave-nat-icmp"/>. Other requirements for carrier-grade NATs can be found in <xref target="I-D.nishitani-cgn" />. </t>
</section>
<section title="Port allocation">
<t>Because IPv4 addresses will be shared among customers and potentially a large address space reduction factor may be applied, in average, only a limited number N of TCP or UDP port numbers will be available per customer. This means that applications opening a very large number of TCP ports may have a harder time to work. For example, it has been reported that a very well know web site was using AJAX techniques and was opening up to 69 TCP ports per web page. If we make the hypothesis of an address space reduction of a factor 100 (one IPv4 address per 100 customers), and 65k ports per IPv4 addresses available, that makes a total of N=650 ports available simultaneously to be shared among the various devices behind the dual-stack lite tunnel end-point.
</t>
<t>
There is an important operational difference if those N ports are pre-allocated in a cookie-cutter fashion versus allocated on demand by incoming connections. This is a difference between an average of N ports and a maximum of N ports. Several service providers have reported an average number of connections per customer in the single digit. At the opposite end, thousands or tens of thousands of ports could be use in a peak by any single customer browsing a number of AJAX/Web 2.0 sites. With that average number of connections per customers in mind, having an address space reduction of a factor 100 or more is realistic.
</t>
<t>
Application expecting incoming connections, such a peer-to-peer ones, have become popular. Those applications use a very limited number of ports, usually a single one. Making sure those applications keep working in a dual-stack lite environment is important. Similarly, there is a growing list of applications that require some king of ALG to work through a NAT. Service provider carrier-grade NATs should not to be in the way of the deployment of such applications. As such, there is a legitimate need to leave certain ports under the control of the end user. This argue for an hybrid environment, where most ports are dynamically managed by the carrier-grade NAT in a shared pool and a limited number are dedicated per users and controlled by them.
</t>
<t>
More considerations on sharing IPv4 addresses can be found in <xref target="I-D.ford-shared-addressing-issues"/>.
</t>
<section title="Static port reservation">
<t>
A service provider can reserve a static number of ports per user. Note: those could be TCP and/or UDP ports. The simplest way to allow users to control the associated NAT bindings is to offer a web interface (for example as part of the service provider portal) where, once authenticated, a user can configure each dedicated external IPv4 address/port binding on the carrier-grade NAT in one of the following way:
<list style="symbols">
<t>
either direct the carrier-grade NAT to forward incoming traffic on this address/port to the dual-stack lite home gateway, and let this device deal with it. This required support for <xref target="I-D.ymbk-aplusp">A+P</xref> semantic on the home gateway.
</t>
<t>
or direct the carrier-grade NAT to rewrite the destination address in those incoming packets to a private IPv4 address within the home network. For obvious security reasons, redirection to global IPv4 address should not be authorized. Note: this behavior is very similar to the port forwarding function found in most home gateways.
</t>
</list>
</t>
<t>
The exact number of ports reserved per user is left at the discretion of the service provider.</t>
</section>
<section title="Dynamic port reservation">
<section title="UPnP">
<t>
One could be tempted to have the home gateway relaying UPnP messages over the tunnel to the carrier-grade NAT. Unfortunately, this would not work.
Some applications insist on running on a well-known port number (or port range) using UPnP to request the NAT to reserve that port. Those ports may or may not be available; they could be used by another customer. Using UPnP, a NAT box does not have any way to redirect such applications to use another port, the only option is to deny the request. Those applications typically then cycle through a small range of ports (typically 10 or so) until they abort. The likelihood of those ports being all already in use by other users is very high. As such, UPnP cannot be supported as-is in a dual-stack lite environment.
</t>
<t>oNote: the UPnP forum has been reported to address this issue in an upcoming version of the IGD profile.
</t>
</section>
<section title="NAT-PMP">
<t>
<xref target="I-D.cheshire-nat-pmp">NAT-PMP</xref> offers a better semantic, by enabling the NAT to redirect the application to use another unallocated port. A Dual-stack lite home gateway could proxy the NAT-PMP messages to the carrier-grade NAT through the tunnel.
</t>
</section>
<section title="DHCPv6">
<t> If more ports need to be reserved outside of that static dedicated range, a DHCPv6 option such as <xref target="I-D.bajko-v6ops-port-restricted-ipaddr-assign"/> may also be an interesting approach. This may be limited to the A+P semantic mentioned above, as there might not be a way to explicitly control the port forwarding semantic. Also, there are concerns that this would lead to a cooky cutter distribution of ports per customers, dramatically reducing the ratio of customer per IPv4 address.
</t>
</section>
</section>
</section>
<section title="Other carrier-grade NAT considerations">
<section title="ALG">
<t>
The carrier-grade NAT should only perform a minimum number of ALG for the classic applications such as FTP, RTSP/RTP, IPsec and PPTP VPN pass-through and enable the users to use their own ALG on statically or dynamically reserved port instead.
</t>
<t>
In particular, the carrier-grade NAT SHOULD NOT perform any ALG on the ports reserved either statically or dynamically for a user.
</t>
</section>
<section title="MTU" anchor="mtu">
<t>
Using an encapsulation (IP-in-IP or L2TP) to carry IPv4 traffic over IPv6 will reduce the effective MTU
of the datagram. Unfortunately, path MTU discovery <xref target="RFC1191"/>
is not a reliable method to deal with this problem. For IPv4-in-IPv6 softwire
<xref target="RFC2473"/>, we suggest to increase the MTU size to the link-MTU + 40 bytes to
all the links between the Dual-Stack lite Tunnel Entry-Point and Tunnel Exit-Point
<xref target="RFC2473"/>. The
extra 40 bytes can accommodate both the IPv6 encapsulation header and the IPv4 datagram
without fragmenting the IPv6 packet. If the link MTU cannot be increased, the Tunnel Entry-Point
and Tunnel Exit-Point MUST fragment and reassemble the over-sized datagram after
IPv6 encapsulation. When the Tunnel Entry-Point forwards a packet larger than the MTU after encapsulation,
it MUST fragment the over-sized IPv6 packet into two IPv6 packets.
Fragmentation happens because the resulted IPv6 packet
after encapsulation is larger than MTU. Thus, fragmentation MUST happen after the encapsulation on the
IPv6 packet. When the Tunnel Exit-Point receives
the fragmented IPv6 packets, it MUST reassemble and decapsulate the packets. Detailed procedure has
been specified in <xref target="RFC2473"/> Section 7.2.
</t>
<t>
There is a performance trade-off for this approach. Fragmentation at
the Tunnel Entry-Point is a light-weighted 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 carrier-grade NAT is the
Tunnel Exit-Point for many tunnels. If many clients simultaneously source large number of
fragmented packets to the carrier-grade NAT, this will demand the carrier-grade NAT to
buffer and consume enormous resources to keep track of the flows. This reassembly process
will significantly impact the carrier-grade NAT performance. However, this impact
only happens when many clients simultaneously source large IPv4 packets. Since we believe that
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), so reassembly is only a fraction of
the overall carrier-grade NAT's workload.
</t>
<t> Fragmentation/Reassembly could be expensive. We suggest a method to optimize TCP sessions to
reduce the need to fragment and reassemble TCP packets.
When the carrier-grade NAT receive the first TCP SYN packet which is used to initiate a TCP session,
the carrier-grade NAT rewrites the MSS option in the TCP header to a lower value. When the
carrier-grade NAT receives
the returned TCP SYN-ACK for that session, it will also rewrite the MSS option to a lower value.
In the case of using simple IPv4-in-IPv6, the suggested maximum MSS value is MTU substracts
(IPv6 header + TCP header + IPv4 header). For example: If the MTU is 1500, the MSS value would be
re-written to 1500 - 40 - 20 - 20 = 1420.
This optimization tries to assure that the TCP client and server generate packets smaller
than the MTU size after encapsulation. Hence, fragmentation and reassembly can be avoided
throughout the life-time of this TCP session.
</t>
<t> TCP Authentication Option (TCP-AO) <xref target="I-D.ietf-tcpm-tcp-auth-opt"/> is specified
to protect against replays for TCP sessions. In TCP-AO, when the TCP option flag sets to 0,
all TCP options are included in the MAC calculation.
Modifying MSS option by carrier-grade NAT will alter the Message Authentication Codes (MAC) calculation.
Thus, the TCP-AO originator
will consider this is a Man-in-the-Middle attack and fails the TCP-AO check. When the TCP option flag
sets to 1, TCP-AO will exclude all TCP options in the MAC calculation. Modifying
MSS option will not alter the MAC calculation. Thus, TCP-AO originator will pass the TCP-AO check.
The default TCP-AO behavior is to set TCP option flag to 0, so using TCP-AO in default mode with
this optimization will cause TCP-AO check to fail. For those consider to use MSS optimization,
we recommend to set the TCP option flag to 1 when using TCP-AO. TCP-AO is specified to replace
TCP MD5 Signature Option (TCP-MD5) <xref target="RFC2385"/>. TCP-MD5 will continue to work
because TCP-MD5 applies the MD5 algorithm on the TCP header, excluding options, and assuming a
checksum of zero.
</t>
</section>
</section>
<section title="Future work">
<t>The items described bellow could be included in a future version of this document or be the object of a separate document.</t>
<section title="Multicast considerations">
<t>
This document only describes unicast IPv4 as IPv4 Multicast is not widely deployed in broadband networks. Some multicast IPv4 considerations might to be discussed as well in a future revision of this document.
</t>
</section>
<section title="3rd party carrier-grade NAT">
<t>The dual-stack lite architecture can be easily extended to support 3rd party carrier-grade NATs. The dual-stack lite interface just need to be pointed to the IPv6 address of that 3rd party carrier-grade NAT instead of the IPv6 address of the service provider carrier-grade NAT. Implementation of dual-stack lite should enable users to override the mechanism used for automatic discovery of the carrier grade NAT and, for example, manually enter the DNS name of the selected carrier-grade NAT.</t>
</section>
<section title="Interface initialization">
<t>The initialization sequence of each interface of a dual-stack lite node need to be analyzed and heuristics need to be defined to determined if each interface operates in IPv4 mode, IPv6 mode, dual-stack mode or dual-stack lite mode. The absence/presence of the DHCPv6 option discussed above in requests/responses could be a trigger to decide in which mode to operate.</t>
</section>
</section>
<section title="Comparison with an architecture with multiple-layers of NAT">
<t>
An alternative architecture could consist on layering multiple levels of IPv4-IPv4 NAT toward the edges of the service provider network. Such architecture has a key advantage: it would work with any existing IPv4 home gateway. However, it would have a number of drawbacks:
</t>
<t>
<list style="symbols">
<t>Each NAT device in the path will have its own application level gateways, increasing the odds of failure or miss-configuration.</t>
<t>The larger private IPv4 address space available today is Net 10.0.0.0/8. It can in theory accommodate for about 16 million addresses, in practice, with an 80% allocation efficiency, it can address about 13 million devices. This may not be enough for existing and future large scale deployments, thus multiple overlapping copies of Net 10 might have to be used simultaneously. This in itself create more complexity:
<list style="symbols">
<t>If multiple copies of Net 10 are in use, network troubleshooting gets more difficult. One first need to figure out in which Net 10 realm the customer is before sending a ping to a home gateway to test it. This means that provisioning systems need to be modified to include this information.</t>
<t>Multiple overlapping copies of Net 10 often intersect in some places with routers and firewalls. The configuration of such devices need to carefully take into accounts the overlapping address space. Debugging problems created by miss-configuration can be time consuming.</t>
</list></t>
<t>Both legacy customers with global IPv4 addresses and new customers with private IPv4 addresses may be connected to the same aggregation router. That router will have to make the decision to send packets directly to the Internet or via a translator based on the source address of those packets, which is known as source-based routing. Although not impossible to implement, this adds complexity to the management of the network.</t>
</list>
</t>
<t>None of the issues described above are show stoppers, but put together, they seriously increase the complexity of the management of the network.</t>
</section>
<section title="Comparison with NAT-PT (or its potential replacements)">
<t>
NAT-PT <xref target="RFC2766"/> deals with the translation from IPv6 to IPv4 and vice versa. As such, it would not help solving the problem of offering IPv4 service to legacy IPv4 hosts. NAT-PT is targeted at green field IPv6 deployments, allowing them to access services and content on the IPv4 Internet. In that sense, NAT-PT could be in competition with dual-stack lite for green field deployment of new devices directly connected to the broadband service provider network.
</t>
<t>In this situation, NAT-PT has the advantage of enabling to remove entirely the IPv4 stack on edge devices. This may be critical on sensor type devices with a very small memory footprint. However, it is unclear if such devices really need to have access to the whole global IPv4 Internet in the first place or if they only need to communicate with servers that can be made IPv6 enable.</t>
<t>In the more general case, dual-stack lite has several advantages over NAT-PT:
</t>
<t>
<list style="symbols">
<t>Dual-stack lite does not require any hack to the DNS. In other words, there is no need to synthesize fake AAAA records to represent IPv4 addresses. This make DNSsec works more reliably.</t>
<t>Because of the DNS ALG hack, NAT-PT places restriction on the topology, in most cases requiring that all exiting traffic go through a single point of contention. Because there is no DNS ALG with dual-stack lite and because each dual-stack lite device can be directed independently to a different dual-stack lite NAT, the dual-stack lite architecture can scale better.</t>
<t>ALG sometimes need to manipulate literal IP address in the payload of packets. In the case of an IPv4-IPv4 NAT, this is a simple 32 bit field replacement. In the case of IPv6-IPv4 (or IPv4-IPv6) NAT, a 128 bit field need to be substituted by a 32 bit field (or vice versa). This makes NAT-PT ALG more complex than dual-stack lite NAT ALG.</t>
</list>
</t>
<t>For more detail on NAT-PT related issues, see <xref target="RFC4966"/>.</t>
</section>
<section title="Comparison with DSTM">
<t>
DSTM <xref target="I-D.bound-dstm-exp"/> was addressing IPv6 backward compatibility with IPv4 by providing a temporary IPv4 address to dual-stack nodes. Connectivity was also provided by the way of IPv4-in-IPv6 tunnels. However, DSTM was relying on nodes acquiring and releasing IPv4 addresses on a need to have basis. It is the authors' opinion that such mechanism may not provide the necessary savings in address space for large scale broadband deployments.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>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 <xref
target="I-D.droms-softwires-snat"/>. Note that this
document results from a merging of <xref
target="I-D.durand-dual-stack-lite"/> and <xref
target="I-D.droms-softwires-snat"/>.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, Ichiro
Mizukoshi. The author would also like to thank David Ward, Jari
Arkko, Thomas Narten and Geoff Huston for their constructive
feedbacks. A special thank you goes to Dave Thaler for his review and comments.
</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This draft request IANA to allocate a well know IPv4 e.f.g.h/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 last IPv4 address of this range is reserved as the IPv4 address of the default router for such dual-stack lite hosts.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>Security issues associated with NAT have long been documented. See <xref target="RFC2663"/>
and <xref target="RFC2993"/>.</t>
<t>However, moving the NAT functionality from the home gateway 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 a timestamps are no longer sufficient to identify a particular broadband
customer. Additional information such as transport protocol information will be required for that
purpose. For example, we suggest to log the transport port number for TCP and UDP connections.
</t>
<t>
The carrier-grade NAT performs translation functions for interior IPv4
hosts at RFC 1918 addresses or at the IANA reserved address range
(TBA by IANA). If the interior host is properly using the
authorized IPv4 address with the authorized transport protocol
port range such as A+P semantic for the tunnel, the carrier-grade NAT
can simply forward without translation to permit the authorized address
and port range to function properly. All packets with unauthorized
interior IPv4 addresses or with authorized interior IPv4 address
but unauthorized port range MUST NOT be forwarded by the carrier-grade NAT.
This prevents rogue devices from launching denial of service attacks
using unauthorized public IPv4 addresses in the IPv4 source header field
or unauthorized transport port range in the IPv4 transport header
field. For example, rogue devices could bombard a public web server by
launching TCP SYN ACK attack. The victim will receive TCP SYN from random
IPv4 source addresses at a rapid rate and deny TCP services to legitimate
users.
</t>
<t>
Similarly, some attack mitigation techniques put an IPv4 address in a "penalty box" for a period of time if an abnormal behavior is observed. Such techniques may need to be revisited as they would impact more than just one user (presumably the offender) at a time.
</t>
<t>
With IPv4 addresses shared by multiple users, ports become a critical resource. As such, some mechanisms need to be put in place by a carrier-grade NAT to limit port usage, either by rate-limiting new connections or putting a hard limit on the maximum number of port usable by single user. If this number is high enough, it should not interfere with normal usage and still provide reasonable protection of the shared pool.
</t>
<t>
More considerations on sharing IPv4 addresses can be found in "I-D.ford-shared-addressing-issues".
</t>
<t>
If some form of IPv6 ingress filtering is deployed in the broadband network and dual-stack lite service is restricted to those customers, then tunnels terminating at the carrier-grade NAT and coming from registered customer IPv6 addresses cannot be spoofed. Thus a simple access control list on the tunnel transport source address is all what is required to accept traffic on the southbound interface of a carrier-grade NAT.
</t>
</section>
<section title="Author's Address">
<t>
This document is the result of the work of the following authors:
</t>
<t>
<figure><artwork>
Alain Durand
Comcast
1, Comcast center
Philadelphia, PA 19103
USA
Email: alain_durand@cable.comcast.com
</artwork></figure>
</t>
<t>
<figure><artwork>
Ralph Droms
Cisco
1414 Massachusetts Avenue
Boxborough, MA 01714
USA
Phone: +1 978.936.1674
Email: rdroms@cisco.com
</artwork></figure>
</t>
<t>
<figure><artwork>
Brian Haberman
Johns Hopkins University Applied Physics Lab
11100 Johns Hopkins Road
Laurel, MD 20723-6099
USA
Phone: +1 443 778 1319
Email: brian@innovationslab.net
</artwork></figure>
</t>
<t>
<figure><artwork>
James Woodyatt
Apple Inc.
1 Infinite Loop
Cupertino, CA 95014
USA
Email: jhw@apple.com
</artwork></figure>
</t>
<t>
<figure><artwork>
Yiu Lee
Comcast
1, Comcast center
Philadelphia, PA 19103
USA
Email: yiu_lee@cable.comcast.com
</artwork></figure>
</t>
<t>
<figure><artwork>
Randy Bush
Internet Initiative Japan
5147 Crystal Springs
Bainbridge Island, Washington 98110
USA
Phone: +1 206 780 0431 x1
Email: randy@psg.com
</artwork></figure>
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative references">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
</references>
<references title="Informative references">
&RFC1191;
&RFC1700;
&RFC1918;
&RFC2385;
&RFC2460;
&RFC2473;
&RFC2663;
&RFC2766;
&RFC2993;
&RFC3315;
&RFC3646;
&RFC4966;
&RFC5571;
&I-D.ietf-dnsext-dnsproxy;
&I-D.bound-dstm-exp;
&I-D.droms-softwires-snat;
&I-D.durand-dual-stack-lite;
&RFC4787;
&I-D.ietf-behave-tcp;
&I-D.ietf-behave-nat-icmp;
&I-D.ietf-tcpm-tcp-auth-opt;
&I-D.cheshire-nat-pmp;
&I-D.dhankins-softwire-tunnel-option;
&I-D.bajko-v6ops-port-restricted-ipaddr-assign;
&I-D.ymbk-aplusp;
&I-D.despres-sam;
&I-D.nishitani-cgn;
&I-D.ford-shared-addressing-issues;
<reference anchor='UPnP-IGD'
target='http://www.upnp.org/standardizeddcps/igd.asp'>
<front>
<title>Universal Plug and Play Internet Gateway Device Standardized
Gateway Device Protocol</title>
<author fullname='UPnP Forum'>
<organization>UPnP Forum</organization>
</author>
<date month='September' year='2006'/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:28:32 |