One document matched: draft-penno-softwire-sdnat-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 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 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-penno-softwire-sdnat-01" 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 Deterministic NAT</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="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="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>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 in both a NAT44 and DS-Lite environment.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
NAT44 and DS-Lite <xref target="RFC6333"/>,are two solutions to deal with the IPv4 exhaustion problem.
NAT44 solves it by introducing a second layer of NAT in the ISP network. DS-Lite solves it by decoupling the deployment of IPv6 in the access network from the deployment of IPv6 in the applications. DS-Lite is based on a combination of IPv4 over IPv6 encapsulation and a carrier grade NAT (CGN).
</t>
<t>
There have been a number of efforts at IETF to evolve the DS-Lite model by moving the NAT function from a centralized, stateful carrier grade NAT to the CPEs by allocating a fixed number of ports to each customer. The provider equipment would then only do the decapsulation of the IPv4 traffic, providing a stateless operation model, where a number of those relay devices could be operated independently in the ISP network. One drawback of such design, is that the service provider looses some flexibility on how ports are allocated. In particular, The IPv6 and global IPv4 address spaces are mapped to each over, making it difficult for an ISP to add or remove addresses from the NAT pool. Another drawback is that the number of IPv4 port allocated per subscriber is encoded in the IPv6 address. This results in a renumbering event when the ISP want to change the IPv4 oversubscription ratio.
</t>
<t>
Another direction has been to define a deterministic operation model for NAT44 CGNs, where ports are statically distributed to users on that CGN. A deterministic mapping function is defined to convert an internal address to an external address and port range. This mapping function is reversible, eliminating the need to keep logs for abuse/LEA purpose. However, such a deterministic NAT still need to maintain per connection state and as such is not stateless.
</t>
<t>
This proposal enhances the deterministic NAT model. By offering a fully programmatic mapping of the complete NAT binding, it enables a carrier-grade NAT/ AFTR to become completely stateless and deterministic. This model of operation applies similarly to DS-Lite and NAT44 environments.
</t>
<t>
The SD-NAT architecture has the following characteristics:
<list style="symbols">
<t>
Zero log: Because the SD-CGN/SD-AFTR NAT bindings are deterministic and reversible, the ISP does not need to keep any NAT binding logs.
</t>
<t>
Zero state on SD-CGN/SD-AFTR: There is no operational per-session state on the SD-CGNs/SD-AFTRs. By leveraging this stateless and deterministic mode of operation, an ISP can deploy any number of SD-CGNs/SD-AFTRs to provide redundancy and scalability at low cost. Because the NAT mappings on the CGNs or AFTRs are fully stateless and deterministic, routers can implement the functionality in hardware and perform it at very high speed with very low overhead in terms of packet delay.
</t>
<t>
Low barrier of adoption: SD-CPEs can remain IPv4-only devices. Only minor code change or configuration is required to modify the port mapping algorithms, the rest of the CPE implementation remains the same. The ISP access network can also remain IPv4-only, enabling the ISP to deploy IPv6 independently to this IPv4-exhaustion solution.
</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>
Compatible with IPv6: This SD-NAT mechanism can be deployed similarly by IPv4-only ISPs, Dual-Stack ISPs or IPv6-only ISPs. In the IPv4 case, the SD-CPE WAN Ipv4 address is used as customer index, in the IPv6 case, IPv4 packets are tunneled over IPv6 just like in the DS-Lite case and the SD-CPE WAN IPv6 address is used as customer index.
</t>
</list>
</t>
</section>
<section title="SD-CPE operation">
<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>
An SD-CPE operates like a regular CPE with some modification on the way the NAT function is performed.
</t>
<section title="SD-CPE NAT function">
<t>
The SD-CPE performs IPv4 NAPT from the internal RFC1918 addresses to the IPv4 address configured on the WAN interface. In a DS-Lite environment, the B4 address 192.0.0.2 is used in lieu of the IPv4 WAN interface.
</t>
<t>
Internal IPv4 source ports are translated into the range [1024..maxport]. Different SD-CPEs can implement different methods to determine the value of maxport, some of which are defined below.
</t>
<t>
A key design element here is that the SD-CGN or SD-AFTR can make the assumption that all datagrams coming from the SD-CPE will have source ports formatted in a well-known range. This will make the stateless deterministic NAT function on the SD-CGN or SD-AFTR easy to implement.
</t>
<t>
Another key design element is that the SD-CPE does not need to know which external IPv4 address it will be mapped to. That design element allows for a great flexibility on the ISP side, the pool of global IPv4 addresses on the SD-CGNs or SD-AFTRs can be changed at any time with little impact on the subscriber. The subscriber configuration will not have to change, the SD-CPE will not have to renumber or reboot, however the current connections may or may not survive depending on the pool update mechanism implemented on the SD-CGNs / SD-AFTRs. Note: the SD-CPE can learn the external address it is mapped to using the PCP protocol defined in <xref target="I-D.ietf-pcp-base"/>.
</t>
</section>
<section title="SD-CPE maxport configuration">
<t>
The simplest way to build an SD-CPE is to configure it with a maxport value. This could be done, for example, using either manual configuration, a TR69 parameter to be defined or a DHCP option, to be defined.
</t>
<t>
A quick look at the open source OpenWRT project show that the functionality to restrict the source port space is already present, so no new code is necessary.
</t>
</section>
<section title="SD-CPE with incremental port allocation">
<t>
In this model, an SD-CPE would dynamically learn the value of maxport instead of being configured with it. This removes a configuration step of the CPE. The trade-off is that some new code implementing the following algorithm must be implemented on the SD-CPE.
</t>
<t>
When the incremental SD-CPE needs to allocate a new external port, it MUST start from 1024 and increment until it finds an un-allocated port. If the SD-CPE
allocates a port number that is too high and does not fit into the range allocated on the SD-CGN or SD-AFTR, the outgoing packet will be dropped by the SD-CGN or SD-AFTR and an ICMP <xref target="RFC0792"/> message type 13 (Communication administratively prohibited) will be returned to the SD-CPE.
</t>
<t>
The trade-off to the simplicity of this algorithm are a) the restart at 1024 may use extra cycles and b) port randomization is impacted. See alternative scramble techniques on SD-CGN/SD-AFTR to mitigate this issue.
</t>
</section>
<section title="SD-CPE with dynamic maxport determination">
<t>
In this model the SD-CPE will try to determine the value of maxport. The easiest way of doing this is to send dummy packets at boot time starting with source port 1024 and incrementing the source port number until the ICMP message type 13 is received. This is, however, quite inefficient. A better way is to use a dichotomy algorithm. Start with a high port of 65535 and a low port of 1024 and then divide the space in two depending on the reception (or non-reception of the ICMP message type 13. The advantage over incremental port allocation is that source port randomization is preserved.
</t>
<t>
Note 1: this dichotomy algorithm can be apply to real traffic, there is no need to send dummy packets. If the ICMP message type 13 is received, then the packet is retransmitted with a lower source port number.
</t>
<t>
Note 2: if an ICMP message type 13 does not come back within (TBD) seconds, the packets is considered successfully delivered through the SD-CGN/SD-NAT.
</t>
</section>
</section>
<section title="Host based SD-NAT, Wireless application">
<t>
If the SD-CPE is running it's own applications sourcing datagrams on its WAN interface (or B4 element 192.0.0.2), or if a host is directly connected to the ISP access network, it must select a source port using the same algorithm as the NAPT function.
</t>
<t>
In particular, this makes SD-NAT well suited for wireless environments where the UE can be easily programmed to restrict its outgoing source port space.
</t>
</section>
<section title="SD-CGN and SD-AFTR operation">
<section title="Anycast IPv6 address for SD-AFTR">
<t>
All SD-AFTRs associated to a domain (or group of users) will be configured with the same IPv6 address on the interface facing IPv6 customers. A route for that IPv6 address will be anycasted within the access network.
</t>
</section>
<section title="Multiple default IPv4 routes leading to SD-CGN">
<t>
Similarly, in the NAT44 environment, the IPv4 traffic will be send to a number of SD-CGNs using a number of default routes or equivalent techniques.
</t>
</section>
<section title="SD-CGN and SD-AFTR operation">
<t>
All SD-CGNs or SD-AFTRs associated to a domain (or group of users) will be configured with the same pool of global IPv4 addresses. They will be configured also with the same deterministic address and port mapping function. This function will map the customer ID, derived from either its private IPv4 address in the NAT44 case or its IPv6 address in the DS-Lite case and the source port used by the incoming connection into a global IPv4 address and port.
</t>
</section>
<section title="Mapping function">
<t>
Various mapping functions can be defined. This is an implementation issue on the SD-CGNs or SD-AFTRs, however that function MUST be the same on all the SD-CGNs or SD-AFTRs within a domain.
</t>
<t>
The input parameters of that mapping function are the number of addresses in the IPv4 global pool, the number of customers and the maximum number of ports per customers.
</t>
<t>
Note: external ports in the range of [0..1023] MAY be excluded in the mapping function , however this is not a requirement.
</t>
</section>
<section title="Example mapping function">
<t>
Lets say that all external ports above 1023 are used and a 1024 ports are allocated per subscriber, and only one IPv4 address is configured in the NAT pool. Customer #1 will have external ports 1024 to 2047, customer #2 will have external ports 2048 to 3071, etc...
</t>
<t>
Here is an algorithm that produces this result:
</t>
<t>
Input variables:
</t>
<t>
<list style="symbols">
<t>
i: subscriber index
</t>
<t>
maxPort: maximum number of ports per subscriber
</t>
<t>
baseCPE:CPE address base, determined by Service Provider, e.g. 172.16.0.1
</t>
<t>
baseCGN:CGN address base, determined by Service Provider e.g. 1.2.3.1.
</t>
</list>
</t>
<t>
Each SD-CPE implements a stateful NAT44 function with the following mappings:
</t>
<t>
<list style="symbols">
<t>
host_src_ip is mapped to: CPE WAN IPv4.
</t>
<t>
host_src_port is mapped to: port, Where port is the first available port starting at 1024.
</t>
</list>
</t>
<t>
Each SD-CGN/SD-AFTR implements a deterministic stateless NAT44 function with following mappings:
</t>
<t>
<list>
<t>
cpe_src_ip is mapped to: baseCGN + floor ( i / P)
</t>
<t>
cpe_src_port is mapped to: cpe_src_port + maxPort x (i mod P) )
</t>
<t>
Where i = cpe_src_ip - baseCPE and P = floor ( (65536-1024) / maxPort )
</t>
<t>
Note that in this simple algorithm, (65536-1024) must be multiple of maxPort. However, with minor modification to the algorithm, you can avoid this limitation.
</t>
</list>
</t>
</section>
<section title="Port exceeded message">
<t>
If the SD-CGN or SD-AFTR receives an incoming datagram with a source port number higher than1023 + the maximum number of allocated ports per customer, the datagram MUST be dropped and an ICMP <xref target="RFC0792"/> error message type 13 (Communication administratively prohibited) MUST be returned to the originating SD-CPE.
</t>
</section>
<section title="Address compression ratio">
<t>
The maximum number of subscriber per IPv4 address is equal to (65536 minus 1024) divided by the number of ports per user, as configured on the SD-CGN or SD-AFTR.
</t>
</section>
<section title="Anycast global IPv4 pool">
<t>
Routes to the pool of global IPv4 addresses configured on the SD-CGN or SD-AFTR will be anycasted by all relevant SD-CGN or SD-AFTRs within the ISP routing domain.
</t>
</section>
<section title="Stateless operation">
<t>
By using anycast IPv4 pool, return IPv4 traffic can go back to any SD-CGN or SD-AFTR associated with that pool of address. Because the mapping function is deterministic (shared on all AFTRs) and because there is no dynamic state associated with any particular NAT mappings on any SD-CGN or SD-AFTR, the returning IPv4 traffic can be translated back, re-encapsulated in IPv6 in the case of DS-Lite, and send back to the customer by any SD-CGN or SD-AFTRs within the domain
</t>
<t>
No need to do port mapping garbage collection on SD-CGN/SD-AFTR:
</t>
<t>
Because those bindings are completely stateless and deterministic, an SD-CGN or SD-AFTR does not need to maintain state in its port-mapping table, and as such, does not need to perform any garbage collection on idle connections.
From a subscriber application perspective, that mean that the application only need to negotiate ports with the local SD-CPE, for example using the PCP protocol.
</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 SD-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 title="SD-CGN/SD-AFTR post mapping source port scrambling">
<t>
In order to improve source port randomization, an SD-CGN or SD-AFTR can do post-mapping source port scrambling. The details of this optional feature are out of scope of this document. The scrambling function MUST be the same on all SD-CGN/SD-AFTR responsible for the same global IPv4 pool, and configured with the same parameters on all those devices. That scrambling function MUST be reversible.
</t>
</section>
</section>
<section title="SD-NAT 444 example">
<t>
This examples assume two SD-CGNs or two SD-AFTRs configured with the same IPv4 global address in their NAT pool. The operator has configured a limit of 1024 ports per subscriber. Subscriber #3 has 2 hosts, each running one connection and subscriber #7 has one host running one connection. Subscriber #3 SD-CPE WAN IPv4 address is 172.16.0.3 in case of NAT44 or WAN IPv6 address 2001:db8::3 in case of DS-LITE. Subscriber #7 WAN IPv4 address is 172.16.0.7 in case of NAT44 or WANT IPv6 address 2001:db8::7 in case of DS-LITE. Host 1 and 2 in subscriber #3 network are using IPv4 address 192.168.1.2 and 192.168.1.3, and host 1 in subscriber #7 network is using IPv4 address 192.168.1.2.
</t>
<section title="SD-NAT44 architecture">
<figure align="center" anchor="sdcgn-arch" title="SD-NAT NAT44 CGN example">
<artwork align="left"><![CDATA[
+------+ +------+ +------+
|Host 1| |Host 2| |Host 1|
+------+ +------+ +------+
192.168.1.2\ /192.168.1.3 |192.168.1.2
\ / |
\ / |
+---------+ +---------+
|SD-CPE #3| |SD-CPE #7|
+---------+ +---------+
172.16.0.3| /172.16.0.7
| /
| /
----------------------
/ \
| ISP core network |
\ IPv4 /
----------------------
| Anycast \ Anycast
| default \ default
| IPv4 route \ IPv4 route
+------------+ +------------+
| SD-CGN1 | | SD-CGN2 |
+------------+ +------------+
1.2.3.4\ /1.2.3.4
Anycast IPv4 route\ / Anycast IPv4 route
for 1.2.3.4 \ / for 1.2.3.4
--------R-R-------
/ \
| Internet |
\ IPv4 /
-----------------
]]></artwork>
</figure>
</section>
<section title="SD-CPE3 NAT bindings in NAT44 mode">
<figure align="center" anchor="SD-CPE3-NAT44" title="SD-CPE3-NAT44">
<artwork align="left"><![CDATA[
+--------------------------------------------------+
|Connection subscriber3-1: |
|SRC IPv4 192.168.1.2 mapped to SRC IPv4 172.16.0.3|
|SRC port 3786 mapped to SRC port 1024 |
+--------------------------------------------------+
|Connection subscriber3-2:
|SRC IPv4 192.168.1.3 mapped to SRC IPv4 172.16.0.3|
|SRC port 60345 mapped to SRC port 1025 |
+--------------------------------------------------+
]]></artwork>
</figure>
</section>
<section title="SD-CPE7 NAT bindings in NAT44 mode">
<figure align="center" anchor="SD-CPE7-NAT44" title="SD-CPE7-NAT44">
<artwork align="left"><![CDATA[
+--------------------------------------------------+
|Connection subscriber7-1: |
|SRC IPv4 192.168.1.2 mapped to SRC IPv4 172.16.0.7|
|SRC port 3786 mapped to SRC port 1024 |
+--------------------------------------------------+
]]></artwork>
</figure>
</section>
<section title="SD-CGN NAT bindings in NAT44 mode">
<figure align="center" anchor="SD-CGN-NAT44" title="SD-CGN-NAT44">
<artwork align="left"><![CDATA[
+--------------------------------------------------+
|Connection subscriber3-1: |
|SRC IPv4 172.16.0.3 mapped to SRC IPv4 1.2.3.4 |
|SRC port 1024 mapped to SRC port 3072 |
+--------------------------------------------------+
|Connection subscriber3-2 |
|SRC IPv4 172.16.0.3 mapped to SRC IPv4 1.2.3.4 |
|SRC port 1025 mapped to SRC port 3073 |
+--------------------------------------------------+
|Connection subscriber7-1: |
|SRC IPv4 172.16.0.7 mapped to SRC IPv4 1.2.3.4 |
|SRC port 1024 mapped to SRC port 7168 |
+--------------------------------------------------+
]]></artwork>
</figure>
</section>
</section>
<section title="SD-DS-Lite example">
<t>
This example assumes two SD-AFTRs configured with the same IPv4 global address in their NAT pool. The operator has configured a limit of 1024 ports per subscriber. Subscriber #3 has 2 hosts, each running one connection and subscriber #7 has one host running one connection. Subscriber #3 SD-CPE WAN IPv6 address is 2001:db8::3. Subscriber #7 WAN IPv6 address is 2001:db8::7. Both SD-CPE use the same B4 address 192.0.0.2, as specified in DS-Lite. Host 1 and 2 in subscriber #3 network are using IPv4 address 192.168.1.2 and 192.168.1.3, and host 1 in subscriber #7 network is using IPv4 address 192.168.1.2.
</t>
<section title="SD-DS-Lite architecture">
<figure align="center" anchor="sdaftr-arch" title="SD-NAT DS-Lite AFTR example">
<artwork align="left"><![CDATA[
+------+ +------+ +------+
|Host 1| |Host 2| |Host 1|
+------+ +------+ +------+
192.168.1.2\ /192.168.1.3 |192.168.1.2
\ / |
\ / |
+---------+ +---------+
|SD-CPE #3| |SD-CPE #7|
+---------+ +---------+
2001:db8::3|| //2001:db8::7
192.0.0.2|| //192.0.0.2
|| //
----------------------
/ \
| ISP core network |
\ IPv6 /
----------------------
|| Anycast \\ Anycast
|| AFTR \\ AFTR
|| IPv6 route \\ IPv6 route
+------------+ +------------+
| SD-AFTR1 | | SD-AFTR2 |
+------------+ +------------+
1.2.3.4\ /1.2.3.4
Anycast IPv4 route\ / Anycast IPv4 route
for 1.2.3.4 \ / for 1.2.3.4
--------R-R-------
/ \
| Internet |
\ IPv4 /
------------------
]]></artwork>
</figure>
</section>
<section title="SD-CPE3 NAT bindings in DS-Lite mode">
<figure align="center" anchor="SD-CPE3-DS-Lite" title="SD-CPE3-DS-Lite">
<artwork align="left"><![CDATA[
+--------------------------------------------------+
|Connection subscriber3-1: |
|SRC IPv4 192.168.1.2 mapped to SRC IPv4 192.0.0.2 |
|SRC port 3786 mapped to SRC port 1024 |
+--------------------------------------------------+
|Connection subscriber3-2:
|SRC IPv4 192.168.1.3 mapped to SRC IPv4 192.0.0.2 |
|SRC port 60345 mapped to SRC port 1025 |
+--------------------------------------------------+
]]></artwork>
</figure>
</section>
<section title="SD-CPE7 NAT bindings in DS-Lite mode">
<figure align="center" anchor="SD-CPE7-DS-Lite" title="SD-CPE7-DS-Lite">
<artwork align="left"><![CDATA[
+--------------------------------------------------+
|Connection subscriber7-1: |
|SRC IPv4 192.168.1.2 mapped to SRC IPv4 192.0.0.2 |
|SRC port 3786 mapped to SRC port 1024 |
+--------------------------------------------------+
]]></artwork>
</figure>
</section>
<section title="SD-AFTR NAT bindings in DS-Lite mode">
<figure align="center" anchor="SD-AFTR-DS-Lite" title="SD-AFTR-DS-Lite">
<artwork align="left"><![CDATA[
+--------------------------------------------------+
|Connection subscriber3-1 (2001:db8::3): |
|SRC IPv4 192.0.0.2 mapped to SRC IPv4 1.2.3.4 |
|SRC port 1024 mapped to SRC port 3072 |
+--------------------------------------------------+
|Connection subscriber3-2 (2001:db8::3): |
|SRC IPv4 192.0.0.2 mapped to SRC IPv4 1.2.3.4 |
|SRC port 1025 mapped to SRC port 3073 |
+--------------------------------------------------+
|Connection subscriber7-1 (2001:db8::7): |
|SRC IPv4 192.0.0.2 mapped to SRC IPv4 1.2.3.4 |
|SRC port 1024 mapped to SRC port 7168 |
+--------------------------------------------------+
]]></artwork>
</figure>
</section>
</section>
<section title="Comparison with other techniques">
<section title="Comparison with DS-Lite and NAT44 CGN">
<t>
The trade-off of this stateless deterministic model of operation is efficiency in IPv4 address sharing. A typical DS-Lite or NAT44 environment can share an IPv4 address among over 1000 customers, if the ratio of maximum number of port used by any given subscriber to the maximum average number of ports used by all subscribers is high. A typical SD-DS-Lite or SD-NAT44 environment will share the same address among only about 100 subscribers, using a maximum number of ports per subscribers of 600.
</t>
</section>
<section title="Comparison with 4rd/4via6/A+P/DIVI">
<t>
The main difference with 4rd/A+P/4via6/DIVI techniques is that the CPE is unaware of the exact port distribution algorithm. That way, the ISP maintains the flexibility to change the numbers of ports allocated per subscriber, or add/delete/modify the pool of available global IPv4 addresses at any time without creating a customer outage.
</t>
<t>
SD-DS-Lite is based on encapsulation, 4via6 and DIVI are based on double translation IPv4 to IPv6 and back to IPv4. Service providers have deployed encapsulation techniques for many years, double translation is new and there is less operational experience with it.
</t>
<t>
An SD-CPE sends packets through a set of identified devices, the SD-CGNs or SD-AFTRs. This enables simple enforcement points to do IPv4 subscriber management (e.g. counting IPv4 traffic). A consequence of that architecture in the SD-DS-Lite model is that is does not allow for 4rd style shortcuts, where traffic between customers within the same domain does not go through the relay.
</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
None.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
As described in <xref target="RFC6269"/>, with any fixed size address sharing techniques, port randomization is achieve with a smaller entropy.
Post mapping source port scrambling (see section XXX) can mitigate this issue.
</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;
</references>
<references title="Informative references">
&RFC6269;
&RFC6302;
&I-D.ietf-pcp-base;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 06:10:19 |