One document matched: draft-ietf-softwire-dual-stack-lite-07.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 RFC3232 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3232.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 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 RFC2474 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2474.xml">
<!ENTITY RFC4213 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4213.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.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 RFC4987 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4987.xml">
<!ENTITY RFC5320 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5320.xml">
<!ENTITY RFC5382 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5382.xml">
<!ENTITY RFC5571 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5571.xml">
<!ENTITY RFC5508 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5508.xml">
<!ENTITY RFC5625 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5625.xml">
<!ENTITY RFC5625 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5625.xml">
<!ENTITY I-D.ietf-softwire-ds-lite-tunnel-option SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-softwire-ds-lite-tunnel-option.xml">
<!ENTITY I-D.nishitani-cgn SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.nishitani-cgn.xml">
<!ENTITY I-D.ietf-intarea-shared-addressing-issues SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-intarea-shared-addressing-issues.xml">
<!ENTITY I-D.ietf-intarea-server-logging-recommendations SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-intarea-server-logging-recommendations.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">
<!ENTITY I-D.ietf-pcp-base SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pcp-base.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-07" ipr="trust200902">
<!-- 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 Following 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." surname="Durand">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1194 North Mathilda Avenue</street>
<!-- Reorder these if your country does things differently -->
<city>Sunnyvale</city>
<region>CA</region>
<code>94089-1206</code>
<country>USA</country>
</postal>
<email>adurand@juniper.net</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Ralph Droms" initials="R.D." surname="Droms">
<organization>Cisco</organization>
<address>
<postal>
<street>
1414 Massachusetts Avenue</street>
<city>Boxborough</city>
<region>MA </region>
<code>01714</code>
<country>USA</country>
</postal>
<email>rdroms@cisco.com</email>
</address>
</author>
<author fullname="James Woodyatt" initials="J.W." surname="Woodyatt">
<organization>Apple</organization>
<address>
<postal>
<street>1 Infinite Loop</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>USA</country>
</postal>
<email>jhw@apple.com</email>
</address>
</author>
<author fullname="Yiu L. Lee" initials="Y.L." surname="Lee">
<organization>Comcast</organization>
<address>
<postal>
<street>One Comcast Center</street>
<city>Philadelphia</city>
<region>PA</region>
<code>19103</code>
<country>USA</country>
</postal>
<email>yiu_lee@cable.comcast.com</email>
</address>
</author>
<date year="2011" />
<!-- 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>
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).</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
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 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.
</t>
<t>
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.
</t>
<t>
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 NAT.
</t>
<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 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.
</t>
<t>
Pure IPv6-only devices (i.e. devices that do not include an IPv4 stack) are outside of the scope of this document.
</t>
<t>
This document will first present some deployment scenario and then define the behavior of the two elements of the dual-stack lite technology: the B4 and the AFTR. It will then go into networking and NAT-ing considerations.
</t>
</section>
<section title="Requirements language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Terminology">
<t>
The technology described in this document is known as dual-stack lite. The abbreviation DS-Lite will be used along this text.
</t>
<t>
This document also introduces two new terms: the DS-Lite Basic Bridging BroadBand element (B4) and the DS-Lite Address Family Transition Router element (AFTR).
</t>
<t>Dual-stack is defined in <xref target="RFC4213"/>.</t>
<t>NAT related terminology is defined in <xref target="RFC4787"/>.</t>
<t>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.</t>
</section>
<section title="Deployment scenarios">
<section title="Access model">
<t>
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 numbers of benefits to this approach:
</t>
<t>
<list style="symbols">
<t>
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 & devices.
</t>
<t>
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.
</t>
<t>
As tunnels can terminate anywhere in the service provider network, this architecture leads itself to horizontal scaling and provides great flexibility to adapt to changing traffic load.
</t>
<t>
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.
</t>
</list>
</t>
<t>
A key characteristic of this approach is that communications between end-nodes stay within their address family. IPv6 sources only communicate with IPv6 destinations, 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 payload.
</t>
</section>
<section title="CPE">
<t>
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.
</t>
<t>
A DS-Lite CPE is an IPv6 aware CPE with a B4 Interface implemented in the WAN interface.
</t>
<t>
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. That will avoid accidentally operating in a double NAT environment.
</t>
<t>
However, it SHOULD operate its own DHCP(v4) server handing out <xref target="RFC1918"/> 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 Section 5.5.
</t>
<t>
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 direct impact to the AFTR's NAT table utilization.
</t>
<t>IPv6 capable devices directly reach the IPv6 Internet. Packets simply follow IPv6 routing, they do not go through the tunnel, and 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 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>
Pure IPv6-only devices (i.e. devices that do not include an IPv4 stack) are outside of the scope of this document.
</t>
</section>
<section title="Directly connected device">
<t>
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.
</t>
<t>
Under this scenario, the customer device is a dual-stack capable host that is only 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.
</t>
<t>
A directly connected DS-Lite device SHOULD send its DNS requests over IPv6 to the IPv6 DNS server it has been configured to use.
</t>
<t>
Similarly to the previous sections, IPv6 packets follow IPv6 routing, they do not go through the tunnel, and are not subject to any translation.
</t>
<t>
The support of IPv4-only devices and IPv6-only devices in this scenario is out of scope for this document.
</t>
<t>
</t>
</section>
</section>
<section title="B4 element">
<section title="Definition">
<t>
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.
</t>
</section>
<section title="Encapsulation">
<t>
The tunnel is a multi-point to point IPv4-in-IPv6 tunnel ending on a service provider AFTR.
</t>
<t>
See section 7.1 for additional tunneling considerations.
</t>
<t>
Note: at this point, DS-Lite only defines IPv4-in-IPv6 tunnels, however other types of encapsulation could be defined in the future.
</t>
</section>
<section title="Fragmentation and Reassembly">
<t>
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 <xref target="RFC1191"/> is not a reliable method to deal with
this problem.
</t>
<t>
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.
</t>
<t>
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 for the extra IPv6 header. Fragmentation MUST happen
after the encapsulation on the IPv6 packet. Reassembly MUST happen
before the decapsulation of the IPv6 header.
Detailed procedure has been specified in
<xref target="RFC2473"/> Section 7.2.
</t>
</section>
<section title="AFTR discovery">
<t>
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.
</t>
<t>
In order to guarantee interoperability, a B4 element SHOULD implement
the DHCPv6 option defined in <xref target="I-D.ietf-softwire-ds-lite-tunnel-option"/>.
</t>
</section>
<section title="DNS">
<t>
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.
</t>
<t>
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 <xref target="RFC5625"/>.
</t>
</section>
<section title="Interface initialization">
<t>
Initialization of the interface including a B4 element is out-of-scope in this specification.
</t>
</section>
<section title="Well-known IPv4 address">
<t>
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.
</t>
<t>
192.0.0.0 is the reserved subnet address. 192.0.0.1 is reserved for the AFTR
element. The B4 element MAY use any other addresses within the 192.0.0.0/29 range.
</t>
<t>
Note: a range of addresses has been reserved for this purpose. The intent is to accommodate nodes
implementing multiple B4 elements.
</t>
</section>
</section>
<section title="AFTR element">
<section title="Definition">
<t>
An AFTR element is the combination of an IPv4-in-IPv6 tunnel end-point
and an IPv4-IPv4 NAT implemented on the same node.
</t>
</section>
<section title="Encapsulation">
<t>
The tunnel is a point-to-multipoint IPv4-in-IPv6 tunnel ending at the B4 elements.
</t>
<t>
See section 7.1 for additional tunneling considerations.
</t>
<t>
Note: at this point, DS-Lite only defines IPv4-in-IPv6 tunnels, however other types of encapsulation could be defined in the future.
</t>
</section>
<section title="Fragmentation and Reassembly">
<t>
As noted previously, fragmentation and reassembly need to be taken care of by the tunnel end-points.
As such, the AFTR MUST perform fragmentation and reassembly if
the underlying link MTU cannot accommodate the extra IPv6 header of the tunnel.
Fragmentation MUST happen after the encapsulation on the IPv6 packet.
Reassembly MUST happen before the decapsulation of the IPv6 header.
Detailed procedure has been specified in <xref target="RFC2473"/> Section 7.2.
</t>
<t>
Fragmentation at the Tunnel Entry-Point is a light-weight 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 clients simultaneously source large number of
fragmented packets to the AFTR, 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 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 AFTR's workload.
</t>
<t>
Methods to avoid fragmentation, such as rewriting the TCP MSS
option or using technologies such as Subnetwork Encapsulation and
Adaptation Layer defined in <xref target="RFC5320"/> are out of scope for
this document.
</t>
</section>
<section title="DNS">
<t>
As noted previously, DS-Lite node implementing a B4 elements will perform DNS resolution
over IPv6. As such, very few, if any, DNS packets will flow through the AFTR element.
</t>
</section>
<section title="Well-known IPv4 address">
<t>
The AFTR MAY 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.
</t>
</section>
<section title="Extended binding table">
<t>
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.
</t>
<t>
By doing a reverse look-up in the extended IPv4 NAT binding table, the
AFTR knows how to reconstruct the IPv6 encapsulation when the packets comes back from the Internet. That
way, there is no need to keep a static configuration for each tunnel.
</t>
</section>
</section>
<section title="Network Considerations">
<section title="Tunneling">
<t>
Tunneling MUST be done in accordance to <xref target="RFC2473"/> and <xref target="RFC4213"/>.
Traffic classes (<xref target="RFC2474"/>) from the IPv4 headers SHOULD be carried over to the IPv6 headers and vice versa.
</t>
</section>
<section title="VPN">
<t>
Dual-stack lite implementations SHOULD NOT interfere with the functioning of IPv4 or IPv6 VPNs.
</t>
</section>
<section title="Multicast considerations">
<t>
Multicast is out-of-scope in this document.
</t>
</section>
</section>
<section title="NAT considerations">
<section title="NAT pool">
<t>
The AFTR MAY be provisioned with different NAT pools. The address range 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, a AFTR can have two interfaces. Each
interface will have a disjoint pool NAT assigned to it. In another case, a
policy can apply to the AFTR that a set of B4s will use NAT pool 1 and a
different set of B4s will use NAT pool 2. </t>
</section>
<section title="NAT conformance">
<t>
A dual-stack lite AFTR SHOULD implement behavior conforming to the best current practice, currently documented in <xref target="RFC4787"/> and <xref target="RFC5382"/>. Other discusions about carrier-grade NATs can be found in <xref target="I-D.nishitani-cgn" />.
</t>
</section>
<section title="Application Level Gateways (ALG)">
<t>
AFTR performs NAT-44 and inherits the limitations of NAT. Some protocols
required ALGs in the NAT device to traverse through the NAT. For example:
SIP and ICMP require 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 ALGs. This specification only requires
that the AFTR MUST support <xref target="RFC5508"/>. Implementers can decide to implement
other ALGs in their implementations.
</t>
</section>
<section title="Sharing global IPv4 addresses">
<t>AFTR shares a single IP to 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 <xref target="I-D.ietf-intarea-shared-addressing-issues"/>.
</t>
</section>
<section title="Port forwarding / keep alive">
<t>
Work on a control plane to the carrier-grade NAT is done in the PCP working group
at IETF. The PCP protocol enables applications to directly negotiate
with the NAT to open ports and negotiate liefetime values to avoid
keep-alive traffic. More on PCP can be found in <xref target="I-D.ietf-pcp-base"/>.
</t>
</section>
</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
feedback. Special thanks go to Dave Thaler and Dan Wing for their reviews 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 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.</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 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 a 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.
</t>
<t>
The AFTR performs translation functions for interior IPv4
hosts using RFC 1918 addresses or the IANA reserved address range
(TBA by IANA). In some circumstances, ISP may provision policies
in the AFTR and instructs the AFTR to
bypass translation functions based on <IPv4 Address,
port number, protocol>. When the AFTR receives a packet with
matching information of the policy from the interior host,
the AFTR can simply forward without translation.
The addresses, ports and protocols information must be
provisioned on the AFTR before receiving the packet.
The provisioning mechanism is out-of-scope of
this specification.
</t>
<t>
When decapsulating packets, the AFTR MUST only forward packets sourced by
RFC 1918 addresses, IANA reserved address range, or any other
out-of-band pre-authorized addresses. The AFTR MUST drop all others packets.
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 a TCP SYN ACK attack <xref target="RFC4987"/>. The victim will receive
TCP SYN from random
IPv4 source addresses at a rapid rate and deny TCP services to legitimate
users.
</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 an AFTR to limit port usage, either by rate-limiting new connections or putting a hard limit on the maximum number of port 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 <xref target="I-D.ietf-intarea-shared-addressing-issues"/>.
Other considerations and recommendations on logging can be found in <xref target="I-D.ietf-intarea-server-logging-recommendations"/>.
</t>
<t>
AFTRs should support ways to limit service only to registered customers.
One simple option is to implement IPv6 ingress filter on the AFTR's tunnel interface
to accept only the IPv6 address range defined in the filter.
</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;
&RFC2473;
&RFC2474;
&RFC4213;
&RFC5625;
&I-D.ietf-softwire-ds-lite-tunnel-option;
</references>
<references title="Informative references">
&RFC1191;
&RFC1918;
&RFC2663;
&RFC2993;
&RFC4787;
&RFC4987;
&RFC5320;
&RFC5382;
&RFC5508;
&RFC5571;
&I-D.droms-softwires-snat;
&I-D.durand-dual-stack-lite;
&I-D.nishitani-cgn;
&I-D.ietf-intarea-shared-addressing-issues;
&I-D.ietf-intarea-server-logging-recommendations;
&I-D.ietf-pcp-base;
</references>
<section title="Deployment considerations">
<section title="AFTR service distribution and horizontal scaling">
<t>
One of the key benefits of the dual-stack lite technology lies in the fact it is tunnel based. That is, tunnel end-points may be anywhere in the service provider network.
</t>
<t>
Using the DHCPv6 tunnel end-point option, service providers can create groups of users sharing the same AFTR. Those groups can be merged or divided at will. This leads to an horizontally scaled solution, where more capacity is added simply by adding more boxes.
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.
</t>
</section>
<section title="Horizontal scaling">
<t>
</t>
<t>
A service provider can start using just a few AFTR centrally located. Later, when more capacity is needed, more boxes can be added and pushed to the edges of the access network.
In case of a spike of traffic, for example during the Olympic games or an important political event, capacity can be quickly added in any location of the network (tunnels can terminate anywhere) simply by splitting user groups. Extra capacity can be later removed when the traffic returns to normal by resetting the DHCPv6 tunnel end-point settings.
</t>
</section>
<section title="High availability">
<t>
An important element in the design of the dual-stack lite technology is the simplicity of implementation on the customer side. A simple IP4-in-IPv6 tunnel and a default route over it is all is needed to get IPv4 connectivity. Dealing with 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 end-point is provided in the DHCPv6 option defined in <xref target="I-D.ietf-softwire-ds-lite-tunnel-option" />. The service provider can use techniques such as anycast or various types of clusters to ensure availability of the IPv4 service. The exact synchronization (or lack thereof) between redundant AFTRs is out of scope for this document.
</t>
</section>
<section title="Logging">
<t>
DS-Lite AFTR implementation should offer the possibility 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, as well as to meet region-specific requirements for responding to legally-binding requests for information from law enforcement authorities.
</t>
</section>
</section>
<section title="Examples">
<section title="Gateway 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 devices is important.</t>
<t>
Consider a scenario where a Dual-Stack lite CPE is provisioned only with IPv6 in the WAN port, no IPv4. The CPE acts as an IPv4 DCHP server for the LAN network (wireline and wireless) handing out RFC1918 addresses. In addition, the CPE may support IPv6 Auto-Configuration and/or DHCPv6 server for the LAN network. When an IPv4-only device connects to the CPE, that CPE will hand it out a RFC1918 address. When a dual-stack capable device connects to the CPE, that CPE will hand out a RFC1918 address and a global IPv6 address to the device. Besides, the CPE will create an IPv4-in-IPv6 softwire tunnel <xref target="RFC5571"/>to an
AFTR that resides in the service provider network.
</t>
<t>
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 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 CPE. The CPE will encapsulate the IPv4 datagram inside the IPv4-in-IPv6 softwire tunnel and forward the IPv6 datagram to the AFTR. This contrasts what the CPE normally does today, which is, NAT the RFC1918 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.
</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 with a B4 element, the
AFTR and a softwire between the B4 element acting as softwire initiator (SI) <xref target="RFC5571"/> in the
dual-stack lite home router and the softwire concentrator (SC) <xref target="RFC5571"/> in
the AFTR. The AFTR performs IPv4-IPv4 NAT translations to
multiplex multiple subscribers through a pool of 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="gateway-based architecture">
<preamble></preamble>
<artwork align="left"><![CDATA[
+-----------+
| Host |
+-----+-----+
|10.0.0.1
|
|
|10.0.0.2
+---------|---------+
| | |
| Home router |
|+--------+--------+|
|| B4 ||
|+--------+--------+|
+--------|||--------+
|||2001:db8:0:1::1
|||
|||<-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 |
+-----------+
]]></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 AFTR is
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 a datagram with IP SRC address
192.0.2.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
+---------|---------+
| | |
| home router |
|+--------+--------+|
|| B4 ||
|+--------+--------+|
+--------|||--------+
| |||2001:db8:0:1::1
IPv6 datagram 2| |||
| |||<-IPv4-in-IPv6 softwire
| |||
-----|-|||-------
/ | ||| \
| ISP core network |
\ | ||| /
-----|-|||-------
| |||
| |||2001:db8:0:2::1
+------|-|||--------+
| | AFTR |
| v ||| |
|+--------+--------+|
|| Concentrartor ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
| |192.0.2.1
IPv4 datagram 3 | |
| |
-----|--|--------
/ | | \
| Internet |
\ | | /
-----|--|--------
| |
v |198.51.100.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>198.51.100.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:db8:0:2::1</c>
<c></c>
<c>IPv6 Src</c>
<c>2001:db8:0:1::1</c>
<c></c>
<c>IPv4 Dst</c>
<c>198.51.100.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>198.51.100.1</c>
<c></c>
<c>IPv4 Src</c>
<c>192.0.2.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 B4 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 tunnel concentrator in the AFTR 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
192.0.2.1 and TCP SRC port 5000.</t>
<t><xref target="inbound-dg" /> 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 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 B4 in the
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
+---------|---------+
| +-+-+ |
| home router |
|+--------+--------+|
|| B4 ||
|+--------+--------+|
+--------|||--------+
^ |||2001:db8:0:1::1
IPv6 datagram 2 | |||
| |||<-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 |
+-----------+
]]></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>192.0.2.1</c>
<c></c>
<c>IPv4 Src</c>
<c>198.51.100.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:db8:0:1::1</c>
<c></c>
<c>IPv6 Src</c>
<c>2001:db8:0:2::1</c>
<c></c>
<c>IPv4 Dst</c>
<c>10.0.0.1</c>
<c></c>
<c>IP Src</c>
<c>198.51.100.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>198.51.100.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 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.</t>
<t>In <xref target="outbound-dg"/>, 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:
<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 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 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 B4. The B4
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/Prot/Port</ttcol>
<ttcol align="left">IPv4/Prot/Port</ttcol>
<c>2001:db8:0:1::1/10.0.0.1/TCP/10000</c>
<c>192.0.2.1/TCP/5000</c>
</texttable>
<t> 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 is the RFC1918
addressed assigned by the Dual-Stack home router which 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. </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-in-IPv6 softwire tunnel to an AFTR. 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-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.</t>
<t>
This scenario works on both wireline and wireless networks. A typical wireless device will connect directly to the service provider without CPE 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 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.</t>
<t>The AFTR performs IPv4-IPv4 NAT
translations to multiplex multiple subscribers through a pool of
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 192.0.0.2 out of the well-known range 192.0.0.0/29 (defined by IANA) on its
B4 interface. It also configure the first non-reserved IPv4 address of the
reserved range, 192.0.0.1 as the address of its default gateway.</t>
<figure align="center" anchor="gnat-arch2" title="host-based architecture">
<preamble></preamble>
<artwork align="left"><![CDATA[
+-------------------+
| |
| Host 192.0.0.2 |
|+--------+--------+|
|| B4 ||
|+--------+--------+|
+--------|||--------+
|||2001:db8:0:1::1
|||
|||<-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 |
+-----------+
]]></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 AFTR is configured to forward between IP/TCP (a.b.c.d/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 a
datagram with IP SRC address 192.0.2.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 192.0.0.2 |
|+--------+--------+|
|| B4 ||
|+--------+--------+|
+--------|||--------+
| |||2001:db8:0:1::1
IPv6 datagram 1| |||
| |||<-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 |
+-----------+
]]></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:db8:0:2::1</c>
<c></c>
<c>IPv6 Src</c>
<c>2001:db8:0:1::1</c>
<c></c>
<c>IPv4 Dst</c>
<c>198.51.100.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>198.51.100.1</c>
<c></c>
<c>IPv4 Src</c>
<c>192.0.2.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 AFTR over the softwire.</t>
<t>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 Softwire_1 with TCP SRC port 10000 should be translated to
datagram 3 with IP SRC address 192.0.2.1 and TCP SRC port
5000.</t>
<t><xref target="inbound-dg2" /> 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 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 concentrator for transmission over Softwire_1. The B4 in
the dual-stack lite hosts 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 192.0.0.2 |
|+--------+--------+|
|| B4 ||
|+--------+--------+|
+--------|||--------+
^ |||2001:db8:0:1::1
IPv6 datagram 2 | |||
| |||<-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 |
+-----------+
]]></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>192.0.2.1</c>
<c></c>
<c>IPv4 Src</c>
<c>198.51.100.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:db8:0:1::1</c>
<c></c>
<c>IPv6 Src</c>
<c>2001:db8:0:2::1</c>
<c></c>
<c>IPv4 Dst</c>
<c>a.b.c.d</c>
<c></c>
<c>IP Src</c>
<c>198.51.100.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 AFTR
are the same as in the previous examples. The
well known IPv4 address 192.0.0.2 out of the 192.0.0.0/29 (defined 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/Prot/Port</ttcol>
<ttcol align="left">IPv4/Prot/Port</ttcol>
<c>2001:db8:0:1::1/a.b.c.d/TCP/10000</c>
<c>192.0.2.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. 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.
</t>
</section>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:28:32 |