< draft-lmhp-v6ops-transition-comparison-02.txt   draft-lmhp-v6ops-transition-comparison-03.txt >
Internet Engineering Task Force G. Lencse Internet Engineering Task Force G. Lencse
Internet-Draft BUTE Internet-Draft BUTE
Intended status: Informational J. Palet Martinez Intended status: Informational J. Palet Martinez
Expires: July 28, 2019 The IPv6 Company Expires: January 7, 2020 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
January 24, 2019 July 6, 2019
Pros and Cons of IPv6 Transition Technologies for IPv4aaS Pros and Cons of IPv6 Transition Technologies for IPv4aaS
draft-lmhp-v6ops-transition-comparison-02 draft-lmhp-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 July 28, 2019. This Internet-Draft will expire on January 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 51 skipping to change at page 2, line 51
4.3. Support for Public Server Operation . . . . . . . . . . . 14 4.3. Support for Public Server Operation . . . . . . . . . . . 14
4.4. Support and Implementations . . . . . . . . . . . . . . . 15 4.4. Support and Implementations . . . . . . . . . . . . . . . 15
4.4.1. OS Support . . . . . . . . . . . . . . . . . . . . . 15 4.4.1. OS Support . . . . . . . . . . . . . . . . . . . . . 15
4.4.2. Support in Cellular and Broadband Networks . . . . . 15 4.4.2. Support in Cellular and Broadband Networks . . . . . 15
4.4.3. Implementation Code Sizes . . . . . . . . . . . . . . 16 4.4.3. Implementation Code Sizes . . . . . . . . . . . . . . 16
4.5. Typical Deployment and Traffic Volume Considerations . . 16 4.5. Typical Deployment and Traffic Volume Considerations . . 16
4.5.1. Deployment Possibilities . . . . . . . . . . . . . . 16 4.5.1. Deployment Possibilities . . . . . . . . . . . . . . 16
4.5.2. Cellular Networks with 464XLAT . . . . . . . . . . . 16 4.5.2. Cellular Networks with 464XLAT . . . . . . . . . . . 16
4.6. Load Sharing . . . . . . . . . . . . . . . . . . . . . . 17 4.6. Load Sharing . . . . . . . . . . . . . . . . . . . . . . 17
4.7. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.7. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 17
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 4.8. Optimization for IPv4-only devices/applications . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 22 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 23
A.1. 01 - 02 . . . . . . . . . . . . . . . . . . . . . . . . . 22 A.1. 01 - 02 . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 A.2. 02 - 03 . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
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
[LEN2017] based on differing requirements and deployment scenarios. [LEN2017] based on differing requirements and deployment scenarios.
skipping to change at page 3, line 41 skipping to change at page 3, line 43
1. 464XLAT [RFC6877] 1. 464XLAT [RFC6877]
2. Dual Stack Lite [RFC6333] 2. Dual Stack Lite [RFC6333]
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
mechanisms during IPv6 deployment addressing a much broader topic,
whereas this document focuses on a small part of it.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Overview of the Technologies 2. Overview of the Technologies
skipping to change at page 9, line 41 skipping to change at page 9, line 41
that devices in the traffic path that perform header inspection (e.g. that devices in the traffic path that perform header inspection (e.g.
router ACLs or firewalls) require the functionality to look into the router ACLs or firewalls) require the functionality to look into the
payload header. payload header.
Solutions using double translation can only carry port-aware IP Solutions using double translation can only carry port-aware IP
protocols (e.g. TCP, UDP) and ICMP when they are used with IPv4 protocols (e.g. TCP, UDP) and ICMP when they are used with IPv4
address sharing (please refer to Section 4.3 for more details). address sharing (please refer to Section 4.3 for more details).
Encapsulation based solutions can carry any other protocols over IP, Encapsulation based solutions can carry any other protocols over IP,
too. too.
An in-depth analysis of stateful NAT64 can be found in [RFC6889].
3.3. IPv4 Address Sharing 3.3. IPv4 Address Sharing
As public IPv4 address exhaustion is a common motivation for As public IPv4 address exhaustion is a common motivation for
deploying IPv6, transition technologies need to provide a solution deploying IPv6, transition technologies need to provide a solution
for allowing public IPv4 address sharing. for allowing public IPv4 address sharing.
In order to fullfill 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 the architecture this function is differentiator is where in the architecture this function is located.
located.
The solutions compared by this document fall into two categories: The solutions compared by this document fall into two categories:
o Centralized Stateful NAPT44 (DS-Lite, 464XLAT) o CGN-based approaches (DS-Lite, 464XLAT)
o Distributed Stateful NAPT44 (lw4o6, MAP-E, MAP-T) o A+P-based approaches (lw4o6, MAP-E, MAP-T)
In the centralized model, a device such as a CGN/AFTR or NAT64 In the CGN-based model, a device such as a CGN/AFTR or NAT64 performs
performs the NAPT44 function and maintains per-session state for all the NAPT44 function and maintains per-session state for all of the
of the active client's traffic. The customer's device does not active client's traffic. The customer's device does not require per-
require per-session state for NAPT. session state for NAPT.
In the distributed 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 centralised 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.
However, it is also worth noting that if the data retention
regulatory requirements in force mandate per-flow logging, then a
centralised NAPT44 model may be the only way to meet this
requirement.
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.
Dynamic DNS issues in address-sharing contexts and their possible
solutions using PCP (Port Control Protocol) are discussed in detail
in [RFC7393].
3.4. CE Provisioning Considerations 3.4. 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 protocols 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 | | | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T |
+------------------+---------+---------+-------+-------+-------+ +------------------+-----------+---------+-------+-------+-------+
| DHCPv6 [RFC8415] | | X | X | X | X | | DHCPv6 [RFC8415] | | X | X | X | X |
| RADIUS Attr. | | X | X | X | X | | RADIUS Attr. | | X | X | X | X |
| TR-69 | X | X | | X | X | | TR-69 | | X | | X | X |
| DNS64 [RFC6147] | X | | | | | | DNS64 [RFC7050] | X | | | | |
| YANG [RFC6050] | | X | X | X | X | | YANG [RFC7950] | [RFC8512] | X | X | X | X |
| DHCP4o6 | | | X | X | | | DHCP4o6 | | | X | X | |
+------------------+---------+---------+-------+-------+-------+ +------------------+-----------+---------+-------+-------+-------+
Table 2: Available Provisioning Mechanisms Table 2: Available Provisioning Mechanisms
3.5. Support for Multicast 3.5. 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.
skipping to change at page 12, line 11 skipping to change at page 12, line 11
+-----------------------+---------+---------+-------+-------+-------+ +-----------------------+---------+---------+-------+-------+-------+
Table 3: Available Provisioning Mechanisms Table 3: Available Provisioning Mechanisms
4.2. Tradeoff between Port Number Efficiency and Stateless Operation 4.2. Tradeoff between Port Number Efficiency and Stateless Operation
464XLAT and DS-Lite use stateful NAPT at the PLAT/AFTR devices, 464XLAT and DS-Lite use stateful NAPT at the PLAT/AFTR devices,
respectively. This may cause scalability issues for the number of respectively. This may cause scalability issues for the number of
clients or volume of traffic, but does not impose a limitation on the clients or volume of traffic, but does not impose a limitation on the
number of ports per user, as they can be allocated dynamically on- number of ports per user, as they can be allocated dynamically on-
deman and the allocation policy can be centrally managed/adjusted. demand and the allocation policy can be centrally managed/adjusted.
A+P based mechanisms (Lw4o6, MAP-E, and MAP-T) avoid using NAPT in 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 the service provider network. However, this means that the number of
ports provided to each user (and hence the effective IPv4 address ports provided to each user (and hence the effective IPv4 address
sharing ratio) must be pre-provisioned to the client. sharing ratio) must be pre-provisioned to the client.
Changing the allocated port ranges with A+P based technologies, Changing the allocated port ranges with A+P based technologies,
requires more planning and is likely to involve re-provisioning both requires more planning and is likely to involve re-provisioning both
hosts and operator side equipment. It should be noted that due to hosts and operator side equipment. It should be noted that due to
the per-customer binding table entry used by lw4o6, a single customer the per-customer binding table entry used by lw4o6, a single customer
skipping to change at page 14, line 26 skipping to change at page 14, line 26
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) [RFC6877] provides a mechanism for a
client to request an external public port from a CGN device and is client to request an external public port from a CGN device. For
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
need to run the service on an allocated port, or configure port need to run the service on an allocated port, or configure port
translation. translation.
skipping to change at page 17, line 30 skipping to change at page 17, line 30
use of anycast routing for load sharing and resiliency across use of anycast routing for load sharing and resiliency across
network-devices, both ingress and egress; flows can take asymmetric network-devices, both ingress and egress; flows can take asymmetric
paths through the network, i.e., in through one lwAFTR/BR and out via paths through the network, i.e., in through one lwAFTR/BR and out via
another. another.
Mechanisms with centralized NAPT44 state have a number of challenges Mechanisms with centralized NAPT44 state have a number of challenges
specifically related to scaling and resilience. As the total amount specifically related to scaling and resilience. As the total amount
of client traffic exceeds the capacity of a single CGN instance, of client traffic exceeds the capacity of a single CGN instance,
additional nodes are required to handle the load. As each CGN additional nodes are required to handle the load. As each CGN
maintains a stateful table of active client sessions, this table may maintains a stateful table of active client sessions, this table may
need to be syncronised between CGN instances. This is necessary for need to be syncronized between CGN instances. This is necessary for
two reasons: two reasons:
o To prevent all active customer sessions being dropped in event of o To prevent all active customer sessions being dropped in event of
a CGN node failure. a CGN node failure.
o To ensure a matching state table entry for an active session in o To ensure a matching state table entry for an active session in
the event of asymetric routing through different egress and the event of asymmetric routing through different egress and
ingress CGN nodes. ingress CGN nodes.
4.7. Logging 4.7. Logging
In the case of 464XLAT and DS-Lite, the user of any given public IPv4 In the case of 464XLAT and DS-Lite, the user of any given public IPv4
address and port combination will will vary over time, therefore, address and port combination will vary over time, therefore, logging
logging is necessary to meet data retention laws. Each entry in the is necessary to meet data retention laws. Each entry in the PLAT/
PLAT/AFTR's generates a logging entry. As discussed in Section 4.2, AFTR's generates a logging entry. As discussed in Section 4.2, a
a client may open hundreds of sessions during common tasks such as client may open hundreds of sessions during common tasks such as web-
web-browsing, each of which needs to be logged so the overall logging browsing, each of which needs to be logged so the overall logging
burden on the network operator is significant. In some countries, burden on the network operator is significant. In some countries,
this level of logging is required to comply with data retention this level of logging is required to comply with data retention
legislation. legislation.
One common optimization available to reduce the logging overhead is One common optimization available to reduce the logging overhead is
the allocation of a block of ports to a client for the duration of the allocation of a block of ports to a client for the duration of
their session. This means that logging entry only needs to be made their session. This means that logging entry only needs to be made
when the client's port block is released, which dramatically reducing when the client's port block is released, which dramatically reducing
the logging overhead. This comes as the cost of less efficient the logging overhead. This comes as the cost of less efficient
public address sharing as clients need to be allocated a port block public address sharing as clients need to be allocated a port block
skipping to change at page 18, line 25 skipping to change at page 18, line 25
only require that copies of the active MAP rules (for MAP-E and MAP- only require that copies of the active MAP rules (for MAP-E and MAP-
T), or binding-table (for lw4o6) are retained along with timestamp T), or binding-table (for lw4o6) are retained along with timestamp
information of when they have been active. Support tools (e.g., information of when they have been active. Support tools (e.g.,
those used to serve data retention requests) may need to be updated those used to serve data retention requests) may need to be updated
to be aware of the mechanism in use (e.g., implementing the MAP 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 algorithm so that IPv4 information can be linked to the IPv6 prefix
delegated to a client). As stateless technologies do not have a delegated to a client). As stateless technologies do not have a
centralized stateful element which customer traffic needs to pass centralized stateful element which customer traffic needs to pass
through, so if data retention laws mandate per-session logging, there through, so if data retention laws mandate per-session logging, there
is no simple way of meeting this requirement with a stateless is no simple way of meeting this requirement with a stateless
technology alone. technology alone. Thus a centralized NAPT44 model may be the only
way to meet this requirement.
Deterministic CGN [RFC7422] was proposed as a solution to reduce the
resource consumption of logging.
4.8. Optimization for IPv4-only devices/applications
When IPv4-only devices or applications are behind a CE connected with
IPv6-only and IPv4aaS, the IPv4-only traffic flows will necessarily,
be encapsulated/decapsulated (in the case of DS-Lite, lw4o6 and MAP-
E) and will reach the IPv4 address of the destination, even if that
service supports dual-stack. This means that the traffic flow will
cross thru the AFTR, lwAFTR or BR, depending on the specific
transition mechanism being used.
Even if those services are directly connected to the operator network
(for example, CDNs, caches), or located internally (such as VoIP,
etc.), it is not possible to avoid that overhead.
However, in the case of those mechanism 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
[I-D.palet-v6ops-464xlat-opt-cdn-caches].
Using those optimizations, because the NAT46 has already translated
the IPv4-only flow to IPv6, and the services are dual-stack, they can
be reached without the need to translate them back to IPv4.
5. Acknowledgements 5. Acknowledgements
The authors would like to thank Ole Troan for his thorough review of The authors would like to thank Ole Troan for his thorough review of
this draft and acknowledge the inputs of Ole Troan, Mark Andrews, this draft and acknowledge the inputs of Mark Andrews, Edwin
Edwin Cordeiro, Fred Baker, Alexandre Petrescu, Cameron Byrne, Tore Cordeiro, Fred Baker, Alexandre Petrescu, Cameron Byrne, Tore
Anderson, Alexandre Petrescu, Mikael Abrahamsson, Gert Doering, Anderson, Mikael Abrahamsson, Gert Doering, Satoru Matsushima,
Satoru Matsushima, and TBD ... Mohamed Boucadair, Tom Petch, Yannis Nikolopoulos, and TBD ...
6. IANA Considerations 6. IANA Considerations
This document does not make any request to IANA. This document does not make any request to IANA.
7. Security Considerations 7. Security Considerations
According to the simplest model, the number of bugs is proportional According to the simplest model, the number of bugs is proportional
to the number of code lines. Please refer to Section 4.4.3 for code to the number of code lines. Please refer to Section 4.4.3 for code
sizes of CE implementations. sizes of CE implementations.
skipping to change at page 20, line 11 skipping to change at page 20, line 36
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <https://www.rfc-editor.org/info/rfc6146>. April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147, Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
DOI 10.17487/RFC6147, April 2011, DOI 10.17487/RFC6147, April 2011,
<https://www.rfc-editor.org/info/rfc6147>. <https://www.rfc-editor.org/info/rfc6147>.
[RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6
Transition Mechanisms during IPv6 Deployment", RFC 6180,
DOI 10.17487/RFC6180, May 2011,
<https://www.rfc-editor.org/info/rfc6180>.
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
P. Roberts, "Issues with IP Address Sharing", RFC 6269, P. Roberts, "Issues with IP Address Sharing", RFC 6269,
DOI 10.17487/RFC6269, June 2011, DOI 10.17487/RFC6269, June 2011,
<https://www.rfc-editor.org/info/rfc6269>. <https://www.rfc-editor.org/info/rfc6269>.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4 Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
<https://www.rfc-editor.org/info/rfc6333>. <https://www.rfc-editor.org/info/rfc6333>.
[RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to
the IPv4 Address Shortage", RFC 6346, the IPv4 Address Shortage", RFC 6346,
DOI 10.17487/RFC6346, August 2011, DOI 10.17487/RFC6346, August 2011,
<https://www.rfc-editor.org/info/rfc6346>. <https://www.rfc-editor.org/info/rfc6346>.
[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>.
[RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar,
"Analysis of Stateful 64 Translation", RFC 6889,
DOI 10.17487/RFC6889, April 2013,
<https://www.rfc-editor.org/info/rfc6889>.
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis",
RFC 7050, DOI 10.17487/RFC7050, November 2013,
<https://www.rfc-editor.org/info/rfc7050>.
[RFC7393] Deng, X., Boucadair, M., Zhao, Q., Huang, J., and C. Zhou,
"Using the Port Control Protocol (PCP) to Update Dynamic
DNS", RFC 7393, DOI 10.17487/RFC7393, November 2014,
<https://www.rfc-editor.org/info/rfc7393>.
[RFC7422] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K.,
and O. Vautrin, "Deterministic Address Mapping to Reduce
Logging in Carrier-Grade NAT Deployments", RFC 7422,
DOI 10.17487/RFC7422, December 2014,
<https://www.rfc-editor.org/info/rfc7422>.
[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
Farrer, "Lightweight 4over6: An Extension to the Dual- Farrer, "Lightweight 4over6: An Extension to the Dual-
Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596,
July 2015, <https://www.rfc-editor.org/info/rfc7596>. July 2015, <https://www.rfc-editor.org/info/rfc7596>.
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, Ed., "Mapping of Address and Murakami, T., and T. Taylor, Ed., "Mapping of Address and
Port with Encapsulation (MAP-E)", RFC 7597, Port with Encapsulation (MAP-E)", RFC 7597,
DOI 10.17487/RFC7597, July 2015, DOI 10.17487/RFC7597, July 2015,
<https://www.rfc-editor.org/info/rfc7597>. <https://www.rfc-editor.org/info/rfc7597>.
skipping to change at page 21, line 10 skipping to change at page 22, line 15
[RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address
Mappings for Stateless IP/ICMP Translation", RFC 7757, Mappings for Stateless IP/ICMP Translation", RFC 7757,
DOI 10.17487/RFC7757, February 2016, DOI 10.17487/RFC7757, February 2016,
<https://www.rfc-editor.org/info/rfc7757>. <https://www.rfc-editor.org/info/rfc7757>.
[RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont,
"IP/ICMP Translation Algorithm", RFC 7915, "IP/ICMP Translation Algorithm", RFC 7915,
DOI 10.17487/RFC7915, June 2016, DOI 10.17487/RFC7915, June 2016,
<https://www.rfc-editor.org/info/rfc7915>. <https://www.rfc-editor.org/info/rfc7915>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8114] Boucadair, M., Qin, C., Jacquenet, C., Lee, Y., and Q. [RFC8114] Boucadair, M., Qin, C., Jacquenet, C., Lee, Y., and Q.
Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients
over an IPv6 Multicast Network", RFC 8114, over an IPv6 Multicast Network", RFC 8114,
DOI 10.17487/RFC8114, March 2017, DOI 10.17487/RFC8114, March 2017,
<https://www.rfc-editor.org/info/rfc8114>. <https://www.rfc-editor.org/info/rfc8114>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters, Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018, RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>. <https://www.rfc-editor.org/info/rfc8415>.
[RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C.,
Vinapamula, S., and Q. Wu, "A YANG Module for Network
Address Translation (NAT) and Network Prefix Translation
(NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019,
<https://www.rfc-editor.org/info/rfc8512>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-v6ops-nat64-deployment] [I-D.ietf-v6ops-nat64-deployment]
Palet, J., "NAT64/464XLAT Deployment Guidelines in Palet, J., "Additional NAT64/464XLAT Deployment Guidelines
Operator and Enterprise Networks", draft-ietf-v6ops- in Operator and Enterprise Networks", draft-ietf-v6ops-
nat64-deployment-03 (work in progress), October 2018. nat64-deployment-06 (work in progress), May 2019.
[I-D.palet-v6ops-464xlat-opt-cdn-caches]
Palet, J. and A. D'Egidio, "464XLAT Optimization", draft-
palet-v6ops-464xlat-opt-cdn-caches-02 (work in progress),
June 2019.
[LEN2017] Lencse, G. and Y. Kadobayashi, "Survey of IPv6 Transition [LEN2017] Lencse, G. and Y. Kadobayashi, "Survey of IPv6 Transition
Technologies for Security Analysis", IEICE Communications Technologies for Security Analysis", IEICE Communications
Society Internet Architecture Workshop, Tokyo, Japan, Society Internet Architecture Workshop, Tokyo, Japan,
IEICE Tech. Rep., vol. 117, no. 187, pp. 19-24, Aug IEICE Tech. Rep., vol. 117, no. 187, pp. 19-24, Aug
2017, <http://www.hit.bme.hu/~lencse/publications/ 2017, <http://www.hit.bme.hu/~lencse/publications/
IEICE-IA-2017-survey.pdf>. IEICE-IA-2017-survey.pdf>.
[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
skipping to change at page 22, line 38 skipping to change at page 24, line 11
o Section titled "Performance Analysis" was dropped due to lack of o Section titled "Performance Analysis" was dropped due to lack of
results yet. results yet.
o Word based text ported to XML. o Word based text ported to XML.
o Further text cleanups, added text on state sync and load o Further text cleanups, added text on state sync and load
balancing. Additional comments inline that should be considered balancing. Additional comments inline that should be considered
for future updates. for future updates.
A.2. 02 - 03
o The suggestions of Mohamed Boucadair are incorporated.
o New considerations regarding possible optimizations.
Authors' Addresses Authors' Addresses
Gabor Lencse Gabor Lencse
Budapest University of Technology and Economics Budapest University of Technology and Economics
Magyar Tudosok korutja 2. Magyar Tudosok korutja 2.
Budapest H-1117 Budapest H-1117
Hungary Hungary
Email: lencse@hit.bme.hu Email: lencse@hit.bme.hu
Jordi Palet Martinez Jordi Palet Martinez
The IPv6 Company The IPv6 Company
Molino de la Navata, 75 Molino de la Navata, 75
La Navata - Galapagar, Madrid 28420 La Navata - Galapagar, Madrid 28420
Spain Spain
Email: jordi.palet@theipv6company.com Email: jordi.palet@theipv6company.com
URI: http://www.theipv6company.com/ URI: http://www.theipv6company.com/
Lee Howard Lee Howard
 End of changes. 33 change blocks. 
55 lines changed or deleted 137 lines changed or added

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