< draft-ietf-v6ops-transition-comparison-02.txt   draft-ietf-v6ops-transition-comparison-03.txt >
v6ops G. Lencse v6ops G. Lencse
Internet-Draft BUTE Internet-Draft BUTE
Intended status: Informational J. Palet Martinez Intended status: Informational J. Palet Martinez
Expires: 4 September 2022 The IPv6 Company Expires: 7 October 2022 The IPv6 Company
L. Howard L. Howard
Retevia Retevia
R. Patterson R. Patterson
Sky UK Sky UK
I. Farrer I. Farrer
Deutsche Telekom AG Deutsche Telekom AG
3 March 2022 5 April 2022
Pros and Cons of IPv6 Transition Technologies for IPv4aaS Pros and Cons of IPv6 Transition Technologies for IPv4aaS
draft-ietf-v6ops-transition-comparison-02 draft-ietf-v6ops-transition-comparison-03
Abstract Abstract
Several IPv6 transition technologies have been developed to provide Several IPv6 transition technologies have been developed to provide
customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only
access and/or core network. All these technologies have their access and/or core network. All these technologies have their
advantages and disadvantages, and depending on existing topology, advantages and disadvantages, and depending on existing topology,
skills, strategy and other preferences, one of these technologies may skills, strategy and other preferences, one of these technologies may
be the most appropriate solution for a network operator. be the most appropriate solution for a network operator.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 4 September 2022. This Internet-Draft will expire on 7 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Overview of the Technologies . . . . . . . . . . . . . . . . 4 2. Overview of the Technologies . . . . . . . . . . . . . . . . 4
2.1. 464XLAT . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. 464XLAT . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Dual-Stack Lite . . . . . . . . . . . . . . . . . . . . . 5 2.2. Dual-Stack Lite . . . . . . . . . . . . . . . . . . . . . 5
2.3. Lightweight 4over6 . . . . . . . . . . . . . . . . . . . 6 2.3. Lightweight 4over6 . . . . . . . . . . . . . . . . . . . 6
2.4. MAP-E . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4. MAP-E . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5. MAP-T . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.5. MAP-T . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. High-level Architectures and their Consequences . . . . . . . 8 3. High-level Architectures and their Consequences . . . . . . . 8
3.1. Service Provider Network Traversal . . . . . . . . . . . 8 3.1. Service Provider Network Traversal . . . . . . . . . . . 8
3.2. Network Address Translation . . . . . . . . . . . . . . . 9 3.2. Network Address Translation . . . . . . . . . . . . . . . 9
3.3. IPv4 Address Sharing . . . . . . . . . . . . . . . . . . 10 3.3. IPv4 Address Sharing . . . . . . . . . . . . . . . . . . 10
3.4. IPv4 Pool Size Considerations . . . . . . . . . . . . . . 11 3.4. IPv4 Pool Size Considerations . . . . . . . . . . . . . . 11
3.5. CE Provisioning Considerations . . . . . . . . . . . . . 13 3.5. CE Provisioning Considerations . . . . . . . . . . . . . 13
3.6. Support for Multicast . . . . . . . . . . . . . . . . . . 14 3.6. Support for Multicast . . . . . . . . . . . . . . . . . . 13
4. Detailed Analysis . . . . . . . . . . . . . . . . . . . . . . 14 4. Detailed Analysis . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Architectural Differences . . . . . . . . . . . . . . . . 14 4.1. Architectural Differences . . . . . . . . . . . . . . . . 14
4.1.1. Basic Comparison . . . . . . . . . . . . . . . . . . 14 4.1.1. Basic Comparison . . . . . . . . . . . . . . . . . . 14
4.2. Tradeoff between Port Number Efficiency and Stateless 4.2. Tradeoff between Port Number Efficiency and Stateless
Operation . . . . . . . . . . . . . . . . . . . . . . . . 14 Operation . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3. Support for Public Server Operation . . . . . . . . . . . 17 4.3. Support for Public Server Operation . . . . . . . . . . . 17
4.4. Support and Implementations . . . . . . . . . . . . . . . 18 4.4. Support and Implementations . . . . . . . . . . . . . . . 18
4.4.1. OS Support . . . . . . . . . . . . . . . . . . . . . 18 4.4.1. OS Support . . . . . . . . . . . . . . . . . . . . . 18
4.4.2. Support in Cellular and Broadband Networks . . . . . 18 4.4.2. Support in Cellular and Broadband Networks . . . . . 18
4.4.3. Implementation Code Sizes . . . . . . . . . . . . . . 19 4.4.3. Implementation Code Sizes . . . . . . . . . . . . . . 19
skipping to change at page 3, line 4 skipping to change at page 2, line 52
4.4.1. OS Support . . . . . . . . . . . . . . . . . . . . . 18 4.4.1. OS Support . . . . . . . . . . . . . . . . . . . . . 18
4.4.2. Support in Cellular and Broadband Networks . . . . . 18 4.4.2. Support in Cellular and Broadband Networks . . . . . 18
4.4.3. Implementation Code Sizes . . . . . . . . . . . . . . 19 4.4.3. Implementation Code Sizes . . . . . . . . . . . . . . 19
4.5. Typical Deployment and Traffic Volume Considerations . . 19 4.5. Typical Deployment and Traffic Volume Considerations . . 19
4.5.1. Deployment Possibilities . . . . . . . . . . . . . . 19 4.5.1. Deployment Possibilities . . . . . . . . . . . . . . 19
4.5.2. Cellular Networks with 464XLAT . . . . . . . . . . . 19 4.5.2. Cellular Networks with 464XLAT . . . . . . . . . . . 19
4.5.3. Wireline Networks with 464XLAT . . . . . . . . . . . 20 4.5.3. Wireline Networks with 464XLAT . . . . . . . . . . . 20
4.6. Load Sharing . . . . . . . . . . . . . . . . . . . . . . 20 4.6. Load Sharing . . . . . . . . . . . . . . . . . . . . . . 20
4.7. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.7. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.8. Optimization for IPv4-only devices/applications . . . . . 22 4.8. Optimization for IPv4-only devices/applications . . . . . 22
5. Performance Comparison . . . . . . . . . . . . . . . . . . . 22 5. Performance Comparison . . . . . . . . . . . . . . . . . . . 22
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1. Normative References . . . . . . . . . . . . . . . . . . 24 9.1. Normative References . . . . . . . . . . . . . . . . . . 24
9.2. Informative References . . . . . . . . . . . . . . . . . 28 9.2. Informative References . . . . . . . . . . . . . . . . . 28
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 30 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 30
A.1. 01 - 02 . . . . . . . . . . . . . . . . . . . . . . . . . 30 A.1. 01 - 02 . . . . . . . . . . . . . . . . . . . . . . . . . 30
A.2. 02 - 03 . . . . . . . . . . . . . . . . . . . . . . . . . 30 A.2. 02 - 03 . . . . . . . . . . . . . . . . . . . . . . . . . 31
A.3. 03 - 04 . . . . . . . . . . . . . . . . . . . . . . . . . 30 A.3. 03 - 04 . . . . . . . . . . . . . . . . . . . . . . . . . 31
A.4. 04 - 05 . . . . . . . . . . . . . . . . . . . . . . . . . 30 A.4. 04 - 05 . . . . . . . . . . . . . . . . . . . . . . . . . 31
A.5. 05 - 06 . . . . . . . . . . . . . . . . . . . . . . . . . 30 A.5. 05 - 06 . . . . . . . . . . . . . . . . . . . . . . . . . 31
A.6. 06 - 00-WG Item . . . . . . . . . . . . . . . . . . . . . 31 A.6. 06 - 00-WG Item . . . . . . . . . . . . . . . . . . . . . 31
A.7. 00 - 01 . . . . . . . . . . . . . . . . . . . . . . . . . 31 A.7. 00 - 01 . . . . . . . . . . . . . . . . . . . . . . . . . 31
A.8. 01 - 02 . . . . . . . . . . . . . . . . . . . . . . . . . 31 A.8. 01 - 02 . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 A.9. 02 - 03 . . . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
As the deployment of IPv6 becomes more prevalent, it follows that As the deployment of IPv6 becomes more prevalent, it follows that
network operators will move to building single-stack IPv6 core and network operators will move to building single-stack IPv6 core and
access networks to simplify network planning and operations. access networks to simplify network planning and operations.
However, providing customers with IPv4 services continues to be a However, providing customers with IPv4 services continues to be a
requirement for the foreseeable future. To meet this need, the IETF requirement for the foreseeable future. To meet this need, the IETF
has standardized a number of different IPv4aaS technologies for this has standardized a number of different IPv4aaS technologies for this
[LEN2019] based on differing requirements and deployment scenarios. [LEN2019] based on differing requirements and deployment scenarios.
skipping to change at page 4, line 8 skipping to change at page 4, line 8
3. lw4o6 (Lightweight 4over6) [RFC7596] 3. lw4o6 (Lightweight 4over6) [RFC7596]
4. MAP-E [RFC7597] 4. MAP-E [RFC7597]
5. MAP-T [RFC7599] 5. MAP-T [RFC7599]
We note that [RFC6180] gives guidelines for using IPv6 transition We note that [RFC6180] gives guidelines for using IPv6 transition
mechanisms during IPv6 deployment addressing a much broader topic, mechanisms during IPv6 deployment addressing a much broader topic,
whereas this document focuses on a small part of it. whereas this document focuses on a small part of it.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Overview of the Technologies 2. Overview of the Technologies
The following sections introduce the different technologies analyzed The following sections introduce the different technologies analyzed
in this document, describing some of their most important in this document, describing some of their most important
characteristics. characteristics.
2.1. 464XLAT 2.1. 464XLAT
464XLAT may use double translation (stateless NAT46 + stateful NAT64) 464XLAT may use double translation (stateless NAT46 + stateful NAT64)
or single translation (stateful NAT64), depending on different or single translation (stateful NAT64), depending on different
skipping to change at page 4, line 48 skipping to change at page 4, line 40
In the operator's network, the provider-side translator (PLAT) In the operator's network, the provider-side translator (PLAT)
performs stateful NAT64 [RFC6146] to translate the traffic. The performs stateful NAT64 [RFC6146] to translate the traffic. The
destination IPv4 address is extracted from the IPv4-embedded IPv6 destination IPv4 address is extracted from the IPv4-embedded IPv6
packet destination address and the source address is from a pool of packet destination address and the source address is from a pool of
public IPv4 addresses. public IPv4 addresses.
Alternatively, when a dedicated /64 is not available for translation, Alternatively, when a dedicated /64 is not available for translation,
the CLAT device uses a stateful NAT44 translation before the the CLAT device uses a stateful NAT44 translation before the
stateless NAT46 translation. stateless NAT46 translation.
In general, state close to the end-user network (i.e. at the CE) is In general, state close to the end-user network (i.e. at the CE -
not perceived as problematic as state in the operators network. Customer Edge router) is not perceived as problematic as state in the
operators network.
In typical deployments, 464XLAT is used together with DNS64 In typical deployments, 464XLAT is used together with DNS64
[RFC6147], see Section 3.1.2 of [RFC8683]. When an IPv6-only client [RFC6147], see Section 3.1.2 of [RFC8683]. When an IPv6-only client
or application communicates with an IPv4-only server, the DNS64 or application communicates with an IPv4-only server, the DNS64
server returns the IPv4-embedded IPv6 address of the IPv4-only server returns the IPv4-embedded IPv6 address of the IPv4-only
server. In this case, the IPv6-only client sends out IPv6 packets, server. In this case, the IPv6-only client sends out IPv6 packets,
and the CLAT functions as an IPv6 router and the PLAT performs a and the CLAT functions as an IPv6 router and the PLAT performs a
stateful NAT64 for these packets. In this case, there is a single stateful NAT64 for these packets. In this case, there is a single
translation. translation.
skipping to change at page 11, line 4 skipping to change at page 10, line 37
In order to fulfill this requirement, a stateful NAPT function is a In order to fulfill this requirement, a stateful NAPT function is a
necessary function in all of the mechanisms. The major necessary function in all of the mechanisms. The major
differentiator is where in the architecture this function is located. differentiator is where in the architecture this function is located.
The solutions compared by this document fall into two categories: The solutions compared by this document fall into two categories:
* CGN-based approaches (DS-Lite, 464XLAT) * CGN-based approaches (DS-Lite, 464XLAT)
* A+P-based approaches (lw4o6, MAP-E, MAP-T) * A+P-based approaches (lw4o6, MAP-E, MAP-T)
In the CGN-based model, a device such as a CGN/AFTR or NAT64 performs 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 the NAPT44 function and maintains per-session state for all of the
active client's traffic. The customer's device does not require per- active client's traffic. The customer's device does not require per-
session state for NAPT. session state for NAPT.
In the A+P-based model, a device (usually a CE) performs stateful In the A+P-based model, a device (usually a CE) performs stateful
NAPT44 and maintains per-session state only co-located devices, e.g. NAPT44 and maintains per-session state only co-located devices, e.g.
in the customer's home network. Here, the centralized network in the customer's home network. Here, the centralized network
function (lwAFTR or BR) only needs to perform stateless function (lwAFTR or BR) only needs to perform stateless
encapsulation/decapsulation or NAT64. encapsulation/decapsulation or NAT64.
Issues related to IPv4 address sharing mechanisms are described in Issues related to IPv4 address sharing mechanisms are described in
[RFC6269] and should also be considered. [RFC6269] and should also be considered.
The address sharing efficiency of the five technologies is The address sharing efficiency of the five technologies is
significantly different, it is discussed in Section 4.2 significantly different, it is discussed in Section 4.2.
lw4o6, MAP-E and MAP-T can also be configured without IPv4 address lw4o6, MAP-E and MAP-T can also be configured without IPv4 address
sharing, see the details in Section 4.3. However, in that case, sharing, see the details in Section 4.3. However, in that case,
there is no advantage in terms of public IPv4 address saving. In the there is no advantage in terms of public IPv4 address saving. In the
case of 464XLAT, this can be achieved as well through EAMT [RFC7757]. case of 464XLAT, this can be achieved as well through EAMT [RFC7757].
Conversely, both MAP-E and MAP-T may be configured to provide more Conversely, both MAP-E and MAP-T may be configured to provide more
than one public IPv4 address (i.e., an IPv4 prefix shorter than a than one public IPv4 address (i.e., an IPv4 prefix shorter than a
/32) to customers. /32) to customers.
skipping to change at page 13, line 26 skipping to change at page 13, line 16
in case the CLAT-enabled CE with 464XLAT makes use of the 5-tuple NAT in case the CLAT-enabled CE with 464XLAT makes use of the 5-tuple NAT
connections tracking, and could also be further extended if the NAT64 connections tracking, and could also be further extended if the NAT64
also use the 5-tuple. also use the 5-tuple.
3.5. CE Provisioning Considerations 3.5. CE Provisioning Considerations
All of the technologies require some provisioning of customer All of the technologies require some provisioning of customer
devices. The table below shows which methods currently have devices. The table below shows which methods currently have
extensions for provisioning the different mechanisms. extensions for provisioning the different mechanisms.
+===================+===========+===========+=======+=======+=======+ +==============+===========+===========+=======+=======+=======+
| | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T | | Provisioning | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T |
+===================+===========+===========+=======+=======+=======+ | Method | | | | | |
| DHCPv6 [RFC8415] | | X | X | X | X | +==============+===========+===========+=======+=======+=======+
+-------------------+-----------+-----------+-------+-------+-------+ | DHCPv6 | | X | X | X | X |
| RADIUS [RFC8658] | | [RFC6519] | X | X | X | | [RFC8415] | | | | | |
+-------------------+-----------+-----------+-------+-------+-------+ +--------------+-----------+-----------+-------+-------+-------+
| TR-069 | * | X | * | X | X | | RADIUS | | [RFC6519] | X | X | X |
+-------------------+-----------+-----------+-------+-------+-------+ | [RFC8658] | | | | | |
| DNS64 [RFC7050] | X | | | | | +--------------+-----------+-----------+-------+-------+-------+
+-------------------+-----------+-----------+-------+-------+-------+ | TR-069 | * | X | * | X | X |
| YANG [RFC7950] | [RFC8512] | X | X | X | X | +--------------+-----------+-----------+-------+-------+-------+
+-------------------+-----------+-----------+-------+-------+-------+ | DNS64 | X | | | | |
| DHCP4o6 | | | X | X | | | [RFC7050] | | | | | |
| [RFC7341] | | | | | | +--------------+-----------+-----------+-------+-------+-------+
+-------------------+-----------+-----------+-------+-------+-------+ | YANG | [RFC8512] | X | X | X | X |
| [RFC7950] | | | | | |
+--------------+-----------+-----------+-------+-------+-------+
| DHCP4o6 | | | X | X | |
| [RFC7341] | | | | | |
+--------------+-----------+-----------+-------+-------+-------+
Table 2: Available Provisioning Mechanisms Table 2: Available Provisioning Mechanisms
*: Work started at BroadBand Forum (2021). *: Work started at BroadBand Forum (2021).
X: Supported by the provisioning method.
3.6. Support for Multicast 3.6. Support for Multicast
The solutions covered in this document are all intended for unicast The solutions covered in this document are all intended for unicast
traffic. [RFC8114] describes a method for carrying encapsulated IPv4 traffic. [RFC8114] describes a method for carrying encapsulated IPv4
multicast traffic over an IPv6 multicast network. This could be multicast traffic over an IPv6 multicast network. This could be
deployed in parallel to any of the operator's chosen IPv4aaS deployed in parallel to any of the operator's chosen IPv4aaS
mechanism. mechanism.
4. Detailed Analysis 4. Detailed Analysis
skipping to change at page 17, line 10 skipping to change at page 17, line 10
should be noticed that this is the same problem when a network has a should be noticed that this is the same problem when a network has a
NAT44 with multiple public IPv4 addresses, or even when applications NAT44 with multiple public IPv4 addresses, or even when applications
in a dual-stack case, behave wrongly if happy eyeballs is flapping in a dual-stack case, behave wrongly if happy eyeballs is flapping
the flow address between IPv4 and IPv6. the flow address between IPv4 and IPv6.
The consequences of IPv4 address sharing [RFC6269] may impact all The consequences of IPv4 address sharing [RFC6269] may impact all
five technologies. However, when ports are allocated statically, five technologies. However, when ports are allocated statically,
more customers may get ports from the same public IPv4 address, which more customers may get ports from the same public IPv4 address, which
may results in negative consequences with higher probability, e.g. may results in negative consequences with higher probability, e.g.
many applications and service providers (Sony PlayStation Network, many applications and service providers (Sony PlayStation Network,
OpenDNS, etc.) permanently black-list IPv4 ranges if they detect that OpenDNS, etc.) permanently blocking IPv4 ranges if they detect that
they are used for address sharing. they are used for address sharing.
Both cases are, again, implementation dependent. Both cases are, again, implementation dependent.
We note that although it is not of typical use, one can do 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 deterministic, stateful NAT and reserve a fixed set of ports for each
customer, as well. customer, as well.
4.3. Support for Public Server Operation 4.3. Support for Public Server Operation
Mechanisms that rely on operator side per-flow state do not, by Mechanisms that rely on operator side per-flow state do not, by
themselves, offer a way for customers to present services on publicly themselves, offer a way for customers to present services on publicly
accessible layer-4 ports. accessible layer-4 ports.
Port Control Protocol (PCP) [RFC6877] provides a mechanism for a Port Control Protocol (PCP) [RFC6887] provides a mechanism for a
client to request an external public port from a CGN device. For client to request an external public port from a CGN device. For
server operation, it is required with NAT64/464XLAT, and it is server operation, it is required with NAT64/464XLAT, and it is
supported in some DS-Lite AFTR implementations. supported in some DS-Lite AFTR implementations.
A+P based mechanisms distribute a public IPv4 address and restricted A+P based mechanisms distribute a public IPv4 address and restricted
range of layer-4 ports to the client. In this case, it is possible range of layer-4 ports to the client. In this case, it is possible
for the user to configure their device to offer a publicly accessible for the user to configure their device to offer a publicly accessible
server on one of their allocated ports. It should be noted that server on one of their allocated ports. It should be noted that
commonly operators do not assign the Well-Known-Ports to users commonly operators do not assign the Well-Known-Ports to users
(unless they are allocating a full IPv4 address), so the user will (unless they are allocating a full IPv4 address), so the user will
skipping to change at page 18, line 31 skipping to change at page 18, line 31
* 'ds-lite' enables support for DSLite B4 functionality * 'ds-lite' enables support for DSLite B4 functionality
* 'map' enables support for MAP-E and lw4o6 CE functionality * 'map' enables support for MAP-E and lw4o6 CE functionality
* 'map-t' enables support for MAP-T CE functionality * 'map-t' enables support for MAP-T CE functionality
At the time of publication some free open-source implementations At the time of publication some free open-source implementations
exist for the operator side functionality: exist for the operator side functionality:
CLAT, NAT64, EAMT, MAP-T CE, MAP-T BR: http://www.jool.mx * Jool [jool] (CLAT, NAT64, EAMT, MAP-T CE, MAP-T BR).
MAP-BR, lwAFTR, CGN, CLAT, NAT64: VPP/fd.io * VPP/fd.io [vpp] (MAP-BR, lwAFTR, CGN, CLAT, NAT64).
https://gerrit.fd.io/r/#/admin/projects/
lwAFTR: https://github.com/Igalia/snabb * Snabb [snabb] (lwAFTR).
DSLite AFTR: https://www.isc.org/downloads/ * AFTR [aftr] (DSLite AFTR).
4.4.2. Support in Cellular and Broadband Networks 4.4.2. Support in Cellular and Broadband Networks
Several cellular networks use 464XLAT, whereas there are no Several cellular networks use 464XLAT, whereas there are no
deployments of the four other technologies in cellular networks, as deployments of the four other technologies in cellular networks, as
they are neither standardised nor implemented in UE devices. they are neither standardised nor implemented in UE devices.
In broadband networks, there are some deployments of 464XLAT, MAP-E In broadband networks, there are some deployments of 464XLAT, MAP-E
and MAP-T. Lw4o6 and DS-Lite have more deployments, with DS-Lite and MAP-T. Lw4o6 and DS-Lite have more deployments, with DS-Lite
being the most common, but lw4o6 taking over in the last years. being the most common, but lw4o6 taking over in the last years.
skipping to change at page 26, line 10 skipping to change at page 26, line 10
[RFC6519] Maglione, R. and A. Durand, "RADIUS Extensions for Dual- [RFC6519] Maglione, R. and A. Durand, "RADIUS Extensions for Dual-
Stack Lite", RFC 6519, DOI 10.17487/RFC6519, February Stack Lite", RFC 6519, DOI 10.17487/RFC6519, February
2012, <https://www.rfc-editor.org/info/rfc6519>. 2012, <https://www.rfc-editor.org/info/rfc6519>.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation", Combination of Stateful and Stateless Translation",
RFC 6877, DOI 10.17487/RFC6877, April 2013, RFC 6877, DOI 10.17487/RFC6877, April 2013,
<https://www.rfc-editor.org/info/rfc6877>. <https://www.rfc-editor.org/info/rfc6877>.
[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
DOI 10.17487/RFC6887, April 2013,
<https://www.rfc-editor.org/info/rfc6887>.
[RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar, [RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar,
"Analysis of Stateful 64 Translation", RFC 6889, "Analysis of Stateful 64 Translation", RFC 6889,
DOI 10.17487/RFC6889, April 2013, DOI 10.17487/RFC6889, April 2013,
<https://www.rfc-editor.org/info/rfc6889>. <https://www.rfc-editor.org/info/rfc6889>.
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis", the IPv6 Prefix Used for IPv6 Address Synthesis",
RFC 7050, DOI 10.17487/RFC7050, November 2013, RFC 7050, DOI 10.17487/RFC7050, November 2013,
<https://www.rfc-editor.org/info/rfc7050>. <https://www.rfc-editor.org/info/rfc7050>.
skipping to change at page 28, line 18 skipping to change at page 28, line 24
DOI 10.17487/RFC8658, November 2019, DOI 10.17487/RFC8658, November 2019,
<https://www.rfc-editor.org/info/rfc8658>. <https://www.rfc-editor.org/info/rfc8658>.
[RFC8683] Palet Martinez, J., "Additional Deployment Guidelines for [RFC8683] Palet Martinez, J., "Additional Deployment Guidelines for
NAT64/464XLAT in Operator and Enterprise Networks", NAT64/464XLAT in Operator and Enterprise Networks",
RFC 8683, DOI 10.17487/RFC8683, November 2019, RFC 8683, DOI 10.17487/RFC8683, November 2019,
<https://www.rfc-editor.org/info/rfc8683>. <https://www.rfc-editor.org/info/rfc8683>.
9.2. Informative References 9.2. Informative References
[aftr] ISC, "ISC implementation of AFTR", 2022,
<https://www.isc.org/downloads/>.
[Azz2021] Al-Azzawi, A. and G. Lencse, "Identification of the [Azz2021] Al-Azzawi, A. and G. Lencse, "Identification of the
Possible Security Issues of the 464XLAT IPv6 Transition Possible Security Issues of the 464XLAT IPv6 Transition
Technology", Infocommunications Journal, vol. 13, no. 4, Technology", Infocommunications Journal, vol. 13, no. 4,
pp. 10-18, DOI: 10.36244/ICJ.2021.4.2, December 2021, pp. 10-18, DOI: 10.36244/ICJ.2021.4.2, December 2021,
<https://www.infocommunications.hu/2021_4_2>. <https://www.infocommunications.hu/2021_4_2>.
[I-D.ietf-v6ops-464xlat-optimization] [I-D.ietf-v6ops-464xlat-optimization]
Martinez, J. P. and A. D'Egidio, "464XLAT/MAT-T Martinez, J. P. and A. D'Egidio, "464XLAT/MAT-T
Optimization", Work in Progress, Internet-Draft, draft- Optimization", Work in Progress, Internet-Draft, draft-
ietf-v6ops-464xlat-optimization-03, 28 July 2020, ietf-v6ops-464xlat-optimization-03, 28 July 2020,
skipping to change at page 28, line 41 skipping to change at page 28, line 50
[I-D.lencse-v6ops-transition-benchmarking] [I-D.lencse-v6ops-transition-benchmarking]
Lencse, G., "Performance Analysis of IPv6 Transition Lencse, G., "Performance Analysis of IPv6 Transition
Technologies for IPv4aaS", Work in Progress, Internet- Technologies for IPv4aaS", Work in Progress, Internet-
Draft, draft-lencse-v6ops-transition-benchmarking-00, 16 Draft, draft-lencse-v6ops-transition-benchmarking-00, 16
October 2021, <https://www.ietf.org/archive/id/draft- October 2021, <https://www.ietf.org/archive/id/draft-
lencse-v6ops-transition-benchmarking-00.txt>. lencse-v6ops-transition-benchmarking-00.txt>.
[I-D.lencse-v6ops-transition-scalability] [I-D.lencse-v6ops-transition-scalability]
Lencse, G., "Scalability of IPv6 Transition Technologies Lencse, G., "Scalability of IPv6 Transition Technologies
for IPv4aaS", Work in Progress, Internet-Draft, draft- for IPv4aaS", Work in Progress, Internet-Draft, draft-
lencse-v6ops-transition-scalability-01, 21 February 2022, lencse-v6ops-transition-scalability-02, 7 March 2022,
<https://www.ietf.org/archive/id/draft-lencse-v6ops- <https://www.ietf.org/archive/id/draft-lencse-v6ops-
transition-scalability-01.txt>. transition-scalability-02.txt>.
[jool] NIC.MX, "Open Source SIIT and NAT64 for Linux", 2022,
<http://www.jool.mx>.
[LEN2018] Lencse, G. and Y. Kadobayashi, "Methodology for the [LEN2018] Lencse, G. and Y. Kadobayashi, "Methodology for the
identification of potential security issues of different identification of potential security issues of different
IPv6 transition technologies: Threat analysis of DNS64 and IPv6 transition technologies: Threat analysis of DNS64 and
stateful NAT64", Computers & Security (Elsevier), vol. stateful NAT64", Computers & Security (Elsevier), vol.
77, no. 1, pp. 397-411, DOI: 10.1016/j.cose.2018.04.012, 77, no. 1, pp. 397-411, DOI: 10.1016/j.cose.2018.04.012,
1 August 2018, 1 August 2018,
<http://www.hit.bme.hu/~lencse/publications/ECS-2018- <http://www.hit.bme.hu/~lencse/publications/ECS-2018-
Methodology-revised.pdf>. Methodology-revised.pdf>.
skipping to change at page 30, line 5 skipping to change at page 30, line 17
technology", Proc. 37th Internat. Conf. on technology", Proc. 37th Internat. Conf. on
Telecommunications and Signal Processing (TSP 2014), Telecommunications and Signal Processing (TSP 2014),
Berlin, Germany, DOI: 10.1109/TSP.2015.7296411, July Berlin, Germany, DOI: 10.1109/TSP.2015.7296411, July
2014, <http://www.hit.bme.hu/~lencse/publications/TSP- 2014, <http://www.hit.bme.hu/~lencse/publications/TSP-
2014-PC.pdf>. 2014-PC.pdf>.
[SIITperf] Lencse, G., "Siitperf: an RFC 8219 compliant SIIT [SIITperf] Lencse, G., "Siitperf: an RFC 8219 compliant SIIT
(stateless NAT64) tester", November 2019, (stateless NAT64) tester", November 2019,
<https://github.com/lencsegabor/siitperf>. <https://github.com/lencsegabor/siitperf>.
[snabb] Igalia, "Snabb implementation of lwAFTR", 2022,
<https://github.com/Igalia/snabb>.
[vpp] "VPP Implementations of IPv6-only with IPv4aaS", 2022,
<https://gerrit.fd.io/r/#/admin/projects/>.
Appendix A. Change Log Appendix A. Change Log
A.1. 01 - 02 A.1. 01 - 02
* Ian Farrer has joined us as an author. * Ian Farrer has joined us as an author.
* Restructuring: the description of the five IPv4aaS technologies * Restructuring: the description of the five IPv4aaS technologies
was moved to a separate section. was moved to a separate section.
* More details and figures were added to the description of the five * More details and figures were added to the description of the five
skipping to change at page 31, line 31 skipping to change at page 32, line 5
iptables.) iptables.)
* New I-D for benchmarking measurements. (Only a stub.) * New I-D for benchmarking measurements. (Only a stub.)
A.8. 01 - 02 A.8. 01 - 02
Update on the basis of the AD review. Update on the basis of the AD review.
Update of the references. Update of the references.
A.9. 02 - 03
Nits and changes from IESG review.
Updated wrong reference to PCP.
Authors' Addresses Authors' Addresses
Gabor Lencse Gabor Lencse
Budapest University of Technology and Economics Budapest University of Technology and Economics
Budapest Budapest
Magyar tudosok korutja 2. Magyar tudosok korutja 2.
H-1117 H-1117
Hungary Hungary
Email: lencse@hit.bme.hu Email: lencse@hit.bme.hu
 End of changes. 29 change blocks. 
51 lines changed or deleted 73 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/