rfc9313xml2.original.xml   rfc9313.xml 
<?xml version="1.0" encoding="UTF-8"?><!-- This template is for creating an Inte <?xml version="1.0" encoding="UTF-8"?>
rnet Draft using xml2rfc, which is available here: http://xml.resource.org. -
-><!DOCTYPE rfc SYSTEM "rfc2629.dtd" [<!-- One method to get references from the <!DOCTYPE rfc [
online citation libraries. There has to be one entity for each item to be re <!ENTITY nbsp "&#160;">
ferenced. An alternate method (rfc include) is described in the references. <!ENTITY zwsp "&#8203;">
--><!ENTITY RFC2473 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference. <!ENTITY nbhy "&#8209;">
RFC.2473.xml"><!ENTITY RFC2544 SYSTEM "http://xml.resource.org/public/rfc/bibxml <!ENTITY wj "&#8288;">
/reference.RFC.2544.xml"><!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public ]>
/rfc/bibxml/reference.RFC.2629.xml"><!ENTITY RFC2663 SYSTEM "http://xml.resource
.org/public/rfc/bibxml/reference.RFC.2663.xml"><!ENTITY RFC3552 SYSTEM "http://x <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
ml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml"><!ENTITY RFC4814 SYSTE info" consensus="true" docName="draft-ietf-v6ops-transition-comparison-04" numbe
M "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4814.xml"><!ENTITY RF r="9313" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="tru
C5180 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5180.xml"> e" tocDepth="4"
<!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC symRefs="true" sortRefs="true" version="3">
.5226.xml"><!ENTITY RFC5452 SYSTEM "http://xml.resource.org/public/rfc/bibxml/re
ference.RFC.5452.xml"><!ENTITY RFC6050 SYSTEM "http://xml.resource.org/public/rf <!-- xml2rfc v2v3 conversion 3.14.0 -->
c/bibxml/reference.RFC.6050.xml"><!ENTITY RFC6052 SYSTEM "http://xml.resource.or <front>
g/public/rfc/bibxml/reference.RFC.6052.xml"><!ENTITY RFC6146 SYSTEM "http://xml.
resource.org/public/rfc/bibxml/reference.RFC.6146.xml"><!ENTITY RFC6147 SYSTEM " <title abbrev="Pros and Cons of IPv4aaS Technologies">Pros and Cons of
http://xml.resource.org/public/rfc/bibxml/reference.RFC.6147.xml"><!ENTITY RFC61 IPv6 Transition Technologies for IPv4-as-a-Service (IPv4aaS)</title>
80 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6180.xml"><!E <seriesInfo name="RFC" value="9313"/>
NTITY RFC6269 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.62 <author fullname="Gábor Lencse" initials="G." surname="Lencse">
69.xml"><!ENTITY RFC6333 SYSTEM "http://xml.resource.org/public/rfc/bibxml/refer <organization abbrev="BUTE">Budapest University of Technology and Economic
ence.RFC.6333.xml"><!ENTITY RFC6346 SYSTEM "http://xml.resource.org/public/rfc/b s</organization>
ibxml/reference.RFC.6346.xml"><!ENTITY RFC6519 SYSTEM "http://xml.resource.org/p <address>
ublic/rfc/bibxml/reference.RFC.6519.xml"><!ENTITY RFC6877 SYSTEM "http://xml.res <postal>
ource.org/public/rfc/bibxml/reference.RFC.6877.xml"><!ENTITY RFC6887 SYSTEM "htt <street>Magyar tudósok körútja 2</street>
p://xml.resource.org/public/rfc/bibxml/reference.RFC.6887.xml"><!ENTITY RFC6888 <city>Budapest</city>
SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6888.xml"><!ENTI <region/>
TY RFC6889 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6889. <code>H-1117</code>
xml"><!ENTITY RFC7050 SYSTEM "http://xml.resource.org/public/rfc/bibxml/referenc <country>Hungary</country>
e.RFC.7050.xml"><!ENTITY RFC7269 SYSTEM "http://xml.resource.org/public/rfc/bibx </postal>
ml/reference.RFC.7269.xml"><!ENTITY RFC7341 SYSTEM "http://xml.resource.org/publ <email>lencse@hit.bme.hu</email>
ic/rfc/bibxml/reference.RFC.7341.xml"><!ENTITY RFC7393 SYSTEM "http://xml.resour <uri>http://www.hit.bme.hu/~lencse/index_en.htm</uri>
ce.org/public/rfc/bibxml/reference.RFC.7393.xml"><!ENTITY RFC7422 SYSTEM "http:/ </address>
/xml.resource.org/public/rfc/bibxml/reference.RFC.7422.xml"><!ENTITY RFC7596 SYS </author>
TEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7596.xml"><!ENTITY <author fullname="Jordi Palet Martinez" initials="J." surname="Palet Martine
RFC7597 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7597.xml z">
"><!ENTITY RFC7599 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.R <organization>The IPv6 Company</organization>
FC.7599.xml"><!ENTITY RFC7605 SYSTEM "http://xml.resource.org/public/rfc/bibxml/ <address>
reference.RFC.7605.xml"><!ENTITY RFC7757 SYSTEM "http://xml.resource.org/public/ <postal>
rfc/bibxml/reference.RFC.7757.xml"><!--<!ENTITY RFC7857 SYSTEM "http://xml.resou <street>Molino de la Navata, 75</street>
rce.org/public/rfc/bibxml/reference.RFC.7757.xml">--><!ENTITY RFC7915 SYSTEM "ht <city>La Navata - Galapagar</city>
tp://xml.resource.org/public/rfc/bibxml/reference.RFC.7915.xml"><!ENTITY RFC7950 <region>Madrid</region>
SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7950.xml"><!ENT <code>28420</code>
ITY RFC8114 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8114 <country>Spain</country>
.xml"><!ENTITY RFC8215 SYSTEM "http://xml.resource.org/public/rfc/bibxml/referen </postal>
ce.RFC.8215.xml"><!ENTITY RFC8219 SYSTEM "http://xml.resource.org/public/rfc/bib <email>jordi.palet@theipv6company.com</email>
xml/reference.RFC.8219.xml"><!ENTITY RFC8415 SYSTEM "http://xml.resource.org/pub <uri>http://www.theipv6company.com/</uri>
lic/rfc/bibxml/reference.RFC.8415.xml"><!ENTITY RFC8512 SYSTEM "http://xml.resou </address>
rce.org/public/rfc/bibxml/reference.RFC.8512.xml"><!ENTITY RFC8513 SYSTEM "http: </author>
//xml.resource.org/public/rfc/bibxml/reference.RFC.8513.xml"><!ENTITY RFC8658 SY <author fullname="Lee Howard" initials="L." surname="Howard">
STEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8658.xml"><!ENTITY <organization>Retevia</organization>
RFC8676 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8676.xm <address>
l"><!ENTITY RFC8683 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference. <postal>
RFC.8683.xml">]><?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?><!-- used <street>9940 Main St., Suite 200</street>
by XSLT processors --><!-- For a complete list and description of processing in <city>Fairfax</city>
structions (PIs), please see http://xml.resource.org/authoring/README.html. <region>Virginia</region>
--><!-- Below are generally applicable Processing Instructions (PIs) that most I <code>22031</code>
-Ds might want to use. (Here they are set differently than their defaults in <country>United States of America</country>
xml2rfc v1.32) --><?rfc strict="yes" ?><!-- give errors regarding ID-nits and DT </postal>
D validation --><!-- control the table of contents (ToC) --><?rfc toc="yes"?><!- <email>lee@asgard.org</email>
- generate a ToC --><?rfc tocdepth="4"?><!-- the number of levels of subsections </address>
in ToC. default: 3 --><!-- control references --><?rfc symrefs="yes"?><!-- use </author>
symbolic references tags, i.e, [RFC2119] instead of [1] --><?rfc sortrefs="yes" <author fullname="Richard Patterson" initials="R." surname="Patterson">
?><!-- sort the reference entries alphabetically --><!-- control vertical white <organization>Sky UK</organization>
space (using these PIs as follows is recommended by the RFC Editor) --><?rfc <address>
compact="yes" ?><!-- do not start each main section on a new page --><?rfc subc <postal>
ompact="no" ?><!-- keep one blank line between list items --><!-- end of list of <street>1 Brick Lane</street>
popular I-D processing instructions --><rfc category="info" docName="draft-ietf <city>London</city>
-v6ops-transition-comparison-04" ipr="trust200902"> <front> <!-- The abbrevi <code>EQ 6PU</code>
ated title is used in the page header - it is only necessary if the fu <country>United Kingdom</country>
ll title is longer than 39 characters --> <title abbrev="Pros and Cons of IPv </postal>
4aaS Technologies">Pros and Cons of IPv6 Transition Technologies for IPv4aaS< <email>richard.patterson@sky.uk</email>
/title> <!-- add 'role="editor"' below for the editors if appropriate --> </address>
<!-- Another author who claims to be an editor --> <author fullname="Gabor Le </author>
ncse" initials="G." surname="Lencse"> <organization abbrev="BUTE">Budapest <author fullname="Ian Farrer" initials="I." surname="Farrer">
University of Technology and Economics</organization> <address> <pos <organization>Deutsche Telekom AG</organization>
tal> <street>Magyar tudosok korutja 2.</street> <!-- Reorder t <address>
hese if your country does things differently --> <city>Budapest</city> <postal>
<region></region> <code>H-1117</code> <country>Hungar <street>Landgrabenweg 151</street>
y</country> </postal> <phone></phone> <email>lencse@hit.bme <city>Bonn</city>
.hu</email> <uri>http://www.hit.bme.hu/~lencse/index_en.htm</uri> <code>53227</code>
</address> </author> <author fullname="Jordi Palet Martinez" initials="J <country>Germany</country>
." surname="Palet Martinez"> <organization>The IPv6 Company</organization> </postal>
<address> <postal> <street>Molino de la Navata, 75</street> <email>ian.farrer@telekom.de</email>
<city>La Navata - Galapagar</city> <region>Madrid</region> </address>
<code>28420</code> <country>Spain</country> </postal> </author>
<email>jordi.palet@theipv6company.com</email> <uri>http://www.theipv6 <date year="2022" month="October" />
company.com/</uri> </address> </author> <author fullname="Lee Howard"
initials="L." surname="Howard"> <organization>Retevia</organization> <area>ops</area>
<address> <postal> <street>9940 Main St., Suite 200</street> <workgroup>v6ops</workgroup>
<!-- Reorder these if your country does things differently --> <c
ity>Fairfax</city> <region>Virginia</region> <code>22031</code <keyword>IPv6</keyword>
> <country>USA</country> </postal> <phone></phone> <keyword>Transition Technologies</keyword>
<email>lee@asgard.org</email> </address> </author> <author fullname= <keyword>Comparison</keyword>
"Richard Patterson" initials="R." surname="Patterson"> <organization>Sky UK <keyword>IPv4aaS</keyword>
</organization> <address> <postal> <street>1 Brick Lane</st <keyword>IPv6-only</keyword>
reet> <!-- Reorder these if your country does things differently --> <keyword>464XLAT</keyword>
<city>London</city> <region></region> <code>EQ 6PU</cod <keyword>DNS64</keyword>
e> <country>United Kingdom</country> </postal> <phone></p <keyword>Dual-Stack Lite</keyword>
hone> <email>richard.patterson@sky.uk</email> </address> </author <keyword>Lightweight 4over6</keyword>
> <author fullname="Ian Farrer" initials="I." surname="Farrer"> <organiz <keyword>MAP-E</keyword>
ation>Deutsche Telekom AG</organization> <address> <postal> <keyword>MAP-T</keyword>
<street>Landgrabenweg 151</street> <!-- Reorder these if your country
does things differently --> <city>Bonn</city> <region></region <abstract>
> <code>53227</code> <country>Germany</country> </posta <t>Several IPv6 transition technologies have been developed to
l> <phone></phone> <email>ian.farrer@telekom.de</email> </add provide customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an
ress> </author> <date year="2022" /> <!-- Meta-data Declarations --> IPv6-only access and/or core network. These technologies have their
<area>ops</area> <workgroup>v6ops</workgroup> <!-- WG name at the upperle advantages and disadvantages. Depending on existing topology, skills,
ft corner of the doc, IETF is fine for individual submissions. If strategy, and other preferences, one of these technologies may be the
this element is not present, the default is "Network Working Group", wh most appropriate solution for a network operator.</t>
ich is used by the RFC Editor as a nod to the history of the IETF. --> <keywo <t>This document examines the five most prominent
rd>IPv6, Transition Technologies, Comparison, IPv4aaS, IPv6-only, 464XLAT, DNS64 IPv4aaS technologies and considers a number of different aspects
, Dual Stack Lite, Lightweight 4over6, MAP-E, MAP-T</keyword> <!-- Keywords w to provide network operators with an easy-to-use reference to assist in
ill be incorporated into HTML output files in a meta tag but they have selecting the technology that best suits their needs.</t>
no effect on text or nroff output. If you submit your draft to the RFC </abstract>
Editor, the keywords will be used for the search engine. --> <abstra </front>
ct> <t>Several IPv6 transition technologies have been developed to pro <middle>
vide customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only <section anchor="intro" numbered="true" toc="default">
access and/or core network. All these technologies have their advantages an <name>Introduction</name>
d disadvantages, and depending on existing topology, skills, strategy and o <t>As the deployment of IPv6 continues to be prevalent, it becomes clearer
ther preferences, one of these technologies may be the most appropriate sol that network operators will move to building single-stack IPv6 core
ution for a network operator.</t> <t>This document examines the five most p and access networks to simplify network planning and operations.
rominent IPv4aaS technologies considering a number of different aspects However, providing customers with IPv4 services continues to be a
to provide network operators with an easy-to-use reference to assist in s requirement for the foreseeable future. To meet this need, the IETF
electing the technology that best suits their needs.</t> </abstract> </front has standardized a number of different IPv4aaS technologies
> <middle> <section anchor="intro" title="Introduction"> <t>As the depl for this (see <xref target="LEN2019" format="default"/>) based on differin
oyment of IPv6 continues to be prevalent, it becomes clearer that network o g requirements and
perators will move to building single-stack IPv6 core and access networks t deployment scenarios.</t>
o simplify network planning and operations. However, providing customers wi <t>The number of technologies that have been developed makes it
th IPv4 services continues to be a requirement for the foreseeable future. time-consuming for a network operator to identify the most appropriate
To meet this need, the IETF has standardised a number of different IPv4aaS mechanism for their specific deployment. This document provides a
technologies for this <xref target="LEN2019"/> based on differing requireme comparative analysis of the most commonly used mechanisms to assist
nts and deployment scenarios.</t> <t>The number of technologies that h operators with this problem.</t>
ave been developed makes it time-consuming for a network operator to identi <t>Five different IPv4aaS solutions are considered:
fy the most appropriate mechanism for their specific deployment. This docum </t>
ent provides a comparative analysis of the most commonly used mechanisms to <ol spacing="normal" type="1"><li>464XLAT <xref target="RFC6877" format="d
assist operators with this problem.</t> <t>Five different IPv4aaS sol efault"/></li>
utions are considered. The following IPv4aaS technologies are covered: <li>Dual-Stack Lite <xref target="RFC6333" format="default"/></li>
<list style="numbers"> <t>464XLAT <xref target="RFC6877"/></t> < <li>Lightweight 4over6 (lw4o6) <xref target="RFC7596" format="default"/>
t>Dual Stack Lite <xref target="RFC6333"/></t> <t>lw4o6 (Lightweight 4ov </li>
er6) <xref target="RFC7596"/></t> <t>MAP-E <xref target="RFC7597"/>
</t> <t>MAP-T <xref target="RFC7599"/></t> </list></t> <li>Mapping of Address and Port with Encapsulation (MAP-E) <xref target=
<t>We note that <xref target="RFC6180"/> gives guidelines for using IPv6 tr "RFC7597" format="default"/></li>
ansition mechanisms during IPv6 deployment addressing a much broader topic, <li>Mapping of Address and Port using Translation (MAP-T) <xref target="
whereas this document focuses on a small part of it.</t> </section> RFC7599" format="default"/></li>
<section anchor="overview" title="Overview of the Technologies"> <t>The f </ol>
ollowing sections introduce the different technologies analyzed in this doc <t>We note that <xref target="RFC6180" format="default"/> gives
ument, describing some of their most important characteristics. </t> < guidelines for using IPv6 transition mechanisms during IPv6 deployment;
section anchor="xlat_ov" title="464XLAT"> <t>464XLAT may use double trans that document addresses a much broader topic, whereas this document
lation (stateless NAT46 + stateful NAT64) or single translation (sta focuses on a small part of it.</t>
teful NAT64), depending on different factors, such as the use of DNS </section>
by the applications and the availability of a DNS64 function (in <section anchor="overview" numbered="true" toc="default">
the host or in the service provider network).</t> <name>Overview of the Technologies</name>
<t>The customer-side translator (CLAT) is located in the customer's devic <t>The following sections introduce the different technologies analyzed
e, and it performs stateless NAT46 translation <xref target="RFC7915 in this document and describe some of their most important characteristics
"/> (more precisely, a stateless IP/ICMP translation from IPv4 to IPv6). .
IPv4-embedded IPv6 addresses <xref target="RFC6052"/> are used for both </t>
source and destination addresses. Commonly, a /96 prefix (either the <section anchor="xlat_ov" numbered="true" toc="default">
64:ff9b::/96 Well-Known Prefix, or a Network-Specific Prefix) is used as <name>464XLAT</name>
the IPv6 destination for the IPv4-embedded client traffic.</t> < <t>464XLAT may use double translation (stateless NAT46 + stateful
t>In deployments where NAT64 load-balancing <xref target="RFC7269"/> s NAT64) or single translation (stateful NAT64) depending on different
ection 4.2 is enabled, multiple WKPs <xref target="RFC8215"/> may be used.</t> factors, such as the use of DNS by the applications and the
<t>In the operator's network, the provider-side translator (PLAT) p availability of a DNS64 function (in the host or service
erforms stateful NAT64 <xref target="RFC6146"/> to translate the traffic. provider network).</t>
The destination IPv4 address is extracted from the IPv4-embedded IPv6 pa <t>The customer-side translator (CLAT) is located in the customer's
cket destination address and the source address is from a pool of public device, and it performs stateless NAT46 translation <xref
IPv4 addresses.</t> <t>Alternatively, when a dedicated /6 target="RFC7915" format="default"/> (more precisely, a stateless
4 is not available for translation, the CLAT device uses a stateful NAT44 IP/ICMP translation from IPv4 to IPv6). IPv4-embedded IPv6 addresses
translation before the stateless NAT46 translation.</t> <!-- I'm <xref target="RFC6052" format="default"/> are used for both source and
not sure I understand the above statement. It seems to conflate the /64 destination addresses. Commonly, a /96 prefix (either the 64:ff9b::/96
destination address needed to route the 46 translated traffic to the PLAT Well-Known Prefix (WKP) or a Network-Specific Prefix) is used as the
with moving the stateful NAT44 function from the PLAT to the CLAT --> IPv6 destination for the IPv4-embedded client traffic.</t>
<!-- GL: Please refer to: https://tools.ietf.org/html/rf <t>In deployments where NAT64 load balancing (see <xref target="RFC7269"
c6877#section-6.3 --> <t>In general, keeping state in devices close to sectionFormat="of" section="4.2"/>) is enabled, multiple WKPs <xref targ
the end-user network (i.e. at the CE - Customer Edge router) is not pe et="RFC8215" format="default"/> may be used.</t>
rceived as problematic as keeping state in the operator's networ <t>In the operator's network, the provider-side translator (PLAT)
k.</t> <!-- GL: <t>The authors generally do not see state close performs stateful NAT64 <xref target="RFC6146" format="default"/> to tra
to the end-user as equally problematic as state in the middle of the netw nslate the
ork.</t> --> <t>In typical deployments, 464XLAT is used tog traffic. The destination IPv4 address is extracted from the
ether with DNS64 <xref target="RFC6147"/>, see Section 3.1.2 of <x IPv4-embedded IPv6 packet destination address, and the source address is
ref target="RFC8683"/>. When an IPv6-only client or application communica from a pool of public IPv4 addresses.</t>
tes with an IPv4-only server, the DNS64 server returns the IPv4-embedded
IPv6 address of the IPv4-only server. In this case, the IPv6-only client <t>Alternatively, when a dedicated /64 is not available for translation,
sends out IPv6 packets, and the CLAT functions as an IPv6 router and the the CLAT device uses a stateful NAT44 translation before the stateless
PLAT performs a stateful NAT64 for these packets. In this case, there is NAT46 translation.</t>
a single translation.</t> <t>Similarly, whe
n an IPv4-only client or application communicates with an IPv4-o <t>In general, keeping state in devices close to the end-user network (i.e., at
nly server, the CLAT will statelessly translate to IPv6 so it can t the CE (Customer Edge) router) is not perceived to be as problematic as keeping
raverse the ISP network up to the PLAT (NAT64), which in turn will translate state in the operator's network.
to IPv4.</t> <t>Alternatively, one can say that DNS64 + stateful N </t>
AT64 is used to carry the traffic of the IPv6-only client and the IPv4-on
ly server, and the CLAT is used only for the IPv4 traffic from applicatio <t>In typical deployments, 464XLAT is used together with DNS64
ns or devices that use literal IPv4 addresses or non-IPv6 compliant APIs. <xref target="RFC6147" format="default"/>; see <xref
</t><!--*** Comment 1 - For the above 2 paragraphs, is the above case a target="RFC8683" sectionFormat="of" section="3.1.2"/>.
typical deployment? Isn't mobile still overwhelmingly the most common dep When an IPv6-only client or application communicates with an IPv4-only
loyer of 464? Comment 2 - I think that the above 2 paragraphs wou server, the DNS64 server returns the IPv4-embedded IPv6 address of the
ld be better moved to another section. This is meant to be a overview of IPv4-only server. In this case, the IPv6-only client sends out IPv6
how 464XLAT works. Combining with DNS64/NAT64 adds in another solution (n packets, the CLAT functions as an IPv6 router, and the PLAT performs a
ot part of the stated scope of the doc ) which could be done with any of stateful NAT64 for these packets. There is a single
the technologies described here whether this is commonly done or not). It translation.</t>
's not a part of 464XLAT and it's not unique to it. --> <t>Similarly, when an IPv4-only client or application communicates
<!-- GL: for Comment 2 - Yes, it could be put to somewhere else, with an IPv4-only server, the CLAT will statelessly translate to IPv6
but, in practice, ONLY 464XLAT is combined with DNS64/NAT64. RFC 6 so it can traverse the ISP network up to the PLAT (NAT64), which in
877 mentions already in the Introduction that it can be use together w turn will translate to IPv4.</t>
ith DNS64 or without it. This is one of the most important advanta <t>Alternatively, one can say that DNS64 + stateful NAT64 is
ges of 464XLAT that the vast majority of the traffic does not need to used to carry the traffic of the IPv6-only client and the IPv4-only
be double translated. I did some Google-ing to chech whether T-Mobile U server, and the CLAT is used only for the IPv4 traffic from applications
SA uses 464XLAT together with DNS64. Yes it does. See slide 13 of or devices that use literal IPv4 addresses or non-IPv6-compliant APIs.
this pdf: https://www.sanog.org/resources/sanog23/SANOG23_464XLAT.p </t>
df --> <figure anchor="xlatarch" align="cente
r" title="Overview of the 464XLAT architecture"> <preamble></pre <figure anchor="xlatarch">
amble> <artwork align="left"><![CDATA[ Private +----------+ Tr <name>Overview of the 464XLAT Architecture</name>
anslated +----------+ _______ +------+ IPv4 | CLAT | 4-6-4 | <artwork align="left" name="" type="" alt=""><![CDATA[
PLAT | ( IPv4 ) | IPv4 |------->| Stateless|------------>| Stateful +--( Private +----------+ Translated +----------+ _______
Internet ) |Device|<-------| NAT46 |<------------| NAT64 | (________) +------+ IPv4 | CLAT | 4-6-4 | PLAT | ( IPv4 )
+------+ +----------+ ^ +----------+ | IPv4 |------->| Stateless|------------>| Stateful +--( Internet )
| Operator IPv6 |Device|<-------| NAT46 |<------------| NAT64 | (________)
network ]]></artwork> <postamble></ +------+ +----------+ ^ +----------+
postamble> </figure> <t>Note: in mobile networks, CLAT is commonly |
implemented in the user's equipment (UE or smartphone), please refer to Operator IPv6
Figure 2 of <xref target="RFC6877"/>.</t> <t>Often Network]]></artwork>
NAT64 vendors support direct communication (that is, without translation) </figure>
between two CLATs by means of hair-pinning through the NAT64.</t>
</section> <section anchor="dslite_ov" title="Dual-Stack Lite" <t>Note: In mobile networks, the CLAT is commonly implemented in the
> <t>Dual-Stack Lite (DS-Lite) <xref target="RFC6333"/> was the first user equipment (UE) or smartphone; please refer to Figure 2 in <xref
of the considered transition mechanisms to be developed. DS-Lite uses a target="RFC6877" format="default"/>.</t>
'Basic Bridging BroadBand' (B4) function in the customer's CE router t <t>Some NAT64 vendors support direct communication (that is, without tra
hat encapsulates IPv4 in IPv6 traffic and sends it over the IPv6 native s nslation)
ervice-provider network to an 'Address Family Transition Router' (AFTR). between two CLATs by means of hairpinning through the NAT64.</t>
The AFTR performs encapsulation/decapsulation of the 4in6 <xref target=" </section>
RFC2473"/> traffic and translates the IPv4 source address in the in <section anchor="dslite_ov" numbered="true" toc="default">
ner IPv4 packet to public IPv4 source address using a stateful NAPT44 <name>Dual-Stack Lite</name>
<xref target="RFC2663"/> function.</t> <figure anchor="dslitearch" align <t>Dual-Stack Lite (DS-Lite) <xref target="RFC6333" format="default"/> w
="center" title="Overview of the DS-Lite architecture"> <preambl as the first
e></preamble> <artwork align="left"><![CDATA[ of the considered transition mechanisms to be developed. DS-Lite uses a
+-------------+ Private +----------+ IPv4-in-IPv6|Stateful Basic Bridging BroadBand (B4) function in the customer's CE router
AFTR|+------+ IPv4 | B4 | tunnel |------+------+ _______| IPv4 that encapsulates IPv4 in IPv6 traffic and sends it over the IPv6 native
|------->| Encap./ |------------>|Encap.| | ( IPv4 )|Device|<-------| service provider network to an Address Family Transition
decap. |<------------| / | NAPT +--( Internet )+------+ +---------- Router (AFTR). The AFTR performs encapsulation/decapsulation of the
+ ^ |Decap.| 44 | (________) | 4in6 <xref target="RFC2473" format="default"/> traffic and translates th
+------+------+ Operator IPv6 e IPv4 source
network ]]></artwork> <postamble></postamble> </ address in the inner IPv4 packet to a public IPv4 source address
figure> <t>Some AFTR vendors support direct communication using
between two B4s by means of hair-pinning through the AFTR.</t> a stateful NAPT44 <xref target="RFC2663" format="default"/> funct
</section> <section anchor="lw4o6_ov" title="Lightweight 4over6"> ion.</t>
<t>Lightweight 4over6 (lw4o6) is a variant of DS-Lite. The main di <figure anchor="dslitearch">
fference is that the stateful NAPT44 function is relocated from the centr <name>Overview of the DS-Lite Architecture</name>
alized AFTR to the customer's B4 element (called a lwB4). The AFTR (calle <artwork align="left" name="" type="" alt=""><![CDATA[
d a lwAFTR) function therefore only performs A+P routing <xref tar +-------------+
get="RFC6346"/> and 4in6 encapsulation/decapsulation.</t> <t>Routing to t Private +----------+ IPv4-in-IPv6|Stateful AFTR|
he correct client and IPv4 address sharing is achieved using the Address +------+ IPv4 | B4 | Tunnel |------+------+ _______
+ Port (A+P) model <xref target="RFC6346"/> of provisioning each lwB4 wit | IPv4 |------->| Encap./ |------------>|Encap.| | ( IPv4 )
h a unique tuple of IPv4 address and a unique range of transport layer po |Device|<-------| Decap. |<------------| / | NAPT +--( Internet )
rts. The client uses these for NAPT44.</t> <t>The lwAFTR implements a bin +------+ +----------+ ^ |Decap.| 44 | (________)
ding table, which has a per-client entry linking the customer's source IP | +------+------+
v4 address and allocated range of transport layer ports to their IPv6 tun Operator IPv6
nel endpoint address. The binding table allows egress traffic from custom Network]]></artwork>
ers to be validated (to prevent spoofing) and ingress traffic to be corr </figure>
ectly encapsulated and forwarded. As there needs to be a per-client entry <t>Some AFTR vendors support direct communication
, an lwAFTR implementation needs to be optimized for performing a per-pac between two B4s by means of hairpinning through the AFTR.</t>
ket lookup on the binding table.</t> <t>Direct communication (that </section>
is, without translation) between two lwB4s is performed by hair-pinning <section anchor="lw4o6_ov" numbered="true" toc="default">
traffic through the lwAFTR.</t> <figure anchor="lw4o6arch" align="center" <name>Lightweight 4over6</name>
title="Overview of the lw4o6 architecture"> <preamble></preamble> <t>Lightweight 4over6 (lw4o6) is a variant of DS-Lite. The main
<artwork align="left"><![CDATA[ +-------------+ difference is that the stateful NAPT44 function is relocated from the
+----------+ Private | lwB4 | IPv4-in-IPv6| Stateless|+------+ centralized AFTR to the customer's B4 element (called an "lwB4"). The
IPv4 |------+------| tunnel | lwAFTR | _______| IPv4 |------->| AFTR (called an "lwAFTR") function therefore only performs A+P
|Encap.|------------>|(encap/A+P| ( IPv4 )|Device|<-------| NAPT | / |< (Address plus Port) routing <xref target="RFC6346" format="default"/> an
------------|bind. tab +--( Internet )+------+ | 44 |Decap.| ^ d 4in6
| routing) | (________) +------+------+ | +-------- encapsulation/decapsulation.</t>
--+ Operator IPv6 <t>Routing to the correct client and IPv4 address sharing are achieved
network ]]></artwork> <postamble></postamble> </figure> using the A+P model <xref target="RFC6346" format="default"/> of
</section> <section anchor="map_e_ov" title="MAP-E"> <t>Like 464X provisioning each lwB4 with a unique tuple of IPv4 address and a unique
LAT (<xref target="xlat_ov"/>), MAP-E and MAP-T use <xref target="RFC range
6052"/> IPv4-embedded IPv6 addresses to represent IPv4 hosts out of transport-layer ports. The client uses these for NAPT44.</t>
side the MAP domain. </t> <t>MAP-E and MAP-T use a stateless algori <t>The lwAFTR implements a binding table, which has a per-client
thm to embed portions of the customer's allocated IPv4 address (or part o entry linking the customer's source IPv4 address and an allocated range
f an address with A+P routing) into the IPv6 prefix delegated to the clie of
nt. This allows for large numbers of clients to be provisioned using a si transport-layer ports to their IPv6 tunnel endpoint address. The binding
ngle MAP rule (called a MAP domain). The algorithm also allows for direct table
IPv4 peer-to-peer communication between hosts provisioned with common MA allows egress traffic from customers to be validated (to prevent
P rules.</t> <t>The CE (Customer-Edge) router typically performs stateful spoofing) and ingress traffic to be correctly encapsulated and
NAPT44 <xref target="RFC2663"/> to translate the private IPv4 source ad forwarded. As there needs to be a per-client entry, an lwAFTR
dresses and source ports into an address and port range defined by applyi implementation needs to be optimized for performing a per-packet
ng the MAP rule to the delegated IPv6 prefix. The client address/p lookup on the binding table.</t>
ort allocation size is a configuration parameter. The CE router then enca <t>Direct communication (that is, without translation) between two lwB4s
psulates the IPv4 packet in an IPv6 packet <xref target="RFC2473"/> and s is performed by hairpinning
ends it directly to another host in the MAP domain (for peer-to-peer) or traffic through the lwAFTR.</t>
to a Border Router (BR) if the IPv4 destination is not covered in one of <figure anchor="lw4o6arch">
the CE's MAP rules.</t> <t>The MAP BR is provisioned with the set of MAP <name>Overview of the lw4o6 Architecture</name>
rules for the MAP domains it serves. These rules determine how <artwork align="left" name="" type="" alt=""><![CDATA[
the MAP BR is to decapsulate traffic that it receives from clie +-------------+ +----------+
nt, validating the source IPv4 address and transport layer ports Private | lwB4 | IPv4-in-IPv6| Stateless|
assigned, as well as how to calculate the destination IPv6 address +------+ IPv4 |------+------| Tunnel | lwAFTR | _______
for ingress IPv4 traffic.</t> <figure anchor="map-e-arch" align="center" | IPv4 |------->| |Encap.|------------>|(encap/A+P| ( IPv4 )
title="Overview of the MAP-E architecture"> <preamble></preambl |Device|<-------| NAPT | / |<------------|bind. tab +--( Internet )
e> <artwork align="left"><![CDATA[ +-------------+ +------+ | 44 |Decap.| ^ | routing) | (________)
+----------+ Private | MAP CE | IPv4-in-IPv6| Stateless|+------ +------+------+ | +----------+
+ IPv4 |------+------| tunnel | MAP BR | _______| IPv4 |------->| Operator IPv6
|Encap.|------------>|(encap/A+P| ( IPv4 )|Device|<-------| NAPT | / Network]]></artwork>
|<------------|algorithm +--( Internet )+------+ | 44 |Decap.| ^ </figure>
| routing) | (________) +------+------+ | +------ </section>
----+ Operator IPv6 <section anchor="map_e_ov" numbered="true" toc="default">
network ]]></artwork> <postamble></postamble> </figure> <name>MAP-E</name>
<t>Some BR vendors support direct communication b <t>Like 464XLAT (<xref target="xlat_ov" format="default"/>), MAP-E and M
etween two MAP CEs by means of hair-pinning through the BR.</t> </section> AP-T use
<section anchor="map_t_ov" title="MAP-T"> <t>MAP-T uses the same mapp IPv4-embedded IPv6 addresses <xref target="RFC6052" format="defau
ing algorithm as MAP-E. The major difference is that double stateless tra lt"/> to represent IPv4
nslation (NAT46 in the CE and NAT64 in the BR) is used to traverse the IS hosts outside the MAP domain. </t>
P's IPv6 single-stack network. MAP-T can also be compared to 464XLAT when <t>MAP-E and MAP-T use a stateless algorithm to embed portions of the cu
there is a double translation.</t> <!-- I think the last sentence can be stomer's
removed as 'double translation' is notreally equivalent in this case. MAP-T has allocated IPv4 address (or part of an address with A+P routing) into the
3 translations - 1 stateful, 2 statelessXLAT has 2 translations - 1 statless, 1 IPv6 prefix delegated to the client. This allows for large numbers of
stateful --><!-- GL: Strictly speaking: you are right. But in a high level view clients to be provisioned using a single MAP rule (called a "MAP domain"
, both translate private IPv4 to IPv6 and IPv6 to public IPv4. --> <t>A M ).
AP CE router typically performs stateful NAPT44 to translate traffic to a public The algorithm also allows direct IPv4 peer-to-peer communication
IPv4 address and port-range calculated by applying the provisioned between hosts provisioned with common MAP rules.</t>
Basic MAP Rule (BMR - a set of inputs to the algorithm) to the delegated <t>The CE router typically performs stateful NAPT44
IPv6 prefix. The CE then performs stateless translation from IPv4 to I <xref target="RFC2663" format="default"/> to translate the private IPv4
Pv6 <xref target="RFC7915"/>. The MAP BR is provisioned with the same BMR source addresses
as the client, enabling the received IPv6 traffic to be statelessly NAT6 and source ports into an address and port range defined by applying
4 translated back to the public IPv4 source address used by the cl the MAP rule to the delegated IPv6 prefix. The client
ient.</t> <t>Using translation instead of encapsulation also allows IPv4- address/port allocation size is a configuration parameter. The CE router
only nodes to correspond directly with IPv6 nodes in the MAP-T domain then
that have IPv4-embedded IPv6 addresses.</t><!-- Whilst the above is theoriti encapsulates the IPv4 packet in an IPv6 packet <xref target="RFC2473" fo
cally true, are there implementations inpractice? How would name resolution /ser rmat="default"/>
ivce discovery work? The node thatgenerally implements MAP (and gets provisioned and sends it directly to another host in the MAP domain
with the MAP rule is a CE device. --><!-- GL: If I remember well, the above sta (for peer-to-peer) or to a Border Router (BR) if the IPv4 destination is
tement is from Ole Troan, one of the authors of the MAP protocols, thus it is ve not covered in one of the CE's MAP rules.</t>
ry likely true. However, I myself can neither prove, nor confute it.--> <
figure anchor="map-t-arch" align="center" title="Overview of the MAP-T ar <t>The MAP BR is provisioned with the set of MAP rules for the MAP
chitecture"> <preamble></preamble> <artwork align="left"><![CDATA[ domains it serves. These rules determine how the MAP BR is to decapsulat
+-------------+ +----------+ Private | MAP e
CE | Translated | Stateless|+------+ IPv4 |------+------| 4-6-4 | M traffic that it receives from the client, validate the source IPv4
AP BR | _______| IPv4 |------->| |State-|------------>|(NAT64/A+P| address and transport-layer ports assigned, and calculate the
( IPv4 )|Device|<-------| NAPT | less |<------------|algorithm +--( Internet )+ destination IPv6 address for ingress IPv4 traffic.</t>
------+ | 44 |NAT46 | ^ | routing) | (________) <figure anchor="map-e-arch">
+------+------+ | +----------+ Operat <name>Overview of the MAP-E Architecture</name>
or IPv6 network ]]></artwork> < <artwork align="left" name="" type="" alt=""><![CDATA[
postamble></postamble> </figure> <t>Some BR vendors suppor +-------------+ +----------+
t direct communication between two MAP CEs by means of hair-pinn Private | MAP CE | IPv4-in-IPv6| Stateless|
ing through the BR.</t> </section> </sec +------+ IPv4 |------+------| tunnel | MAP BR | _______
tion> <section anchor="hl_arch" title="High-level Architectures and theirCons | IPv4 |------->| |Encap.|------------>|(encap/A+P| ( IPv4 )
equences"> <section anchor="sp_net_trav" title="Service Provider Network Tr |Device|<-------| NAPT | / |<------------|algorithm +--( Internet )
aversal"> <t>For the data-plane, there are two approaches for traversing +------+ | 44 |Decap.| ^ | routing) | (________)
the IPv6 provider network: <list style="symbols"> <t>4-6- +------+------+ | +----------+
4 translation</t> <t>4-in-6 encapsulation</t> </list></t> Operator IPv6
<texttable anchor="net_trav_table" title="Available Traversal Mechanisms"> Network]]></artwork>
<preamble></preamble> <ttcol align="center"></ttcol> <ttc </figure>
ol align="center">464XLAT</ttcol> <ttcol align="center">DS-Lite</ttcol> <t>Some BR vendors support direct communication
<ttcol align="center">lw4o6</ttcol> <ttcol align="center">MAP between two MAP CEs by means of hairpinning through the BR.</t>
-E</ttcol> <ttcol align="center">MAP-T</ttcol> <c>4-6-4 trans. </section>
</c> <c>X</c> <c></c> <c></c> <c></c> <section anchor="map_t_ov" numbered="true" toc="default">
<c>X</c> <c>4-6-4 encap.</c> <c></c> <c>X</c> <name>MAP-T</name>
<c>X</c> <c>X</c> <c></c> <postamble></postamble <t>MAP-T uses the same mapping algorithm as MAP-E. The major difference
> </texttable> <t>In the scope of this document, all of the encaps is that double stateless translation (NAT46 in the CE and NAT64 in the
ulation based mechanisms use IP-in-IP tunnelling <xref target="RFC2473"/> BR) is used to traverse the ISP's IPv6 single-stack network. MAP-T can
. This is a stateless tunneling mechanism which does not require any also be compared to 464XLAT when there is a double translation.</t>
additional overhead.</t> <t>It should be noted that both of these appr
oaches result in an increase in the size of the packet that needs to be t <t>A MAP CE router typically performs stateful NAPT44 to translate traffic to a
ransported across the operator's network when compared to native IPv4. 4- public
6-4 translation adds a 20-bytes overhead (the 20-byte IPv4 header is IPv4 address and port range calculated by applying the provisioned
replaced with a 40-byte IPv6 header). Encapsulation has a 40-byte over Basic MAP Rule (BMR), which is a set of inputs to the algorithm, to the
head (an IPv6 header is prepended to the IPv4 header).</t> <t>The increas delegated
e in packet size can become a significant problem if there is a link with IPv6 prefix. The CE then performs stateless translation from IPv4 to
a smaller MTU in the traffic path. This may result in traffic needing to IPv6 <xref target="RFC7915" format="default"/>.
be fragmented at the ingress point to the IPv6 only domain (i.e., the NA The MAP BR is
T46 or 4in6 encapsulation endpoint). It may also result in the need to im provisioned with the same BMR as the client, enabling the received
plement buffering and fragment re-assembly in the PLAT/AFTR/lwAFTR/BR nod IPv6 traffic to be translated (using stateless NAT64) back to the public
e.</t> <t>The advice given in <xref target="RFC7597"/> Section 8.3.1 is IPv4 source address used by the client.
applicable to all of these mechanisms: It is strongly recommended that </t>
the MTU in the IPv6-only domain be well managed (it should have sufficiently <t>Using translation instead of encapsulation also allows IPv4-only
large MTU to support tunneling and/or translation) and that the I nodes to correspond directly with IPv6 nodes in the MAP-T domain
Pv6 MTU on the CE WAN-side interface be set so that no fragmentation occu that have IPv4-embedded IPv6 addresses.</t>
rs within the boundary of the IPv6-only domain.</t> </section>
<section anchor="nat" title="Network Address Translation among the Different IPv <figure anchor="map-t-arch">
4aaS Technologies"> <t>For the high-level solution of IPv6 service provid <name>Overview of the MAP-T Architecture</name>
er network traversal, MAP-T uses double stateless translation. First at t <artwork align="left" name="" type="" alt=""><![CDATA[
he CE from IPv4 to IPv6 (NAT46), and then from IPv6 to IPv4 (NAT64), at t +-------------+ +----------+
he service provider network.</t> <t>464XLAT may use double transla Private | MAP CE | Translated | Stateless|
tion (stateless NAT46 + stateful NAT64) or single translation (stateful N +------+ IPv4 |------+------| 4-6-4 | MAP BR | _______
AT64), depending on different factors, such as the use of DNS by the appl | IPv4 |------->| |State-|------------>|(NAT64/A+P| ( IPv4 )
ications and the availability of a DNS64 function (in the host or in the |Device|<-------| NAPT | less |<------------|algorithm +--( Internet )
service provider network). For deployment guidelines, please refer to <xr +------+ | 44 |NAT46 | ^ | routing) | (________)
ef target="RFC8683"/>.</t><!-- Here we're conflation NAT64 with 464XLAT again - +------+------+ | +----------+
see my comment in the 464XLAT overview --><!-- GL: Yes, because they are used to Operator IPv6
gether. --> <t>The first step for the double translation mechanisms is a Network]]></artwork>
stateless NAT from IPv4 to IPv6 implemented as SIIT (Stateless IP/ICMP Tr </figure>
anslation Algorithm) <xref target="RFC7915"/>, which does not translate I <t>Some BR vendors support direct communication
Pv4 header options and/or multicast IP/ICMP packets. With encapsu between two MAP CEs by means of hairpinning through the BR.</t>
lation-based technologies the header is transported intact and multicast </section>
can also be carried.</t> <t>Single and double translation results in nati </section>
ve IPv6 traffic with a transport layer next-header. The fields in these h <section anchor="hl_arch" numbered="true" toc="default">
eaders can be used for functions such as hashing across equal-co <name>High-Level Architectures and Their Consequences</name>
st multipaths or access control list (ACL) filtering. Encapsulation tec <section anchor="sp_net_trav" numbered="true" toc="default">
hnologies, in contrast, may hinder hashing algorithms or other funct <name>Service Provider Network Traversal</name>
ions relying on header inspection.</t> <t>Solutions using doubl <t>For the data plane, there are two approaches for traversing
e translation can only carry port-aware IP protocols (e.g. TCP, UDP) and the IPv6 provider network:
ICMP when they are used with IPv4 address sharing (please refer to <xref </t>
target="pub_serv"/> for more details). Encapsulation based solutions can
carry any other protocols over IP, too.</t> < <ul spacing="normal">
t>An in-depth analysis of stateful NAT64 can be found in <xref target="RFC6889"/ <li>4-6-4 translation</li>
>.</t> <t>As stateful NAT interferes with the port numbe <li>4in6 encapsulation</li>
rs, <xref target="I-D.ietf-tsvwg-natsupp"/> explains how NATs can han </ul>
dle SCTP (Stream Control Transmission Protocol).</t>
<!-- The above paragraph really needs more detail in there as it <table anchor="net_trav_table" align="center">
oversimplifiesthe reality. Encap with address sharing can't carry a non-port awa <name>Available Traversal Mechanisms</name>
re protocolsuch as GRE (without UDP). A stateful CGN is generally capable of per <thead>
forming NAT44 (not- NAPT) for non-port aware protocols. --><!-- GL: Could you el <tr>
aborate it in the text? --> </section> <section anchor="ipv4_sharing" <th align="center"/>
title="IPv4 Address Sharing"> <t>As public IPv4 address exhaustion is a c <th align="center">464XLAT</th>
ommon motivation for deploying IPv6, transition technologies need to prov <th align="center">DS-Lite</th>
ide a solution for allowing public IPv4 address sharing.</t> <t>In <th align="center">lw4o6</th>
order to fulfill this requirement, a stateful NAPT function is a necessa <th align="center">MAP-E</th>
ry function in all of the mechanisms. The major differentiator is where i <th align="center">MAP-T</th>
n the architecture this function is located.</t> <t>The solutions compare </tr>
d by this document fall into two categories: <list style="symbols"> </thead>
<t>CGN-based approaches (DS-Lite, 464XLAT)</t> <t>A+P-based approac <tbody>
hes (lw4o6, MAP-E, MAP-T)</t> </list></t> <t>In the CGN-based mode <tr>
l, a device such as a CGN/AFTR or NAT64 performs the NAPT44 function and <td align="left">4-6-4 translation</td>
maintains per-session state for all of the active client's traffic. The c <td align="center">X</td>
ustomer's device does not require per-session state for NAPT.</t> <td align="center"/>
<t>In the A+P-based model, a device (usually a CE) performs stateful NA <td align="center"/>
PT44 and maintains per-session state only co-located devices, e.g. in the <td align="center"/>
customer's home network. Here, the centralized network function (lwAFTR <td align="center">X</td>
or BR) only needs to perform stateless encapsulation/decapsulation or NAT </tr>
64.</t> <t>Issues related to IPv4 address sharing mechanisms are describe <tr>
d in <xref target="RFC6269"/> and should also be considered.</t> <td align="left">4in6 encapsulation</td>
<t>The address sharing efficiency of the five technologies is significant <td align="center"/>
ly different, it is discussed in <xref target="port_num_eff"/>.</t> <td align="center">X</td>
<t>lw4o6, MAP-E and MAP-T can also be configured without IPv4 address <td align="center">X</td>
sharing, see the details in <xref target="pub_serv"/>. However, in that c <td align="center">X</td>
ase, there is no advantage in terms of public IPv4 address saving. In the <td align="center"/>
case of 464XLAT, this can be achieved as well through EAMT (Explicit Address Ma </tr>
pping Table) <xref target="RFC7757"/>.</t> <t>Conversely, both MAP </tbody>
-E and MAP-T may be configured to provide more than one public IPv4 addre </table>
ss (i.e., an IPv4 prefix shorter than a /32) to customers.</t>
<t>Dynamic DNS issues in address-sharing contexts and their possi <t>In the scope of this document, all of the encapsulation-based
ble solutions using PCP (Port Control Protocol) are discussed in deta mechanisms use IP-in-IP tunneling <xref target="RFC2473" format="default
il in <xref target="RFC7393"/>.</t> </section> "/>.
<section anchor="ipv4_pool" title="IPv4 Pool Size Considerations"> This is a stateless tunneling mechanism that does not require any
<t>In this section we do some simple calculations regarding port numbers, additional overhead.</t>
however, technical limitations are not the only point to consider for <t>It should be noted that both of these approaches result in an
port sharing, there are also local regulations or BCP.</t> increase in the size of the packet that needs to be transported across
<t>Note: under "port numbers", we mean TCP/UDP port numbers or IC the operator's network when compared to native IPv4. 4-6-4
MP identifiers.</t> <t>In most networks, it is possible to, u translation adds a 20-byte overhead (the 20-byte IPv4 header is
sing existing data about flows to CDNs/caches or other well-known I replaced with a 40-byte IPv6 header). Encapsulation has a 40-byte
Pv6-enabled destinations, calculate the percentage of traffic tha overhead (an IPv6 header is prepended to the IPv4 header).</t>
t would turn into IPv6 if it is enabled on that network or part o <t>The increase in packet size can become a significant problem if there
f it.</t> <t>Knowing that, it is possible to calculate the IPv4 poo is a link with a smaller MTU in the traffic path. This may result in the
l size required for a given number of subscribers, depending on t need for
he IPv4aaS technology being used.</t> <t>According to <xref tar traffic to be fragmented at the ingress point to the IPv6 only
get="MIY2010"/>, each user-device (computer, tablet, smartphone) behin domain (i.e., the NAT46 or 4in6 encapsulation endpoint). It may also
d a NAT, could simultaneously use up to 300 ports. (Table 1 of <xref result in the need to implement buffering and fragment reassembly
target="MIY2010"/> lists the port number usage of various applicati in the PLAT/AFTR/lwAFTR/BR node.</t>
ons. According to <xref target="REP2014"/> the downloading of some w <t>The advice given in <xref target="RFC7597" sectionFormat="of"
eb pages may consume up to 200 port numbers.) If the extended NAPT a section="8.3.1"/> is applicable to all of these mechanisms:
lgorithm is used, which includes the full five tuple into the connection
tracking table, then the port numbers are reused, when the destinations It is
are different. Therefore, we need to consider the number of "port strongly recommended that the MTU in the IPv6-only domain be well
hungry" applications that are accessing the same destination simu managed (it should have sufficiently large MTU to support tunneling
ltaneously. We estimate that in the case of a residential subscriber, and/or translation) and that the IPv6 MTU on the CE WAN-side interface
there will be typically no more than 4 of port hungry applicati be set so that no fragmentation occurs within the boundary of the
ons communicating with the same destination simultaneously, whic IPv6-only domain.</t>
h means a total of 1,200 ports. </t> <t>If for example, 80% of the tra </section>
ffic is expected towards IPv6 destinations, only 20% will actually be <section anchor="nat" numbered="true" toc="default">
using IPv4 ports, so in our example, that will mean 240 ports require <name>Network Address Translation among the Different IPv4aaS Technologi
d per subscriber.</t> <t>From the 65,535 ports available per IPv4 addre es</name>
ss, we could even consider reserving 1,024 ports, in order to allow
customers that need EAMT entries for incoming connections to Syste <t>
m Ports (0-1023, also called well-known ports) <xref target="RFC For the high-level solution of IPv6 service provider network traversal,
7605"/>, which means 64,511 ports actually available per each IPv4 MAP-T uses double stateless translation. The first translation is from IPv4
address.</t> <t>According to this, a /22 (1.024 public IPv4 addresses) to IPv6 (NAT46) at the CE, and the second translation is from IPv6 to IPv4
will be sufficient for over 275,000 subscribers (1,024x64,511/240=27 (NAT64) at the service provider network.
5,246.93).</t> <t>Similarly, a /18 (16,384 public IPv4 a </t>
ddresses) will be sufficient for over 4,403,940 subscribers, and so on <t>464XLAT may use double translation (stateless NAT46 + stateful
.</t> <t>This is a conservative approach, which is valid in the case of NAT64) or single translation (stateful NAT64) depending on different
464XLAT, because ports are assigned dynamically by the NAT64, so i factors, such as the use of DNS by the applications and the availability
t is not necessary to consider if one user is actually using more or of a DNS64 function (in the host or in the service provider network).
less ports: Average values work well.</t> <t>As the For deployment guidelines, please refer to <xref target="RFC8683" format
deployment of IPv6 progresses, the use of NAT64, and therefore of p ="default"/>.</t>
ublic IPv4 addresses, decreases (more IPv6/ports, less IPv4/ports), so either <t>The first step for the double translation mechanisms is a stateless
more subscribers can be accommodated with the same number of IPv4 address NAT from IPv4 to IPv6 implemented as SIIT (Stateless IP/ICMP
es, or some of those addressed can be retired from the NAT64.</t> Translation Algorithm) <xref target="RFC7915" format="default"/>,
<t>For comparison, if dual-stack is being used, any given number of users which does not translate IPv4 header options and/or multicast IP/ICMP
will require the same number of public IPv4 addresses. For instance, a packets. With encapsulation-based technologies, the header is
/14 will provide 262,144 IPv4 public addresses for 262,144 subscri transported intact, and multicast can also be carried.</t>
bers, versus 275,000 subscribers being served with only a /22.</t> <t>Single and double translation results in native IPv6 traffic with a
<t>In the other IPv4aaS technologies, this calculation will only match if transport-layer next header. The fields in these headers can be used
the assignment of ports per subscriber can be done dynamically, which for functions such as hashing across equal-cost multipaths or Access
is not always the case (depending on the vendor implementation) Control List (ACL) filtering. Encapsulation technologies, in contrast,
.</t> <t>An alternative approximation for the other IPv4aaS technologie may hinder hashing algorithms or other functions relying on header
s, when dynamically assignment of addresses is not possible, must en inspection.</t>
sure sufficient number of ports per subscriber. That means 1,200 <t>Solutions using double translation can only carry port-aware IP
ports, and typically, it comes to 2,000 ports in many deployment protocols (e.g., TCP and UDP) and ICMP when they are used with IPv4
s. In that case, assuming 80% of IPv6 traffic, as above, which w address sharing (please refer to <xref target="pub_serv"
ill allow only 30 subscribers per each IPv4 address, so the closer ap format="default"/> for more details). Encapsulation-based solutions
proximation to 275,000 subscribers per our example with 464XLAT ( can also carry any other protocols over IP.</t>
with a /22), will be using a /19, which serves 245,760 subscribers (a /19 <t>An in-depth analysis of stateful NAT64 can be found in <xref target="
has 8,192 addresses, 30 subscribers with 2,000 ports each, per address).< RFC6889" format="default"/>.</t>
/t> <t>If the CGN (in case of DS-Lite) or the CE (in case of lw4o6, M <t>As stateful NAT interferes with the port numbers, <xref
AP-E and MAP-T) make use of a 5-tuple for tracking the NAT connec target="I-D.ietf-tsvwg-natsupp" format="default"/> explains how NATs
tions, the number of ports required per subscriber can be limited as can handle SCTP (Stream Control Transmission Protocol).</t>
low as 4 ports per subscriber. However, the practical limit depe </section>
nds on the desired limit for parallel connections that any single host <section anchor="ipv4_sharing" numbered="true" toc="default">
behind the NAT can have to the same address and port in Internet. Not <name>IPv4 Address Sharing</name>
e that it is becoming more common that applications use AJAX (Asynchr <t>As public IPv4 address exhaustion is a common motivation for
onous JavaScript and XML) and similar mechanisms, so taking that extr deploying IPv6, transition technologies need to provide a solution that
eme limit is probably not a safe choice.</t> <t>This extremely reduced allows public IPv4 address sharing.</t>
number of ports "feature" could also be used in case the CLAT-ena <t>In order to fulfill this requirement, a stateful NAPT function is
bled CE with 464XLAT makes use of the 5-tuple NAT connections track a necessary function in all of the mechanisms. The major differentiator
ing, and could also be further extended if the NAT64 also use the is where in the architecture this function is located.</t>
5-tuple.</t> <t>Please also refer to <xref target="RFC <t>The solutions compared by this document fall into two categories:
6888"/> for in-depth information about the requirements for sizi </t>
ng Carrier-Grade NAT gateways.</t> </section> <section anchor="ce_prov <ul spacing="normal">
" title="CE Provisioning Considerations"> <t>All of the technologies requ <li>Approaches based on Carrier-Grade NAT (CGN) (DS-Lite, 464XLAT)</li
ire some provisioning of customer devices. The table below shows which me >
thods currently have extensions for provisioning the different mechanisms <li>Approaches based on A+P (lw4o6, MAP-E, MAP-T)</li>
.</t> <texttable anchor="prov_mech_table" title="Available Provisioning </ul>
Mechanisms"> <preamble></preamble> <ttcol align="left">P <t>In the CGN-based model, a device such as a CGN/AFTR or NAT64 performs
rovisioning Method</ttcol> <ttcol align="center">464XLAT</ttcol> the NAPT44 function and maintains per-session state for all of the
<ttcol align="center">DS-Lite</ttcol> <ttcol align="center">lw4o6</t active client's traffic. The customer's device does not require
tcol> <ttcol align="center">MAP-E</ttcol> <ttcol align="center per-session state for NAPT.</t>
">MAP-T</ttcol> <c>DHCPv6 <xref target="RFC8415"/></c> <c></c>
<c>X</c> <c>X</c> <c>X</c> <c>X</c> <t>In the A+P-based model, a device (usually a CE) performs stateful
<c>RADIUS <xref target="RFC8658"/></c> <c></c> <c><xref targ NAPT44 and maintains per-session state only for co-located devices,
et="RFC6519"/></c> <c>X</c> <c>X</c> <c>X</c> e.g., in the customer's home network. Here, the centralized network
<c>TR-069 <xref target="TR-069"/></c> <c>*</c> <c>X</c> function (lwAFTR or BR) only needs to perform stateless
<c>*</c> <c>X</c> <c>X</c> <c>DNS64 <xref target encapsulation/decapsulation or NAT64.</t>
="RFC7050"/></c> <c>X</c> <c></c> <c></c> <c <t>Issues related to IPv4 address-sharing mechanisms are described
></c> <c></c> <c>YANG <xref target="RFC7950"/></c> <c in <xref target="RFC6269" format="default"/> and should also be consider
><xref target="RFC8512"/></c> <c><xref target="RFC8513"/></c> ed.</t>
<c><xref target="RFC8676"/></c> <c><xref target="RFC8676"/></c> <t>The address-sharing efficiency of the five technologies is
<c><xref target="RFC8676"/></c> <c>DHCP4o6 <xref target="RFC7341"/></ significantly different and is discussed in
c> <c></c> <c></c> <c>X</c> <c>X</c> <xref target="port_num_eff" format="default"/>.</t>
<c></c> <postamble></postamble> </texttable> <t>*: Work <t>Lw4o6, MAP-E, and MAP-T can also be configured without IPv4 address s
started at BroadBand Forum (2021).</t> <t>X: Supported by the provisioni haring;
ng method.</t><!--*** References to RFCs are needed in the first column of the t see the details in <xref target="pub_serv"
able above. --> </section> <section anchor="multicast" title="S format="default"/>. However, in that case, there is no advantage in
upport for Multicast"> <t>The solutions covered in this document are all terms of public IPv4 address saving.
intended for unicast traffic. <xref target="RFC8114"/> describes a method In the case of 464XLAT, one-to-one mapping can also
for carrying encapsulated IPv4 multicast traffic over an IPv6 multicast be achieved through EAMT (Explicit Address Mapping Table)
network. This could be deployed in parallel to any of the operator's <xref target="RFC7757" format="default"/>.</t>
chosen IPv4aaS mechanism.</t> </section> </section> <section title <t>Conversely, both MAP-E and MAP-T may be configured to provide more
="Detailed Analysis"> <section title="Architectural Differences"> <s than one public IPv4 address (i.e., an address with an IPv4 prefix short
ection title="Basic Comparison"> <t>The five IPv4aaS technologies can b er than a /32)
e classified into 2x2=4 categories on the basis of two aspects: to customers.</t>
<list style="symbols"> <t>Technology used for service provider netw <t>Dynamic DNS issues in address-sharing contexts and their possible
ork traversal. It can be single/double translation or encapsulation. solutions using PCP (Port Control Protocol) are discussed in deta
</t> <t>Presence or absence of NAPT44 per-flow state in the il
operator network. </t> </list></t> <texttable anc in <xref target="RFC7393" format="default"/>.</t>
hor="data_plane_table" title="Basic comparison among the analyzed technologies"> </section>
<preamble></preamble> <ttcol align="center"></ttcol> <section anchor="ipv4_pool" numbered="true" toc="default">
<ttcol align="center">464XLAT</ttcol> <ttcol align="center">DS <name>IPv4 Pool Size Considerations</name>
-Lite</ttcol> <ttcol align="center">lw4o6</ttcol> <ttcol a
lign="center">MAP-E</ttcol> <ttcol align="center">MAP-T</ttcol> <t>In this section, we do some simple calculations regarding port
<c>Translation (T) or Encapsulation (E) </c> <c>T</c> numbers. However, technical limitations are not the only point to
<c>E</c> <c>E</c> <c>E</c> <c>T</c> consider for port sharing; there are also local regulations and
<c>Per-flow state in op. network</c> <c>X</c> <c>X</c> best current practices.</t>
<c></c> <c></c> <c></c> </texttable>
</section> </section> <section anchor="port_num_eff" title= <t>Note: By "port numbers", we mean TCP/UDP port numbers or ICMP
"Tradeoff between Port Number Efficiency and Stateless Operation"> <t>46 identifiers.</t>
4XLAT and DS-Lite use stateful NAPT at the PLAT/AFTR devices, respectively.
This may cause scalability issues for the number of clients or volume of t <t>In most networks, it is possible to use existing data about flows to
raffic, but does not impose a limitation on the number of ports per user, Content Delivery Networks (CDNs), caches, or other well-known
as they can be allocated dynamically on-demand and the allocation policy c IPv6-enabled destinations to calculate the percentage of traffic that
an be centrally managed/adjusted.</t> <t>A+P based mechanisms (lw4o6, would turn into IPv6 if IPv6 is enabled on that network or on part of it.
MAP-E, and MAP-T) avoid using NAPT in the service provider network. Howeve </t>
r, this means that the number of ports provided to each user (and hence the <t>Knowing that, it is possible to calculate the IPv4 pool size
effective IPv4 address sharing ratio) must be pre-provisioned to the clien required for a given number of subscribers, depending on the IPv4aaS
t.</t> <t>Changing the allocated port ranges with A+P based technologi technology being used.</t>
es, requires more planning and is likely to involve re-provisioning both ho <t>According to <xref target="MIY2010" format="default"/>, each
sts and operator side equipment. It should be noted that due to the per-cus user device (computer, tablet, smartphone) behind a NAT could
tomer binding table entry used by lw4o6, a single customer can be re-provis simultaneously use up to 300 ports. (Table 1 of <xref
ioned (e.g., if they request a full IPv4 address) without needing to change target="MIY2010" format="default"/> lists the port number usage of
parameters for a number of customers as in a MAP domain.</t> <t>It is various applications. According to <xref target="REP2014"
also worth noting that there is a direct relationship between the efficien format="default"/>, the downloading of some web pages may consume up to
cy of customer public port-allocations and the corresponding logging overhe 200 port numbers.) If the extended NAPT algorithm is used, which
ad that may be necessary to meet data-retention requirements. This is consi includes the full 5-tuple into the connection tracking table, then
dered in <xref target="logging"/> below.</t> <t>Determining the optimal num the port numbers are reused when the destinations are
ber of ports for a fixed port set is not an easy task, and may also be impa different. Therefore, we need to consider the number of "port-hungry"
cted by local regulatory law (and in the Belgian case it is not a law but mo applications that are accessing the same destination simultaneously.
re a MoU / BCP), which may define a maximum number of users per IP address, We estimate that in the case of a residential subscriber, there will
and consequently a minimum number of ports per user.</t> <t>On the on be typically no more than four port-hungry applications communicating
e hand, the "lack of ports" situation may cause serious problems in the ope with the same destination simultaneously, which is a total of 1,200
ration of certain applications. For example, Miyakawa has demonstrated the ports. </t>
consequences of the session number limitation due to port number shortage o <t>For example, if 80% of the traffic is expected towards IPv6
n the example of Google Maps <xref target="MIY2010"/>. When the limit was destinations, only 20% will actually be using IPv4 ports. Thus, in our
15, several blocks of the map were missing, and the map was unusable. This example, 240 ports are required for each subscriber.</t>
study also provided several examples for the session numbers of different a
pplications (the highest one was Apple's iTunes: 230-270 ports).</t> < <t>From the 65,535 ports available per IPv4 address, we could even
t>The port number consumption of different applications is highly varying a consider reserving 1,024 ports for customers that need
nd e.g. in the case of web browsing it depends on several factors, includin EAMT entries for incoming connections to System ports (0-1023, also
g the choice of the web page, the web browser, and sometimes even the opera called "well-known ports") <xref target="RFC7605" format="default"/>.
ting system <xref target="REP2014"/>. For example, under certain conditions This means that 64,511 ports are actually available for each IPv4 addres
, 120-160 ports were used (URL: sohu.com, browser: Firefox under Ubuntu Li s.</t>
nux), and in some other cases it was only 3-12 ports (URL: twitter.com, bro <t>According to this, a /22 (1.024 public IPv4 addresses) will be suffic
wser: Iceweasel under Debian Linux).</t> <t>There may be several users ient
behind a CE router, especially in the broadband case (e.g. Internet is use for over 275,000 subscribers (1,024x64,511/240=275,246.93).</t>
d by different members of a family simultaneously), so sufficient ports mus <t>Similarly, a /18 (16,384 public IPv4 addresses) will be sufficient
t be allocated to avoid impacting user experience.</t> <t>In g for over 4,403,940 subscribers, and so on.</t>
eneral, assigning too few source port numbers to an end user may results <t>This is a conservative approach, which is valid in the case of
in unexpected and hard to debug consequences, therefore, if the number 464XLAT because ports are assigned dynamically by the NAT64. Therefore,
of ports per end user is fixed, then we recommend to assign a conservatively it is
large number of ports. E.g. the developers of Jool used 2048 ports per not necessary to consider if one user is actually using more or fewer
user in their example for MAP-T <xref target="MEX2022"/>.</t> <t>However, a ports; average values work well.</t>
ssigning too many ports per CE router will result in waste of public IPv4 a
ddresses, which is a scarce and expensive resource. Clearly this is a big a <t>As the deployment of IPv6 progresses, the use of NAT64, and
dvantage in the case of 464XLAT where they are dynamically managed, so tha therefore of public IPv4 addresses, decreases (more IPv6 ports, fewer
t the number of IPv4 addresses for the sharing-pool is smaller while the a IPv4 ports). Thus, either more subscribers can be accommodated with the
vailability of ports per user don't need to be pre-defined and is not a li same number of IPv4 addresses or some of those addressed can be
mitation for them.</t> <t>There is a direct tradeoff between the optimizati retired from the NAT64.</t>
on of client port allocations and the associated logging overhead. <x <t>For comparison, if dual-stack is being used, any given number of
ref target="logging"/> discusses this in more depth.</t><!-- Aren't CGNs general users will require the same number of public IPv4 addresses. For
ly deployed using port block allocation these days?If so, then getting the size instance, a /14 will provide 262,144 IPv4 public addresses for 262,144
of the allocated block right is also importanthere. --><!-- GL: I do not know, a subscribers, versus 275,000 subscribers being served with only a
s I am not a network operator. --> <t>We note that common CE router NAT44 i /22.</t>
mplementations utilizing Netfilter, multiplexes active sessions using a 3-t <t>In the other IPv4aaS technologies, this calculation will only match
uple (source address, destination address, and destination port). This mean if the assignment of ports per subscriber can be done dynamically,
s that external source ports can be reused for unique internal source and d which is not always the case (depending on the vendor
estination address and port sessions. It is also noted, that Netfilter cann implementation).</t>
ot currently make use of multiple source port ranges (i.e. several blocks o
f ports distributed across the total port space as is common in MAP deploy <t> When dynamic assignment of addresses is not possible, an
ments), this may influence the design when using stateless technologies.</t alternative approximation for the other IPv4aaS technologies must ensure a
> <t>Stateful technologies, 464XLAT and DS-Lite (and also NAT444) can sufficient number of ports per subscriber.
therefore be much more efficient in terms of port allocation and thus publi That means 1,200 ports, and
c IP address saving. The price is the stateful operation in the service pro typically, it comes to 2,000 ports in many deployments.
vider network, which allegedly does not scale up well. It should be noticed In that case, assuming 80% is IPv6 traffic (as above), only 30 subscribers
that in many cases, all those factors may depend on how it is actually imp will be allowed per each IPv4 address; thus, the closer approximation to
lemented.</t> <t>Measurements have been started to examine the scalability 275,000 subscribers per our example with 464XLAT (with a /22) will be using
of a few stateful solutions in two areas: <list style="symbols"> a /19, which serves 245,760 subscribers (a /19 has 8,192 addresses and 30
<t>How their performance scales up with the number of CPU cores?</t> subscribers with 2,000 ports each per address).
<t>To what extent their performance degrades with the number of </t>
concurrent connections?</t> </list> The details of <t>If the CGN (in case of DS-Lite) or the CE (in case of lw4o6, MAP-E,
the measurements and their results are available from <xref target="I and MAP-T) make use of a 5-tuple for tracking the NAT connections, the
-D.lencse-v6ops-transition-scalability"/>. </t><!--*** +1 on that! --> number of ports required per subscriber can be limited as low as four
<t>We note that some CGN-type solutions can allocate ports dynamically "o ports per subscriber. However, the practical limit depends on the
n the fly". Depending on configuration, this can result in the same custome desired limit for parallel connections that any single host behind the
r being allocated ports from different source addresses. This can cause ope NAT can have to the same address and port in Internet. Note that it is
rational issues for protocols and applications that expect multiple flows t becoming more common that applications use AJAX (Asynchronous
o be sourced from the same address. E.g., ECMP hashing, STUN, gaming, conte JavaScript and XML) and similar mechanisms, so taking that extreme
nt delivery networks. However, it should be noticed that this is the same p limit is probably not a safe choice.</t>
roblem when a network has a NAT44 with multiple public IPv4 addresses, or e
ven when applications in a dual-stack case, behave wrongly if happy eyeball <t>This feature of extremely reduced number of ports could also be used
s is flapping the flow address between IPv4 and IPv6.</t> <t>The conse in
quences of IPv4 address sharing <xref target="RFC6269"/> may impact all fiv case the CLAT-enabled CE with 464XLAT makes use of tracking the 5
e technologies. However, when ports are allocated statically, more customer -tuple NAT
s may get ports from the same public IPv4 address, which may results in neg connections and could also be further extended
ative consequences with higher probability, e.g. many applications and serv if the NAT64 also uses the 5-tuple.</t>
ice providers (Sony PlayStation Network, OpenDNS, etc.) permanently blockin <t>Please also refer to <xref target="RFC6888" format="default"/> for in
g IPv4 ranges if they detect that they are used for address sharing.</t> -depth information about
<t>Both cases are, again, implementation dependent.</t> <t>We note that the requirements for sizing CGN gateways.</t>
although it is not of typical use, one can do deterministic, stateful NAT a </section>
nd reserve a fixed set of ports for each customer, as well.</t> </sectio <section anchor="ce_prov" numbered="true" toc="default">
n> <section anchor="pub_serv" title="Support for Public Server Operation"> <name>CE Provisioning Considerations</name>
<t>Mechanisms that rely on operator side per-flow state do not, by thems <t>All of the technologies require some provisioning of customer
elves, offer a way for customers to present services on publicly accessible devices. The table below shows which methods currently have
transport layer ports.</t> <t>Port Control Protocol (PCP) <xref target="RF extensions for provisioning the different mechanisms.</t>
C6887"/> provides a mechanism for a client to request an external public po <table anchor="prov_mech_table" align="center">
rt from a CGN device. For server operation, it is required with NAT64/464XL <name>Available Provisioning Mechanisms</name>
AT, and it is supported in some DS-Lite AFTR implementations.</t> <thead>
<t>A+P based mechanisms distribute a public IPv4 address and restricted ran <tr>
ge of transport layer ports to the client. In this case, it is possible for <th align="left">Provisioning Method</th>
the user to configure their device to offer a publicly accessible server <th align="center">464XLAT</th>
on one of their allocated ports. It should be noted that commonly operators <th align="center">DS-Lite</th>
do not assign the Well-Known-Ports to users (unless they are allocating a <th align="center">lw4o6</th>
full IPv4 address), so the user will need to run the service on an allocat <th align="center">MAP-E</th>
ed port, or configure port translation.</t> <t>Lw4o6, MAP-E and MAP-T <th align="center">MAP-T</th>
may be configured to allocated clients with a full IPv4 address, allowing </tr>
exclusive use of all ports, and non-port-based transport layer protocols. </thead>
Thus, they may also be used to support server/services operation on their <tbody>
default ports. However, when public IPv4 addresses are assigned to the CE r <tr>
outer without address sharing, obviously there is no advantage in terms of <td align="left">DHCPv6 <xref target="RFC8415" format="default"/><
IPv4 public addresses saving. </t> <t>It is also possible to configure /td>
specific ports mapping in 464XLAT/NAT64 using EAMT <xref target="RFC7757"/ <td align="center"/>
>, which means that only those ports are "lost" from the pool of addresses, <td align="center">X</td>
so there is a higher maximization of the total usage of IPv4/port resource <td align="center">X</td>
s.</t><!--** I'm not familiar with EAMT - does this require operator side i <td align="center">X</td>
ntervention? Maybe a good way to deal with this section would be to divide <td align="center">X</td>
what is possible without and with operator intervention? --> <!-- GL: I am cur </tr>
rently working on benchmarking three differen stateless NAT64 implementat <tr>
ions: TAYGA, Jool and map646. I set the mappings in their configurations fi <td align="left">RADIUS <xref target="RFC8658" format="default"/><
les. Thus, I would say: yes, it requires... --> </section> /td>
<section anchor="supp_imp" title="Support and Implementations"> <section <td align="center"/>
title="Vendor Support"><!-- In a future update, this can be expanded to include <td align="center">
implementations ofdata plane and provisioning mechanisms, as to be useful, you <xref target="RFC6519" format="default"/></td>
really need both--> <t>In general, router vendors support AFTR, MAP-E <td align="center">X</td>
/T BR and NAT64. Load balancer and firewall vendors usually suppor <td align="center">X</td>
t NAT64 as well, while not all of them have support for the other <td align="center">X</td>
protocols.</t> <t>A 464XLAT client (CLAT) is implemented in Wind </tr>
ows 10, Linux (including Android), Windows Mobile, Chrome OS and iOS, but <tr>
it is not available in macOS 12.3.1.</t> <t>The remaining fo <td align="left">TR-069 <xref target="TR-069" format="default"/></
ur solutions are commonly deployed as functions in the CE device only, ho td>
wever in general, except DS-Lite, the vendors support is poor.</t> <td align="center">*</td>
<t>The OpenWRT Linux based open-source OS designed for CE devices offers <td align="center">X</td>
a number of different 'opkg' packages as part of the distribution: <list <td align="center">*</td>
style="symbols"> <t>'464xlat' enables support for 464XLAT CLAT functio <td align="center">X</td>
nality</t> <t>'ds-lite' enables support for DSLite B4 functionality</t> <td align="center">X</td>
<t>'map' enables support for MAP-E and lw4o6 CE functionality</t> </tr>
<t>'map-t' enables support for MAP-T CE functionality</t> </list></t <tr>
> <t>At the time of publication some free open-source implementations <td align="left">DNS64 <xref target="RFC7050" format="default"/></
exist for the operator side functionality: <list style="symbols"> td>
<t>Jool <xref target="jool"/> (CLAT, NAT64, EAMT, MAP-T CE, MAP-T BR).< <td align="center">X</td>
/t> <t>VPP/fd.io <xref target="vpp"/> (MAP-BR, lwAFTR, CGN, CLAT, NAT64 <td align="center"/>
).</t> <t>Snabb <xref target="snabb"/> (lwAFTR).</t> <t>AFTR < <td align="center"/>
xref target="aftr"/> (DSLite AFTR).</t> </list></t> </section> <td align="center"/>
<section anchor="cell_broad_supp" title="Support in Cellular and Broadband Netwo <td align="center"/>
rks"> <t>Several cellular networks use 464XLAT, whereas there are no </tr>
deployments of the four other technologies in cellular networks, as th <tr>
ey are neither standardised nor implemented in UE devices.</t> <t>In broa <td align="left">YANG <xref target="RFC7950" format="default"/></t
dband networks, there are some deployments of 464XLAT, MAP-E and MAP-T. L d>
w4o6 and DS-Lite have more deployments, with DS-Lite being the most comm <td align="center">
on, but lw4o6 taking over in the last years.</t> < <xref target="RFC8512" format="default"/></td>
t>Please refer to Table 2 and Table 3 of <xref target="LEN2019"/> f <td align="center">
or a limited set of deployment information.</t><!--*** I still see DS-Lite as be <xref target="RFC8513" format="default"/></td>
ing overwhelmingly the most common technology here. Do we have any deploy <td align="center">
ment information that was can used here? Do we have any figures ab <xref target="RFC8676" format="default"/></td>
out number of deployments of each type to back the statements up? --><!- <td align="center">
- GL: I am working on the revison of a paper, which has some tables on the deplo <xref target="RFC8676" format="default"/></td>
yment of different IPv6 transition technologies. Ihope that we can cite it in t <td align="center">
he next version. Now (July 8, 2020) I have added the reference. --> <xref target="RFC8676" format="default"/></td>
</section> <section anchor="code_size" title="Implemen </tr>
tation Code Sizes"> <t>As hint to the relative complexity of the mechanis <tr>
ms, the following code sizes are reported from the OpenWRT impleme <td align="left">DHCP 4o6 <xref target="RFC7341" format="default"/
ntations of each technology are 17kB, 35kB, 15kB, 35kB, and 48kB for 464X ></td>
LAT, lw4o6, DS-Lite, MAP-E, MAP-T, and lw4o6, respectively (https: <td align="center"/>
//openwrt.org/packages/start).</t><!-- Worth noting that for many of the above c <td align="center"/>
ases, these are for provisioning.Netfilter is doing that actual work for NAT and <td align="center">X</td>
encap/decap. --><!-- GL: I think, Netfiler only provides you with hooks, but it <td align="center">X</td>
does not perform the encap/decap. --> <t>We note that the support for al <td align="center"/>
l five technologies requires much less code size than the total sum of th </tr>
e above quantities, because they contain a lot of common functions (data </tbody>
plane is shared among several of them).</t> </section> </section> </table>
<section title="Typical Deployment and Traffic Volume Considerations"> <dl newline="false" spacing="normal">
<section title="Deployment Possibilities"> <t>Theoretically, all five IPv <dt>*:</dt>
4aaS technologies could be used together with DNS64 + stateful NAT64, as <dd>Work started at Broadband Forum (2021)</dd>
it is done in 464XLAT. In this case the CE router would treat the traffic <dt>X:</dt>
between an IPv6-only client and IPv4-only server as normal IPv6 traffic, <dd>Supported by the provisioning method</dd>
and the stateful NAT64 gateway would do a single translation, thus </dl>
offloading this kind of traffic from the IPv4aaS technology. The cost o </section>
f this solution would be the need for deploying also DNS64 + stateful NAT <section anchor="multicast" numbered="true" toc="default">
64.</t> <t>However, this has not been implemented in clients or actual <name>Support for Multicast</name>
deployments, so only 464XLAT always uses this optimization and the o <t>The solutions covered in this document are all intended for
ther four solutions do not use it at all.</t> </section> <section titl unicast traffic. <xref target="RFC8114" format="default"/> describes a m
e="Cellular Networks with 464XLAT"> <t>Figures from existing deployments ethod for
(end of 2018), show that the typical traffic volumes in an IPv6-only cell carrying encapsulated IPv4 multicast traffic over an IPv6 multicast
ular network, when 464XLAT technology is used together with DNS64, are: network. This could be deployed in parallel to any of the operator's
<list style="symbols"> <t>75% of traffic is IPv6 end-to-end (no t chosen IPv4aaS mechanism.</t>
ranslation)</t> <t>24% of traffic uses DNS64 + NAT64 (1 translation)</t </section>
> <t>Less than 1% of traffic uses the CLAT in addition to NAT64 </section>
(2 translations), due to an IPv4 socket and/or IPv4 literal.</t> </list <section numbered="true" toc="default">
></t> <t>Without using DNS64, 25% of the traffic would undergo double <name>Detailed Analysis</name>
translation.</t> <!-- Can we point to the source of this data <section numbered="true" toc="default">
? Also, are there tangible benefits to only going through single translat <name>Architectural Differences</name>
ion that can be described. --> <!-- GL: I have also asked for it <section numbered="true" toc="default">
, but no one took the resposibility to name the company, where they w <name>Basic Comparison</name>
ere taken from. --> <!-- Jordi: This info was provided in v6ops by Ca
meron (T-Mobile) Oct. 2018 it is factual data, what I'm not sure is <t>The five IPv4aaS technologies can be classified
if he will agree to name the network in an RFC, or if it is good a based on two aspects:
t all to cite networks in a document. I've asked him already a c </t>
ouple of days ago, if he has actual data to share, so we can publi <ul spacing="normal">
sh 2018 and 2020 comparison. --> </section> <section title="Wireline N <li>Technology used for service provider network traversal.
etworks with 464XLAT"> <t>Figures from several existing deployments (end It can be single/double translation or encapsulation.</li>
of 2020), mainly with residential customers, show that the typical traff <li>Presence or absence of per-flow state in the
ic volumes in an IPv6-only network, when 464XLAT is used with DNS64, are operator network.
in the following ranges: <list style="symbols"> <t>65%-85% of t </li>
raffic is IPv6 end-to-end (no translation)</t> <t>14%-34% of traffic us </ul>
es DNS64 + NAT64 (1 translation)</t> <t>Less than 1-2% of traffic uses
the CLAT in addition to NAT64 (2 translations), due to an IPv4 socket a <table anchor="data_plane_table" align="center">
nd/or IPv4 literal.</t> </list></t> <t>Without using DNS64, 16%-35 <name>Basic Comparison among the Analyzed Technologies</name>
% of the traffic would undergo double translation.</t> <thead>
<t>This data is consistent with non-public information of actual deployme <tr>
nts, which can be easily explained. When a wireline ISP has mainly res <th align="center"/>
idential customers, content providers and CDNs which are already IPv6 <th align="center">464XLAT</th>
enabled (Google/Youtube, Netflix, Facebook, Akamai, etc) typically <th align="center">DS-Lite</th>
account for the 65-85% of the traffic in the network, so when the subsc <th align="center">lw4o6</th>
ribers are IPv6 enabled, about the same figures of traffic will become IPv6.</t> <th align="center">MAP-E</th>
<!-- Jordi: This info comes from several of my customers, <th align="center">MAP-T</th>
that's why is a "range" not an average, I think it makes more sen </tr>
se to talk about ranges as it shows how other networks could be aroun </thead>
d similar figures. However I've no permission to cite them, and agai <tbody>
n, I don't think is good to name specific networks in an RFC? --> <tr>
</section> </section> <section title="Load Sharing"> <t>If multip <td align="left">Translation (T) or Encapsulation (E) </td>
le network-side devices are needed as PLAT/AFTR/BR for capacity, then there <td align="center">T</td>
is a need for a load sharing mechanism. ECMP (Equal-Cost Multi-Path) load <td align="center">E</td>
sharing can be used for all technologies, however stateful technologies wil <td align="center">E</td>
l be impacted by changes in network topology or device failure.</t> <! <td align="center">E</td>
--- I'm not sure the last part of that paragraph is true. I've added some <td align="center">T</td>
text describing the problems below --> <!--- GL: It is also from Ole Troan. </tr>
You can find it in one of the e-mails on the v6ops mailing list. --> <t> <tr>
Technologies utilizing DNS64 can also distribute load across PLAT/AFTR devi <td align="left"> Presence (+) of Per-Flow State in Operator Net
ces, evenly or unevenly, by using different prefixes. Different network spe work</td>
cific prefixes can be distributed for subscribers in appropriately sized se <td align="center">+</td>
gments (like split-horizon DNS, also called DNS views).</t> <t>Statele <td align="center">+</td>
ss technologies, due to the lack of per-flow state, can make use of anycast <td align="center"/>
routing for load sharing and resiliency across network-devices, both ingre <td align="center"/>
ss and egress; flows can take asymmetric paths through the network, i.e., i <td align="center"/>
n through one lwAFTR/BR and out via another.</t> <t>Mechanisms with ce </tr>
ntralized NAPT44 state have a number of challenges specifically related to </tbody>
scaling and resilience. As the total amount of client traffic exceeds the c </table>
apacity of a single CGN instance, additional nodes are required to handle t </section>
he load. As each CGN maintains a stateful table of active client sessions, </section>
this table may need to be syncronized between CGN instances. This is necess <section anchor="port_num_eff" numbered="true" toc="default">
ary for two reasons: </t> <t><list style="symbols"> <t>To prevent <name>Trade-Off between Port Number Efficiency and Stateless Operation</
all active customer sessions being dropped in event of a CGN node failure. name>
</t> <t>To ensure a matching state table entry for an active session in <t>464XLAT and DS-Lite use stateful NAPT at the PLAT and AFTR devices,
the event of asymmetric routing through different egress and ingress CGN respectively. This may cause scalability issues for the number of clients
nodes.</t> </list></t> </section> <section anchor="logging" title="Lo or volume of traffic, but it does not impose a limitation
gging"> <t>In the case of 464XLAT and DS-Lite, the user of any given public on the number of ports per user, as they can be allocated dynamically
IPv4 address and port combination will vary over time, therefore, log on-demand and the allocation policy can be centrally managed and adjusted.
ging is necessary to meet data retention laws. Each entry in the PLAT/AFTR' </t>
s generates a logging entry. As discussed in <xref target="port_num_eff"/> <t>A+P-based mechanisms (lw4o6, MAP-E, and MAP-T) avoid using NAPT in th
, a client may open hundreds of sessions during common tasks such as web-br e
owsing, each of which needs to be logged so the overall logging burden on t service provider network. However, this means that the number of ports
he network operator is significant. In some countries, this level of loggin provided to each user (and hence the effective IPv4 address-sharing ratio)
g is required to comply with data retention legislation.</t> <t>One co must be pre-provisioned to the client.</t>
mmon optimization available to reduce the logging overhead is the allocatio <t>Changing the allocated port ranges with A+P-based
n of a block of ports to a client for the duration of their session. This m technologies requires more planning and is likely to involve
eans that a logging entry only needs to be made when the client's port bloc reprovisioning both hosts and operator-side equipment. It should be
k is released, which dramatically reduces the logging overhead. This comes noted that due to the per-customer binding table entry used
as the cost of less efficient public address sharing as clients need to be by lw4o6, a single customer can be reprovisioned (e.g., if they
allocated a port block of a fixed size regardless of the actual number of p request a full IPv4 address) without needing to change parameters for a
orts that they are using.</t> <t>Stateless technologies that pre-alloc number of customers as in a MAP domain.</t>
ate the IPv4 addresses and ports only require that copies of the active MAP <t>It is also worth noting that there is a direct relationship between
rules (for MAP-E and MAP-T), or binding-table (for lw4o6) are retained alo the efficiency of public port allocations for customers and the correspond
ng with timestamp information of when they have been active. Support tools ing
(e.g., those used to serve data retention requests) may need to be upd logging overhead that may be necessary to meet data-retention
ated to be aware of the mechanism in use (e.g., implementing the MAP algori requirements. This is considered in <xref target="logging" format="default
thm so that IPv4 information can be linked to the IPv6 prefix delegated to "/>.</t>
a client). As stateless technologies do not have a centralized stateful ele
ment which customer traffic needs to pass through, so if data retention la <t>Determining the optimal number of ports for a fixed port set is not
ws mandate per-session logging, there is no simple way of meeting this requ an easy task and may also be impacted by local regulatory law (and in
irement with a stateless technology alone. Thus, a centralized NAPT44 model the Belgian case, it is not a law but more a memorandum of
may be the only way to meet this requirement.</t> <t>Dete understanding or best current practice), which may define a maximum
rministic CGN <xref target="RFC7422"/> was proposed as a solution to reduce number of users per IP address and consequently a minimum number of
the resource consumption of logging.</t> <t>Please also refer to Section ports per user.</t>
4 of <xref target="RFC6888"/> for more information about requirements fo
r logging Carrier-Grade NAT gateways.</t> </section> <sect <t>On the one hand, the "lack of ports" situation may cause serious
ion anchor="optimization" title="Optimization for IPv4-only devices/applications problems in the operation of certain applications. For example, Miyakawa
"> <t>When IPv4-only devices or applications are behind a CE connected with has demonstrated the consequences of the session number limitation due
IPv6-only and IPv4aaS, the IPv4-only traffic flows will necessarily, be to port number shortage in the example of Google Maps
encapsulated/decapsulated (in the case of DS-Lite, lw4o6 and MAP-E) a <xref target="MIY2010" format="default"/>. When the limit was 15, several
nd will reach the IPv4 address of the destination, even if that service su blocks of the
pports dual-stack. This means that the traffic flow will cross through the map were missing, and the map was unusable. This study also provided
AFTR, lwAFTR or BR, depending on the specific transition mechanism being several examples for the session numbers of different applications
used.</t> <t>Even if those services are directly connected to the operato (the highest one was Apple's iTunes at 230-270 ports).</t>
r network (for example, CDNs, caches), or located internally (such as VoI
P, etc.), it is not possible to avoid that overhead.</t> <t>Howe <t>The port number consumption of different applications is highly
ver, in the case of those mechanisms that use a NAT46 function, in the varying. In the case of web browsing, it depends on several
CE (464XLAT and MAP-T), it is possible to take advantage of optimization fu factors, including the choice of the web page, the web browser, and
nctionalities, such as the ones described in <xref target="I-D.ietf-v6ops-46 sometimes the operating system <xref target="REP2014"
4xlat-optimization"/>.</t> <t>Using those optimizations, because the NAT46 format="default"/>. For example, under certain conditions, 120-160
has already translated the IPv4-only flow to IPv6, and the services are ports were used (URL: sohu.com, browser: Firefox under Ubuntu Linux),
dual-stack, they can be reached without the need to translate them ba and in some other cases, only 3-12 ports were used (URL: twitter.com,
ck to IPv4.</t> </section> </section> <section anchor="performance" title= browser: Iceweasel under Debian Linux).</t>
"Performance Comparison"> <t>We plan to compare the performances of the most <t>There may be several users behind a CE router, especially in the
prominent free software implementations of the five IPv6 transition tech broadband case (e.g., Internet is used by different members of a family
nologies using the methodology described in "Benchmarking Methodology for I simultaneously), so sufficient ports must be allocated to avoid
Pv6 Transition Technologies" <xref target="RFC8219"/>.</t> impacting user experience.</t>
<t>The Dual DUT Setup of <xref target="RFC8219"/> makes it possible to use the e <t>In general, assigning too few source port numbers to an end user may
xisting "Benchmarking Methodology for Network Interconnect Devices" result in unexpected and hard-to-debug consequences; therefore, if the
<xref target="RFC2544"/> compliant measurement devices, however, this sol number of ports per end user is fixed, then we recommend assigning a
ution has two kinds of limitations: <list style="symbols"> <t>Dual D conservatively large number of ports. For example, the developers of Jo
UT setup has the drawback that the performances of the CE and of th ol used
e ISP side device (e.g. the CLAT and the PLAT of 464XLAT) are measu 2048 ports per user in their example for MAP-T <xref target="JOOL-MAPT"
red together. In order to measure the performance of only one of them, format="default"/>.</t>
we need to ensure that the desired one is the bottleneck.</t> <t>However, assigning too many ports per CE router
<t>Measurements procedures for PDV and IPDV measurements are missing will result in waste of public IPv4 addresses, which are scarce and
from the legacy devices, and the old measurement procedure for L expensive resources. Clearly, this is a big advantage in the case of 464XL
atency has been redefined in <xref target="RFC8219"/>.</t> </list> </t> AT
<t>The Single DUT Setup of <xref target="RFC8219"/> makes it possible where they are dynamically managed so that the number of IPv4 addresses
to benchmark the selected device separately, but it either requires a special for the sharing pool is smaller while the availability of ports per user
Tester or some trick is need, if we want to use legacy Testers. An examp doesn't need to be pre-defined and is not a limitation.</t>
le for the latter is our stateless NAT64 measurements testing Througput and Fr <t>There is a direct trade-off between the optimization of client
ame Loss Rate using a legacy <xref target="RFC5180"/> compliant commercial tes port allocations and the associated logging overhead.
ter <xref target="LEN2020a"/></t> <t>Siitperf, an <xref target="RF <xref target="logging" format="default"/> discusses this in more depth.</t
C8219"/> compliant DPDK-based software Tester for benchmarking stateless NAT64 >
gateways has been developed recently and it is available from GitHub
<xref target="SIITperf"/> as free software and documented in <xref target="LE <t> We note that common NAT44 implementations utilizing Netfilter at the
N2021"/>. Originally, it literally followed the test frame format of <xref ta CE router multiplex active sessions using a 3-tuple (source address,
rget="RFC2544"/> including "hard-wired" source and destination port numbers destination address, and destination port). This means that external
, and then it has been complemented with the random port feature required by source ports can be reused for unique internal source and destination
<xref target="RFC4814"/>. The new version is documented in <xref target="L addresses and port sessions. It is also noted that Netfilter cannot
EN2020b"/></t> <t>Further DPDK-based, <xref target="RFC8219"/> complian currently make use of multiple source port ranges (i.e., several blocks
t software testers are being developed at the Budapest University of Techno of ports distributed across the total port space as is common in MAP
logy and Economics as student projects. They are planned to be released a deployments). This may influence the design when using stateless
s free software, too.</t> <t>Information about the benchma technologies.</t>
rking tools, measurements and results will be made available in <xref targe <t>Stateful technologies, 464XLAT, DS-Lite, and NAT444 can
t="I-D.lencse-v6ops-transition-benchmarking"/>. </t> </section> <se therefore be much more efficient in terms of port allocation and thus
ction anchor="Acknowledgements" title="Acknowledgements"> <t>The authors wou public IP address saving. The price is the stateful operation in the
ld like to thank Ole Troan, Warren Kumari, Dan Romascanu, Brian Trammell, service provider network, which allegedly does not scale up well.
Joseph Salowey, Roman Danyliw, Erik Kline, Lars Eggert, Zaheduzzaman Sar It should be noted that, in many cases, all those factors may depend on
ker, Robert Wilton, Eric Vyncke and Martin Duke for their review of this how it is actually implemented.</t>
draft and acknowledge the inputs of Mark Andrews, Edwin Cordeiro, Fred Bak <t>Measurements have been started to examine the scalability of a few
er, Alexandre Petrescu, Cameron Byrne, Tore Anderson, Mikael Abrahamsson, G stateful solutions in two areas:
ert Doering, Satoru Matsushima, Yutianpeng (Tim), Mohamed Boucadair, Nick </t>
Hilliard, Joel Jaeggli, Kristian McColm, Nick Hilliard, Tom Petch, Yanni <ul spacing="normal">
s Nikolopoulos, Havard Eidnes, Yann-Ju Chu, Barbara Stark, Vasilenko Eduard <li>How their performance scales up with the number of CPU cores</li>
, Chongfeng Xie, Henri Alves de Godoy, Magnus Westerlund, Michael Tuexen, <li>To what extent their performance degrades with the number of
Philipp S. Tiesel, Brian E Carpenter and Joe Touch.</t> </section> <!-- Poss concurrent connections</li>
ibly a 'Contributors' section ... --> <section anchor="IANA" title="IANA Consi </ul>
derations"> <t>This document does not make any request to IANA.</t> </sect <t>
ion> <section anchor="Security" title="Security Considerations"> <t>As The details of the measurements and their results are available from
discussed in section 4.7, the different technologies have varying logging <xref target="I-D.lencse-v6ops-transition-scalability" format="
capabilities and limitations. Care should be taken when storing, transmit default"/>.
ting, and providing access to log entries that may be considered personal </t>
ly identifiable information. However, it should be noticed that those is
sues are not specific to the IPv4aaS IPv6 transition technologies, but in g <t>We note that some CGN-type solutions can allocate ports dynamically
eneral to logging functionalities.</t> <t>For all five technologies, the "on the fly". Depending on configuration, this can result in the same
CE device typically contains a DNS proxy. However, the user may change DNS s customer being allocated ports from different source addresses. This can
ettings. If it happens and lw4o6, MAP-E and MAP-T are used with significantl cause operational issues for protocols and applications that expect
y restricted port set, which is required for an efficient public IPv4 addres multiple flows to be sourced from the same address (e.g., ECMP hashing,
s sharing, the entropy of the source ports is significantly lowered (e.g. fr STUN, gaming, and content delivery networks). However, it should be noted
om 16 bits to 10 bits, when 1024 port numbers are assigned to each subscribe that this is the same problem when a network has a NAT44 with multiple
r) and thus these technologies are theoretically less resilient against cach public IPv4 addresses, or even when applications in a dual-stack case,
e poisoning, see <xref target="RFC5452"/>. However, an efficient cache poiso behave wrongly if Happy Eyeballs is flapping the flow address between
ning attack requires that the subscriber operates an own caching DNS server IPv4 and IPv6.</t>
and the attack is performed in the service provider network. Thus, we consid <t>The consequences of IPv4 address sharing <xref target="RFC6269" forma
er the chance of the successful exploitation of this vulnerability as low.</ t="default"/> may
t> <t>IPv4aaS technologies based on encapsulation have not DNSSEC implicatio impact all five technologies. However, when ports are allocated
ns. However, those based on translation may have implications as discussed i statically, more customers may get ports from the same public IPv4
n Section 4.1 of <xref target="RFC8683"/>.</t> <t>An in-depth security address, which may result in negative consequences with higher
analysis of all five IPv6 transition technologies and their most prominent probability. For example, many applications and service providers (Sony
free software implementations according to the methodology defined in <xref PlayStation Network, OpenDNS, etc.) can permanently block IPv4 ranges
target="LEN2018"/> is planned.</t> <t>As the first step, an initial if they detect that they are used for address sharing.</t>
security analysis of 464XLAT was done in <xref target="Azz2021"/>.</t> <t>Both cases are, again, implementation-dependent.</t>
<t>The implementers of any of the five IPv4aaS solutions should <t>We note that although it is not of typical use, one can do
consult the Security Considerations of the respective RFCs documenting them. deterministic, stateful NAT and reserve a fixed set of ports for each
</t> </section> </middle> <!-- *****BACK MATTER ***** --> <back> <!-- R customer as well.</t>
eferences split into informative and normative --> <!-- There are 2 ways to in </section>
sert reference entries from the citation libraries: 1. define an ENTITY at th <section anchor="pub_serv" numbered="true" toc="default">
e top, and use "ampersand character"RFC2629; here (as shown) 2. simply use a <name>Support for Public Server Operation</name>
PI "less than character"?rfc include="reference.RFC.2119.xml"?> here (for <t>Mechanisms that rely on operator-side per-flow state do not, by
I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml") Both themselves, offer a way for customers to present services on publicly
are cited textually in the same manner: by using xref elements. If you use t accessible transport-layer ports.</t>
he PI option, xml2rfc will, by default, try to find included files in the same <t>The Port Control Protocol (PCP) <xref target="RFC6887" format="defaul
directory as the including file. You can also define the XML_LIBRARY environme t"/> provides a
nt variable with a value containing a set of directories to search. These ca mechanism for a client to request an external public port from a CGN
n be either in the local filing system or remote ones accessed by http (http: device. For server operation, it is required with 464XLAT/NAT64, and
//domain/dir/... ).--> <references title="Normative References"> <!--?rfc i it is supported in some DS-Lite AFTR implementations.</t>
nclude="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?--> <t>A+P-based mechanisms distribute a public IPv4 address and
&RFC2473; &RFC2544; &RFC2663; &RFC4814; &RFC5180; &RFC5452;<!--&RFC restricted range of transport-layer ports to the client. In this case,
6050;--> &RFC6052; &RFC6146; &RFC6147; &RFC6180; &RFC6269; it is possible for the user to configure their device to offer a
&RFC6333; &RFC6346; &RFC6519; &RFC6877; &RFC6887; &RFC6888; & publicly accessible server on one of their allocated ports. It should
RFC6889; &RFC7050; &RFC7269; &RFC7341; &RFC7393; & be noted that operators commonly do not assign the well-known ports to
RFC7422; &RFC7757;<!--&RFC7857;--> &RFC7915; &RFC7596; &RFC7597; users (unless they are allocating a full IPv4 address), so the user
&RFC7599; &RFC7605; &RFC7950; &RFC8114; &RFC8215; &RFC8219; will need to run the service on an allocated port or configure port
&RFC8415; &RFC8512; &RFC8513; &RFC8658; &RFC8676; &RFC8683; translation.</t>
</references> <references title="Informative References"> <!-- Here we <t>Lw4o6, MAP-E, and MAP-T may be configured to allocated clients with
use entities that we defined at the beginning. --> <?rfc include='reference. a full IPv4 address, allowing exclusive use of all ports and
I-D.ietf-v6ops-464xlat-optimization'?> <?rfc include='reference.I-D.ietf-tsvw non-port-based transport-layer protocols. Thus, they may also be used to s
g-natsupp'?> <?rfc include='reference.I-D.lencse-v6ops-transition-scalability upport
'?> <?rfc include='reference.I-D.lencse-v6ops-transition-benchmarking'?> server/services operation on their default ports. However, when public
<reference anchor="Azz2021" target="https://www.infocommunications.hu/2021_4_2" IPv4 addresses are assigned to the CE router without address sharing,
> <front> <title>Identification of the Possible Security Issues of t there is obviously no advantage in terms of IPv4 public addresses saving.
he 464XLAT IPv6 Transition Technology </title> <author </t>
initials="A." surname="Al-Azzawi"> <organization></organization> <t>It is also possible to configure specific ports mapping in
</author> <author initials="G." surname="Lencse"> <organizatio 464XLAT/NAT64 using EAMT <xref target="RFC7757" format="default"/>, which
n></organization> </author> <date month="Dec" year="2021"/> < means that only
/front> <seriesInfo name="" value="Infocommunications Journal, vol. 13, no. those ports are "lost" from the pool of addresses, so there is a higher
4, pp. 10-18"/> <seriesInfo name="" value="DOI: 10.36244/ICJ.2021.4.2"/> maximization of the total usage of IPv4 port resources.</t>
</reference> <reference anchor="LEN2018" target="http://www.hit.bme
.hu/~lencse/publications/ECS-2018-Methodology-revised.pdf"> <front> </section>
<title>Methodology for the identification of potential security issues of <section anchor="supp_imp" numbered="true" toc="default">
different IPv6 transition technologies: Threat analysis of DNS64 and sta <name>Support and Implementations</name>
teful NAT64 </title> <author initials="G." surname="Lencse"> <section numbered="true" toc="default">
<organization></organization> </author> <author initials="Y." <name>Vendor Support</name>
surname="Kadobayashi"> <organization></organization> </author>
<date day="1" month="Aug" year="2018"/> </front> <seriesInfo nam <t>In general, router vendors support AFTR, MAP-E BR, MAP-T
e="" value="Computers &amp; Security (Elsevier), vol. 77, no. 1, pp. 397-4 BR, and NAT64. Vendors of load balancers and firewalls usually
11"/> <seriesInfo name="" value="DOI: 10.1016/j.cose.2018.04.012"/> </re support NAT64 as well while not all of them have support for
ference> <reference anchor="LEN2019" target="http://www.hit.bme.hu/~lencs the other protocols.</t>
e/publications/e102-b_10_2021.pdf"> <front> <title>Comprehensive Sur <t>A 464XLAT client (CLAT) is implemented in Windows 10, Linux
vey of IPv6 Transition Technologies: A Subjective Classification for S (including Android), Windows Mobile, Chrome OS, and iOS, but it is
ecurity Analysis </title> <author initials="G." surname="Lencse"> not available in macOS 12.3.1.</t>
<organization></organization> </author> <author initials= <t>The remaining four solutions are commonly deployed as functions
"Y." surname="Kadobayashi"> <organization></organization> </auth in the CE device only; however, the vendors' support is poor in
or> <date day="1" month="Oct" year="2019" /> </front> <seriesIn general (except for DS-Lite).</t>
fo name="" value="IEICE Transactions on Communications, vol. E102-B, no.10, pp.
2021-2035."/> <seriesInfo name="" value="DOI: 10.1587/transcom.2018EBR0002" <t> OpenWRT is a Linux-based open-source OS designed for CE devices. It
/> </reference> <reference anchor="LEN2020a" target="https:// offers a number of different 'opkg' packages as part of the distribution:
link.springer.com/article/10.1007/s11235-020-00681-x"> <front> <titl </t>
e>Benchmarking Stateless NAT64 Implementations with a Standard Tester </t <ul spacing="normal">
itle> <author initials="G." surname="Lencse"> <organization></or <li>'464xlat' enables support for 464XLAT CLAT functionality.</li>
ganization> </author> <date day="15" month="Jun <li>'ds-lite' enables support for DSLite B4 functionality.</li>
" year="2020" /> </front> <seriesInfo name="" value="Telecommunic <li>'map' enables support for MAP-E and lw4o6 CE
ation Systems, vol. 75, pp. 245-257"/> <seriesInfo name="" value="DOI: 10.1007 functionality.</li>
/s11235-020-00681-x"/> </reference> <reference anchor="LEN2020b" target=" <li>'map-t' enables support for MAP-T CE functionality.</li>
http://ijates.org/index.php/ijates/article/view/291"> <front> <title </ul>
>Adding RFC 4814 Random Port Feature to Siitperf: Design, Implementation and <t>At the time of publication, some free open-source implementations
Performance Estimation </title> <author initials="G." surna exist for the operator-side functionality:
me="Lencse"> <organization></organization> </author> </t>
<date day="" month="" year="2020" /> </front> <ser <ul spacing="normal">
iesInfo name="" value="International Journal of Advances in Telecommunications, <li>Jool <xref target="JOOL" format="default"/> (CLAT, NAT64, EAMT,
Electrotechnics, Signals and Systems, vol 9, no 3, pp. 18-26"/> <series MAP-T CE, MAP-T BR)</li>
Info name="" value="DOI: 10.11601/ijates.v9i3.291"/> </reference> < <li>VPP/fd.io <xref target="VPP" format="default"/> (MAP-BR, lwAFTR,
reference anchor="LEN2021" target="https://www.jstage.jst.go.jp/article/tran CGN, CLAT, NAT64)</li>
scom/E104.B/2/E104.B_2019EBN0010/_article"> <front> <title>Design an <li>Snabb <xref target="SNABB" format="default"/> (lwAFTR)</li>
d Implementation of a Software Tester for Benchmarking Stateless NAT64 Gateways <li>AFTR <xref target="AFTR" format="default"/> (DSLite AFTR)</li>
</title> <author initials="G." surname="Lencse"> <organiz </ul>
ation></organization> </author> <date day="" mont </section>
h="" year="2021" /> </front> <seriesInfo name="" value="IEICE Tra <section anchor="cell_broad_supp" numbered="true" toc="default">
nsactions on Communications"/> <seriesInfo name="" value="DOI: 10.1587/transco <name>Support in Cellular and Broadband Networks</name>
m.2019EBN0010"/> </reference> <reference anchor="MEX2022" target="h <t>Several cellular networks use 464XLAT, whereas there are no
ttps://www.jool.mx/en/run-mapt.html"> <front> <title>Jool: Siit and deployments of the four other technologies in cellular networks, as
NAT64</title> <author initials="" surname="Jool Developers"> <or they are neither standardized nor implemented in UE devices.</t>
ganization>NIC Mexico</organization> </author> <
date day="" month="" year="2022" /> </front> <seriesInfo name="" <t>In broadband networks, there are some deployments of 464XLAT, MAP-E,
value="Documentation of Jool MAP-T implementation"/> </reference> < and MAP-T.
reference anchor="MIY2010" target="https://www.jstage.jst.go.jp/article/tran Lw4o6 and DS-Lite have more deployments, with DS-Lite
scom/E93.B/5/E93.B_5_1078/_article"> <front> <title>IPv4 to IPv6 tra being the most common, but deployments of lw4o6 have been rapidly
nsformation schemes </title> <author initials="S." surname="Miyaka increasing in the last few years.
wa"> <organization></organization> </author> <date month= </t>
"May" year="2010"/> </front> <seriesInfo name="" value="IEICE Trans. C <t>Please refer to Tables 2 and 3 of <xref target="LEN2019" format="de
ommun., vol.E93-B, no.5, pp. 1078-1084"/> <seriesInfo name="" value="D fault"/>
OI:10.1587/transcom.E93.B.10"/> </reference> <reference anchor="REP2014" t for a limited set of deployment information.</t>
arget="http://www.hit.bme.hu/~lencse/publications/TSP-2014-PC.pdf"> <front> </section>
<title>Port number consumption of the NAT64 IPv6 transition technology <section anchor="code_size" numbered="true" toc="default">
</title> <author initials="S." surname="Repas"> <organizat <name>Implementation Code Sizes</name>
ion></organization> </author> <author initials="T." surname="Hajas
"> <organization></organization> </author> <author initia <t>As a hint to the relative complexity of the mechanisms, the
ls="G." surname="Lencse"> <organization></organization> </author code sizes reported from the OpenWRT
> <date month="July" year="2014"/> </front> <seriesInfo name="" implementations of each technology are 17 kB, 35 kB, 15 kB, 35 kB, and
value="Proc. 37th Internat. Conf. on Telecommunications and Signal Proces 48 kB for 464XLAT, lw4o6,
sing (TSP 2014), Berlin, Germany"/> <seriesInfo name="" value="DOI: 10.1109 DS-Lite, MAP-E, and MAP-T, respectively
/TSP.2015.7296411"/> </reference> <reference anchor="SIITperf" targ (see <eref target="https://openwrt.org/packages/start" brackets="angle"/
et="https://github.com/lencsegabor/siitperf"> <front> <title>Siitper >).</t>
f: an RFC 8219 compliant SIIT (stateless NAT64) tester</title>
<author initials="G." surname="Lencse"> <organization></organizati <t>We note that the support for all five technologies requires a much
on> </author> <date month="November" year="2019"/> </front> smaller code size than the total sum of the above quantities, because
</reference> <reference anchor="TR-069" target="https://www.broadband-forum.or they contain a lot of common functions (e.g., data plane is shared among
g/technical/download/TR-069.pdf"> <front> <title>TR-069: CPE WAN Man several of them).</t>
agement Protocol</title> <author initials="" surname="BroadBand Forum"> </section>
<organization></organization> </author> <date month="June" </section>
year="2020"/> </front> </reference> <reference anchor="jool" target=" <section numbered="true" toc="default">
http://www.jool.mx"> <front> <title>Open Source SIIT and NAT64 for L <name>Typical Deployment and Traffic Volume Considerations</name>
inux</title> <author> <organization>NIC.MX</organization> <section numbered="true" toc="default">
</author> <date year="2022"/> </front> </reference> <referenc <name>Deployment Possibilities</name>
e anchor="vpp" target="https://gerrit.fd.io/r/#/admin/projects/"> <front> <t>Theoretically, all five IPv4aaS technologies could be
<title>VPP Implementations of IPv6-only with IPv4aaS</title> <autho used together with DNS64 + stateful NAT64, as is done in 464XLAT.
r> </author> <date year="2022"/> </front> </reference> < In this case, the CE router would treat the traffic between an
reference anchor="snabb" target="https://github.com/Igalia/snabb"> <front> IPv6-only client and IPv4-only server as normal IPv6 traffic, and
<title>Snabb implementation of lwAFTR</title> <author> <o the stateful NAT64 gateway would do a single translation, thus
rganization>Igalia</organization> </author> <date year="2022"/> offloading this kind of traffic from the IPv4aaS technology. The
</front> </reference> <reference anchor="aftr" target="https://www.isc. cost of this solution would be the need to also deploy DNS64 +
org/downloads/"> <front> <title>ISC implementation of AFTR</title> stateful NAT64.</t>
<author> <organization>ISC</organization> </author> <t>However, this has not been implemented in clients or actual
<date year="2022"/> </front> </reference> </references> <secti deployments, so only 464XLAT always uses this optimization, and the
on anchor="change_log" title="Change Log"> <section title="01 - 02"> <t> other four solutions do not use it at all.</t>
<list style="symbols"> <t>Ian Farrer has joined us as an author.</t </section>
> <t>Restructuring: the description of the five IPv4aaS technologie <section numbered="true" toc="default">
s was moved to a separate section.</t> <t>More details and figur <name>Cellular Networks with 464XLAT</name>
es were added to the description of the five IPv4aaS technologies.</t>
<t>Section titled "High-level Architectures and their Consequences" has b <t>Figures from existing deployments (through the end of 2018) show
een completely rewritten.</t> <t>Several additions/clarificatio the typical traffic volumes in an IPv6-only cellular network when
n throughout Section titled "Detailed Analysis".</t> <t>Sectio 464XLAT technology is used together with DNS64:
n titled "Performance Analysis" was dropped due to lack of results yet.</t> </t>
<t>Word based text ported to XML.</t> <t>Further text cleanups, added <ul spacing="normal">
text on state sync and load balancing. Additional comments inline that shoul <li>75% of traffic is IPv6 end-to-end (no translation).</li>
d be considered for future updates.</t> </list> </t> </section> <li>24% of traffic uses DNS64 + NAT64 (one translation).</li>
<section title="02 - 03"> <t> <list style="symbols"> <t>The sugges <li>Less than 1% of traffic uses the CLAT in addition to NAT64
tions of Mohamed Boucadair are incorporated.</t> <t>New considerations re (two translations), due to an IPv4 socket and/or IPv4 literal.</li>
garding possible optimizations.</t> </list> </t> </section> </ul>
<section title="03 - 04"> <t> <list style="symbols"> <t>Se <t>Without using DNS64, 25% of the traffic would undergo double
ction titled "Performance Analysis" was added. It mentions our new b translation.</t>
enchmarking tool, siitperf, and highlights our plans.</t> <t>Some referen
ces were updated or added.</t> </list> </t> </section> <section </section>
title="04 - 05"> <t> <list style="symbols"> <t>Some references <section numbered="true" toc="default">
were updated or added.</t> </list> </t> </section> <section <name>Wireline Networks with 464XLAT</name>
title="05 - 06"> <t> <list style="symbols"> <t>Some references <t> Figures from several existing deployments (through the end of
were updated or added.</t> </list> </t> </section> < 2020), mainly with residential customers, show the ranges of typical
section title="06 - 00-WG Item"> <t> <list style="symbols"> <t> traffic volumes in an IPv6-only network, when 464XLAT is used with
Stats dated and added for Broadband deployments.</t> <t>Other clarificati DNS64:
ons and references.</t> <t>New section: IPv4 Pool Size.</t> <t>Typ </t>
os.</t> </list> </t> </section> <section title="00 - 01"> <t <ul spacing="normal">
>To facilitate WGLC, the unfinished parts were moved to two new drafts: <li>65%-85% of traffic is IPv6 end-to-end (no translation).</li>
<list style="symbols"> <t>New I-D for scale up measurements. (Inclu <li>14%-34% of traffic uses DNS64 + NAT64 (one translation).</li>
ding the results of iptables.)</t> <t>New I-D for benchmarking measuremen <li>Less than 1-2% of traffic uses the CLAT in addition to NAT64
ts. (Only a stub.)</t> </list> </t> </section> <section title="0 (two translations), due to an IPv4 socket and/or IPv4 literal.</li>
1 - 02"> <t>Update on the basis of the AD review.</t> <t>Update of th </ul>
e references.</t> </section> <section title="02 - 03"> <t <t>Without using DNS64, 16%-35% of the traffic would undergo double
>Nits and changes from IESG review.</t> <t>Updated wrong reference to P translation.</t>
CP.</t> </section> <section title="03 - 04"> <t>Update to address th
e comments of further reviews.</t> <t>Updated Acknowledgements.</t> </s <t>
ection> </section> </back></rfc> This data is consistent with non-public information of actual deployments,
which can be easily explained. When a wireline ISP has mainly residential
customers, content providers and CDNs that are already IPv6 enabled
(Google/YouTube, Netflix, Facebook, Akamai, etc.) typically account for 65-85%
of the traffic in the network. Thus, when the subscribers are IPv6 enabled,
about the same percentage of traffic will become IPv6.
</t>
</section>
</section>
<section numbered="true" toc="default">
<name>Load Sharing</name>
<t>If multiple network-side devices are needed as PLAT/AFTR/BR for
capacity, then there is a need for a load-sharing mechanism. ECMP
(Equal-Cost Multipath) load sharing can be used for all
technologies; however, stateful technologies will be impacted by
changes in network topology or device failure.</t>
<t>Technologies utilizing DNS64 can also distribute load across
PLAT/AFTR devices, evenly or unevenly, by using different prefixes.
Different network-specific prefixes can be distributed for
subscribers in appropriately sized segments (like split-horizon DNS,
also called "DNS views").</t>
<t>Stateless technologies, due to the lack of per-flow state, can
make use of anycast routing for load sharing and resiliency across
network devices, both ingress and egress; flows can take asymmetric
paths through the network, i.e., in through one lwAFTR/BR and out
via another.</t>
<t>Mechanisms with centralized NAPT44 state have a number of challenges
specifically related to scaling and resilience. As the total amount of
client traffic exceeds the capacity of a single CGN instance, additional
nodes are required to handle the load. Each CGN maintains a
stateful table of active client sessions, and this table may need to be
synchronized between CGN instances. This is necessary for two reasons:
</t>
<ul spacing="normal">
<li>To prevent all active customer sessions from being dropped in the
event
of a CGN node failure.</li>
<li>To ensure a matching state table entry for an active session in
the event of asymmetric routing through different egress and ingress
CGN nodes.</li>
</ul>
</section>
<section anchor="logging" numbered="true" toc="default">
<name>Logging</name>
<t>In the case of 464XLAT and DS-Lite, the user of any given public
IPv4 address and port combination will vary over time; therefore,
logging is necessary to meet data-retention laws. Each entry in the
PLAT/AFTR generates a logging entry. As discussed in
<xref target="port_num_eff" format="default"/>, a client may open hundreds
of sessions
during common tasks such as web browsing, each of which needs to be
logged so the overall logging burden on the network operator is
significant. In some countries, this level of logging is required to compl
y
with data-retention legislation.</t>
<t>One common optimization available to reduce the logging overhead
is the allocation of a block of ports to a client for the duration
of their session. This means that a logging entry only needs to be
made when the client's port block is released, which dramatically
reduces the logging overhead. This comes as the cost of less
efficient public address sharing as clients need to be allocated a
port block of a fixed size regardless of the actual number of ports
that they are using.</t>
<t>Stateless technologies that pre-allocate the IPv4 addresses and
ports only require that copies of the active MAP rules (for MAP-E and
MAP-T) or binding table (for lw4o6) are retained along with timestamp
information of when they have been active. Support tools (e.g., those
used to serve data-retention requests) may need to be updated to be
aware of the mechanism in use (e.g., implementing the MAP algorithm so
that IPv4 information can be linked to the IPv6 prefix delegated to a
client). Stateless technologies do not have a centralized stateful
element that customer traffic needs to pass through, so if
data-retention laws mandate per-session logging, there is no simple
way of meeting this requirement with a stateless technology alone.
Thus, a centralized NAPT44 model may be the only way to meet this
requirement.</t>
<t>Deterministic CGN <xref target="RFC7422" format="default"/> was propo
sed as a solution to
reduce the resource consumption of logging.</t>
<t>Please also refer to <xref target="RFC6888" sectionFormat="of" sectio
n="4"/> for more information about
requirements for logging CGN gateways.</t>
</section>
<section anchor="optimization" numbered="true" toc="default">
<name>Optimization for IPv4-Only Devices and Applications</name>
<t>When IPv4-only devices or applications are behind a CE connected with
IPv6-only and IPv4aaS, the IPv4-only traffic flows will necessarily be
encapsulated/decapsulated (in the case of DS-Lite, lw4o6, and MAP-E)
and will reach the IPv4 address of the destination, even if that
service supports dual-stack. This means that the traffic flow will
cross through the AFTR, lwAFTR, or BR, depending on the specific
transition mechanism being used.</t>
<t>Even if those services are directly connected to the operator network
(e.g., CDNs and caches) or located internally (such as VoIP, etc.),
it is not possible to avoid that overhead.</t>
<t>However, in the case of those mechanisms that use a NAT46 function, i
n the CE (464XLAT and MAP-T), it is possible to take
advantage of optimization functionalities, such as the ones described
in <xref target="I-D.ietf-v6ops-464xlat-optimization"
format="default"/>.
</t>
<t>
Because the NAT46 has already translated
the IPv4-only flow to IPv6 and the services are dual-stack, using these
optimizations allows the services to
be reached without the need to translate the flow back to IPv4.
</t>
</section>
</section>
<section anchor="performance" numbered="true" toc="default">
<name>Performance Comparison</name>
<t>We plan to compare the performances of the most prominent free software
implementations of the five IPv6 transition technologies using the
methodology described in "Benchmarking Methodology for IPv6 Transition
Technologies" <xref target="RFC8219" format="default"/>.</t>
<t>The dual Device Under Test (DUT) setup of <xref target="RFC8219" format
="default"/> makes it possible to use the existing measurement devices compliant
with
"Benchmarking Methodology for Network Interconnect Devices"
<xref target="RFC2544" format="default"/>; however,
this solution has two kinds of limitations:
</t>
<ul spacing="normal">
<li>Dual DUT setup has the drawback that the performances of the CE
and the ISP-side device (e.g., the CLAT and PLAT of 464XLAT)
are measured together. In order to measure the performance of
only one of them, we need to ensure that the desired one is the
bottleneck.</li>
<li>Measurement procedures for Packet Delay Variation (PDV)
and Inter-Packet Delay Variation (IPDV) measurements are
missing from the legacy devices, and the old measurement
procedure for latency has been redefined in <xref
target="RFC8219" format="default"/>.</li>
</ul>
<t>The single DUT setup of <xref target="RFC8219" format="default"/>
makes it possible to benchmark the selected device separately, but
either special Tester is required or some trick is needed if we want to
use legacy Testers. An example for the latter is our stateless NAT64
measurements testing Throughput and Frame Loss Rate using a legacy
commercial Tester <xref target="LEN2020a" format="default"/> that is
compliant with <xref target="RFC5180" format="default"/>.</t>
<t>Siitperf, a DPDK-based
software Tester that is compliant with <xref target="RFC8219" format="de
fault"/> and used for benchmarking stateless NAT64 gateways, has been
developed recently. Siitperf is available from GitHub
<xref target="SIITPERF" format="default"/> as free software and is docum
ented in
<xref target="LEN2021" format="default"/>. Originally, it literally foll
owed the test
frame format of <xref target="RFC2544" format="default"/>, including "ha
rd-wired" source and
destination port numbers, and then it was complemented with the
pseudorandom port feature required by <xref target="RFC4814" format="def
ault"/>. The new
version is documented in <xref target="LEN2020b" format="default"/>.</t>
<t>Further DPDK-based software Testers that are compliant with <xref targe
t="RFC8219" format="default"/>
are being developed at the Budapest University of Technology and
Economics as student projects. They are planned to be released as free
software, too.</t>
<t>Information about the benchmarking tools, measurements, and results wil
l
be made available in <xref target="I-D.lencse-v6ops-transition-benchmark
ing" format="default"/>.
</t>
</section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
<section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>As discussed in <xref target="logging"></xref>, the different technolog
ies have varying
logging capabilities and limitations. Care should be taken when storing,
transmitting, and providing access to log entries that may be considered
personally identifiable information. However, it should be noted that
those issues are not specific to the IPv4aaS IPv6 transition technologie
s
but apply to logging functionalities in general.</t>
<t>For all five technologies, the CE device typically contains a DNS pro
xy.
However, the user may change DNS settings. If this happens and lw4o6, MAP-E
,
and MAP-T are used with a significantly restricted port set (which is
required for efficient public IPv4 address sharing), the entropy of the
source ports is significantly lowered (e.g., from 16 bits to 10 bits when
1024 port numbers are assigned to each subscriber), and these
technologies are thus theoretically less resilient against cache poisoning
(see
<xref target="RFC5452" format="default"/>). However, an efficient cache poi
soning attack
requires that the subscriber operates its own caching DNS server and the
attack is performed in the service provider network. Thus, we consider the
chance of the successful exploitation of this vulnerability to be low.</t>
<t>IPv4aaS technologies based on encapsulation have no DNSSEC
implications. However, those based on translation may have implications
as discussed in <xref target="RFC8683" sectionFormat="of"
section="4.1"/>.</t>
<t>An in-depth security analysis of all five IPv6 transition technologies
and their most prominent free software implementations according to the
methodology defined in <xref target="LEN2018" format="default"/> is planned
.</t>
<t>As the first step, an initial security analysis of 464XLAT was
done in <xref target="AZZ2021" format="default"/>.</t>
<t>The implementers of any of the five IPv4aaS solutions should consult th
e
Security Considerations of the respective RFCs documenting them.</t>
</section>
</middle>
<back>
<displayreference target="I-D.ietf-v6ops-464xlat-optimization" to="OP-464XLAT/MA
P-T"/>
<displayreference target="I-D.ietf-tsvwg-natsupp" to="NAT-SUPP"/>
<displayreference target="I-D.lencse-v6ops-transition-scalability" to="IPv4aaS-S
CALE-TECH"/>
<displayreference target="I-D.lencse-v6ops-transition-benchmarking" to="IPv4aaS-
BENCHMARK-TECH"/>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.24
73.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
544.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
663.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
814.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
180.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
452.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.60
52.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
146.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
147.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
180.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
269.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
333.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
346.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
519.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
877.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
887.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
888.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
889.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
050.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
269.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
341.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
393.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
422.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
757.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.79
15.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
596.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
597.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
599.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
605.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
950.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
114.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
215.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
219.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
415.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
512.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
513.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
658.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
676.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
683.xml"/>
</references>
<references>
<name>Informative References</name>
<!-- [I-D.ietf-v6ops-464xlat-optimization] IESG state Expired -->
<reference anchor="I-D.ietf-v6ops-464xlat-optimization">
<front>
<title>464XLAT/MAT-T Optimization</title>
<author initials="J." surname="Palet Martinez">
<organization>The IPv6 Company</organization>
</author>
<author initials="A" surname="D'Egidio" fullname="Alejandro D'Egidio">
<organization>Telecentro</organization>
</author>
<date month="July" day="28" year="2020" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-v6ops-464xlat-optimizatio
n-03" />
<format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-v6ops-4
64xlat-optimization-03.txt" />
</reference>
<!-- [I-D.ietf-tsvwg-natsupp] IESG state Expired -->
<xi:include
href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-tsvwg-natsupp.
xml"/>
<!-- [I-D.lencse-v6ops-transition-scalability] IESG state I-D Exists -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.lencse-v6ops-transition-scalability.xml"/>
<!-- [I-D.lencse-v6ops-transition-benchmarking] IESG state I-D Exists -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.lencse-v6ops-transition-benchmarking.xml"/>
<reference anchor="AZZ2021" target="https://www.infocommunications.hu/20
21_4_2">
<front>
<title>Identification of the Possible Security Issues of the
464XLAT IPv6 Transition Technology
</title>
<author initials="A." surname="Al-Azzawi">
<organization/>
</author>
<author initials="G." surname="Lencse">
<organization/>
</author>
<date month="December" year="2021"/>
</front>
<seriesInfo name="DOI" value="10.36244/ICJ.2021.4.2"/>
<refcontent>Infocommunications Journal, Vol. 13, No. 4, pp. 10-18</ref
content>
</reference>
<reference anchor="LEN2018" target="http://www.hit.bme.hu/~lencse/publications/E
CS-2018-Methodology-revised.pdf">
<front>
<title>Methodology for the identification of potential security issu
es
of different IPv6 transition technologies: Threat analysis of DNS64 and
stateful NAT64
</title>
<author initials="G." surname="Lencse">
<organization/>
</author>
<author initials="Y." surname="Kadobayashi">
<organization/>
</author>
<date month="August" year="2018"/>
</front>
<seriesInfo name="DOI" value="10.1016/j.cose.2018.04.012"/>
<refcontent>Computers &amp; Security, Vol. 77, No. 1, pp. 397-411</ref
content>
</reference>
<reference anchor="LEN2019" target="http://www.hit.bme.hu/~lencse/public
ations/e102-b_10_2021.pdf">
<front>
<title>Comprehensive Survey of IPv6 Transition Technologies:
A Subjective Classification for Security Analysis
</title>
<author initials="G." surname="Lencse">
<organization/>
</author>
<author initials="Y." surname="Kadobayashi">
<organization/>
</author>
<date month="October" year="2019"/>
</front>
<seriesInfo name="DOI" value="10.1587/transcom.2018EBR0002"/>
<refcontent>IEICE Transactions on Communications, Vol. E102-B, No. 10,
pp. 2021-2035</refcontent>
</reference>
<reference anchor="LEN2020a" target="https://link.springer.com/article/1
0.1007/s11235-020-00681-x">
<front>
<title>Benchmarking stateless NAT64 implementations with a standard
tester
</title>
<author initials="G." surname="Lencse">
<organization/>
</author>
<date month="June" year="2020"/>
</front>
<seriesInfo name="DOI" value="10.1007/s11235-020-00681-x"/>
<refcontent>Telecommunication Systems, Vol. 75, pp. 245-257</refcontent
>
</reference>
<reference anchor="LEN2020b" target="https://ijates.org/index.php/ijates
/article/view/291">
<front>
<title>Adding RFC 4814 Random Port Feature to Siitperf: Design, Impl
ementation and
Performance Estimation
</title>
<author initials="G." surname="Lencse">
<organization/>
</author>
<date month="" year="2020"/>
</front>
<seriesInfo name="DOI" value="10.11601/ijates.v9i3.291"/>
<refcontent>International Journal of Advances in Telecommunications, El
ectrotechnics, Signals and Systems, Vol. 9, No. 3, pp. 18-26</refcontent>
</reference>
<reference anchor="LEN2021">
<front>
<title>Design and Implementation of a Software Tester for Benchmarki
ng Stateless NAT64 Gateways
</title>
<author initials="G." surname="Lencse">
<organization/>
</author>
<date year="2021"/>
</front>
<seriesInfo name="DOI" value="10.1587/transcom.2019EBN0010"/>
<refcontent>IEICE Transactions on Communications, Vol. E104.B, Issue 2,
pp. 128-140</refcontent>
</reference>
<reference anchor="JOOL-MAPT" target="https://www.jool.mx/en/run-mapt.ht
ml">
<front>
<title>MAP-T Run</title>
<author>
</author>
</front>
</reference>
<reference anchor="MIY2010" target="https://www.jstage.jst.go.jp/article
/transcom/E93.B/5/E93.B_5_1078/_article">
<front>
<title>IPv4 to IPv6 Transformation Schemes
</title>
<author initials="S." surname="Miyakawa">
<organization/>
</author>
<date year="2010"/>
</front>
<seriesInfo name="DOI" value="10.1587/transcom.E93.B.1078"/>
<refcontent>IEICE Transactions on Communications, Vol. E93-B, Issue 5,
pp. 1078-1084</refcontent>
</reference>
<reference anchor="REP2014" target="http://www.hit.bme.hu/~lencse/public
ations/TSP-2014-PC.pdf">
<front>
<title>Port Number Consumption of the NAT64 IPv6 Transition Technolo
gy
</title>
<author initials="S." surname="Répás">
<organization/>
</author>
<author initials="T." surname="Hajas">
<organization/>
</author>
<author initials="G." surname="Lencse">
<organization/>
</author>
<date year="2014"/>
</front>
<seriesInfo name="DOI" value="10.1109/TSP.2015.7296411"/>
<refcontent>37th International Conference on Telecommunications and Sig
nal Processing</refcontent>
</reference>
<reference anchor="SIITPERF" target="https://github.com/lencsegabor/siit
perf">
<front>
<title>Siitperf: an RFC 8219 compliant SIIT (stateless NAT64)
tester</title>
<author/>
<date month="February" year="2021"/>
</front>
<refcontent>commit bdce0f</refcontent>
</reference>
<reference anchor="TR-069" target="https://www.broadband-forum.org/techn
ical/download/TR-069.pdf">
<front>
<title>CPE WAN Management Protocol</title>
<author>
<organization>Broadband Forum</organization>
</author>
<date month="June" year="2020"/>
</front>
<seriesInfo name="Technical Report" value="TR-069"/>
</reference>
<reference anchor="JOOL" target="http://www.jool.mx">
<front>
<title>Jool: SIIT &amp; NAT64</title>
<author>
</author>
</front>
</reference>
<reference anchor="VPP" target="https://wiki.fd.io/index.php?title=VPP&a
mp;oldid=11809">
<front>
<title>VPP</title>
<author>
</author>
<date month="July" year="2022"/>
</front>
</reference>
<reference anchor="SNABB" target="https://github.com/Igalia/snabb">
<front>
<title>Snabb implementation of lwAFTR</title>
<author>
</author>
<date month="January" year="2022"/>
</front>
<refcontent>commit 1ef72ce</refcontent>
</reference>
<reference anchor="AFTR" target="https://downloads.isc.org/isc/aftr/">
<front>
<title>ISC Implementation of AFTR</title>
<author>
<organization>ISC</organization>
</author>
</front>
</reference>
</references>
</references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Ole Troan"/>,
<contact fullname="Warren Kumari"/>, <contact fullname="Dan
Romascanu"/>, <contact fullname="Brian Trammell"/>, <contact
fullname="Joseph Salowey"/>, <contact fullname="Roman Danyliw"/>,
<contact fullname="Erik Kline"/>, <contact fullname="Lars Eggert"/>,
<contact fullname="Zaheduzzaman Sarker"/>, <contact fullname="Robert
Wilton"/>, <contact fullname="Éric Vyncke"/> and <contact
fullname="Martin Duke"/> for their review of this draft and acknowledge
the inputs of <contact fullname=" Mark Andrews"/>, <contact
fullname="Edwin Cordeiro"/>, <contact fullname="Fred Baker"/>, <contact
fullname="Alexandre Petrescu"/>, <contact fullname="Cameron Byrne"/>,
<contact fullname="Tore Anderson"/>, <contact fullname="Mikael
Abrahamsson"/>, <contact fullname="Gert Doering"/>, <contact
fullname="Satoru Matsushima"/>, <contact fullname="Yutianpeng (Tim)"/>,
<contact fullname="Mohamed Boucadair"/>, <contact fullname="Nick
Hilliard"/>, <contact fullname="Joel Jaeggli"/>, <contact
fullname="Kristian McColm"/>,
<contact fullname="Tom Petch"/>, <contact fullname="Yannis
Nikolopoulos"/>, <contact fullname="Havard Eidnes"/>, <contact
fullname="Yann-Ju Chu"/>, <contact fullname="Barbara Stark"/>, <contact
fullname="Vasilenko Eduard"/>, <contact fullname="Chongfeng Xie"/>,
<contact fullname="Henri Alves de Godoy"/>, <contact fullname="Magnus
Westerlund"/>, <contact fullname="Michael Tüxen"/>, <contact
fullname="Philipp S. Tiesel"/>, <contact fullname="Brian E. Carpenter"/>,
and <contact fullname="Joe Touch"/>.</t>
</section>
</back>
</rfc>
 End of changes. 1 change blocks. 
lines changed or deleted lines changed or added

This html diff was produced by rfcdiff 1.48.