<?xml<?xml version="1.0" encoding="UTF-8"?><!-- This template is for creating an Internet Draft using xml2rfc, which is available here: http://xml.resource.org. --><!DOCTYPE encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [<!-- One method to get references from the online citation libraries. There has to be one entity for each item to be referenced. An alternate method (rfc include) is described in the references. --><!ENTITY RFC2473 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2473.xml"><!ENTITY RFC2544 SYSTEM "http://xml.resource.org/public/rfc/bibxml/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://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml"><!ENTITY RFC4814 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4814.xml"><!ENTITY RFC5180 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5180.xml"><!ENTITY RFC5226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml"><!ENTITY RFC5452 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5452.xml"><!ENTITY RFC6050 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6050.xml"><!ENTITY RFC6052 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6052.xml"><!ENTITY RFC6146 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6146.xml"><!ENTITY RFC6147 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6147.xml"><!ENTITY RFC6180 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6180.xml"><!ENTITY RFC6269 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6269.xml"><!ENTITY RFC6333 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6333.xml"><!ENTITY RFC6346 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6346.xml"><!ENTITY RFC6519 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6519.xml"><!ENTITY RFC6877 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6877.xml"><!ENTITY RFC6887 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6887.xml"><!ENTITY RFC6888 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6888.xml"><!ENTITY RFC6889 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6889.xml"><!ENTITY RFC7050 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7050.xml"><!ENTITY RFC7269 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7269.xml"><!ENTITY RFC7341 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7341.xml"><!ENTITY RFC7393 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7393.xml"><!ENTITY RFC7422 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7422.xml"><!ENTITY RFC7596 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7596.xml"><!ENTITY RFC7597 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7597.xml"><!ENTITY RFC7599 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7599.xml"><!ENTITY RFC7605 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7605.xml"><!ENTITY RFC7757 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7757.xml"><!--<!ENTITY RFC7857 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7757.xml">--><!ENTITY RFC7915 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7915.xml"><!ENTITY RFC7950 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7950.xml"><!ENTITY RFC8114 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8114.xml"><!ENTITY RFC8215 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8215.xml"><!ENTITY RFC8219 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8219.xml"><!ENTITY RFC8415 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8415.xml"><!ENTITY RFC8512 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8512.xml"><!ENTITY RFC8513 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8513.xml"><!ENTITY RFC8658 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8658.xml"><!ENTITY RFC8676 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8676.xml"><!ENTITY RFC8683 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8683.xml">]><?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?><!-- used by XSLT processors --><!-- For a complete list and description of processing instructions (PIs), please see http://xml.resource.org/authoring/README.html. --><!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use. (Here they are set differently than their defaults in xml2rfc v1.32) --><?rfc strict="yes" ?><!-- give errors regarding ID-nits and DTD validation --><!-- control the table of contents (ToC) --><?rfc toc="yes"?><!-- generate a ToC --><?rfc tocdepth="4"?><!-- the number of levels of subsections in ToC. default: 3 --><!-- control references --><?rfc symrefs="yes"?><!-- use symbolic references tags, i.e, [RFC2119] instead of [1] --><?rfc sortrefs="yes" ?><!-- sort the reference entries alphabetically --><!-- control vertical white space (using these PIs as follows is recommended by the RFC Editor) --><?rfc compact="yes" ?><!-- do not start each main section on a new page --><?rfc subcompact="no" ?><!-- keep one blank line between list items --><!-- end of list of popular I-D processing instructions --><rfc [
<!ENTITY nbsp " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑">
<!ENTITY wj "⁠">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="info" consensus="true" docName="draft-ietf-v6ops-transition-comparison-04" ipr="trust200902"> <front> number="9313" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="4"
symRefs="true" sortRefs="true" version="3">
<!-- The abbreviated title is used in the page header - it is only necessary if the full title is longer than 39 characters xml2rfc v2v3 conversion 3.14.0 -->
<front>
<title abbrev="Pros and Cons of IPv4aaS Technologies">Pros and Cons of
IPv6 Transition Technologies for IPv4aaS</title> <!-- add 'role="editor"' below for the editors if appropriate --> <!-- Another author who claims to be an editor --> IPv4-as-a-Service (IPv4aaS)</title>
<seriesInfo name="RFC" value="9313"/>
<author fullname="Gabor fullname="Gábor Lencse" initials="G." surname="Lencse">
<organization abbrev="BUTE">Budapest University of Technology and Economics</organization>
<address>
<postal>
<street>Magyar tudosok korutja 2.</street> <!-- Reorder these if your country does things differently --> tudósok körútja 2</street>
<city>Budapest</city> <region></region>
<region/>
<code>H-1117</code>
<country>Hungary</country>
</postal> <phone></phone>
<email>lencse@hit.bme.hu</email>
<uri>http://www.hit.bme.hu/~lencse/index_en.htm</uri>
</address>
</author>
<author fullname="Jordi Palet Martinez" initials="J." surname="Palet Martinez">
<organization>The IPv6 Company</organization>
<address>
<postal>
<street>Molino de la Navata, 75</street>
<city>La Navata - Galapagar</city>
<region>Madrid</region>
<code>28420</code>
<country>Spain</country>
</postal>
<email>jordi.palet@theipv6company.com</email>
<uri>http://www.theipv6company.com/</uri>
</address>
</author>
<author fullname="Lee Howard" initials="L." surname="Howard">
<organization>Retevia</organization>
<address>
<postal>
<street>9940 Main St., Suite 200</street> <!-- Reorder these if your country does things differently -->
<city>Fairfax</city>
<region>Virginia</region>
<code>22031</code> <country>USA</country>
<country>United States of America</country>
</postal> <phone></phone>
<email>lee@asgard.org</email>
</address>
</author>
<author fullname="Richard Patterson" initials="R." surname="Patterson">
<organization>Sky UK</organization>
<address>
<postal>
<street>1 Brick Lane</street> <!-- Reorder these if your country does things differently -->
<city>London</city> <region></region>
<code>EQ 6PU</code>
<country>United Kingdom</country>
</postal> <phone></phone>
<email>richard.patterson@sky.uk</email>
</address>
</author>
<author fullname="Ian Farrer" initials="I." surname="Farrer">
<organization>Deutsche Telekom AG</organization>
<address>
<postal>
<street>Landgrabenweg 151</street> <!-- Reorder these if your country does things differently -->
<city>Bonn</city> <region></region>
<code>53227</code>
<country>Germany</country>
</postal> <phone></phone>
<email>ian.farrer@telekom.de</email>
</address>
</author>
<date year="2022" month="October" /> <!-- Meta-data Declarations -->
<area>ops</area>
<workgroup>v6ops</workgroup> <!-- WG name at the upperleft corner of the doc, IETF is fine for individual submissions. If this element is not present, the default is "Network Working Group", which is used by the RFC Editor as a nod to the history of the IETF. --> <keyword>IPv6, Transition Technologies, Comparison, IPv4aaS, IPv6-only, 464XLAT, DNS64, Dual Stack Lite, Lightweight 4over6, MAP-E, MAP-T</keyword> <!-- Keywords will be incorporated into HTML output files in a meta tag but they have no effect on text or nroff output. If you submit your draft to the RFC Editor, the keywords will be used for the search engine. -->
<keyword>IPv6</keyword>
<keyword>Transition Technologies</keyword>
<keyword>Comparison</keyword>
<keyword>IPv4aaS</keyword>
<keyword>IPv6-only</keyword>
<keyword>464XLAT</keyword>
<keyword>DNS64</keyword>
<keyword>Dual-Stack Lite</keyword>
<keyword>Lightweight 4over6</keyword>
<keyword>MAP-E</keyword>
<keyword>MAP-T</keyword>
<abstract>
<t>Several IPv6 transition technologies have been developed to
provide customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an
IPv6-only access and/or core network. All these These technologies have their
advantages and disadvantages, and depending disadvantages. Depending on existing topology, skills, strategy
strategy, and other preferences, one of these technologies may be the
most appropriate solution for a network operator.</t>
<t>This document examines the five most prominent
IPv4aaS technologies considering and considers a number of different aspects
to provide network operators with an easy-to-use reference to assist in
selecting the technology that best suits their needs.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction"> numbered="true" toc="default">
<name>Introduction</name>
<t>As the deployment of IPv6 continues to be prevalent, it becomes clearer
that network operators will move to building single-stack IPv6 core
and access networks to simplify network planning and operations.
However, providing customers with IPv4 services continues to be a
requirement for the foreseeable future. To meet this need, the IETF
has standardised standardized a number of different IPv4aaS technologies
for this (see <xref target="LEN2019"/> target="LEN2019" format="default"/>) based on differing requirements and
deployment scenarios.</t>
<t>The number of technologies that have been developed makes it
time-consuming for a network operator to identify the most appropriate
mechanism for their specific deployment. This document provides a
comparative analysis of the most commonly used mechanisms to assist
operators with this problem.</t>
<t>Five different IPv4aaS solutions are considered. The following IPv4aaS technologies are covered: <list style="numbers"> <t>464XLAT <xref target="RFC6877"/></t> <t>Dual Stack considered:
</t>
<ol spacing="normal" type="1"><li>464XLAT <xref target="RFC6877" format="default"/></li>
<li>Dual-Stack Lite <xref target="RFC6333"/></t> <t>lw4o6 (Lightweight 4over6) target="RFC6333" format="default"/></li>
<li>Lightweight 4over6 (lw4o6) <xref target="RFC7596"/></t> <t>MAP-E target="RFC7596" format="default"/></li>
<li>Mapping of Address and Port with Encapsulation (MAP-E) <xref target="RFC7597"/></t> <t>MAP-T target="RFC7597" format="default"/></li>
<li>Mapping of Address and Port using Translation (MAP-T) <xref target="RFC7599"/></t> </list></t> target="RFC7599" format="default"/></li>
</ol>
<t>We note that <xref target="RFC6180"/> target="RFC6180" format="default"/> gives
guidelines for using IPv6 transition mechanisms during IPv6 deployment addressing deployment;
that document addresses a much broader topic, whereas this document
focuses on a small part of it.</t>
</section>
<section anchor="overview" title="Overview numbered="true" toc="default">
<name>Overview of the Technologies"> Technologies</name>
<t>The following sections introduce the different technologies analyzed
in this document, describing document and describe some of their most important characteristics.
</t>
<section anchor="xlat_ov" title="464XLAT"> numbered="true" toc="default">
<name>464XLAT</name>
<t>464XLAT may use double translation (stateless NAT46 + stateful
NAT64) or single translation (stateful NAT64), NAT64) depending on different
factors, such as the use of DNS by the applications and the
availability of a DNS64 function (in the host or in the service
provider network).</t>
<t>The customer-side translator (CLAT) is located in the customer's
device, and it performs stateless NAT46 translation <xref target="RFC7915"/>
target="RFC7915" format="default"/> (more precisely, a stateless
IP/ICMP translation from IPv4 to IPv6). IPv4-embedded IPv6 addresses
<xref target="RFC6052"/> target="RFC6052" format="default"/> are used for both source and
destination addresses. Commonly, a /96 prefix (either the 64:ff9b::/96
Well-Known Prefix, Prefix (WKP) or a Network-Specific Prefix) is used as the
IPv6 destination for the IPv4-embedded client traffic.</t>
<t>In deployments where NAT64 load-balancing load balancing (see <xref target="RFC7269"/> section 4.2 target="RFC7269"
sectionFormat="of" section="4.2"/>) is enabled, multiple WKPs <xref target="RFC8215"/> target="RFC8215" format="default"/> may be used.</t>
<t>In the operator's network, the provider-side translator (PLAT)
performs stateful NAT64 <xref target="RFC6146"/> target="RFC6146" format="default"/> to translate the
traffic. The destination IPv4 address is extracted from the
IPv4-embedded IPv6 packet destination address address, and the source address is
from a pool of public IPv4 addresses.</t>
<t>Alternatively, when a dedicated /64 is not available for translation,
the CLAT device uses a stateful NAT44 translation before the stateless
NAT46 translation.</t> <!-- I'm not sure I understand the above statement. It seems to conflate the /64 destination address needed to route the 46 translated traffic to the PLAT with moving the stateful NAT44 function from the PLAT to the CLAT --> <!-- GL: Please refer to: https://tools.ietf.org/html/rfc6877#section-6.3 -->
<t>In general, keeping state in devices close to the end-user network (i.e. (i.e., at the CE - Customer Edge (Customer Edge) router) is not perceived to be as problematic as keeping state in the operator's network.</t> <!-- GL: <t>The authors generally do not see state close to the end-user as equally problematic as state in the middle of the network.</t> --> network.
</t>
<t>In typical deployments, 464XLAT is used together with DNS64
<xref target="RFC6147"/>, target="RFC6147" format="default"/>; see Section 3.1.2 of <xref target="RFC8683"/>.
target="RFC8683" sectionFormat="of" section="3.1.2"/>.
When an IPv6-only client or application communicates 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 sends out IPv6
packets, and the CLAT functions as an IPv6 router router, and the PLAT performs a
stateful NAT64 for these packets. In this case, there There is a single
translation.</t>
<t>Similarly, when an IPv4-only client or application communicates
with an IPv4-only server, the CLAT will statelessly translate to IPv6
so it can traverse the ISP network up to the PLAT (NAT64), which in
turn will translate to IPv4.</t>
<t>Alternatively, one can say that DNS64 + stateful NAT64 is
used to carry the traffic of the IPv6-only client and the IPv4-only
server, and the CLAT is used only for the IPv4 traffic from applications
or devices that use literal IPv4 addresses or non-IPv6 compliant non-IPv6-compliant APIs. </t><!--*** Comment 1 - For the above 2 paragraphs, is the above case a typical deployment? Isn't mobile still overwhelmingly the most common deployer of 464? Comment 2 - I think that the above 2 paragraphs would be better moved to another section. This is meant to be a overview of how 464XLAT works. Combining with DNS64/NAT64 adds in another solution (not part of the stated scope of the doc ) which could be done with any of the technologies described here whether this is commonly done or not). It's not a part of 464XLAT and it's not unique to it. --> <!-- GL: for Comment 2 - Yes, it could be put to somewhere else, but, in practice, ONLY 464XLAT is combined with DNS64/NAT64. RFC 6877 mentions already in the Introduction that it can be use together with DNS64 or without it. This is one of the most important advantages of 464XLAT that the vast majority of the traffic does not need to be double translated. I did some Google-ing to chech whether T-Mobile USA uses 464XLAT together with DNS64. Yes it does. See slide 13 of this pdf: https://www.sanog.org/resources/sanog23/SANOG23_464XLAT.pdf -->
</t>
<figure anchor="xlatarch" align="center" title="Overview anchor="xlatarch">
<name>Overview of the 464XLAT architecture"> <preamble></preamble> Architecture</name>
<artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
Private +----------+ Translated +----------+ _______
+------+ IPv4 | CLAT | 4-6-4 | PLAT | ( IPv4 )
| IPv4 |------->| Stateless|------------>| Stateful +--( Internet )
|Device|<-------| NAT46 |<------------| NAT64 | (________)
+------+ +----------+ ^ +----------+
|
Operator IPv6 network ]]></artwork> <postamble></postamble>
Network]]></artwork>
</figure>
<t>Note: in In mobile networks, the CLAT is commonly implemented in the user's
user equipment (UE (UE) or smartphone), smartphone; please refer to Figure 2 of in <xref target="RFC6877"/>.</t> <t>Often
target="RFC6877" format="default"/>.</t>
<t>Some NAT64 vendors support direct communication (that is, without translation)
between two CLATs by means of hair-pinning hairpinning through the NAT64.</t>
</section>
<section anchor="dslite_ov" title="Dual-Stack Lite"> numbered="true" toc="default">
<name>Dual-Stack Lite</name>
<t>Dual-Stack Lite (DS-Lite) <xref target="RFC6333"/> target="RFC6333" format="default"/> was the first
of the considered transition mechanisms to be developed. DS-Lite uses a 'Basic
Basic Bridging BroadBand' BroadBand (B4) function in the customer's CE router
that encapsulates IPv4 in IPv6 traffic and sends it over the IPv6 native service-provider
service provider network to an 'Address Address Family Transition Router'
Router (AFTR). The AFTR performs encapsulation/decapsulation of the
4in6 <xref target="RFC2473"/> target="RFC2473" format="default"/> traffic and translates the IPv4 source
address in the inner IPv4 packet to a public IPv4 source address using
a stateful NAPT44 <xref target="RFC2663"/> target="RFC2663" format="default"/> function.</t>
<figure anchor="dslitearch" align="center" title="Overview anchor="dslitearch">
<name>Overview of the DS-Lite architecture"> <preamble></preamble> Architecture</name>
<artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
+-------------+
Private +----------+ IPv4-in-IPv6|Stateful AFTR|+------+ AFTR|
+------+ IPv4 | B4 | tunnel Tunnel |------+------+ _______| _______
| IPv4 |------->| Encap./ |------------>|Encap.| | ( IPv4 )|Device|<-------| decap. )
|Device|<-------| Decap. |<------------| / | NAPT +--( Internet )+------+ )
+------+ +----------+ ^ |Decap.| 44 | (________)
| +------+------+
Operator IPv6 network ]]></artwork> <postamble></postamble>
Network]]></artwork>
</figure>
<t>Some AFTR vendors support direct communication
between two B4s by means of hair-pinning hairpinning through the AFTR.</t>
</section>
<section anchor="lw4o6_ov" title="Lightweight 4over6"> numbered="true" toc="default">
<name>Lightweight 4over6</name>
<t>Lightweight 4over6 (lw4o6) is a variant of DS-Lite. The main
difference is that the stateful NAPT44 function is relocated from the
centralized AFTR to the customer's B4 element (called a lwB4). an "lwB4"). The
AFTR (called a lwAFTR) an "lwAFTR") function therefore only performs A+P
(Address plus Port) routing <xref target="RFC6346"/> target="RFC6346" format="default"/> and 4in6
encapsulation/decapsulation.</t>
<t>Routing to the correct client and IPv4 address sharing is are achieved
using the Address + Port (A+P) A+P model <xref target="RFC6346"/> target="RFC6346" format="default"/> of
provisioning each lwB4 with a unique tuple of IPv4 address and a unique range
of transport layer transport-layer ports. The client uses these for NAPT44.</t>
<t>The lwAFTR implements a binding table, which has a per-client
entry linking the customer's source IPv4 address and an allocated range of transport layer
transport-layer ports to their IPv6 tunnel endpoint address. The binding table
allows egress traffic from customers to be validated (to prevent
spoofing) and ingress traffic to be correctly encapsulated and
forwarded. As there needs to be a per-client entry, an lwAFTR
implementation needs to be optimized for performing a per-packet
lookup on the binding table.</t>
<t>Direct communication (that is, without translation) between two lwB4s is performed by hair-pinning hairpinning
traffic through the lwAFTR.</t>
<figure anchor="lw4o6arch" align="center" title="Overview anchor="lw4o6arch">
<name>Overview of the lw4o6 architecture"> <preamble></preamble> Architecture</name>
<artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
+-------------+ +----------+
Private | lwB4 | IPv4-in-IPv6| Stateless|+------+ Stateless|
+------+ IPv4 |------+------| tunnel Tunnel | lwAFTR | _______| _______
| IPv4 |------->| |Encap.|------------>|(encap/A+P| ( IPv4 )|Device|<-------| )
|Device|<-------| NAPT | / |<------------|bind. tab +--( Internet )+------+ )
+------+ | 44 |Decap.| ^ | routing) | (________)
+------+------+ | +----------+
Operator IPv6 network ]]></artwork> <postamble></postamble>
Network]]></artwork>
</figure>
</section>
<section anchor="map_e_ov" title="MAP-E"> numbered="true" toc="default">
<name>MAP-E</name>
<t>Like 464XLAT (<xref target="xlat_ov"/>), target="xlat_ov" format="default"/>), MAP-E and MAP-T use <xref target="RFC6052"/>
IPv4-embedded IPv6 addresses <xref target="RFC6052" format="default"/> to represent IPv4
hosts outside the MAP domain. </t>
<t>MAP-E and MAP-T use a stateless algorithm to embed portions of the customer's
allocated IPv4 address (or part of an address with A+P routing) into the
IPv6 prefix delegated to the client. This allows for large numbers of
clients to be provisioned using a single MAP rule (called a MAP domain). "MAP domain").
The algorithm also allows for direct IPv4 peer-to-peer communication
between hosts provisioned with common MAP rules.</t>
<t>The CE (Customer-Edge) router typically performs stateful NAPT44
<xref target="RFC2663"/> target="RFC2663" format="default"/> to translate the private IPv4 source addresses
and source ports into an address and port range defined by applying
the MAP rule to the delegated IPv6 prefix. The client
address/port allocation size is a configuration parameter. The CE router then
encapsulates the IPv4 packet in an IPv6 packet <xref target="RFC2473"/> target="RFC2473" format="default"/>
and sends it directly to another host in the MAP domain
(for peer-to-peer) or to a Border Router (BR) if the IPv4 destination is
not covered in one of the CE's MAP rules.</t>
<t>The MAP BR is provisioned with the set of MAP rules for the MAP
domains it serves. These rules determine how the MAP BR is to decapsulate
traffic that it receives from the client, validating validate the source IPv4
address and transport layer transport-layer ports assigned, as well as how to and calculate the
destination IPv6 address for ingress IPv4 traffic.</t>
<figure anchor="map-e-arch" align="center" title="Overview anchor="map-e-arch">
<name>Overview of the MAP-E architecture"> <preamble></preamble> Architecture</name>
<artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
+-------------+ +----------+
Private | MAP CE | IPv4-in-IPv6| Stateless|+------+ Stateless|
+------+ IPv4 |------+------| tunnel | MAP BR | _______| _______
| IPv4 |------->| |Encap.|------------>|(encap/A+P| ( IPv4 )|Device|<-------| )
|Device|<-------| NAPT | / |<------------|algorithm +--( Internet )+------+ )
+------+ | 44 |Decap.| ^ | routing) | (________)
+------+------+ | +----------+
Operator IPv6 network ]]></artwork> <postamble></postamble>
Network]]></artwork>
</figure>
<t>Some BR vendors support direct communication
between two MAP CEs by means of hair-pinning hairpinning through the BR.</t>
</section>
<section anchor="map_t_ov" title="MAP-T"> numbered="true" toc="default">
<name>MAP-T</name>
<t>MAP-T uses the same mapping algorithm as MAP-E. The major difference
is that double stateless translation (NAT46 in the CE and NAT64 in the
BR) is used to traverse the ISP's IPv6 single-stack network. MAP-T can
also be compared to 464XLAT when there is a double translation.</t> <!-- I think the last sentence can be removed as 'double translation' is notreally equivalent in this case. MAP-T has 3 translations - 1 stateful, 2 statelessXLAT has 2 translations - 1 statless, 1 stateful --><!-- GL: Strictly speaking: you are right. But in a high level view, both translate private IPv4 to IPv6 and IPv6 to public IPv4. -->
<t>A MAP CE router typically performs stateful NAPT44 to translate traffic to a public
IPv4 address and port-range port range calculated by applying the provisioned
Basic MAP Rule (BMR - (BMR), which is a set of inputs to the algorithm) algorithm, to the delegated
IPv6 prefix. The CE then performs stateless translation from IPv4 to
IPv6 <xref target="RFC7915"/>. target="RFC7915" format="default"/>.
The MAP BR is
provisioned with the same BMR as the client, enabling the received
IPv6 traffic to be statelessly NAT64 translated (using stateless NAT64) back to the public
IPv4 source address used by the client.</t> client.
</t>
<t>Using translation instead of encapsulation also allows IPv4-only
nodes to correspond directly with IPv6 nodes in the MAP-T domain
that have IPv4-embedded IPv6 addresses.</t><!-- Whilst the above is theoritically true, are there implementations inpractice? How would name resolution /serivce discovery work? The node thatgenerally implements MAP (and gets provisioned with the MAP rule is a CE device. --><!-- GL: If I remember well, the above statement is from Ole Troan, one of the authors of the MAP protocols, thus it is very likely true. However, I myself can neither prove, nor confute it.--> addresses.</t>
<figure anchor="map-t-arch" align="center" title="Overview anchor="map-t-arch">
<name>Overview of the MAP-T architecture"> <preamble></preamble> Architecture</name>
<artwork align="left"><![CDATA[ align="left" name="" type="" alt=""><![CDATA[
+-------------+ +----------+
Private | MAP CE | Translated | Stateless|+------+ Stateless|
+------+ IPv4 |------+------| 4-6-4 | MAP BR | _______| _______
| IPv4 |------->| |State-|------------>|(NAT64/A+P| ( IPv4 )|Device|<-------| )
|Device|<-------| NAPT | less |<------------|algorithm +--( Internet )+------+ )
+------+ | 44 |NAT46 | ^ | routing) | (________)
+------+------+ | +----------+
Operator IPv6 network ]]></artwork> <postamble></postamble>
Network]]></artwork>
</figure>
<t>Some BR vendors support direct communication
between two MAP CEs by means of hair-pinning hairpinning through the BR.</t>
</section>
</section>
<section anchor="hl_arch" title="High-level numbered="true" toc="default">
<name>High-Level Architectures and theirConsequences"> Their Consequences</name>
<section anchor="sp_net_trav" title="Service numbered="true" toc="default">
<name>Service Provider Network Traversal"> Traversal</name>
<t>For the data-plane, data plane, there are two approaches for traversing
the IPv6 provider network: <list style="symbols"> <t>4-6-4 translation</t> <t>4-in-6 encapsulation</t> </list></t> <texttable
</t>
<ul spacing="normal">
<li>4-6-4 translation</li>
<li>4in6 encapsulation</li>
</ul>
<table anchor="net_trav_table" title="Available align="center">
<name>Available Traversal Mechanisms"> <preamble></preamble> <ttcol align="center"></ttcol> <ttcol align="center">464XLAT</ttcol> <ttcol align="center">DS-Lite</ttcol> <ttcol align="center">lw4o6</ttcol> <ttcol align="center">MAP-E</ttcol> <ttcol align="center">MAP-T</ttcol> <c>4-6-4 trans.</c> <c>X</c> <c></c> <c></c> <c></c> <c>X</c> <c>4-6-4 encap.</c> <c></c> <c>X</c> <c>X</c> <c>X</c> <c></c> <postamble></postamble> </texttable> Mechanisms</name>
<thead>
<tr>
<th align="center"/>
<th align="center">464XLAT</th>
<th align="center">DS-Lite</th>
<th align="center">lw4o6</th>
<th align="center">MAP-E</th>
<th align="center">MAP-T</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">4-6-4 translation</td>
<td align="center">X</td>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center">X</td>
</tr>
<tr>
<td align="left">4in6 encapsulation</td>
<td align="center"/>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center"/>
</tr>
</tbody>
</table>
<t>In the scope of this document, all of the encapsulation based encapsulation-based
mechanisms use IP-in-IP tunnelling tunneling <xref target="RFC2473"/>. target="RFC2473" format="default"/>.
This is a stateless tunneling mechanism which that does not require any
additional overhead.</t>
<t>It should be noted that both of these approaches result in an
increase in the size of the packet that needs to be transported across
the operator's network when compared to native IPv4. 4-6-4
translation adds a 20-bytes 20-byte overhead (the 20-byte IPv4 header is
replaced with a 40-byte IPv6 header). Encapsulation has a 40-byte
overhead (an IPv6 header is prepended to the IPv4 header).</t>
<t>The increase in packet size can become a significant problem if there
is a link with a smaller MTU in the traffic path. This may result in the need for
traffic needing to be fragmented at the ingress point to the IPv6 only
domain (i.e., the NAT46 or 4in6 encapsulation endpoint). It may also
result in the need to implement buffering and fragment re-assembly reassembly
in the PLAT/AFTR/lwAFTR/BR node.</t>
<t>The advice given in <xref target="RFC7597"/> Section 8.3.1 target="RFC7597" sectionFormat="of"
section="8.3.1"/> is applicable to all of these mechanisms:
It is
strongly recommended that the MTU in the IPv6-only domain be well
managed (it should have sufficiently large MTU to support tunneling
and/or translation) and that the IPv6 MTU on the CE WAN-side interface
be set so that no fragmentation occurs within the boundary of the
IPv6-only domain.</t>
</section>
<section anchor="nat" title="Network numbered="true" toc="default">
<name>Network Address Translation among the Different IPv4aaS Technologies"> <t>For Technologies</name>
<t>
For the high-level solution of IPv6 service provider network traversal,
MAP-T uses double stateless translation. First at the CE The first translation is from IPv4
to IPv6 (NAT46), (NAT46) at the CE, and then the second translation is from IPv6 to IPv4 (NAT64),
(NAT64) at the service provider network.</t> network.
</t>
<t>464XLAT may use double translation (stateless NAT46 + stateful
NAT64) or single translation (stateful NAT64), NAT64) depending on different
factors, such as the use of DNS by the applications and the availability
of a DNS64 function (in the host or in the service provider network).
For deployment guidelines, please refer to <xref target="RFC8683"/>.</t><!-- Here we're conflation NAT64 with 464XLAT again - see my comment in the 464XLAT overview --><!-- GL: Yes, because they are used together. --> target="RFC8683" format="default"/>.</t>
<t>The first step for the double translation mechanisms is a stateless
NAT from IPv4 to IPv6 implemented as SIIT (Stateless IP/ICMP
Translation Algorithm) <xref target="RFC7915"/>, target="RFC7915" format="default"/>,
which does not translate IPv4 header options and/or multicast IP/ICMP
packets. With encapsulation-based technologies technologies, the header is
transported intact intact, and multicast can also be carried.</t>
<t>Single and double translation results in native IPv6 traffic with a transport layer next-header.
transport-layer next header. The fields in these headers can be used
for functions such as hashing across equal-cost multipaths or access control list Access
Control List (ACL) filtering. Encapsulation technologies, in contrast,
may hinder hashing algorithms or other functions relying on header
inspection.</t>
<t>Solutions using double translation can only carry port-aware IP
protocols (e.g. TCP, (e.g., TCP and UDP) and ICMP when they are used with IPv4
address sharing (please refer to <xref target="pub_serv"/> target="pub_serv"
format="default"/> for more details). Encapsulation based Encapsulation-based solutions
can also carry any other protocols over IP, too.</t> IP.</t>
<t>An in-depth analysis of stateful NAT64 can be found in <xref target="RFC6889"/>.</t> target="RFC6889" format="default"/>.</t>
<t>As stateful NAT interferes with the port numbers, <xref target="I-D.ietf-tsvwg-natsupp"/>
target="I-D.ietf-tsvwg-natsupp" format="default"/> explains how NATs
can handle SCTP (Stream Control Transmission Protocol).</t> <!-- The above paragraph really needs more detail in there as it oversimplifiesthe reality. Encap with address sharing can't carry a non-port aware protocolsuch as GRE (without UDP). A stateful CGN is generally capable of performing NAT44 (not- NAPT) for non-port aware protocols. --><!-- GL: Could you elaborate it in the text? -->
</section>
<section anchor="ipv4_sharing" title="IPv4 numbered="true" toc="default">
<name>IPv4 Address Sharing"> Sharing</name>
<t>As public IPv4 address exhaustion is a common motivation for
deploying IPv6, transition technologies need to provide a solution for allowing that
allows public IPv4 address sharing.</t>
<t>In order to fulfill this requirement, a stateful NAPT function is
a necessary function in all of the mechanisms. The major differentiator
is where in the architecture this function is located.</t>
<t>The solutions compared by this document fall into two categories: <list style="symbols"> <t>CGN-based approaches
</t>
<ul spacing="normal">
<li>Approaches based on Carrier-Grade NAT (CGN) (DS-Lite, 464XLAT)</t> <t>A+P-based approaches 464XLAT)</li>
<li>Approaches based on A+P (lw4o6, MAP-E, MAP-T)</t> </list></t> MAP-T)</li>
</ul>
<t>In the CGN-based model, a device such as a CGN/AFTR or NAT64 performs
the NAPT44 function and maintains per-session state for all of the
active client's traffic. The customer's device does not require
per-session state for NAPT.</t>
<t>In the A+P-based model, a device (usually a CE) performs stateful
NAPT44 and maintains per-session state only for co-located devices, e.g.
e.g., in the customer's home network. Here, the centralized network
function (lwAFTR or BR) only needs to perform stateless
encapsulation/decapsulation or NAT64.</t>
<t>Issues related to IPv4 address sharing address-sharing mechanisms are described
in <xref target="RFC6269"/> target="RFC6269" format="default"/> and should also be considered.</t>
<t>The address sharing address-sharing efficiency of the five technologies is
significantly different, it different and is discussed in
<xref target="port_num_eff"/>.</t> <t>lw4o6, MAP-E target="port_num_eff" format="default"/>.</t>
<t>Lw4o6, MAP-E, and MAP-T can also be configured without IPv4 address sharing, sharing;
see the details in <xref target="pub_serv"/>. target="pub_serv"
format="default"/>. However, in that case, there is no advantage in
terms of public IPv4 address saving.
In the case of 464XLAT, this one-to-one mapping can also
be achieved as well through EAMT (Explicit Address Mapping Table)
<xref target="RFC7757"/>.</t> target="RFC7757" format="default"/>.</t>
<t>Conversely, both MAP-E and MAP-T may be configured to provide more
than one public IPv4 address (i.e., an address with an IPv4 prefix shorter than a /32)
to customers.</t>
<t>Dynamic DNS issues in address-sharing contexts and their possible
solutions using PCP (Port Control Protocol) are discussed in detail
in <xref target="RFC7393"/>.</t> target="RFC7393" format="default"/>.</t>
</section>
<section anchor="ipv4_pool" title="IPv4 numbered="true" toc="default">
<name>IPv4 Pool Size Considerations"> Considerations</name>
<t>In this section section, we do some simple calculations regarding port numbers, however,
numbers. However, technical limitations are not the only point to
consider for port sharing, sharing; there are also local regulations or BCP.</t> and
best current practices.</t>
<t>Note: under By "port numbers", we mean TCP/UDP port numbers or ICMP
identifiers.</t>
<t>In most networks, it is possible to, using to use existing data about flows to CDNs/caches
Content Delivery Networks (CDNs), caches, or other well-known
IPv6-enabled destinations, destinations to calculate the percentage of traffic that
would turn into IPv6 if it IPv6 is enabled on that network or on part of it.</t> it.
</t>
<t>Knowing that, it is possible to calculate the IPv4 pool size
required for a given number of subscribers, depending on the IPv4aaS
technology being used.</t>
<t>According to <xref target="MIY2010"/>, target="MIY2010" format="default"/>, each user-device
user device (computer, tablet, smartphone) behind a NAT, NAT could
simultaneously use up to 300 ports. (Table 1 of <xref target="MIY2010"/>
target="MIY2010" format="default"/> lists the port number usage of
various applications. According to <xref target="REP2014"/> target="REP2014"
format="default"/>, the downloading of some web pages may consume up to
200 port numbers.) If the extended NAPT algorithm is used, which
includes the full five tuple 5-tuple into the connection tracking table, then
the port numbers are reused, reused when the destinations are
different. Therefore, we need to consider the number of "port hungry" "port-hungry"
applications that are accessing the same destination simultaneously.
We estimate that in the case of a residential subscriber, there will
be typically no more than 4 of port hungry four port-hungry applications communicating
with the same destination simultaneously, which means is a total of 1,200
ports. </t> <t>If for
<t>For example, if 80% of the traffic is expected towards IPv6
destinations, only 20% will actually be using IPv4 ports, so ports. Thus, in our
example, that will mean 240 ports are required per for each subscriber.</t>
<t>From the 65,535 ports available per IPv4 address, we could even
consider reserving 1,024 ports, in order to allow ports for customers that need
EAMT entries for incoming connections to System Ports ports (0-1023, also
called well-known ports) "well-known ports") <xref target="RFC7605"/>, which target="RFC7605" format="default"/>.
This means that 64,511 ports are actually available per for each IPv4 address.</t>
<t>According to this, a /22 (1.024 public IPv4 addresses) will be sufficient
for over 275,000 subscribers (1,024x64,511/240=275,246.93).</t>
<t>Similarly, a /18 (16,384 public IPv4 addresses) will be sufficient
for over 4,403,940 subscribers, and so on.</t>
<t>This is a conservative approach, which is valid in the case of 464XLAT,
464XLAT because ports are assigned dynamically by the NAT64, so NAT64. Therefore, it is
not necessary to consider if one user is actually using more or less ports: Average fewer
ports; average values work well.</t>
<t>As the deployment of IPv6 progresses, the use of NAT64, and
therefore of public IPv4 addresses, decreases (more IPv6/ports, less IPv4/ports), so IPv6 ports, fewer
IPv4 ports). Thus, either more subscribers can be accommodated with the
same number of IPv4 addresses, addresses or some of those addressed can be
retired from the NAT64.</t>
<t>For comparison, if dual-stack is being used, any given number of
users will require the same number of public IPv4 addresses. For
instance, a /14 will provide 262,144 IPv4 public addresses for 262,144
subscribers, versus 275,000 subscribers being served with only a
/22.</t>
<t>In the other IPv4aaS technologies, this calculation will only match
if the assignment of ports per subscriber can be done dynamically,
which is not always the case (depending on the vendor
implementation).</t> <t>An alternative approximation for the other IPv4aaS technologies, when dynamically
<t> When dynamic assignment of addresses is not possible, an
alternative approximation for the other IPv4aaS technologies must ensure a
sufficient number of ports per subscriber.
That means 1,200 ports, and
typically, it comes to 2,000 ports in many deployments.
In that case, assuming 80% of is IPv6 traffic, as above, which will allow traffic (as above), only 30 subscribers
will be allowed per each IPv4 address, so address; thus, the closer approximation to
275,000 subscribers per our example with 464XLAT (with a /22), /22) will be using
a /19, which serves 245,760 subscribers (a /19 has 8,192 addresses, addresses and 30
subscribers with 2,000 ports each, each per address).</t> address).
</t>
<t>If the CGN (in case of DS-Lite) or the CE (in case of lw4o6, MAP-E MAP-E,
and MAP-T) make use of a 5-tuple for tracking the NAT connections, the
number of ports required per subscriber can be limited as low as 4 four
ports per subscriber. However, the practical limit depends on the
desired limit for parallel connections that any single host behind the
NAT can have to the same address and port in Internet. Note that it is
becoming more common that applications use AJAX (Asynchronous
JavaScript and XML) and similar mechanisms, so taking that extreme
limit is probably not a safe choice.</t>
<t>This feature of extremely reduced number of ports "feature" could also be used in
case the CLAT-enabled CE with 464XLAT makes use of tracking the 5-tuple NAT
connections tracking, and could also be further extended
if the NAT64 also use uses the 5-tuple.</t>
<t>Please also refer to <xref target="RFC6888"/> target="RFC6888" format="default"/> for in-depth information about
the requirements for sizing Carrier-Grade NAT CGN gateways.</t>
</section>
<section anchor="ce_prov" title="CE numbered="true" toc="default">
<name>CE Provisioning Considerations"> Considerations</name>
<t>All of the technologies require some provisioning of customer
devices. The table below shows which methods currently have
extensions for provisioning the different mechanisms.</t> <texttable
<table anchor="prov_mech_table" title="Available align="center">
<name>Available Provisioning Mechanisms"> <preamble></preamble> <ttcol Mechanisms</name>
<thead>
<tr>
<th align="left">Provisioning Method</ttcol> <ttcol align="center">464XLAT</ttcol> <ttcol align="center">DS-Lite</ttcol> <ttcol align="center">lw4o6</ttcol> <ttcol align="center">MAP-E</ttcol> <ttcol align="center">MAP-T</ttcol> <c>DHCPv6 <xref target="RFC8415"/></c> <c></c> <c>X</c> <c>X</c> <c>X</c> <c>X</c> <c>RADIUS <xref target="RFC8658"/></c> <c></c> <c><xref target="RFC6519"/></c> <c>X</c> <c>X</c> <c>X</c> <c>TR-069 <xref target="TR-069"/></c> <c>*</c> <c>X</c> <c>*</c> <c>X</c> <c>X</c> <c>DNS64 <xref target="RFC7050"/></c> <c>X</c> <c></c> <c></c> <c></c> <c></c> <c>YANG <xref target="RFC7950"/></c> <c><xref target="RFC8512"/></c> <c><xref target="RFC8513"/></c> <c><xref target="RFC8676"/></c> <c><xref target="RFC8676"/></c> <c><xref target="RFC8676"/></c> <c>DHCP4o6 <xref target="RFC7341"/></c> <c></c> <c></c> <c>X</c> <c>X</c> <c></c> <postamble></postamble> </texttable> <t>*: Work Method</th>
<th align="center">464XLAT</th>
<th align="center">DS-Lite</th>
<th align="center">lw4o6</th>
<th align="center">MAP-E</th>
<th align="center">MAP-T</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">DHCPv6 <xref target="RFC8415" format="default"/></td>
<td align="center"/>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
</tr>
<tr>
<td align="left">RADIUS <xref target="RFC8658" format="default"/></td>
<td align="center"/>
<td align="center">
<xref target="RFC6519" format="default"/></td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
</tr>
<tr>
<td align="left">TR-069 <xref target="TR-069" format="default"/></td>
<td align="center">*</td>
<td align="center">X</td>
<td align="center">*</td>
<td align="center">X</td>
<td align="center">X</td>
</tr>
<tr>
<td align="left">DNS64 <xref target="RFC7050" format="default"/></td>
<td align="center">X</td>
<td align="center"/>
<td align="center"/>
<td align="center"/>
<td align="center"/>
</tr>
<tr>
<td align="left">YANG <xref target="RFC7950" format="default"/></td>
<td align="center">
<xref target="RFC8512" format="default"/></td>
<td align="center">
<xref target="RFC8513" format="default"/></td>
<td align="center">
<xref target="RFC8676" format="default"/></td>
<td align="center">
<xref target="RFC8676" format="default"/></td>
<td align="center">
<xref target="RFC8676" format="default"/></td>
</tr>
<tr>
<td align="left">DHCP 4o6 <xref target="RFC7341" format="default"/></td>
<td align="center"/>
<td align="center"/>
<td align="center">X</td>
<td align="center">X</td>
<td align="center"/>
</tr>
</tbody>
</table>
<dl newline="false" spacing="normal">
<dt>*:</dt>
<dd>Work started at BroadBand Broadband Forum (2021).</t> <t>X: Supported (2021)</dd>
<dt>X:</dt>
<dd>Supported by the provisioning method.</t><!--*** References to RFCs are needed in the first column of the table above. --> method</dd>
</dl>
</section>
<section anchor="multicast" title="Support numbered="true" toc="default">
<name>Support for Multicast"> Multicast</name>
<t>The solutions covered in this document are all intended for
unicast traffic. <xref target="RFC8114"/> target="RFC8114" format="default"/> describes a method for
carrying encapsulated IPv4 multicast traffic over an IPv6 multicast
network. This could be deployed in parallel to any of the operator's
chosen IPv4aaS mechanism.</t>
</section>
</section>
<section title="Detailed Analysis"> <section title="Architectural Differences"> <section title="Basic Comparison"> numbered="true" toc="default">
<name>Detailed Analysis</name>
<section numbered="true" toc="default">
<name>Architectural Differences</name>
<section numbered="true" toc="default">
<name>Basic Comparison</name>
<t>The five IPv4aaS technologies can be classified into 2x2=4 categories
based on the basis of two aspects: <list style="symbols"> <t>Technology
</t>
<ul spacing="normal">
<li>Technology used for service provider network traversal.
It can be single/double translation or encapsulation.</t> <t>Presence encapsulation.</li>
<li>Presence or absence of NAPT44 per-flow state in the
operator network. </t> </list></t> <texttable
</li>
</ul>
<table anchor="data_plane_table" title="Basic comparison align="center">
<name>Basic Comparison among the analyzed technologies"> <preamble></preamble> <ttcol align="center"></ttcol> <ttcol align="center">464XLAT</ttcol> <ttcol align="center">DS-Lite</ttcol> <ttcol align="center">lw4o6</ttcol> <ttcol align="center">MAP-E</ttcol> <ttcol align="center">MAP-T</ttcol> <c>Translation Analyzed Technologies</name>
<thead>
<tr>
<th align="center"/>
<th align="center">464XLAT</th>
<th align="center">DS-Lite</th>
<th align="center">lw4o6</th>
<th align="center">MAP-E</th>
<th align="center">MAP-T</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">Translation (T) or Encapsulation (E) </c> <c>T</c> <c>E</c> <c>E</c> <c>E</c> <c>T</c> <c>Per-flow state </td>
<td align="center">T</td>
<td align="center">E</td>
<td align="center">E</td>
<td align="center">E</td>
<td align="center">T</td>
</tr>
<tr>
<td align="left"> Presence (+) of Per-Flow State in op. network</c> <c>X</c> <c>X</c> <c></c> <c></c> <c></c> </texttable> Operator Network</td>
<td align="center">+</td>
<td align="center">+</td>
<td align="center"/>
<td align="center"/>
<td align="center"/>
</tr>
</tbody>
</table>
</section>
</section>
<section anchor="port_num_eff" title="Tradeoff numbered="true" toc="default">
<name>Trade-Off between Port Number Efficiency and Stateless Operation"> Operation</name>
<t>464XLAT and DS-Lite use stateful NAPT at the PLAT/AFTR PLAT and AFTR devices,
respectively. This may cause scalability issues for the number of clients
or volume of traffic, but it does not impose a limitation
on the number of ports per user, as they can be allocated dynamically
on-demand and the allocation policy can be centrally managed/adjusted.</t> <t>A+P based managed and adjusted.</t>
<t>A+P-based mechanisms (lw4o6, MAP-E, and MAP-T) avoid using NAPT in the
service provider network. However, this means that the number of ports
provided to each user (and hence the effective IPv4 address sharing address-sharing ratio)
must be pre-provisioned to the client.</t>
<t>Changing the allocated port ranges with A+P based technologies, A+P-based
technologies requires more planning and is likely to involve re-provisioning
reprovisioning both hosts and operator side operator-side equipment. It should be
noted that due to the per-customer binding table entry used
by lw4o6, a single customer can be re-provisioned reprovisioned (e.g., if they
request a full IPv4 address) without needing to change parameters for a
number of customers as in a MAP domain.</t>
<t>It is also worth noting that there is a direct relationship between
the efficiency of customer public port-allocations port allocations for customers and the corresponding
logging overhead that may be necessary to meet data-retention
requirements. This is considered in <xref target="logging"/> below.</t> target="logging" format="default"/>.</t>
<t>Determining the optimal number of ports for a fixed port set is not
an easy task, task and may also be impacted by local regulatory law (and in
the Belgian case case, it is not a law but more a MoU / BCP), memorandum of
understanding or best current practice), which may define a maximum
number of users per IP address, address and consequently a minimum number of
ports per user.</t>
<t>On the one hand, the "lack of ports" situation may cause serious
problems in the operation of certain applications. For example, Miyakawa
has demonstrated the consequences of the session number limitation due
to port number shortage on in the example of Google Maps
<xref target="MIY2010"/>. target="MIY2010" format="default"/>. When the limit was 15, several blocks of the
map were missing, and the map was unusable. This study also provided
several examples for the session numbers of different applications
(the highest one was Apple's iTunes: iTunes at 230-270 ports).</t>
<t>The port number consumption of different applications is highly varying and e.g. in
varying. In the case of web browsing browsing, it depends on several
factors, including the choice of the web page, the web browser, and
sometimes even the operating system <xref target="REP2014"/>. target="REP2014"
format="default"/>. For example, under certain conditions, 120-160
ports were used (URL: sohu.com, browser: Firefox under Ubuntu Linux),
and in some other cases it was cases, only 3-12 ports were used (URL: twitter.com,
browser: Iceweasel under Debian Linux).</t>
<t>There may be several users behind a CE router, especially in the
broadband case (e.g. (e.g., Internet is used by different members of a family
simultaneously), so sufficient ports must be allocated to avoid
impacting user experience.</t>
<t>In general, assigning too few source port numbers to an end user may results
result in unexpected and hard to debug consequences, hard-to-debug consequences; therefore, if the
number of ports per end user is fixed, then we recommend to assign assigning a
conservatively large number of ports. E.g. For example, the developers of Jool used
2048 ports per user in their example for MAP-T <xref target="MEX2022"/>.</t> target="JOOL-MAPT" format="default"/>.</t>
<t>However, assigning too many ports per CE router
will result in waste of public IPv4 addresses, which is a are scarce and
expensive resource. Clearly resources. Clearly, this is a big advantage in the case of 464XLAT
where they are dynamically managed, managed so that the number of IPv4 addresses
for the sharing-pool sharing pool is smaller while the availability of ports per user don't
doesn't need to be pre-defined and is not a limitation for them.</t> limitation.</t>
<t>There is a direct tradeoff trade-off between the optimization of client
port allocations and the associated logging overhead.
<xref target="logging"/> target="logging" format="default"/> discusses this in more depth.</t><!-- Aren't CGNs generally deployed using port block allocation these days?If so, then getting the size of the allocated block right is also importanthere. --><!-- GL: I do not know, as I am not a network operator. --> <t>We depth.</t>
<t> We note that common CE router NAT44 implementations utilizing Netfilter, multiplexes Netfilter at the
CE router multiplex active sessions using a 3-tuple (source address,
destination address, and destination port). This means that external
source ports can be reused for unique internal source and destination address
addresses and port sessions. It is also noted, noted that Netfilter cannot
currently make use of multiple source port ranges (i.e. (i.e., several blocks
of ports distributed across the total port space as is common in MAP deployments), this
deployments). This may influence the design when using stateless
technologies.</t>
<t>Stateful technologies, 464XLAT 464XLAT, DS-Lite, and DS-Lite (and also NAT444) NAT444 can
therefore be much more efficient in terms of port allocation and thus
public IP address saving. The price is the stateful operation in the
service provider network, which allegedly does not scale up well.
It should be noticed that noted that, in many cases, all those factors may depend on
how it is actually implemented.</t>
<t>Measurements have been started to examine the scalability of a few
stateful solutions in two areas: <list style="symbols"> <t>How
</t>
<ul spacing="normal">
<li>How their performance scales up with the number of CPU cores?</t> <t>To cores</li>
<li>To what extent their performance degrades with the number of
concurrent connections?</t> </list> connections</li>
</ul>
<t>
The details of the measurements and their results are available from
<xref target="I-D.lencse-v6ops-transition-scalability"/>. </t><!--*** +1 on that! --> target="I-D.lencse-v6ops-transition-scalability" format="default"/>.
</t>
<t>We note that some CGN-type solutions can allocate ports dynamically
"on the fly". Depending on configuration, this can result in the same
customer being allocated ports from different source addresses. This can
cause operational issues for protocols and applications that expect
multiple flows to be sourced from the same address. E.g., address (e.g., ECMP hashing,
STUN, gaming, and content delivery networks. networks). However, it should be noticed noted
that this is the same problem when a network has a NAT44 with multiple
public IPv4 addresses, or even when applications in a dual-stack case,
behave wrongly if happy eyeballs Happy Eyeballs is flapping the flow address between
IPv4 and IPv6.</t>
<t>The consequences of IPv4 address sharing <xref target="RFC6269"/> target="RFC6269" format="default"/> may
impact all five technologies. However, when ports are allocated
statically, more customers may get ports from the same public IPv4
address, which may results result in negative consequences with higher probability, e.g.
probability. For example, many applications and service providers (Sony
PlayStation Network, OpenDNS, etc.) can permanently blocking block IPv4 ranges
if they detect that they are used for address sharing.</t>
<t>Both cases are, again, implementation dependent.</t> implementation-dependent.</t>
<t>We note that although it is not of typical use, one can do
deterministic, stateful NAT and reserve a fixed set of ports for each customer,
customer as well.</t>
</section>
<section anchor="pub_serv" title="Support numbered="true" toc="default">
<name>Support for Public Server Operation"> Operation</name>
<t>Mechanisms that rely on operator side operator-side per-flow state do not, by
themselves, offer a way for customers to present services on publicly
accessible transport layer transport-layer ports.</t> <t>Port
<t>The Port Control Protocol (PCP) <xref target="RFC6887"/> target="RFC6887" format="default"/> provides a
mechanism for a client to request an external public port from a CGN
device. For server operation, it is required with NAT64/464XLAT, 464XLAT/NAT64, and
it is supported in some DS-Lite AFTR implementations.</t> <t>A+P based
<t>A+P-based mechanisms distribute a public IPv4 address and
restricted range of transport layer transport-layer ports to the client. In this case,
it is possible for the user to configure their device to offer a
publicly accessible server on one of their allocated ports. It should
be noted that commonly operators commonly do not assign the Well-Known-Ports well-known ports to
users (unless they are allocating a full IPv4 address), so the user
will need to run the service on an allocated port, port or configure port
translation.</t>
<t>Lw4o6, MAP-E MAP-E, and MAP-T may be configured to allocated clients with
a full IPv4 address, allowing exclusive use of all ports, ports and
non-port-based transport layer transport-layer protocols. Thus, they may also be used to support
server/services operation on their default ports. However, when public
IPv4 addresses are assigned to the CE router without address sharing, obviously
there is obviously no advantage in terms of IPv4 public addresses saving.
</t>
<t>It is also possible to configure specific ports mapping in
464XLAT/NAT64 using EAMT <xref target="RFC7757"/>, target="RFC7757" format="default"/>, which means that only
those ports are "lost" from the pool of addresses, so there is a higher
maximization of the total usage of IPv4/port resources.</t><!--** I'm not familiar with EAMT - does this require operator side intervention? Maybe a good way to deal with this section would be to divide what is possible without and with operator intervention? --> <!-- GL: I am currently working on benchmarking three differen stateless NAT64 implementations: TAYGA, Jool and map646. I set the mappings in their configurations files. Thus, I would say: yes, it requires... --> IPv4 port resources.</t>
</section>
<section anchor="supp_imp" title="Support and Implementations"> <section title="Vendor Support"><!-- In a future update, this can be expanded to include implementations ofdata plane and provisioning mechanisms, as to be useful, you really need both--> numbered="true" toc="default">
<name>Support and Implementations</name>
<section numbered="true" toc="default">
<name>Vendor Support</name>
<t>In general, router vendors support AFTR, MAP-E/T BR MAP-E BR, MAP-T
BR, and NAT64. Load balancer Vendors of load balancers and firewall vendors firewalls usually
support NAT64 as well, well while not all of them have support for
the other protocols.</t>
<t>A 464XLAT client (CLAT) is implemented in Windows 10, Linux
(including Android), Windows Mobile, Chrome OS OS, and iOS, but it is
not available in macOS 12.3.1.</t>
<t>The remaining four solutions are commonly deployed as functions
in the CE device only, however in general, except DS-Lite, only; however, the vendors vendors' support is poor.</t> <t>The poor in
general (except for DS-Lite).</t>
<t> OpenWRT Linux based is a Linux-based open-source OS designed for CE devices devices. It
offers a number of different 'opkg' packages as part of the distribution: <list style="symbols"> <t>'464xlat'
</t>
<ul spacing="normal">
<li>'464xlat' enables support for 464XLAT CLAT functionality</t> <t>'ds-lite' functionality.</li>
<li>'ds-lite' enables support for DSLite B4 functionality</t> <t>'map' functionality.</li>
<li>'map' enables support for MAP-E and lw4o6 CE functionality</t> <t>'map-t'
functionality.</li>
<li>'map-t' enables support for MAP-T CE functionality</t> </list></t> functionality.</li>
</ul>
<t>At the time of publication publication, some free open-source implementations
exist for the operator side operator-side functionality: <list style="symbols"> <t>Jool
</t>
<ul spacing="normal">
<li>Jool <xref target="jool"/> target="JOOL" format="default"/> (CLAT, NAT64, EAMT, MAP-T CE, MAP-T BR).</t> <t>VPP/fd.io BR)</li>
<li>VPP/fd.io <xref target="vpp"/> target="VPP" format="default"/> (MAP-BR, lwAFTR, CGN, CLAT, NAT64).</t> <t>Snabb NAT64)</li>
<li>Snabb <xref target="snabb"/> (lwAFTR).</t> <t>AFTR target="SNABB" format="default"/> (lwAFTR)</li>
<li>AFTR <xref target="aftr"/> target="AFTR" format="default"/> (DSLite AFTR).</t> </list></t> AFTR)</li>
</ul>
</section>
<section anchor="cell_broad_supp" title="Support numbered="true" toc="default">
<name>Support in Cellular and Broadband Networks"> Networks</name>
<t>Several cellular networks use 464XLAT, whereas there are no
deployments of the four other technologies in cellular networks, as
they are neither standardised standardized nor implemented in UE devices.</t>
<t>In broadband networks, there are some deployments of 464XLAT, MAP-E MAP-E,
and MAP-T.
Lw4o6 and DS-Lite have more deployments, with DS-Lite
being the most common, but deployments of lw4o6 taking over have been rapidly
increasing in the last years.</t> few years.
</t>
<t>Please refer to Table Tables 2 and Table 3 of <xref target="LEN2019"/> target="LEN2019" format="default"/>
for a limited set of deployment information.</t><!--*** I still see DS-Lite as being overwhelmingly the most common technology here. Do we have any deployment information that was can used here? Do we have any figures about number of deployments of each type to back the statements up? --><!-- GL: I am working on the revison of a paper, which has some tables on the deployment of different IPv6 transition technologies. Ihope that we can cite it in the next version. Now (July 8, 2020) I have added the reference. --> information.</t>
</section>
<section anchor="code_size" title="Implementation numbered="true" toc="default">
<name>Implementation Code Sizes"> Sizes</name>
<t>As a hint to the relative complexity of the mechanisms, the following
code sizes are reported from the OpenWRT
implementations of each technology are 17kB, 35kB, 15kB, 35kB, 17 kB, 35 kB, 15 kB, 35 kB, and 48kB
48 kB for 464XLAT, lw4o6,
DS-Lite, MAP-E, MAP-T, and lw4o6, MAP-T, respectively (https://openwrt.org/packages/start).</t><!-- Worth noting that for many of the above cases, these are for provisioning.Netfilter is doing that actual work for NAT and encap/decap. --><!-- GL: I think, Netfiler only provides you with hooks, but it does not perform the encap/decap. -->
(see <eref target="https://openwrt.org/packages/start" brackets="angle"/>).</t>
<t>We note that the support for all five technologies requires a much less
smaller code size than the total sum of the above quantities, because
they contain a lot of common functions (data (e.g., data plane is shared among
several of them).</t>
</section>
</section>
<section title="Typical numbered="true" toc="default">
<name>Typical Deployment and Traffic Volume Considerations"> Considerations</name>
<section title="Deployment Possibilities"> numbered="true" toc="default">
<name>Deployment Possibilities</name>
<t>Theoretically, all five IPv4aaS technologies could be
used together with DNS64 + stateful NAT64, as it is done in 464XLAT.
In this case case, the CE router would treat the traffic between an
IPv6-only client and IPv4-only server as normal IPv6 traffic, and
the stateful NAT64 gateway would do a single translation, thus
offloading this kind of traffic from the IPv4aaS technology. The
cost of this solution would be the need for deploying to also deploy DNS64 +
stateful NAT64.</t>
<t>However, this has not been implemented in clients or actual
deployments, so only 464XLAT always uses this optimization optimization, and the
other four solutions do not use it at all.</t>
</section>
<section title="Cellular numbered="true" toc="default">
<name>Cellular Networks with 464XLAT"> 464XLAT</name>
<t>Figures from existing deployments (end (through the end of 2018), 2018) show that
the typical traffic volumes in an IPv6-only cellular network, network when
464XLAT technology is used together with DNS64, are: <list style="symbols"> <t>75% DNS64:
</t>
<ul spacing="normal">
<li>75% of traffic is IPv6 end-to-end (no translation)</t> <t>24% translation).</li>
<li>24% of traffic uses DNS64 + NAT64 (1 translation)</t> <t>Less (one translation).</li>
<li>Less than 1% of traffic uses the CLAT in addition to NAT64 (2
(two translations), due to an IPv4 socket and/or IPv4 literal.</t> </list></t> literal.</li>
</ul>
<t>Without using DNS64, 25% of the traffic would undergo double
translation.</t> <!-- Can we point to the source of this data? Also, are there tangible benefits to only going through single translation that can be described. --> <!-- GL: I have also asked for it, but no one took the resposibility to name the company, where they were taken from. --> <!-- Jordi: This info was provided in v6ops by Cameron (T-Mobile) Oct. 2018 it is factual data, what I'm not sure is if he will agree to name the network in an RFC, or if it is good at all to cite networks in a document. I've asked him already a couple of days ago, if he has actual data to share, so we can publish 2018 and 2020 comparison. -->
</section>
<section title="Wireline numbered="true" toc="default">
<name>Wireline Networks with 464XLAT"> <t>Figures 464XLAT</name>
<t> Figures from several existing deployments (end (through the end of
2020), mainly with residential customers, show that the ranges of typical
traffic volumes in an IPv6-only network, when 464XLAT is used with DNS64, are in the following ranges: <list style="symbols"> <t>65%-85%
DNS64:
</t>
<ul spacing="normal">
<li>65%-85% of traffic is IPv6 end-to-end (no translation)</t> <t>14%-34% translation).</li>
<li>14%-34% of traffic uses DNS64 + NAT64 (1 translation)</t> <t>Less (one translation).</li>
<li>Less than 1-2% of traffic uses the CLAT in addition to NAT64 (2
(two translations), due to an IPv4 socket and/or IPv4 literal.</t> </list></t> literal.</li>
</ul>
<t>Without using DNS64, 16%-35% of the traffic would undergo double
translation.</t> <t>This
<t>
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 which that are already IPv6 enabled (Google/Youtube,
(Google/YouTube, Netflix, Facebook, Akamai, etc) etc.) typically account for the 65-85%
of the traffic in the network, so network. Thus, when the subscribers are IPv6 enabled,
about the same figures percentage of traffic will become IPv6.</t> <!-- Jordi: This info comes from several of my customers, that's why is a "range" not an average, I think it makes more sense to talk about ranges as it shows how other networks could be around similar figures. However I've no permission to cite them, and again, I don't think is good to name specific networks in an RFC? --> IPv6.
</t>
</section>
</section>
<section title="Load Sharing"> 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 load-sharing mechanism. ECMP
(Equal-Cost Multi-Path) Multipath) load sharing can be used for all technologies, however
technologies; however, stateful technologies will be impacted by
changes in network topology or device failure.</t> <!--- I'm not sure the last part of that paragraph is true. I've added some text describing the problems below --> <!--- GL: It is also from Ole Troan. You can find it in one of the e-mails on the v6ops mailing list. -->
<t>Technologies utilizing DNS64 can also distribute load across
PLAT/AFTR devices, evenly or unevenly, by using different prefixes.
Different network specific network-specific prefixes can be distributed for
subscribers in appropriately sized segments (like split-horizon DNS,
also called DNS views).</t> "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,
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. As each Each CGN maintains a
stateful table of active client sessions, and this table may need to be syncronized
synchronized between CGN instances. This is necessary for two reasons:
</t> <t><list style="symbols"> <t>To
<ul spacing="normal">
<li>To prevent all active customer sessions from being dropped in the event
of a CGN node failure.</t> <t>To 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.</t> </list></t> nodes.</li>
</ul>
</section>
<section anchor="logging" title="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, time; therefore,
logging is necessary to meet data retention data-retention laws. Each entry in the PLAT/AFTR's
PLAT/AFTR generates a logging entry. As discussed in
<xref target="port_num_eff"/>, target="port_num_eff" format="default"/>, a client may open hundreds of sessions
during common tasks such as web-browsing, 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 comply
with data retention 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),
MAP-T) or binding-table 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 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). As stateless Stateless technologies do not have a centralized stateful
element which that customer traffic needs to pass through, so if data retention
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"/> target="RFC7422" format="default"/> was proposed as a solution to
reduce the resource consumption of logging.</t>
<t>Please also refer to Section 4 of <xref target="RFC6888"/> target="RFC6888" sectionFormat="of" section="4"/> for more information about
requirements for logging Carrier-Grade NAT CGN gateways.</t>
</section>
<section anchor="optimization" title="Optimization numbered="true" toc="default">
<name>Optimization for IPv4-only devices/applications"> 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, necessarily be
encapsulated/decapsulated (in the case of DS-Lite, lw4o6 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 lwAFTR, or BR, depending on the specific
transition mechanism being used.</t>
<t>Even if those services are directly connected to the operator network (for example, CDNs, caches),
(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, in 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"/>.</t> <t>Using those optimizations, because target="I-D.ietf-v6ops-464xlat-optimization"
format="default"/>.
</t>
<t>
Because the NAT46 has already translated
the IPv4-only flow to IPv6, IPv6 and the services are dual-stack, they can using these
optimizations allows the services to
be reached without the need to translate them the flow back to IPv4.</t> IPv4.
</t>
</section>
</section>
<section anchor="performance" title="Performance Comparison"> 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"/>.</t> target="RFC8219" format="default"/>.</t>
<t>The Dual DUT Setup dual Device Under Test (DUT) setup of <xref target="RFC8219"/> target="RFC8219" format="default"/> makes it possible to use the existing measurement devices compliant with
"Benchmarking Methodology for Network Interconnect Devices"
<xref target="RFC2544"/> compliant measurement devices, target="RFC2544" format="default"/>; however,
this solution has two kinds of limitations: <list style="symbols"> <t>Dual
</t>
<ul spacing="normal">
<li>Dual DUT setup has the drawback that the performances of the CE
and of the ISP side ISP-side device (e.g. (e.g., the CLAT and the 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.</t> <t>Measurements
bottleneck.</li>
<li>Measurement procedures for PDV and IPDV Packet Delay Variation (PDV)
and Inter-Packet Delay Variation (IPDV) measurements are
missing from the legacy devices, and the old measurement
procedure for Latency latency has been redefined in <xref target="RFC8219"/>.</t> </list> </t>
target="RFC8219" format="default"/>.</li>
</ul>
<t>The Single single DUT Setup setup of <xref target="RFC8219"/> target="RFC8219" format="default"/>
makes it possible to benchmark the selected device separately, but it
either requires a special Tester is required or some trick is need, needed if we want to
use legacy Testers. An example for the latter is our stateless NAT64
measurements testing Througput Throughput and Frame Loss Rate using a legacy
commercial Tester <xref target="RFC5180"/> target="LEN2020a" format="default"/> that is
compliant commercial tester with <xref target="LEN2020a"/></t> target="RFC5180" format="default"/>.</t>
<t>Siitperf, an <xref target="RFC8219"/> compliant a DPDK-based
software Tester that is compliant with <xref target="RFC8219" format="default"/> and used for benchmarking stateless NAT64 gateways gateways, has been
developed recently and it recently. Siitperf is available from GitHub
<xref target="SIITperf"/> target="SIITPERF" format="default"/> as free software and is documented in
<xref target="LEN2021"/>. target="LEN2021" format="default"/>. Originally, it literally followed the test
frame format of <xref target="RFC2544"/> target="RFC2544" format="default"/>, including "hard-wired" source and
destination port numbers, and then it has been was complemented with the random
pseudorandom port feature required by <xref target="RFC4814"/>. target="RFC4814" format="default"/>. The new
version is documented in <xref target="LEN2020b"/></t> target="LEN2020b" format="default"/>.</t>
<t>Further DPDK-based, <xref target="RFC8219"/> compliant DPDK-based software testers Testers that are compliant with <xref target="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 measurements, and results will
be made available in <xref target="I-D.lencse-v6ops-transition-benchmarking"/>. target="I-D.lencse-v6ops-transition-benchmarking" format="default"/>.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements"> <t>The authors would like to thank Ole Troan, Warren Kumari, Dan Romascanu, Brian Trammell, Joseph Salowey, Roman Danyliw, Erik Kline, Lars Eggert, Zaheduzzaman Sarker, Robert Wilton, Eric Vyncke and Martin Duke for their review of this draft and acknowledge the inputs of Mark Andrews, Edwin Cordeiro, Fred Baker, Alexandre Petrescu, Cameron Byrne, Tore Anderson, Mikael Abrahamsson, Gert Doering, Satoru Matsushima, Yutianpeng (Tim), Mohamed Boucadair, Nick Hilliard, Joel Jaeggli, Kristian McColm, Nick Hilliard, Tom Petch, Yannis Nikolopoulos, Havard Eidnes, Yann-Ju Chu, Barbara Stark, Vasilenko Eduard, Chongfeng Xie, Henri Alves de Godoy, Magnus Westerlund, Michael Tuexen, Philipp S. Tiesel, Brian E Carpenter and Joe Touch.</t> </section> <!-- Possibly a 'Contributors' section ... --> <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document does not make any request to IANA.</t> has no IANA actions.</t>
</section>
<section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
<name>Security Considerations</name>
<t>As discussed in section 4.7, <xref target="logging"></xref>, the different technologies 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 noticed noted that
those issues are not specific to the IPv4aaS IPv6 transition technologies, technologies
but in general apply to logging functionalities.</t> functionalities in general.</t>
<t>For all five technologies, the CE device typically contains a DNS proxy.
However, the user may change DNS settings. If it this happens and lw4o6, MAP-E MAP-E,
and MAP-T are used with a significantly restricted port set, which set (which is
required for an efficient public IPv4 address sharing, sharing), the entropy of the
source ports is significantly lowered (e.g. (e.g., from 16 bits to 10 bits, bits when
1024 port numbers are assigned to each subscriber) subscriber), and thus these
technologies are thus theoretically less resilient against cache poisoning, see poisoning (see
<xref target="RFC5452"/>. target="RFC5452" format="default"/>). However, an efficient cache poisoning attack
requires that the subscriber operates an 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 as to be low.</t>
<t>IPv4aaS technologies based on encapsulation have not no DNSSEC
implications. However, those based on translation may have implications
as discussed in Section 4.1 of <xref target="RFC8683"/>.</t> 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"/> target="LEN2018" format="default"/> is planned.</t>
<t>As the first step, an initial security analysis of 464XLAT was
done in <xref target="Azz2021"/>.</t> target="AZZ2021" format="default"/>.</t>
<t>The implementers of any of the five IPv4aaS solutions should consult the
Security Considerations of the respective RFCs documenting them.</t>
</section>
</middle>
<back>
<displayreference target="I-D.ietf-v6ops-464xlat-optimization" to="OP-464XLAT/MAP-T"/>
<displayreference target="I-D.ietf-tsvwg-natsupp" to="NAT-SUPP"/>
<displayreference target="I-D.lencse-v6ops-transition-scalability" to="IPv4aaS-SCALE-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.2473.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2544.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2663.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4814.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5180.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5452.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6052.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6146.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6147.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6180.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6269.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6333.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6346.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6519.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6877.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6887.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6888.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6889.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7050.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7269.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7341.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7393.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7422.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7757.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7915.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7596.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7597.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7599.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7605.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8114.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8215.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8219.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8415.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8512.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8513.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8658.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8676.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8683.xml"/>
</references>
<references>
<name>Informative References</name>
<!-- *****BACK MATTER ***** [I-D.ietf-v6ops-464xlat-optimization] IESG state Expired --> <back>
<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-optimization-03" />
<format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-v6ops-464xlat-optimization-03.txt" />
</reference>
<!-- References split into informative and normative [I-D.ietf-tsvwg-natsupp] IESG state Expired -->
<xi:include
href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-tsvwg-natsupp.xml"/>
<!-- There are 2 ways to insert reference entries from the citation libraries: 1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown) 2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml") Both are cited textually in the same manner: by using xref elements. If you use the PI option, xml2rfc will, by default, try to find included files in the same directory as the including file. You can also define the XML_LIBRARY environment variable with a value containing a set of directories to search. These can be either in the local filing system or remote ones accessed by http (http://domain/dir/... ).--> <references title="Normative References"> <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?--> &RFC2473; &RFC2544; &RFC2663; &RFC4814; &RFC5180; &RFC5452;<!--&RFC6050;--> &RFC6052; &RFC6146; &RFC6147; &RFC6180; &RFC6269; &RFC6333; &RFC6346; &RFC6519; &RFC6877; &RFC6887; &RFC6888; &RFC6889; &RFC7050; &RFC7269; &RFC7341; &RFC7393; &RFC7422; &RFC7757;<!--&RFC7857;--> &RFC7915; &RFC7596; &RFC7597; &RFC7599; &RFC7605; &RFC7950; &RFC8114; &RFC8215; &RFC8219; &RFC8415; &RFC8512; &RFC8513; &RFC8658; &RFC8676; &RFC8683; </references> <references title="Informative References"> [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"/>
<!-- Here we use entities that we defined at the beginning. [I-D.lencse-v6ops-transition-benchmarking] IESG state I-D Exists --> <?rfc include='reference.I-D.ietf-v6ops-464xlat-optimization'?> <?rfc include='reference.I-D.ietf-tsvwg-natsupp'?> <?rfc include='reference.I-D.lencse-v6ops-transition-scalability'?> <?rfc include='reference.I-D.lencse-v6ops-transition-benchmarking'?>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.lencse-v6ops-transition-benchmarking.xml"/>
<reference anchor="Azz2021" anchor="AZZ2021" target="https://www.infocommunications.hu/2021_4_2">
<front>
<title>Identification of the Possible Security Issues of the
464XLAT IPv6 Transition Technology
</title>
<author initials="A." surname="Al-Azzawi"> <organization></organization>
<organization/>
</author>
<author initials="G." surname="Lencse"> <organization></organization>
<organization/>
</author>
<date month="Dec" month="December" year="2021"/>
</front>
<seriesInfo name="" value="Infocommunications name="DOI" value="10.36244/ICJ.2021.4.2"/>
<refcontent>Infocommunications Journal, vol. Vol. 13, no. No. 4, pp. 10-18"/> <seriesInfo name="" value="DOI: 10.36244/ICJ.2021.4.2"/> 10-18</refcontent>
</reference>
<reference anchor="LEN2018" target="http://www.hit.bme.hu/~lencse/publications/ECS-2018-Methodology-revised.pdf">
<front>
<title>Methodology for the identification of potential security issues
of different IPv6 transition technologies: Threat analysis of DNS64 and
stateful NAT64
</title>
<author initials="G." surname="Lencse"> <organization></organization>
<organization/>
</author>
<author initials="Y." surname="Kadobayashi"> <organization></organization>
<organization/>
</author>
<date day="1" month="Aug" month="August" year="2018"/>
</front>
<seriesInfo name="" value="Computers name="DOI" value="10.1016/j.cose.2018.04.012"/>
<refcontent>Computers & Security (Elsevier), vol. Security, Vol. 77, no. No. 1, pp. 397-411"/> <seriesInfo name="" value="DOI: 10.1016/j.cose.2018.04.012"/> 397-411</refcontent>
</reference>
<reference anchor="LEN2019" target="http://www.hit.bme.hu/~lencse/publications/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></organization>
<organization/>
</author>
<author initials="Y." surname="Kadobayashi"> <organization></organization>
<organization/>
</author>
<date day="1" month="Oct" year="2019" /> month="October" year="2019"/>
</front>
<seriesInfo name="" value="IEICE name="DOI" value="10.1587/transcom.2018EBR0002"/>
<refcontent>IEICE Transactions on Communications, vol. Vol. E102-B, no.10, No. 10, pp. 2021-2035."/> <seriesInfo name="" value="DOI: 10.1587/transcom.2018EBR0002"/> 2021-2035</refcontent>
</reference>
<reference anchor="LEN2020a" target="https://link.springer.com/article/10.1007/s11235-020-00681-x">
<front>
<title>Benchmarking Stateless stateless NAT64 Implementations implementations with a Standard Tester standard tester
</title>
<author initials="G." surname="Lencse"> <organization></organization>
<organization/>
</author>
<date day="15" month="Jun" year="2020" /> month="June" year="2020"/>
</front>
<seriesInfo name="" value="Telecommunication name="DOI" value="10.1007/s11235-020-00681-x"/>
<refcontent>Telecommunication Systems, vol. Vol. 75, pp. 245-257"/> <seriesInfo name="" value="DOI: 10.1007/s11235-020-00681-x"/> 245-257</refcontent>
</reference>
<reference anchor="LEN2020b" target="http://ijates.org/index.php/ijates/article/view/291"> target="https://ijates.org/index.php/ijates/article/view/291">
<front>
<title>Adding RFC 4814 Random Port Feature to Siitperf: Design, Implementation and
Performance Estimation
</title>
<author initials="G." surname="Lencse"> <organization></organization>
<organization/>
</author>
<date day="" month="" year="2020" /> year="2020"/>
</front>
<seriesInfo name="" value="International name="DOI" value="10.11601/ijates.v9i3.291"/>
<refcontent>International Journal of Advances in Telecommunications, Electrotechnics, Signals and Systems, vol Vol. 9, no No. 3, pp. 18-26"/> <seriesInfo name="" value="DOI: 10.11601/ijates.v9i3.291"/> 18-26</refcontent>
</reference>
<reference anchor="LEN2021" target="https://www.jstage.jst.go.jp/article/transcom/E104.B/2/E104.B_2019EBN0010/_article"> anchor="LEN2021">
<front>
<title>Design and Implementation of a Software Tester for Benchmarking Stateless NAT64 Gateways
</title>
<author initials="G." surname="Lencse"> <organization></organization>
<organization/>
</author>
<date day="" month="" year="2021" /> year="2021"/>
</front>
<seriesInfo name="" value="IEICE name="DOI" value="10.1587/transcom.2019EBN0010"/>
<refcontent>IEICE Transactions on Communications"/> <seriesInfo name="" value="DOI: 10.1587/transcom.2019EBN0010"/> Communications, Vol. E104.B, Issue 2, pp. 128-140</refcontent>
</reference>
<reference anchor="MEX2022" anchor="JOOL-MAPT" target="https://www.jool.mx/en/run-mapt.html">
<front> <title>Jool: Siit and NAT64</title> <author initials="" surname="Jool Developers"> <organization>NIC Mexico</organization>
<title>MAP-T Run</title>
<author>
</author> <date day="" month="" year="2022" />
</front> <seriesInfo name="" value="Documentation of Jool MAP-T implementation"/>
</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 Transformation Schemes
</title>
<author initials="S." surname="Miyakawa"> <organization></organization>
<organization/>
</author>
<date month="May" year="2010"/>
</front>
<seriesInfo name="" value="IEICE Trans. Commun., vol.E93-B, no.5, name="DOI" value="10.1587/transcom.E93.B.1078"/>
<refcontent>IEICE Transactions on Communications, Vol. E93-B, Issue 5, pp. 1078-1084"/> <seriesInfo name="" value="DOI:10.1587/transcom.E93.B.10"/> 1078-1084</refcontent>
</reference>
<reference anchor="REP2014" target="http://www.hit.bme.hu/~lencse/publications/TSP-2014-PC.pdf">
<front>
<title>Port number consumption Number Consumption of the NAT64 IPv6 transition technology Transition Technology
</title>
<author initials="S." surname="Repas"> <organization></organization> surname="Répás">
<organization/>
</author>
<author initials="T." surname="Hajas"> <organization></organization>
<organization/>
</author>
<author initials="G." surname="Lencse"> <organization></organization>
<organization/>
</author>
<date month="July" year="2014"/>
</front>
<seriesInfo name="" value="Proc. 37th Internat. Conf. name="DOI" value="10.1109/TSP.2015.7296411"/>
<refcontent>37th International Conference on Telecommunications and Signal Processing (TSP 2014), Berlin, Germany"/> <seriesInfo name="" value="DOI: 10.1109/TSP.2015.7296411"/> Processing</refcontent>
</reference>
<reference anchor="SIITperf" anchor="SIITPERF" target="https://github.com/lencsegabor/siitperf">
<front>
<title>Siitperf: an RFC 8219 compliant SIIT (stateless NAT64)
tester</title> <author initials="G." surname="Lencse"> <organization></organization> </author>
<author/>
<date month="November" year="2019"/> month="February" year="2021"/>
</front>
<refcontent>commit bdce0f</refcontent>
</reference>
<reference anchor="TR-069" target="https://www.broadband-forum.org/technical/download/TR-069.pdf">
<front> <title>TR-069: CPE
<title>CPE WAN Management Protocol</title> <author initials="" surname="BroadBand Forum"> <organization></organization>
<author>
<organization>Broadband Forum</organization>
</author>
<date month="June" year="2020"/>
</front>
<seriesInfo name="Technical Report" value="TR-069"/>
</reference>
<reference anchor="jool" anchor="JOOL" target="http://www.jool.mx">
<front> <title>Open Source
<title>Jool: SIIT and NAT64 for Linux</title> & NAT64</title>
<author> <organization>NIC.MX</organization>
</author> <date year="2022"/>
</front>
</reference>
<reference anchor="vpp" target="https://gerrit.fd.io/r/#/admin/projects/"> anchor="VPP" target="https://wiki.fd.io/index.php?title=VPP&oldid=11809">
<front> <title>VPP Implementations of IPv6-only with IPv4aaS</title>
<title>VPP</title>
<author>
</author>
<date month="July" year="2022"/>
</front>
</reference>
<reference anchor="snabb" anchor="SNABB" target="https://github.com/Igalia/snabb">
<front>
<title>Snabb implementation of lwAFTR</title>
<author> <organization>Igalia</organization>
</author>
<date month="January" year="2022"/>
</front>
<refcontent>commit 1ef72ce</refcontent>
</reference>
<reference anchor="aftr" target="https://www.isc.org/downloads/"> anchor="AFTR" target="https://downloads.isc.org/isc/aftr/">
<front>
<title>ISC implementation Implementation of AFTR</title>
<author>
<organization>ISC</organization>
</author> <date year="2022"/>
</front>
</reference>
</references>
</references>
<section anchor="change_log" title="Change Log"> <section title="01 - 02"> <t> <list style="symbols"> <t>Ian Farrer has joined us as an author.</t> <t>Restructuring: the description of the five IPv4aaS technologies was moved to a separate section.</t> <t>More details and figures were added to the description of the five IPv4aaS technologies.</t> <t>Section titled "High-level Architectures and their Consequences" has been completely rewritten.</t> <t>Several additions/clarification throughout Section titled "Detailed Analysis".</t> <t>Section titled "Performance Analysis" was dropped due to lack of results yet.</t> <t>Word based text ported to XML.</t> <t>Further text cleanups, added text on state sync and load balancing. Additional comments inline that should be considered for future updates.</t> </list> </t> </section> <section title="02 - 03"> <t> <list style="symbols"> anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The suggestions of Mohamed Boucadair are incorporated.</t> <t>New considerations regarding possible optimizations.</t> </list> </t> </section> <section title="03 - 04"> <t> <list style="symbols"> <t>Section titled "Performance Analysis" was added. It mentions our new benchmarking tool, siitperf, and highlights our plans.</t> <t>Some references were updated or added.</t> </list> </t> </section> <section title="04 - 05"> <t> <list style="symbols"> <t>Some references were updated or added.</t> </list> </t> </section> <section title="05 - 06"> <t> <list style="symbols"> <t>Some references were updated or added.</t> </list> </t> </section> <section title="06 - 00-WG Item"> <t> <list style="symbols"> <t>Stats dated and added for Broadband deployments.</t> <t>Other clarifications and references.</t> <t>New section: IPv4 Pool Size.</t> <t>Typos.</t> </list> </t> </section> <section title="00 - 01"> <t>To facilitate WGLC, the unfinished parts were moved authors would like to two new drafts: <list style="symbols"> <t>New I-D for scale up measurements. (Including the results of iptables.)</t> <t>New I-D 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 benchmarking measurements. (Only a stub.)</t> </list> </t> </section> <section title="01 - 02"> <t>Update on the basis of the AD review.</t> <t>Update their review of the references.</t> </section> <section title="02 - 03"> <t>Nits this draft and changes from IESG review.</t> <t>Updated wrong reference to PCP.</t> </section> <section title="03 - 04"> <t>Update to address acknowledge
the comments inputs of further reviews.</t> <t>Updated Acknowledgements.</t> </section> <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>
</back>
</rfc>