One document matched: draft-penno-softwire-sdnat-02.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 RFC0792 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0792.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC6269 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6269.xml">
<!ENTITY RFC6302 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6302.xml">
<!ENTITY RFC6333 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6333.xml">
<!ENTITY RFC6346 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6346.xml">
<!ENTITY I-D.ietf-pcp-base SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-pcp-base.xml">
<!ENTITY I-D.ietf-dhc-dhcpv4-over-ipv6 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dhc-dhcpv4-over-ipv6.xml">
<!ENTITY I-D.cui-softwire-b4-translated-ds-lite SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.cui-softwire-b4-translated-ds-lite.xml">
<!ENTITY I-D.ietf-softwire-public-4over6 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-softwire-public-4over6.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-penno-softwire-sdnat-02" 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>Stateless DS-Lite</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Reinaldo Penno" initials="R.P." surname="Penno">
<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>rpenno@juniper.net</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<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="Alex Clauberg" initials="A.C." surname="Clauberg">
<organization>Deutsche Telekom AG</organization>
<address>
<postal>
<street>GTN-FM4</street>
<street>Landgrabenweg 151</street>
<!-- Reorder these if your country does things differently -->
<city>Bonn</city>
<region>CA</region>
<code>53227</code>
<country>Germany</country>
</postal>
<email>axel.clauberg@telekom.de</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Lionel Hoffmann" initials="L.H." surname="Hoffmann">
<organization>Bouygues Telecom</organization>
<address>
<postal>
<street>TECHNOPOLE</street>
<street>13/15 Avenue du Marechal Juin</street>
<!-- Reorder these if your country does things differently -->
<city>Meudon</city>
<code>92360</code>
<country>France</country>
</postal>
<email>lhoffman@bouyguestelecom.fr</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2012" />
<!-- 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>stateless deterministic 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 memo define a simple stateless and deterministic mode of operating a carrier-grade NAT as a backward compatible evolution of DS-Lite.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
DS-Lite <xref target="RFC6333"/>,is a solution to deal with the IPv4 exhaustion problem once an IPv6 access network is deployed. It enables unmodified IPv4 application to access the IPv4 Internet over the IPv6 access network. In the DS-Lite architecture, global IPv4 addresses are shared among subscribers in the AFTR, acting as a Carrier-Grade NAT (CGN).
</t>
<t>
<xref target="I-D.ietf-softwire-public-4over6"/> extends the original DS-Lite model to offer a mode where the NAT function is performed in the CPE. This simplifies the AFTR operation as it does not have to perform the NAT function anymore, however, the flip side is that the address sharing function among subscribers was no longer available. <xref target="I-D.cui-softwire-b4-translated-ds-lite"/> introduces port restrictions, but does not completely specifies how the CPE acquires the information about its IPv4 address and its port range. More importantly, that draft does not explain how this solution can be deployed in a regular DS-Lite environment. This memo addresses these issues and clarifies the operation model.
</t>
<t>
Other approaches like variations of 4rd allows also for a full stateless operation of the decapsulation device. By introducing a strong coupling between the IPv6 address and the derived IPv4 address, they get rid of the per-subscriber state on the decapsulation devices. The approach take here argues that such per-subscriber state is not an issue as it is easily replicated among all decapsulation devices. Eliminating the strong coupling between IPv6 and IPv4 derived addresses, the approach presented here enables service providers a greater flexibility on how their limited pool of IPv4 addresses is managed. It also provide greater freedom on how IPv6 addresses are allocated, as sequential allocation is no longer a pre-requisite.
</t>
<t>
The approach presented here is stateless and deterministic. It is stateless is NAT bindings are maintained on the CPE, not on the AFTR. It is deterministic as no logs are required on the AFTR to identify which subscriber is using an external Ipv4 address and port.
</t>
<t>
The stateless DS-Lite architecture has the following characteristics:
<list style="symbols">
<t>
Backward compatible with DS-Lite. A mix of regular DS-Lite CPE and stateless DS-Lite CPEs can interoperate with a stateless DS-Lite AFTR.
</t>
<t>
Zero log: Because the AFTR relies only on a per-subscriber mapping table that is reversible, the ISP does not need to keep any NAT binding logs.
</t>
<t>
Stateless AFTR: There is no per-session state on the AFTRs. By leveraging this stateless and deterministic mode of operation, an ISP can deploy any number of AFTRs to provide redundancy and scalability at low cost. Because there is no per-flow state to maintain, AFTR can implement the functionality in hardware and perform it at high speed with low latency.
</t>
<t>
Flexibility of operation: The ISP can add or remove addresses from the NAT pool without having to renumber the access network.
</t>
<t>
Leverage IPv6: This stateless DS-Lite model leverage the IPv6 access network deployed by the ISPs.
</t>
</list>
</t>
</section>
<section title="Stateless DS-Lite CPE">
<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>
<t>
A Stateless DS-Lite CPE operates in similar fashion than a regular DS-Lite CPE, where the NAT function is re-introduced in CPE with a modification on how ports are managed.
</t>
<section title="Learning external IPv4 address">
<t>
A stateless DS-Lite CPE MUST implement the DHCPv4 client relay option defined in <xref target="I-D.ietf-dhc-dhcpv4-over-ipv6"/> to learn is external IPv4 address. Other mechanism, such as manual configuration or TR69, MAY be implemented.
</t>
</section>
<section title="Learning external port range">
<t>
A stateless DS-Lite CPE MUST implement the ICMP "port restricted" option defined later in this memo.
</t>
<t>
At boot time and later at intervals of 1h +/- a random number of seconds between 0 and 900), the stateless DS-Lite CPE MUST send packets with source port 0, source IPv4 address of the B4 element, destination IPv4 address 192.0.0.1 (the AFTR well-known IPv4 address) destination port 0, for each of the supported transport protocols (usually TCP and UDP). This will trigger an ICMP "port restricted" message from the AFTR.
</t>
<t>
After validating the content of the "ICMP port restricted" message, the stateless DS-Lite CPE MUST configure its port pool with it. If existing connections were using source ports outside of that range, the stateless DS-Lite CPE MUST terminate them.
</t>
</section>
<section title="Stateless DS-Lite CPE operation">
<t>
The stateless DS-Lite CPE performs IPv4 NAPT from the internal RFC1918 addresses to the IPv4 address configured on the WAN interface, restricting its available ports to the range obtained as described above.
</t>
</section>
<section title="Host-based Stateless DS-Lite">
<t>
Any host initiating directly a DS-Lite IPv4 over IPv6 tunnel can benefit from this techniques by implementing
a 'virtual' stateless DS-Lite CPE function within its IP stack.
</t>
</section>
</section>
<section title="Stateless AFTR">
<section title="Anycast IPv6 address for Stateless AFTR">
<t>
All stateless AFTRs associated to a domain (or group of subscribers) will be configured with the same IPv6 address on the interface facing IPv6 subscribers. A route for that IPv6 address will be anycasted within the access network.
</t>
</section>
<section title="Stateless AFTR IPv4 address pool">
<t>
All stateless AFTRs associated to a domain (or group of subscribers) MUST be configured with the same pool of global IPv4 addresses.
</t>
<t>
Routes to the pool of global IPv4 addresses configured on the stateless AFTRs will be anycasted by the relevant AFTRs within the ISP routing domain.
</t>
</section>
<section title="Stateless AFTR per-subscriber mapping table">
<t>
Stateless AFTRs associated to a domain (or group of subscribers) MUST be configured with the same per-subscriber mapping table, associating the IPv6 address of the subscriber CPE to the external IPv4 address and port range provisioned for this subscriber.
</t>
<t>
Because the association IPv6 address --- IPv4 address + port range is not tied to a mathematical formula, the ISP maintains all flexibility to allocate independently IPv6 address and IPv4 addresses. In particular, IPv6 addresses do not have to be allocated sequentially and IPv4 resources can be modified freely.
</t>
<figure align="center" anchor="per-subscriber-mapping-table" title="Per-subscriber mapping table example">
<artwork align="left"><![CDATA[
+--------------+------------+----------+
| IPv6 address |IPv4 address|port-range|
+--------------+------------+----------+
|2001:db8::1 | 1.2.3.4 | 1000-1999|
|2001:db8::5 | 1.2.3.4 | 2000-2999|
|2001:db8::a:1 | 1.2.3.4 | 3000-3999|
+--------------+------------+----------+
]]></artwork>
</figure>
<t>
This per-subscriber mapping table can be implemented in various ways which details are out of scope for this memo. In its simplest form, it can be a static file that is replicated out-of-band on the AFTRs. In a more elaborated way, this table can be dynamically built using radius queries to a subscriber database.
</t>
</section>
<section title="Stateless AFTR decapsulation rules">
<t>
Upstream IPv4 over IPv6 traffic will be decapsulated by the AFTR. The AFTR MUST check the outer IPv6 source address belongs to an identified subscriber and drop the traffic if not. The AFTR MUST then check the inner IPv4 header to make sure the IPv4 source address and ports are valid according to the per-subscriber mapping table.
</t>
<t>
If the inner IPv4 source address does not match the entry in the per-subscriber mapping table, the packet MUST be discarded and an ICMP 'administratively prohibited' message MAY be returned.
</t>
<t>
If the IPv4 source port number falls outside of the range allocated to the subscriber, the AFTR MUST discard the datagram and MUST send back an ICMP "port restricted" message to the IPv6 source address of the packet.
</t>
<t>
Fragmentation and reassembly is treated as in DS-Lite <xref target="RFC6333"/>.
</t>
</section>
<section title="Stateless AFTR encapsulation rules">
<t>
Downstream traffic is validated using the per-subscriber mapping table. Traffic that falls outside of the IPv4 address/port range entries in that table MUST be discarded. Validated traffic is then encapsulated in IPv6 and forwarded to the associated IPv6 address.
</t>
<t>
Fragmentation and reassembly is treated as in DS-Lite <xref target="RFC6333"/>.
</t>
</section>
<section title="Redundancy and fail over">
<t>
Because there is no per-flow state, upstream and downstream traffic can use any stateless AFTR.
</t>
</section>
<section title="SD-AFTR stateless domain">
<t>
Using the DHCPv6 DS-Lite tunnel-end-point option, groups of subscribers and can be associated to a different stateless AFTR domain. That can allow for differentiated level of services, e.g. number of ports per customer device, QoS, bandwidth, value added services,...
</t>
</section>
</section>
<section title="Backward compatibility with DS-Lite">
<t>
A number of service providers are, or are in the process of, deploying DS-Lite in their network. They are interested in evolving their design toward a stateless model. Backward compatibility is a critical issue, as, from an operational perspective, it is difficult to get all CPEs evolve at the same time.
</t>
<t>
So AFTRs have to be ready to service CPEs that are pure DS-Lite, some that are implementing only DHCPv4 over IPv6 and handle the NAT on the full IPv4 address themselves and some that also implement port restrictions via the ICMP message described here. For this reason, a AFTR operating in backward compatibility mode MAY decide to re-NAT upstream packets which source port number do not fall into the predefined range instead of simply dropping the packets.
</t>
<t>
The operating model is the following:
<list style="symbols">
<t>
Stateless DS-Lite: for CPEs that pre-NAT and pre-shape the source port space into the range assigned to the subscriber: decapsulate, check per-subscriber mapping, forward.
</t>
<t>
B4-translated DS-Lite: for CPEs that performs NAT before encapsulation and are allocated a full IPv4 address: decapsulate, check per-subscriber mapping, forward.
</t>
<t>
Re-shaper DS-Lite: for CPEs that pre NAT but fail to restrict the source ports: decapsulate, check per-subscriber mapping, re-NAT statefully the packets into the restricted port range, mark range as 'stateful', forward.
</t>
<t>
Regular DS-Lite: for regular DS-Lite CPEs that do not pre-NAT: decapsulate, NAT statefully, forward.
</t>
</list>
</t>
<t>
In such a backward compatibility mode, the AFTR is only operating statelessly for the stateless DS-Lite CPEs. It needs to maintain per-flow state for the regular DS-Lite CPEs and the non-ICMP port restricted compliant CPEs. In this legacy mode where per-flow state is required, the simple anycast-based fail-over mechanism is no longer available.
</t>
</section>
<section title="ICMP port restricted message">
<t>
Note: this section may end-up being a separate Internet draft.
</t>
<section title="Introduction">
<t>
In the framework of A+P <xref target="RFC6346">RFC 6346</xref>, sources may be restricted to use only a subset of the port range
of a transport protocol associated with an IPv4 address. When that source transmit a packet
with a source outside of the pre-authorized range, the upstream NAT will drop the packet
and use the ICMP message defined here to inform the source of the actual port range allocated.
</t>
<t>
This memo defines such ICMP messages for TCP and UDP and leaves the definition of the ICMP option for other transport protocol for future work.
</t>
<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="Source port restricted ICMP">
<figure align="center" anchor="ICMP" title="Source Port Restricted ICMP">
<artwork align="left"><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min Port | Max Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Original Internet Headers + 64 bits of Payload ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
Type: TBD for Source Port Restricted
</t>
<t>
Checksum: The checksum is the 16-bit ones's complement of the one's
complement sum of the ICMP message starting with the ICMP Type.
For computing the checksum , the checksum field should be zero.
This checksum may be replaced in the future.
</t>
<t>
Code: 6 for TCP, 17 for UDP
</t>
<t>
Min Port: The lowest port number allocated for that source.
</t>
<t>
Max Port: The highest port number allocated for that source.
</t>
</section>
<section title="Host behavior">
<t>
A host receiving an ICMP type TBD message for a given transport protocol SHOULD NOT
send packets sourced by the IP address(es) corresponding to the interface that received
that ICMP message with source ports outside of the range specified for the given transport
protocol.
</t>
<t>
Packets sourced with port numbers outside of the restricted range MAY be dropped or NATed upstream to fit within the restricted range.
</t>
<t>
A host MUST NOT take port restriction information applying to a given IP address and transport
protocol and applies it to other IP addresses on other interfaces and/or other transport protocols.
</t>
<t>
If Min Port = 0 and Max Port = 65535, it indicates that the entire port range for
the given transport protocol is available. If such 'full range' messages are received for all transport protocols, the host can take this as an indication that its IP address is probably not shared with other devices.
</t>
<t>
In order to mitigate possible man in the middle attacks, a host MUST discard
ICMP type TBD messages if the associated port range
(Max Port - Min Port) is lower than 64.
</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
IANA is to allocated a code point for this ICMP message type.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
This ICMP message type has the same security properties as other ICMP messages
such as Redirect or Destination Unreachable. A man-in-the-middle attack
can be mounted to create a DOS attack on the source. Ingress filtering
on network boundary can mitigate such attacks. However, in case such filtering
measures are not enough, the additional provision that a host MUST discard such ICMP
message with a port range smaller than 64 can mitigate even further such attacks.
</t>
<t>
As described in <xref target="RFC6269"/>, with any fixed size address sharing techniques, port randomization is achieved with a smaller entropy.
</t>
<t>
Recommendations listed in <xref target="RFC6302"/> applies.
</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"?-->
&RFC0792;
&RFC2119;
&RFC6333;
&I-D.ietf-dhc-dhcpv4-over-ipv6;
</references>
<references title="Informative references">
&RFC6269;
&RFC6302;
&RFC6346;
&I-D.ietf-pcp-base;
&I-D.ietf-softwire-public-4over6;
&I-D.cui-softwire-b4-translated-ds-lite;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:39:42 |