| < 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/ | ||||