idnits 2.17.1 draft-lmhp-v6ops-transition-comparison-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (Jan 6, 2020) is 1565 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Duplicate reference: RFC8219, mentioned in 'SIITperf', was also mentioned in 'RFC8219'. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Lencse 3 Internet-Draft BUTE 4 Intended status: Informational J. Palet Martinez 5 Expires: July 9, 2020 The IPv6 Company 6 L. Howard 7 Retevia 8 R. Patterson 9 Sky UK 10 I. Farrer 11 Deutsche Telekom AG 12 Jan 6, 2020 14 Pros and Cons of IPv6 Transition Technologies for IPv4aaS 15 draft-lmhp-v6ops-transition-comparison-04 17 Abstract 19 Several IPv6 transition technologies have been developed to provide 20 customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only 21 access and/or core network. All these technologies have their 22 advantages and disadvantages, and depending on existing topology, 23 skills, strategy and other preferences, one of these technologies may 24 be the most appropriate solution for a network operator. 26 This document examines the five most prominent IPv4aaS technologies 27 considering a number of different aspects to provide network 28 operators with an easy to use reference to assist in selecting the 29 technology that best suits their needs. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on July 9, 2020. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 67 2. Overview of the Technologies . . . . . . . . . . . . . . . . 4 68 2.1. 464XLAT . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.2. Dual-Stack Lite . . . . . . . . . . . . . . . . . . . . . 5 70 2.3. Lightweight 4over6 . . . . . . . . . . . . . . . . . . . 5 71 2.4. MAP-E . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 2.5. MAP-T . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 3. High-level Architectures and their Consequences . . . . . . . 8 74 3.1. Service Provider Network Traversal . . . . . . . . . . . 8 75 3.2. Network Address Translation . . . . . . . . . . . . . . . 9 76 3.3. IPv4 Address Sharing . . . . . . . . . . . . . . . . . . 10 77 3.4. CE Provisioning Considerations . . . . . . . . . . . . . 11 78 3.5. Support for Multicast . . . . . . . . . . . . . . . . . . 11 79 4. Detailed Analysis . . . . . . . . . . . . . . . . . . . . . . 11 80 4.1. Architectural Differences . . . . . . . . . . . . . . . . 11 81 4.1.1. Basic Comparison . . . . . . . . . . . . . . . . . . 11 82 4.2. Tradeoff between Port Number Efficiency and Stateless 83 Operation . . . . . . . . . . . . . . . . . . . . . . . . 12 84 4.3. Support for Public Server Operation . . . . . . . . . . . 14 85 4.4. Support and Implementations . . . . . . . . . . . . . . . 15 86 4.4.1. OS Support . . . . . . . . . . . . . . . . . . . . . 15 87 4.4.2. Support in Cellular and Broadband Networks . . . . . 16 88 4.4.3. Implementation Code Sizes . . . . . . . . . . . . . . 16 89 4.5. Typical Deployment and Traffic Volume Considerations . . 16 90 4.5.1. Deployment Possibilities . . . . . . . . . . . . . . 16 91 4.5.2. Cellular Networks with 464XLAT . . . . . . . . . . . 16 92 4.6. Load Sharing . . . . . . . . . . . . . . . . . . . . . . 17 93 4.7. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 17 94 4.8. Optimization for IPv4-only devices/applications . . . . . 18 95 5. Performance Comparison . . . . . . . . . . . . . . . . . . . 19 96 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 97 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 99 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 100 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 101 9.2. Informative References . . . . . . . . . . . . . . . . . 24 102 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25 103 A.1. 01 - 02 . . . . . . . . . . . . . . . . . . . . . . . . . 25 104 A.2. 02 - 03 . . . . . . . . . . . . . . . . . . . . . . . . . 26 105 A.3. 03 - 04 . . . . . . . . . . . . . . . . . . . . . . . . . 26 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 108 1. Introduction 110 As the deployment of IPv6 becomes more prevalent, it follows that 111 network operators will move to building single-stack IPv6 core and 112 access networks to simplify network planning and operations. 113 However, providing customers with IPv4 services continues to be a 114 requirement for the foreseeable future. To meet this need, the IETF 115 has standardized a number of different IPv4aaS technologies for this 116 [LEN2019] based on differing requirements and deployment scenarios. 118 The number of technologies that have been developed makes it time 119 consuming for a network operator to identify the most appropriate 120 mechanism for their specific deployment. This document provides a 121 comparative analysis of the most commonly used mechanisms to assist 122 operators with this problem. 124 Five different IPv4aaS solutions are considered. The following IPv6 125 transition technologies are covered: 127 1. 464XLAT [RFC6877] 129 2. Dual Stack Lite [RFC6333] 131 3. lw4o6 (Lightweight 4over6) [RFC7596] 133 4. MAP-E [RFC7597] 135 5. MAP-T [RFC7599] 137 We note that [RFC6180] gives guidelines for using IPv6 transition 138 mechanisms during IPv6 deployment addressing a much broader topic, 139 whereas this document focuses on a small part of it. 141 1.1. Requirements Language 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in 146 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 147 capitals, as shown here. 149 2. Overview of the Technologies 151 The following sections introduce the different technologies analyzed 152 in this document, describing some of their most important 153 characteristics. 155 2.1. 464XLAT 157 464XLAT is a single/dual translation model, which uses a customer- 158 side translator (CLAT) located in the customer's device to perform 159 stateless NAT64 translation [RFC7915] (more precisely, stateless 160 NAT46, a stateless IP/ICMP translation from IPv4 to IPv6). 161 IPv4-embedded IPv6 addresses [RFC6052] are used for both source and 162 destination addresses. Commonly, a /96 prefix (either the 163 64:ff9b::/96 Well-Known Prefix, or a Network-Specific Prefix) is used 164 as the IPv6 destination for the IPv4-embedded client traffic. 166 In the operator's network, the provider-side translator (PLAT) 167 performs stateful NAT64 [RFC6146] to translate the traffic. The 168 destination IPv4 address is extracted from the IPv4-embedded IPv6 169 packet destination address and the source address is from a pool of 170 public IPv4 addresses. 172 Alternatively, when a dedicated /64 is not available for translation, 173 the CLAT device uses a stateful NAT44 translation before the 174 stateless NAT46 translation. 176 Note that we generally do not see state close to the end-user as 177 equally problematic as state in the middle of the network. 179 In typical deployments, 464XLAT is used together with DNS64 180 [RFC6147], see Section 3.1.2 of [RFC8683]. When an IPv6-only client 181 or application communicates with an IPv4-only server, the DNS64 182 server returns the IPv4-embedded IPv6 address of the IPv4-only 183 server. In this case, the IPv6-only client sends out IPv6 packets, 184 thus CLAT functions as an IPv6 router and the PLAT performs a 185 stateful NAT64 for these packets. In this case, there is a single 186 translation. 188 Alternatively, one can say that the DNS64 + stateful NAT64 is used to 189 carry the traffic of the IPv6-only client and the IPv4-only server, 190 and the CLAT is used only for the IPv4 traffic from applications or 191 devices that use literal IPv4 addresses or non-IPv6 compliant APIs. 193 Private +----------+ Translated +----------+ _______ 194 +------+ IPv4 | CLAT | 4-6-4 | Stateful | ( IPv4 ) 195 | IPv4 |------->| Stateless|------------>| PLAT +--( Internet ) 196 |Device|<-------| NAT46 |<------------| NAT64 | (________) 197 +------+ +----------+ ^ +----------+ 198 | 199 Operator IPv6 200 network 202 Figure 1: Overview of the 464XLAT architecture 204 Note: in mobile networks, CLAT is commonly implemented in the user's 205 equipment (UE or smartphone). 207 2.2. Dual-Stack Lite 209 Dual-Stack Lite (DS-Lite) [RFC6333] was the first of the considered 210 transition mechanisms to be developed. DS-Lite uses a 'Basic 211 Broadband Bridging' (B4) function in the customer's CE router that 212 encapsulates IPv4 in IPv6 traffic and sends it over the IPv6 native 213 service-provider network to a centralized 'Address Family Transition 214 Router' (AFTR). The AFTR performs encapsulation/decapsulation of the 215 4in6 traffic and translates the IPv4 payload to public IPv4 source 216 address using a stateful NAPT44 function. 218 +-------------+ 219 Private +----------+ IPv4-in-IPv6|Stateful AFTR| 220 +------+ IPv4 | B4 | tunnel |------+------+ _______ 221 | IPv4 |------->| Encap./ |------------>|Encap.| | ( IPv4 ) 222 |Device|<-------| decap. |<------------| / | NAPT +--( Internet ) 223 +------+ +----------+ ^ |Decap.| 44 | (________) 224 | +------+------+ 225 Operator IPv6 226 network 228 Figure 2: Overview of the DS-Lite architecture 230 2.3. Lightweight 4over6 232 Lightweight 4over6 (lw4o6) is a variant of DS-Lite. The main 233 difference is that the stateful NAPT44 function is relocated from the 234 centralized AFTR to the customer's B4 element (called a lwB4). The 235 AFTR (called a lwAFTR) function therefore only performs A+P routing 236 and 4in6 encapsulation/decapsulation. 238 Routing to the correct client and IPv4 address sharing is achieved 239 using the Address + Port (A+P) model [RFC6346] of provisioning each 240 lwB4 with a unique tuple of IPv4 address unique range of layer-4 241 ports. The client uses these for NAPT44. 243 The lwAFTR implements a binding table, which has a per-client entry 244 linking the customer's source IPv4 address and allocated range of 245 layer-4 ports to their IPv6 tunnel endpoint address. The binding 246 table allows egress traffic from customers to be validated (to 247 prevent spoofing) and ingress traffic to be correctly encapsulated 248 and forwarded. As there needs to be a per-client entry, an lwAFTR 249 implementation needs to be optimized for performing a per-packet 250 lookup on the binding table. 252 Direct communication between two lwB4s is performed by hair-pinning 253 traffic through the lwAFTR. 255 +-------------+ +----------+ 256 Private | lwB4 | IPv4-in-IPv6| Stateless| 257 +------+ IPv4 |------+------| tunnel | lwAFTR | _______ 258 | IPv4 |------->| |Encap.|------------>|(encap/A+P| ( IPv4 ) 259 |Device|<-------| NAPT | / |<------------|bind. tab +--( Internet ) 260 +------+ | 44 |Decap.| ^ | routing) | (________) 261 +------+------+ | +----------+ 262 Operator IPv6 263 network 265 Figure 3: Overview of the lw4o6 architecture 267 2.4. MAP-E 269 MAP-E uses a stateless algorithm to embed portions of the customer's 270 allocated IPv4 address (or part of an address with A+P routing) into 271 the IPv6 prefix delegated to the client. This allows for large 272 numbers of clients to be provisioned using a single MAP rule (called 273 a MAP domain). The algorithm also allows for direct IPv4 peer-to- 274 peer communication between hosts provisioned with common MAP rules. 276 The CE (Customer-Edge) router typically performs stateful NAPT44 277 [RFC2663] to translate the private IPv4 source addresses and source 278 ports into an address and port range defined by applying the MAP rule 279 applied to the delegated IPv6 prefix. The client address/port 280 allocation size is a design parameter. The CE router then 281 encapsulates the IPv4 packet in an IPv6 packet [RFC2473] and sends it 282 directly to another host in the MAP domain (for peer-to-peer) or to a 283 Border Router (BR) if the IPv4 destination is not covered in one of 284 the CE's MAP rules. 286 The MAP BR is provisioned with the set of MAP rules for the MAP 287 domains it serves. These rules determine how the MAP BR is to 288 decapsulate traffic that it receives from client, validating the 289 source IPv4 address and layer 4 ports assigned, as well as how to 290 calculate the destination IPv6 address for ingress IPv4 traffic. 292 +-------------+ +----------+ 293 Private | MAP CE | IPv4-in-IPv6| Stateless| 294 +------+ IPv4 |------+------| tunnel | MAP BR | _______ 295 | IPv4 |------->| |Encap.|------------>|(encap/A+P| ( IPv4 ) 296 |Device|<-------| NAPT | / |<------------|algorithm +--( Internet ) 297 +------+ | 44 |Decap.| ^ | routing) | (________) 298 +------+------+ | +----------+ 299 Operator IPv6 300 network 302 Figure 4: Overview of the MAP-E architecture 304 2.5. MAP-T 306 MAP-T uses the same mapping algorithm as MAP-E. The major difference 307 is that double stateless translation (NAT46 in the CE and NAT64 in 308 the BR) is used to traverse the ISP's IPv6 single-stack network. 309 MAP-T can also be compared to 464XLAT when there is a double 310 translation. 312 A MAP CE typically performs stateful NAPT44 to translate traffic to a 313 public IPv4 address and port-range calculated by applying the 314 provisioned Basic MAP Rule (BMR - a set of inputs to the algorithm) 315 to the delegated IPv6 prefix. The CE then performs stateless 316 translation from IPv4 to IPv6 [RFC7915]. The MAP BR is provisioned 317 with the same BMR as the client, enabling the received IPv6 traffic 318 to be statelessly NAT64 translated back to the public IPv4 source 319 address used by the client. 321 Using translation instead of encapsulation also allows IPv4-only 322 nodes to correspond directly with IPv6 nodes in the MAP-T domain that 323 have IPv4-embedded IPv6 addresses. 325 +-------------+ +----------+ 326 Private | MAP CE | Translated | Stateless| 327 +------+ IPv4 |------+------| 4-6-4 | MAP BR | _______ 328 | IPv4 |------->| |State-|------------>|(NAT64/A+P| ( IPv4 ) 329 |Device|<-------| NAPT | less |<------------|algorithm +--( Internet ) 330 +------+ | 44 |NAT46 | ^ | routing) | (________) 331 +------+------+ | +----------+ 332 Operator IPv6 333 network 335 Figure 5: Overview of the MAP-T architecture 337 3. High-level Architectures and their Consequences 339 3.1. Service Provider Network Traversal 341 For the data-plane, there are two approaches for traversing the IPv6 342 provider network: 344 o 4-6-4 translation 346 o 4-in-6 encapsulation 348 +--------------+---------+---------+-------+-------+-------+ 349 | | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T | 350 +--------------+---------+---------+-------+-------+-------+ 351 | 4-6-4 trans. | X | | | | X | 352 | 4-6-4 encap. | | X | X | X | | 353 +--------------+---------+---------+-------+-------+-------+ 355 Table 1: Available Traversal Mechanisms 357 In the scope of this document, all of the encapsulation based 358 mechanisms use IP-in-IP tunnelling [RFC2473]. This is a stateless 359 tunneling mechanism which does not require any additional tunnel 360 headers. 362 It should be noted that both of these approaches result in an 363 increase in the size of the packet that needs to be transported 364 across the operator's network when compared to native IPv4. 4-6-4 365 translation adds a 20-bytes overhead (the 20-byte IPv4 header is 366 replaced with a 40-byte IPv6 header). Encapsulation has a 40-byte 367 overhead (an IPv6 header is prepended to the IPv4 header). 369 The increase in packet size can become a significant problem if there 370 is a link with a smaller MTU in the traffic path. This may result in 371 traffic needing to be fragmented at the ingress point to the IPv6 372 only domain (i.e., the NAT46 or 4in6 encapsulation endpoint). It may 373 also result in the need to implement buffering and fragment re- 374 assembly in the BR node. 376 The advice given in [RFC7597] Section 8.3.1 is applicable to all of 377 these mechanisms: It is strongly recommended that the MTU in the 378 IPv6-only domain be well managed and that the IPv6 MTU on the CE WAN- 379 side interface be set so that no fragmentation occurs within the 380 boundary of the IPv6-only domain. 382 3.2. Network Address Translation 384 For the high-level solution of IPv6 service provider network 385 traversal, MAP-T uses double stateless translation. First at the CE 386 from IPv4 to IPv6 (NAT46), and then from IPv6 to IPv4 (NAT64), at the 387 service provider network. 389 464XLAT may use double translation (stateless NAT46 + stateful NAT64) 390 or single translation (stateful NAT64), depending on different 391 factors, such as the use of DNS by the applications and the 392 availability of a DNS64 function (in the host or in the service 393 provider network). For deployment guidelines, please refer to 394 [RFC8683]. 396 The first step for the double translation mechanisms is a stateless 397 NAT from IPv4 to IPv6 implemented as SIIT (Stateless IP/ICMP 398 Translation Algorithm) [RFC7915], which does not translate IPv4 399 header options and/or multicast IP/ICMP packets. With encapsulation- 400 based technologies the header is transported intact and multicast can 401 also be carried. 403 Single and double translation results in native IPv6 traffic with a 404 layer-4 next-header. The fields in these headers can be used for 405 functions such as hashing across equal-cost multipaths or ACLs. For 406 encapsulation, there is an IPv6 header followed by an IPv4 header. 407 This results in less entropy for hashing algorithms, and may mean 408 that devices in the traffic path that perform header inspection (e.g. 409 router ACLs or firewalls) require the functionality to look into the 410 payload header. 412 Solutions using double translation can only carry port-aware IP 413 protocols (e.g. TCP, UDP) and ICMP when they are used with IPv4 414 address sharing (please refer to Section 4.3 for more details). 415 Encapsulation based solutions can carry any other protocols over IP, 416 too. 418 An in-depth analysis of stateful NAT64 can be found in [RFC6889]. 420 3.3. IPv4 Address Sharing 422 As public IPv4 address exhaustion is a common motivation for 423 deploying IPv6, transition technologies need to provide a solution 424 for allowing public IPv4 address sharing. 426 In order to fulfill this requirement, a stateful NAPT function is a 427 necessary function in all of the mechanisms. The major 428 differentiator is where in the architecture this function is located. 430 The solutions compared by this document fall into two categories: 432 o CGN-based approaches (DS-Lite, 464XLAT) 434 o A+P-based approaches (lw4o6, MAP-E, MAP-T) 436 In the CGN-based model, a device such as a CGN/AFTR or NAT64 performs 437 the NAPT44 function and maintains per-session state for all of the 438 active client's traffic. The customer's device does not require per- 439 session state for NAPT. 441 In the A+P-based model, a device (usually a CE) performs stateful 442 NAPT44 and maintains per-session state only co-located devices, e.g. 443 in the customer's home network. Here, the centralized network 444 function (lwAFTR or BR) only needs to perform stateless 445 encapsulation/decapsulation or NAT64. 447 Issues related to IPv4 address sharing mechanisms are described in 448 [RFC6269] and should also be considered. 450 The address sharing efficiency of the five technologies is 451 significantly different, it is discussed in Section 4.2 453 lw4o6, MAP-E and MAP-T can also be configured without IPv4 address 454 sharing, see the details in Section 4.3. However, in that case, 455 there is no advantage in terms of public IPv4 address saving. In the 456 case of 464XLAT, this can be achieved as well through EAMT [RFC7757]. 458 Conversely, both MAP-E and MAP-T may be configured to provide more 459 than one public IPv4 address (i.e., an IPv4 prefix shorter than a 460 /32) to customers. 462 Dynamic DNS issues in address-sharing contexts and their possible 463 solutions using PCP (Port Control Protocol) are discussed in detail 464 in [RFC7393]. 466 3.4. CE Provisioning Considerations 468 All of the technologies require some provisioning of customer 469 devices. The table below shows which methods currently have 470 extensions for provisioning the different mechanisms. 472 +------------------+-----------+---------+-------+-------+-------+ 473 | | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T | 474 +------------------+-----------+---------+-------+-------+-------+ 475 | DHCPv6 [RFC8415] | | X | X | X | X | 476 | RADIUS Attr. | | X | X | X | X | 477 | TR-69 | | X | | X | X | 478 | DNS64 [RFC7050] | X | | | | | 479 | YANG [RFC7950] | [RFC8512] | X | X | X | X | 480 | DHCP4o6 | | | X | X | | 481 +------------------+-----------+---------+-------+-------+-------+ 483 Table 2: Available Provisioning Mechanisms 485 3.5. Support for Multicast 487 The solutions covered in this document are all intended for unicast 488 traffic. [RFC8114] describes a method for carrying encapsulated IPv4 489 multicast traffic over an IPv6 multicast network. This could be 490 deployed in parallel to any of the operator's chosen IPv4aaS 491 mechanism. 493 4. Detailed Analysis 495 4.1. Architectural Differences 497 4.1.1. Basic Comparison 499 The five IPv4aaS technologies can be classified into 2x2=4 categories 500 on the basis of two aspects: 502 o Technology used for service provider network traversal. It can be 503 single/double translation or encapsulation. 505 o Presence or absence of NAPT44 per-flow state in the operator 506 network. 508 +-----------------------+---------+---------+-------+-------+-------+ 509 | | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T | 510 +-----------------------+---------+---------+-------+-------+-------+ 511 | 4-6-4 trans. | X | | | | X | 512 | 4-in-4 encap. | | X | X | X | | 513 | Per-flow state in op. | X | X | | | | 514 | network | | | | | | 515 +-----------------------+---------+---------+-------+-------+-------+ 517 Table 3: Available Provisioning Mechanisms 519 4.2. Tradeoff between Port Number Efficiency and Stateless Operation 521 464XLAT and DS-Lite use stateful NAPT at the PLAT/AFTR devices, 522 respectively. This may cause scalability issues for the number of 523 clients or volume of traffic, but does not impose a limitation on the 524 number of ports per user, as they can be allocated dynamically on- 525 demand and the allocation policy can be centrally managed/adjusted. 527 A+P based mechanisms (Lw4o6, MAP-E, and MAP-T) avoid using NAPT in 528 the service provider network. However, this means that the number of 529 ports provided to each user (and hence the effective IPv4 address 530 sharing ratio) must be pre-provisioned to the client. 532 Changing the allocated port ranges with A+P based technologies, 533 requires more planning and is likely to involve re-provisioning both 534 hosts and operator side equipment. It should be noted that due to 535 the per-customer binding table entry used by lw4o6, a single customer 536 can be re-provisioned (e.g., if they request a full IPv4 address) 537 without needing to change parameters for a number of customers as in 538 a MAP domain. 540 It is also worth noting that there is a direct relationship between 541 the efficiency of customer public port-allocations and the 542 corresponding logging overhead that may be necessary to meet data- 543 retention requirements. This is considered in Section 4.7 below. 545 Determining the optimal number of ports for a fixed port set is not 546 an easy task, and may also be impacted by local regulatory law, which 547 may define a maximum number of users per IP address, and consequently 548 a minimum number of ports per user. 550 On the one hand, the "lack of ports" situation may cause serious 551 problems in the operation of certain applications. For example, 552 Miyakawa has demonstrated the consequences of the session number 553 limitation due to port number shortage on the example of Google Maps 554 [MIY2010]. When the limit was 15, several blocks of the map were 555 missing, and the map was unusable. This study also provided several 556 examples for the session numbers of different applications (the 557 highest one was Apple's iTunes: 230-270 ports). 559 The port number consumption of different applications is highly 560 varying and e.g. in the case of web browsing it depends on several 561 factors, including the choice of the web page, the web browser, and 562 sometimes even the operating system [REP2014]. For example, under 563 certain conditions, 120-160 ports were used (URL: sohu.com, browser: 564 Firefox under Ubuntu Linux), and in some other cases it was only 3-12 565 ports (URL: twitter.com, browser: Iceweasel under Debian Linux). 567 There may be several users behind a CE router, especially in the 568 broadband case (e.g. Internet is used by different members of a 569 family simultaneously), so sufficient ports must be allocated to 570 avoid impacting user experience. 572 Furthermore, assigning too many ports per CE router will result in 573 waste of public IPv4 addresses, which is a scarce and expensive 574 resource. Clearly this is a big advantage in the case of 464XLAT 575 where they are dynamically managed, so that the number of IPv4 576 addresses for the sharing-pool is smaller while the availability of 577 ports per user don't need to be pre-defined and is not a limitation 578 for them. 580 There is a direct tradeoff between the optimization of client port 581 allocations and the associated logging overhead. Section 4.7 582 discusses this in more depth. 584 We note that common CE router NAT44 implementations utilizing 585 Netfilter, multiplexes active sessions using a 3-tuple (source 586 address, destination address, and destination port). This means that 587 external source ports can be reused for unique internal source and 588 destination address and port sessions. It is also noted, that 589 Netfilter cannot currently make use of multiple source port ranges 590 (i.e. several blocks of ports distributed across the total port space 591 as is common in MAP deployments), this may influence the design when 592 using stateless technologies. 594 Stateful technologies, 464XLAT and DS-Lite (and also NAT444) can 595 therefore be much more efficient in terms of port allocation and thus 596 public IP address saving. The price is the stateful operation in the 597 service provider network, which allegedly does not scale up well. It 598 should be noticed that in many cases, all those factors may depend on 599 how it is actually implemented. 601 XXX MEASUREMENTS ARE PLANNED TO TEST IF THE ABOVE IS TRUE. XXX 602 We note that some CGN-type solutions can allocate ports dynamically 603 "on the fly". Depending on configuration, this can result in the 604 same customer being allocated ports from different source addresses. 605 This can cause operational issues for protocols and applications that 606 expect multiple flows to be sourced from the same address. E.g., 607 ECMP hashing, STUN, gaming, content delivery networks. However, it 608 should be noticed that this is the same problem when a network has a 609 NAT44 with multiple public IPv4 addresses, or even when applications 610 in a dual-stack case, behave wrongly if happy eyeballs is flapping 611 the flow address between IPv4 and IPv6. 613 The consequences of IPv4 address sharing [RFC6269] may impact all 614 five technologies. However, when ports are allocated statically, 615 more customers may get ports from the same public IPv4 address, which 616 may results in negative consequences with higher probability, e.g. 617 many applications and service providers (Sony PlayStation Network, 618 OpenDNS, etc.) permanently black-list IPv4 ranges if they detect that 619 they are used for address sharing. 621 Both cases are, again, implementation dependent. 623 We note that although it is not of typical use, one can do 624 deterministic, stateful NAT and reserve a fixed set of ports for each 625 customer, as well. 627 4.3. Support for Public Server Operation 629 Mechanisms that rely on operator side per-flow state do not, by 630 themselves, offer a way for customers to present services on publicly 631 accessible layer-4 ports. 633 Port Control Protocol (PCP) [RFC6877] provides a mechanism for a 634 client to request an external public port from a CGN device. For 635 server operation, it is required with NAT64/464XLAT, and it is 636 supported in some DS-Lite AFTR implementations. 638 A+P based mechanisms distribute a public IPv4 address and restricted 639 range of layer-4 ports to the client. In this case, it is possible 640 for the user to configure their device to offer a publicly accessible 641 server on one of their allocated ports. It should be noted that 642 commonly operators do not assign the Well-Known-Ports to users 643 (unless they are allocating a full IPv4 address), so the user will 644 need to run the service on an allocated port, or configure port 645 translation. 647 Lw4o6, MAP-E and MAP-T may be configured to allocated clients with a 648 full IPv4 address, allowing exclusive use of all ports, and non-port- 649 based layer 4 protocols. Thus, they may also be used to support 650 server/services operation on their default ports. However, when 651 public IPv4 addresses are assigned to the CE router without address 652 sharing, obviously there is no advantage in terms of IPv4 public 653 addresses saving. 655 It is also possible to configure specific ports mapping in 464XLAT/ 656 NAT64 using EAMT [RFC7757], which means that only those ports are 657 "lost" from the pool of addresses, so there is a higher maximization 658 of the total usage of IPv4/port resources. 660 4.4. Support and Implementations 662 4.4.1. OS Support 664 A 464XLAT client (CLAT) is implemented in Windows 10, Linux 665 (including Android), Windows Mobile, Chrome OS and iOS, but at the 666 time of writing is not available in MacOS. 668 The remaining four solutions are commonly deployed as functions in 669 the CE device only, however in general, except DS-Lite, the vendors 670 support is poor. 672 The OpenWRT Linux based open-source OS designed for CE devices offers 673 a number of different 'opkg' packages as part of the distribution: 675 o '464xlat' enables support for 464XLAT CLAT functionality 677 o 'ds-lite' enables support for DSLite B4 functionality 679 o 'map' enables support for MAP-E and lw4o6 CE functionality 681 o 'map-t' enables support for MAP-T CE functionality 683 For the operator side functionality, some free open-source 684 implementations exist: 686 CLAT, NAT64, EAMT: http://www.jool.mx 688 MAP-BR, lwAFTR, CGN, CLAT, NAT64: VPP/fd.io 689 https://gerrit.fd.io/r/#/admin/projects/ 691 lwAFTR: https://github.com/Igalia/snabb 693 DSLite AFTR: https://www.isc.org/downloads/ 695 4.4.2. Support in Cellular and Broadband Networks 697 Several cellular networks use 464XLAT, whereas we are not aware of 698 any deployment of the four other technologies in cellular networks, 699 as they are not implemented in UE devices. 701 In broadband networks, there are some deployments of 464XLAT, MAP-E 702 and MAP-T. lw4o6 and DS-Lite have more deployments, with DS-Lite 703 being the most common, but lw4o6 taking over in the last years. 705 4.4.3. Implementation Code Sizes 707 As hint to the relative complexity of the mechanisms, the following 708 code sizes are reported from the OpenWRT implementations of each 709 technology are 17kB, 35kB, 15kB, 35kB, and 48kB for 464XLAT, lw4o6, 710 DS-Lite, MAP-E, MAP-T, and lw4o6, respectively 711 (https://openwrt.org/packages/start). 713 We note that the support for all five technologies requires much less 714 code size than the total sum of the above quantities, because they 715 contain a lot of common functions (data plane is shared among several 716 of them). 718 4.5. Typical Deployment and Traffic Volume Considerations 720 4.5.1. Deployment Possibilities 722 Theoretically, all five IPv4aaS technologies could be used together 723 with DNS64 + stateful NAT64, as it is done in 464XLAT. In this case 724 the CE router would treat the traffic between an IPv6-only client and 725 IPv4-only server as normal IPv6 traffic, and the stateful NAT64 726 gateway would do a single translation, thus offloading this kind of 727 traffic from the IPv4aaS technology. The cost of this solution would 728 be the need for deploying also DNS64 + stateful NAT64. 730 However, this has not been implemented in clients or actual 731 deployments, so only 464XLAT always uses this optimization and the 732 other four solutions do not use it at all. 734 4.5.2. Cellular Networks with 464XLAT 736 Actual figures from existing deployments, show that the typical 737 traffic volumes in an IPv6-only cellular network, when 464XLAT 738 technology is used together with DNS64, are: 740 o 75% of traffic is IPv6 end-to-end (no translation) 742 o 24% of traffic uses DNS64 + NAT64 (1 translation) 743 o Less than 1% of traffic uses the CLAT in addition to NAT64 (2 744 translations), due to an IPv4 socket and/or IPv4 literal. 746 Without using DNS64, 25% of the traffic would undergo double 747 translation. 749 4.6. Load Sharing 751 If multiple network-side devices are needed as PLAT/AFTR/BR for 752 capacity, then there is a need for a load sharing mechanism. ECMP 753 (Equal-Cost Multi-Path) load sharing can be used for all 754 technologies, however stateful technologies will be impacted by 755 changes in network topology or device failure. 757 Technologies utilizing DNS64 can also distribute load across PLAT/ 758 AFTR devices, evenly or unevenly, by using different prefixes. 759 Different network specific prefixes can be distributed for 760 subscribers in appropriately sized segments (like split-horizon DNS, 761 also called DNS views). 763 Stateless technologies, due to the lack of per-flow state, can make 764 use of anycast routing for load sharing and resiliency across 765 network-devices, both ingress and egress; flows can take asymmetric 766 paths through the network, i.e., in through one lwAFTR/BR and out via 767 another. 769 Mechanisms with centralized NAPT44 state have a number of challenges 770 specifically related to scaling and resilience. As the total amount 771 of client traffic exceeds the capacity of a single CGN instance, 772 additional nodes are required to handle the load. As each CGN 773 maintains a stateful table of active client sessions, this table may 774 need to be syncronized between CGN instances. This is necessary for 775 two reasons: 777 o To prevent all active customer sessions being dropped in event of 778 a CGN node failure. 780 o To ensure a matching state table entry for an active session in 781 the event of asymmetric routing through different egress and 782 ingress CGN nodes. 784 4.7. Logging 786 In the case of 464XLAT and DS-Lite, the user of any given public IPv4 787 address and port combination will vary over time, therefore, logging 788 is necessary to meet data retention laws. Each entry in the PLAT/ 789 AFTR's generates a logging entry. As discussed in Section 4.2, a 790 client may open hundreds of sessions during common tasks such as web- 791 browsing, each of which needs to be logged so the overall logging 792 burden on the network operator is significant. In some countries, 793 this level of logging is required to comply with data retention 794 legislation. 796 One common optimization available to reduce the logging overhead is 797 the allocation of a block of ports to a client for the duration of 798 their session. This means that logging entry only needs to be made 799 when the client's port block is released, which dramatically reducing 800 the logging overhead. This comes as the cost of less efficient 801 public address sharing as clients need to be allocated a port block 802 of a fixed size regardless of the actual number of ports that they 803 are using. 805 Stateless technologies that pre-allocate the IPv4 addresses and ports 806 only require that copies of the active MAP rules (for MAP-E and MAP- 807 T), or binding-table (for lw4o6) are retained along with timestamp 808 information of when they have been active. Support tools (e.g., 809 those used to serve data retention requests) may need to be updated 810 to be aware of the mechanism in use (e.g., implementing the MAP 811 algorithm so that IPv4 information can be linked to the IPv6 prefix 812 delegated to a client). As stateless technologies do not have a 813 centralized stateful element which customer traffic needs to pass 814 through, so if data retention laws mandate per-session logging, there 815 is no simple way of meeting this requirement with a stateless 816 technology alone. Thus a centralized NAPT44 model may be the only 817 way to meet this requirement. 819 Deterministic CGN [RFC7422] was proposed as a solution to reduce the 820 resource consumption of logging. 822 4.8. Optimization for IPv4-only devices/applications 824 When IPv4-only devices or applications are behind a CE connected with 825 IPv6-only and IPv4aaS, the IPv4-only traffic flows will necessarily, 826 be encapsulated/decapsulated (in the case of DS-Lite, lw4o6 and MAP- 827 E) and will reach the IPv4 address of the destination, even if that 828 service supports dual-stack. This means that the traffic flow will 829 cross thru the AFTR, lwAFTR or BR, depending on the specific 830 transition mechanism being used. 832 Even if those services are directly connected to the operator network 833 (for example, CDNs, caches), or located internally (such as VoIP, 834 etc.), it is not possible to avoid that overhead. 836 However, in the case of those mechanism that use a NAT46 function, in 837 the CE (464XLAT and MAP-T), it is possible to take advantage of 838 optimization functionalities, such as the ones described in 839 [I-D.palet-v6ops-464xlat-opt-cdn-caches]. 841 Using those optimizations, because the NAT46 has already translated 842 the IPv4-only flow to IPv6, and the services are dual-stack, they can 843 be reached without the need to translate them back to IPv4. 845 5. Performance Comparison 847 We plan to compare the performances of the most prominent free 848 software implementations of the five IPv6 transition technologies 849 using the methodology described in "Benchmarking Methodology for IPv6 850 Transition Technologies" [RFC8219]. 852 The Dual DUT Setup of [RFC8219] makes it possible to use the existing 853 "Benchmarking Methodology for Network Interconnect Devices" [RFC2544] 854 compliant measurement devices, however, this solution has two kinds 855 of limitations: 857 o Dual DUT setup has the drawback that the performances of the CE 858 and of the ISP side device (e.g. the CLAT and the PLAT of 464XLAT) 859 are measured together. In order to measure the performance of 860 only one of them, we need to ensure that the desired one is the 861 bottleneck. 863 o Measurements procedures for PDV and IPDV measurements are missing 864 from the legacy devices, and the old measurement procedure for 865 Latency has been redefined in [RFC8219]. 867 The Single DUT Setup of [RFC8219] makes it possible to benchmark the 868 selected device separately, but it either requires a special Tester 869 or some trick is need, if we want to use legacy Testers. An example 870 for the latter is our stateless NAT64 measurements testing Througput 871 and Frame Loss Rate using a legacy [RFC5180] compliant commercial 872 tester [LEN2020] 874 Siitperf, an [RFC8219] compliant DPDK-based software Tester for 875 benchmarking stateless NAT64 gateways has been developed recently and 876 it is available from GitHub [SIITperf] as free software. 878 o It can be used for benchmarking both the CLAT and PLAT of 464XLAT 879 separately, according to the single DUT setup. (We note that the 880 benchmarking prodedures for stateful NAT64 include the stateless 881 tests, plus a few additional tests, which are not implemented 882 yet.) 884 o It can also be used for benchmarking all five IPv4-as-a-Service 885 technologies according to the Dual DUT setup, because it supports 886 the usage of IPv4 on its both sides, too. 888 Another software tester for benchmaring the B4 and AFTR components of 889 DS-Lite is currently being developed at the Budapest University of 890 Technology and Economics as a student project. It is planned to be 891 released as free software later this year. 893 We plan to start an intesive benchmaking campaign using the resources 894 of NICT StarBED, Japan. 896 6. Acknowledgements 898 The authors would like to thank Ole Troan for his thorough review of 899 this draft and acknowledge the inputs of Mark Andrews, Edwin 900 Cordeiro, Fred Baker, Alexandre Petrescu, Cameron Byrne, Tore 901 Anderson, Mikael Abrahamsson, Gert Doering, Satoru Matsushima, 902 Mohamed Boucadair, Tom Petch, Yannis Nikolopoulos, and TBD ... 904 7. IANA Considerations 906 This document does not make any request to IANA. 908 8. Security Considerations 910 According to the simplest model, the number of bugs is proportional 911 to the number of code lines. Please refer to Section 4.4.3 for code 912 sizes of CE implementations. 914 For all five technologies, the CE device should contain a DNS proxy. 915 However, the user may change DNS settings. If it happens and lw4o6, 916 MAP-E and MAP-T are used with significantly restricted port set, 917 which is required for an efficient public IPv4 address sharing, the 918 entropy of the source ports is significantly lowered (e.g. from 16 919 bits to 10 bits, when 1024 port numbers are assigned to each 920 subscriber) and thus these technologies are theoretically less 921 resilient against cache poisoning, see [RFC5452]. However, an 922 efficient cache poisoning attack requires that the subscriber 923 operates an own caching DNS server and the attack is performed in the 924 service provider network. Thus, we consider the chance of the 925 successful exploitation of this vulnerability as low. 927 An in-depth security analysis of all five IPv6 transition 928 technologies and their most prominent free software implementations 929 according to the methodology defined in [LEN2018] is planned. 931 9. References 933 9.1. Normative References 935 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 936 Requirement Levels", BCP 14, RFC 2119, 937 DOI 10.17487/RFC2119, March 1997, 938 . 940 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 941 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 942 December 1998, . 944 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 945 Network Interconnect Devices", RFC 2544, 946 DOI 10.17487/RFC2544, March 1999, 947 . 949 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 950 Translator (NAT) Terminology and Considerations", 951 RFC 2663, DOI 10.17487/RFC2663, August 1999, 952 . 954 [RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D. 955 Dugatkin, "IPv6 Benchmarking Methodology for Network 956 Interconnect Devices", RFC 5180, DOI 10.17487/RFC5180, May 957 2008, . 959 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 960 Resilient against Forged Answers", RFC 5452, 961 DOI 10.17487/RFC5452, January 2009, 962 . 964 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 965 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 966 DOI 10.17487/RFC6052, October 2010, 967 . 969 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 970 NAT64: Network Address and Protocol Translation from IPv6 971 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 972 April 2011, . 974 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 975 Beijnum, "DNS64: DNS Extensions for Network Address 976 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 977 DOI 10.17487/RFC6147, April 2011, 978 . 980 [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 981 Transition Mechanisms during IPv6 Deployment", RFC 6180, 982 DOI 10.17487/RFC6180, May 2011, 983 . 985 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 986 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 987 DOI 10.17487/RFC6269, June 2011, 988 . 990 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 991 Stack Lite Broadband Deployments Following IPv4 992 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 993 . 995 [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to 996 the IPv4 Address Shortage", RFC 6346, 997 DOI 10.17487/RFC6346, August 2011, 998 . 1000 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 1001 Combination of Stateful and Stateless Translation", 1002 RFC 6877, DOI 10.17487/RFC6877, April 2013, 1003 . 1005 [RFC6889] Penno, R., Saxena, T., Boucadair, M., and S. Sivakumar, 1006 "Analysis of Stateful 64 Translation", RFC 6889, 1007 DOI 10.17487/RFC6889, April 2013, 1008 . 1010 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 1011 the IPv6 Prefix Used for IPv6 Address Synthesis", 1012 RFC 7050, DOI 10.17487/RFC7050, November 2013, 1013 . 1015 [RFC7393] Deng, X., Boucadair, M., Zhao, Q., Huang, J., and C. Zhou, 1016 "Using the Port Control Protocol (PCP) to Update Dynamic 1017 DNS", RFC 7393, DOI 10.17487/RFC7393, November 2014, 1018 . 1020 [RFC7422] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., 1021 and O. Vautrin, "Deterministic Address Mapping to Reduce 1022 Logging in Carrier-Grade NAT Deployments", RFC 7422, 1023 DOI 10.17487/RFC7422, December 2014, 1024 . 1026 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 1027 Farrer, "Lightweight 4over6: An Extension to the Dual- 1028 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 1029 July 2015, . 1031 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 1032 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 1033 Port with Encapsulation (MAP-E)", RFC 7597, 1034 DOI 10.17487/RFC7597, July 2015, 1035 . 1037 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 1038 and T. Murakami, "Mapping of Address and Port using 1039 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 1040 2015, . 1042 [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address 1043 Mappings for Stateless IP/ICMP Translation", RFC 7757, 1044 DOI 10.17487/RFC7757, February 2016, 1045 . 1047 [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, 1048 "IP/ICMP Translation Algorithm", RFC 7915, 1049 DOI 10.17487/RFC7915, June 2016, 1050 . 1052 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1053 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1054 . 1056 [RFC8114] Boucadair, M., Qin, C., Jacquenet, C., Lee, Y., and Q. 1057 Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients 1058 over an IPv6 Multicast Network", RFC 8114, 1059 DOI 10.17487/RFC8114, March 2017, 1060 . 1062 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1063 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1064 May 2017, . 1066 [RFC8219] Georgescu, M., Pislaru, L., and G. Lencse, "Benchmarking 1067 Methodology for IPv6 Transition Technologies", RFC 8219, 1068 DOI 10.17487/RFC8219, August 2017, 1069 . 1071 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1072 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1073 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1074 RFC 8415, DOI 10.17487/RFC8415, November 2018, 1075 . 1077 [RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C., 1078 Vinapamula, S., and Q. Wu, "A YANG Module for Network 1079 Address Translation (NAT) and Network Prefix Translation 1080 (NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019, 1081 . 1083 [RFC8683] Palet Martinez, J., "Additional Deployment Guidelines for 1084 NAT64/464XLAT in Operator and Enterprise Networks", 1085 RFC 8683, DOI 10.17487/RFC8683, November 2019, 1086 . 1088 9.2. Informative References 1090 [I-D.palet-v6ops-464xlat-opt-cdn-caches] 1091 Palet, J. and A. D'Egidio, "464XLAT Optimization", draft- 1092 palet-v6ops-464xlat-opt-cdn-caches-04 (work in progress), 1093 November 2019. 1095 [LEN2018] Lencse, G. and Y. Kadobayashi, "Methodology for the 1096 identification of potential security issues of different 1097 IPv6 transition technologies: Threat analysis of DNS64 and 1098 stateful NAT64", Computers & Security (Elsevier), vol. 1099 77, no. 1, pp. 397-411, DOI: 10.1016/j.cose.2018.04.012, 1100 Aug 2018, . 1103 [LEN2019] Lencse, G. and Y. Kadobayashi, "Comprehensive Survey of 1104 IPv6 Transition Technologies: A Subjective Classification 1105 for Security Analysis", IEICE Transactions on 1106 Communications, vol. E102-B, no.10, pp. 2021-2035., DOI: 1107 10.1587/transcom.2018EBR0002, Oct 2019, 1108 . 1111 [LEN2020] Lencse, G., "Benchmarking Stateless NAT64 Implementations 1112 with a Standard Tester", under review in (Springer) 1113 Telecommunication Systems, 1114 . 1117 [MIY2010] Miyakawa, S., "IPv4 to IPv6 transformation 1118 schemes", IEICE Trans. Commun., vol.E93-B, no.5, pp. 1119 1078-1084, DOI:10.1587/transcom.E93.B.10, May 2010, 1120 . 1123 [REP2014] Repas, S., Hajas, T., and G. Lencse, "Port number 1124 consumption of the NAT64 IPv6 transition 1125 technology", Proc. 37th Internat. Conf. on 1126 Telecommunications and Signal Processing (TSP 2014), 1127 Berlin, Germany, DOI: 10.1109/TSP.2015.7296411, July 1128 2014. 1130 [SIITperf] 1131 Lencse, G., "Siitperf: an RFC 8219 compliant SIIT 1132 (stateless NAT64) tester", November 2019, 1133 . 1135 Appendix A. Change Log 1137 A.1. 01 - 02 1139 o Ian Farrer has joined us as an author. 1141 o Restructuring: the description of the five IPv4aaS technologies 1142 was moved to a separate section. 1144 o More details and figures were added to the description of the five 1145 IPv4aaS technologies. 1147 o Section titled "High-level Architectures and their Consequences" 1148 has been completely rewritten. 1150 o Several additions/clarification throughout Section titled 1151 "Detailed Analysis". 1153 o Section titled "Performance Analysis" was dropped due to lack of 1154 results yet. 1156 o Word based text ported to XML. 1158 o Further text cleanups, added text on state sync and load 1159 balancing. Additional comments inline that should be considered 1160 for future updates. 1162 A.2. 02 - 03 1164 o The suggestions of Mohamed Boucadair are incorporated. 1166 o New considerations regarding possible optimizations. 1168 A.3. 03 - 04 1170 o Section titled "Performance Analysis" was added. It mentions our 1171 new benchmarking tool, siitperf, and highlights our plans. 1173 o Some references were updated or added. 1175 Authors' Addresses 1177 Gabor Lencse 1178 Budapest University of Technology and Economics 1179 Magyar Tudosok korutja 2. 1180 Budapest H-1117 1181 Hungary 1183 Email: lencse@hit.bme.hu 1185 Jordi Palet Martinez 1186 The IPv6 Company 1187 Molino de la Navata, 75 1188 La Navata - Galapagar, Madrid 28420 1189 Spain 1191 Email: jordi.palet@theipv6company.com 1192 URI: http://www.theipv6company.com/ 1194 Lee Howard 1195 Retevia 1196 9940 Main St., Suite 200 1197 Fairfax, Virginia 22031 1198 USA 1200 Email: lee@asgard.org 1201 Richard Patterson 1202 Sky UK 1203 1 Brick Lane 1204 London EQ 6PU 1205 United Kingdom 1207 Email: richard.patterson@sky.uk 1209 Ian Farrer 1210 Deutsche Telekom AG 1211 Landgrabenweg 151 1212 Bonn 53227 1213 Germany 1215 Email: ian.farrer@telekom.de