idnits 2.17.1 draft-lmhp-v6ops-transition-comparison-02.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 (January 24, 2019) is 1920 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-v6ops-nat64-deployment-03 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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 28, 2019 The IPv6 Company 6 L. Howard 7 Retevia 8 R. Patterson 9 Sky UK 10 I. Farrer 11 Deutsche Telekom AG 12 January 24, 2019 14 Pros and Cons of IPv6 Transition Technologies for IPv4aaS 15 draft-lmhp-v6ops-transition-comparison-02 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 28, 2019. 48 Copyright Notice 50 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . 9 77 3.4. CE Provisioning Considerations . . . . . . . . . . . . . 10 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 . . . . . 15 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 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 95 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 97 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 98 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 99 8.2. Informative References . . . . . . . . . . . . . . . . . 21 100 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 22 101 A.1. 01 - 02 . . . . . . . . . . . . . . . . . . . . . . . . . 22 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 104 1. Introduction 106 As the deployment of IPv6 becomes more prevalent, it follows that 107 network operators will move to building single-stack IPv6 core and 108 access networks to simplify network planning and operations. 109 However, providing customers with IPv4 services continues to be a 110 requirement for the foreseeable future. To meet this need, the IETF 111 has standardized a number of different IPv4aaS technologies for this 112 [LEN2017] based on differing requirements and deployment scenarios. 114 The number of technologies that have been developed makes it time 115 consuming for a network operator to identify the most appropriate 116 mechanism for their specific deployment. This document provides a 117 comparative analysis of the most commonly used mechanisms to assist 118 operators with this problem. 120 Five different IPv4aaS solutions are considered. The following IPv6 121 transition technologies are covered: 123 1. 464XLAT [RFC6877] 125 2. Dual Stack Lite [RFC6333] 127 3. lw4o6 (Lightweight 4over6) [RFC7596] 129 4. MAP-E [RFC7597] 131 5. MAP-T [RFC7599] 133 1.1. Requirements Language 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 137 "OPTIONAL" in this document are to be interpreted as described in 138 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 139 capitals, as shown here. 141 2. Overview of the Technologies 143 The following sections introduce the different technologies analyzed 144 in this document, describing some of their most important 145 characteristics. 147 2.1. 464XLAT 149 464XLAT is a single/dual translation model, which uses a customer- 150 side translator (CLAT) located in the customer's device to perform 151 stateless NAT64 translation [RFC7915] (more precisely, stateless 152 NAT46, a stateless IP/ICMP translation from IPv4 to IPv6). 153 IPv4-embedded IPv6 addresses [RFC6052] are used for both source and 154 destination addresses. Commonly, a /96 prefix (either the 155 64:ff9b::/96 Well-Known Prefix, or a Network-Specific Prefix) is used 156 as the IPv6 destination for the IPv4-embedded client traffic. 158 In the operator's network, the provider-side translator (PLAT) 159 performs stateful NAT64 [RFC6146] to translate the traffic. The 160 destination IPv4 address is extracted from the IPv4-embedded IPv6 161 packet destination address and the source address is from a pool of 162 public IPv4 addresses. 164 Alternatively, when a dedicated /64 is not available for translation, 165 the CLAT device uses a stateful NAT44 translation before the 166 stateless NAT46 translation. 168 Note that we generally do not see state close to the end-user as 169 equally problematic as state in the middle of the network. 171 In typical deployments, 464XLAT is used together with DNS64, see 172 Section 3.1.2 of [I-D.ietf-v6ops-nat64-deployment]. When an 173 IPv6-only client or application communicates with an IPv4-only 174 server, the DNS64 server returns the IPv4-embedded IPv6 address of 175 the IPv4-only server. In this case, the IPv6-only client sends out 176 IPv6 packets, thus CLAT functions as an IPv6 router and the PLAT 177 performs a stateful NAT64 for these packets. In this case, there is 178 a single translation. 180 Alternatively, one can say that the DNS64 + stateful NAT64 is used to 181 carry the traffic of the IPv6-only client and the IPv4-only server, 182 and the CLAT is used only for the IPv4 traffic from applications or 183 devices that use literal IPv4 addresses or non-IPv6 compliant APIs. 185 Private +----------+ Translated +----------+ _______ 186 +------+ IPv4 | CLAT | 4-6-4 | Stateful | ( IPv4 ) 187 | IPv4 |------->| Stateless|------------>| PLAT +--( Internet ) 188 |Device|<-------| NAT46 |<------------| NAT64 | (________) 189 +------+ +----------+ ^ +----------+ 190 | 191 Operator IPv6 192 network 194 Figure 1: Overview of the 464XLAT architecture 196 Note: in mobile networks, CLAT is commonly implemented in the user's 197 equipment (UE or smartphone). 199 2.2. Dual-Stack Lite 201 Dual-Stack Lite (DS-Lite) [RFC6333] was the first of the considered 202 transition mechanisms to be developed. DS-Lite uses a 'Basic 203 Broadband Bridging' (B4) function in the customer's CE router that 204 encapsulates IPv4 in IPv6 traffic and sends it over the IPv6 native 205 service-provider network to a centralized 'Address Family Transition 206 Router' (AFTR). The AFTR performs encapsulation/decapsulation of the 207 4in6 traffic and translates the IPv4 payload to public IPv4 source 208 address using a stateful NAPT44 function. 210 +-------------+ 211 Private +----------+ IPv4-in-IPv6|Stateful AFTR| 212 +------+ IPv4 | B4 | tunnel |------+------+ _______ 213 | IPv4 |------->| Encap./ |------------>|Encap.| | ( IPv4 ) 214 |Device|<-------| decap. |<------------| / | NAPT +--( Internet ) 215 +------+ +----------+ ^ |Decap.| 44 | (________) 216 | +------+------+ 217 Operator IPv6 218 network 220 Figure 2: Overview of the DS-Lite architecture 222 2.3. Lightweight 4over6 224 Lightweight 4over6 (lw4o6) is a variant of DS-Lite. The main 225 difference is that the stateful NAPT44 function is relocated from the 226 centralized AFTR to the customer's B4 element (called a lwB4). The 227 AFTR (called a lwAFTR) function therefore only performs A+P routing 228 and 4in6 encapsulation/decapsulation. 230 Routing to the correct client and IPv4 address sharing is achieved 231 using the Address + Port (A+P) model [RFC6346] of provisioning each 232 lwB4 with a unique tuple of IPv4 address unique range of layer-4 233 ports. The client uses these for NAPT44. 235 The lwAFTR implements a binding table, which has a per-client entry 236 linking the customer's source IPv4 address and allocated range of 237 layer-4 ports to their IPv6 tunnel endpoint address. The binding 238 table allows egress traffic from customers to be validated (to 239 prevent spoofing) and ingress traffic to be correctly encapsulated 240 and forwarded. As there needs to be a per-client entry, an lwAFTR 241 implementation needs to be optimized for performing a per-packet 242 lookup on the binding table. 244 Direct communication between two lwB4s is performed by hair-pinning 245 traffic through the lwAFTR. 247 +-------------+ +----------+ 248 Private | lwB4 | IPv4-in-IPv6| Stateless| 249 +------+ IPv4 |------+------| tunnel | lwAFTR | _______ 250 | IPv4 |------->| |Encap.|------------>|(encap/A+P| ( IPv4 ) 251 |Device|<-------| NAPT | / |<------------|bind. tab +--( Internet ) 252 +------+ | 44 |Decap.| ^ | routing) | (________) 253 +------+------+ | +----------+ 254 Operator IPv6 255 network 257 Figure 3: Overview of the lw4o6 architecture 259 2.4. MAP-E 261 MAP-E uses a stateless algorithm to embed portions of the customer's 262 allocated IPv4 address (or part of an address with A+P routing) into 263 the IPv6 prefix delegated to the client. This allows for large 264 numbers of clients to be provisioned using a single MAP rule (called 265 a MAP domain). The algorithm also allows for direct IPv4 peer-to- 266 peer communication between hosts provisioned with common MAP rules. 268 The CE (Customer-Edge) router typically performs stateful NAPT44 269 [RFC2663] to translate the private IPv4 source addresses and source 270 ports into an address and port range defined by applying the MAP rule 271 applied to the delegated IPv6 prefix. The client address/port 272 allocation size is a design parameter. The CE router then 273 encapsulates the IPv4 packet in an IPv6 packet [RFC2473] and sends it 274 directly to another host in the MAP domain (for peer-to-peer) or to a 275 Border Router (BR) if the IPv4 destination is not covered in one of 276 the CE's MAP rules. 278 The MAP BR is provisioned with the set of MAP rules for the MAP 279 domains it serves. These rules determine how the MAP BR is to 280 decapsulate traffic that it receives from client, validating the 281 source IPv4 address and layer 4 ports assigned, as well as how to 282 calculate the destination IPv6 address for ingress IPv4 traffic. 284 +-------------+ +----------+ 285 Private | MAP CE | IPv4-in-IPv6| Stateless| 286 +------+ IPv4 |------+------| tunnel | MAP BR | _______ 287 | IPv4 |------->| |Encap.|------------>|(encap/A+P| ( IPv4 ) 288 |Device|<-------| NAPT | / |<------------|algorithm +--( Internet ) 289 +------+ | 44 |Decap.| ^ | routing) | (________) 290 +------+------+ | +----------+ 291 Operator IPv6 292 network 294 Figure 4: Overview of the MAP-E architecture 296 2.5. MAP-T 298 MAP-T uses the same mapping algorithm as MAP-E. The major difference 299 is that double stateless translation (NAT46 in the CE and NAT64 in 300 the BR) is used to traverse the ISP's IPv6 single-stack network. 301 MAP-T can also be compared to 464XLAT when there is a double 302 translation. 304 A MAP CE typically performs stateful NAPT44 to translate traffic to a 305 public IPv4 address and port-range calculated by applying the 306 provisioned Basic MAP Rule (BMR - a set of inputs to the algorithm) 307 to the delegated IPv6 prefix. The CE then performs stateless 308 translation from IPv4 to IPv6 [RFC7915]. The MAP BR is provisioned 309 with the same BMR as the client, enabling the received IPv6 traffic 310 to be statelessly NAT64 translated back to the public IPv4 source 311 address used by the client. 313 Using translation instead of encapsulation also allows IPv4-only 314 nodes to correspond directly with IPv6 nodes in the MAP-T domain that 315 have IPv4-embedded IPv6 addresses. 317 +-------------+ +----------+ 318 Private | MAP CE | Translated | Stateless| 319 +------+ IPv4 |------+------| 4-6-4 | MAP BR | _______ 320 | IPv4 |------->| |State-|------------>|(NAT64/A+P| ( IPv4 ) 321 |Device|<-------| NAPT | less |<------------|algorithm +--( Internet ) 322 +------+ | 44 |NAT46 | ^ | routing) | (________) 323 +------+------+ | +----------+ 324 Operator IPv6 325 network 327 Figure 5: Overview of the MAP-T architecture 329 3. High-level Architectures and their Consequences 331 3.1. Service Provider Network Traversal 333 For the data-plane, there are two approaches for traversing the IPv6 334 provider network: 336 o 4-6-4 translation 338 o 4-in-6 encapsulation 340 +--------------+---------+---------+-------+-------+-------+ 341 | | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T | 342 +--------------+---------+---------+-------+-------+-------+ 343 | 4-6-4 trans. | X | | | | X | 344 | 4-6-4 encap. | | X | X | X | | 345 +--------------+---------+---------+-------+-------+-------+ 347 Table 1: Available Traversal Mechanisms 349 In the scope of this document, all of the encapsulation based 350 mechanisms use IP-in-IP tunnelling [RFC2473]. This is a stateless 351 tunneling mechanism which does not require any additional tunnel 352 headers. 354 It should be noted that both of these approaches result in an 355 increase in the size of the packet that needs to be transported 356 across the operator's network when compared to native IPv4. 4-6-4 357 translation adds a 20-bytes overhead (the 20-byte IPv4 header is 358 replaced with a 40-byte IPv6 header). Encapsulation has a 40-byte 359 overhead (an IPv6 header is prepended to the IPv4 header). 361 The increase in packet size can become a significant problem if there 362 is a link with a smaller MTU in the traffic path. This may result in 363 traffic needing to be fragmented at the ingress point to the IPv6 364 only domain (i.e., the NAT46 or 4in6 encapsulation endpoint). It may 365 also result in the need to implement buffering and fragment re- 366 assembly in the BR node. 368 The advice given in [RFC7597] Section 8.3.1 is applicable to all of 369 these mechanisms: It is strongly recommended that the MTU in the 370 IPv6-only domain be well managed and that the IPv6 MTU on the CE WAN- 371 side interface be set so that no fragmentation occurs within the 372 boundary of the IPv6-only domain. 374 3.2. Network Address Translation 376 For the high-level solution of IPv6 service provider network 377 traversal, MAP-T uses double stateless translation. First at the CE 378 from IPv4 to IPv6 (NAT46), and then from IPv6 to IPv4 (NAT64), at the 379 service provider network. 381 464XLAT may use double translation (stateless NAT46 + stateful NAT64) 382 or single translation (stateful NAT64), depending on different 383 factors, such as the use of DNS by the applications and the 384 availability of a DNS64 function (in the host or in the service 385 provider network). For deployment guidelines, please refer to 386 [I-D.ietf-v6ops-nat64-deployment]. 388 The first step for the double translation mechanisms is a stateless 389 NAT from IPv4 to IPv6 implemented as SIIT (Stateless IP/ICMP 390 Translation Algorithm) [RFC7915], which does not translate IPv4 391 header options and/or multicast IP/ICMP packets. With encapsulation- 392 based technologies the header is transported intact and multicast can 393 also be carried. 395 Single and double translation results in native IPv6 traffic with a 396 layer-4 next-header. The fields in these headers can be used for 397 functions such as hashing across equal-cost multipaths or ACLs. For 398 encapsulation, there is an IPv6 header followed by an IPv4 header. 399 This results in less entropy for hashing algorithms, and may mean 400 that devices in the traffic path that perform header inspection (e.g. 401 router ACLs or firewalls) require the functionality to look into the 402 payload header. 404 Solutions using double translation can only carry port-aware IP 405 protocols (e.g. TCP, UDP) and ICMP when they are used with IPv4 406 address sharing (please refer to Section 4.3 for more details). 407 Encapsulation based solutions can carry any other protocols over IP, 408 too. 410 3.3. IPv4 Address Sharing 412 As public IPv4 address exhaustion is a common motivation for 413 deploying IPv6, transition technologies need to provide a solution 414 for allowing public IPv4 address sharing. 416 In order to fullfill this requirement, a stateful NAPT function is a 417 necessary function in all of the mechanisms. The major 418 differentiator is where in the the architecture this function is 419 located. 421 The solutions compared by this document fall into two categories: 423 o Centralized Stateful NAPT44 (DS-Lite, 464XLAT) 425 o Distributed Stateful NAPT44 (lw4o6, MAP-E, MAP-T) 427 In the centralized model, a device such as a CGN/AFTR or NAT64 428 performs the NAPT44 function and maintains per-session state for all 429 of the active client's traffic. The customer's device does not 430 require per-session state for NAPT. 432 In the distributed model, a device (usually a CE) performs stateful 433 NAPT44 and maintains per-session state only co-located devices, e.g. 434 in the customer's home network. Here, the centralised network 435 function (lwAFTR or BR) only needs to perform stateless 436 encapsulation/decapsulation or NAT64. 438 However, it is also worth noting that if the data retention 439 regulatory requirements in force mandate per-flow logging, then a 440 centralised NAPT44 model may be the only way to meet this 441 requirement. 443 Issues related to IPv4 address sharing mechanisms are described in 444 [RFC6269] and should also be considered. 446 The address sharing efficiency of the five technologies is 447 significantly different, it is discussed in Section 4.2 449 lw4o6, MAP-E and MAP-T can also be configured without IPv4 address 450 sharing, see the details in Section 4.3. However, in that case, 451 there is no advantage in terms of public IPv4 address saving. In the 452 case of 464XLAT, this can be achieved as well through EAMT [RFC7757]. 454 Conversely, both MAP-E and MAP-T may be configured to provide more 455 than one public IPv4 address (i.e., an IPv4 prefix shorter than a 456 /32) to customers. 458 3.4. CE Provisioning Considerations 460 All of the technologies require some provisioning of customer 461 devices. The table below shows which protocols currently have 462 extensions for provisioning the different mechanisms. 464 +------------------+---------+---------+-------+-------+-------+ 465 | | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T | 466 +------------------+---------+---------+-------+-------+-------+ 467 | DHCPv6 [RFC8415] | | X | X | X | X | 468 | RADIUS Attr. | | X | X | X | X | 469 | TR-69 | X | X | | X | X | 470 | DNS64 [RFC6147] | X | | | | | 471 | YANG [RFC6050] | | X | X | X | X | 472 | DHCP4o6 | | | X | X | | 473 +------------------+---------+---------+-------+-------+-------+ 475 Table 2: Available Provisioning Mechanisms 477 3.5. Support for Multicast 479 The solutions covered in this document are all intended for unicast 480 traffic. [RFC8114] describes a method for carrying encapsulated IPv4 481 multicast traffic over an IPv6 multicast network. This could be 482 deployed in parallel to any of the operator's chosen IPv4aaS 483 mechanism. 485 4. Detailed Analysis 487 4.1. Architectural Differences 489 4.1.1. Basic Comparison 491 The five IPv4aaS technologies can be classified into 2x2=4 categories 492 on the basis of two aspects: 494 o Technology used for service provider network traversal. It can be 495 single/double translation or encapsulation. 497 o Presence or absence of NAPT44 per-flow state in the operator 498 network. 500 +-----------------------+---------+---------+-------+-------+-------+ 501 | | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T | 502 +-----------------------+---------+---------+-------+-------+-------+ 503 | 4-6-4 trans. | X | | | | X | 504 | 4-in-4 encap. | | X | X | X | | 505 | Per-flow state in op. | X | X | | | | 506 | network | | | | | | 507 +-----------------------+---------+---------+-------+-------+-------+ 509 Table 3: Available Provisioning Mechanisms 511 4.2. Tradeoff between Port Number Efficiency and Stateless Operation 513 464XLAT and DS-Lite use stateful NAPT at the PLAT/AFTR devices, 514 respectively. This may cause scalability issues for the number of 515 clients or volume of traffic, but does not impose a limitation on the 516 number of ports per user, as they can be allocated dynamically on- 517 deman and the allocation policy can be centrally managed/adjusted. 519 A+P based mechanisms (Lw4o6, MAP-E, and MAP-T) avoid using NAPT in 520 the service provider network. However, this means that the number of 521 ports provided to each user (and hence the effective IPv4 address 522 sharing ratio) must be pre-provisioned to the client. 524 Changing the allocated port ranges with A+P based technologies, 525 requires more planning and is likely to involve re-provisioning both 526 hosts and operator side equipment. It should be noted that due to 527 the per-customer binding table entry used by lw4o6, a single customer 528 can be re-provisioned (e.g., if they request a full IPv4 address) 529 without needing to change parameters for a number of customers as in 530 a MAP domain. 532 It is also worth noting that there is a direct relationship between 533 the efficiency of customer public port-allocations and the 534 corresponding logging overhead that may be necessary to meet data- 535 retention requirements. This is considered in Section 4.7 below. 537 Determining the optimal number of ports for a fixed port set is not 538 an easy task, and may also be impacted by local regulatory law, which 539 may define a maximum number of users per IP address, and consequently 540 a minimum number of ports per user. 542 On the one hand, the "lack of ports" situation may cause serious 543 problems in the operation of certain applications. For example, 544 Miyakawa has demonstrated the consequences of the session number 545 limitation due to port number shortage on the example of Google Maps 546 [MIY2010]. When the limit was 15, several blocks of the map were 547 missing, and the map was unusable. This study also provided several 548 examples for the session numbers of different applications (the 549 highest one was Apple's iTunes: 230-270 ports). 551 The port number consumption of different applications is highly 552 varying and e.g. in the case of web browsing it depends on several 553 factors, including the choice of the web page, the web browser, and 554 sometimes even the operating system [REP2014]. For example, under 555 certain conditions, 120-160 ports were used (URL: sohu.com, browser: 556 Firefox under Ubuntu Linux), and in some other cases it was only 3-12 557 ports (URL: twitter.com, browser: Iceweasel under Debian Linux). 559 There may be several users behind a CE router, especially in the 560 broadband case (e.g. Internet is used by different members of a 561 family simultaneously), so sufficient ports must be allocated to 562 avoid impacting user experience. 564 Furthermore, assigning too many ports per CE router will result in 565 waste of public IPv4 addresses, which is a scarce and expensive 566 resource. Clearly this is a big advantage in the case of 464XLAT 567 where they are dynamically managed, so that the number of IPv4 568 addresses for the sharing-pool is smaller while the availability of 569 ports per user don't need to be pre-defined and is not a limitation 570 for them. 572 There is a direct tradeoff between the optimization of client port 573 allocations and the associated logging overhead. Section 4.7 574 discusses this in more depth. 576 We note that common CE router NAT44 implementations utilizing 577 Netfilter, multiplexes active sessions using a 3-tuple (source 578 address, destination address, and destination port). This means that 579 external source ports can be reused for unique internal source and 580 destination address and port sessions. It is also noted, that 581 Netfilter cannot currently make use of multiple source port ranges 582 (i.e. several blocks of ports distributed across the total port space 583 as is common in MAP deployments), this may influence the design when 584 using stateless technologies. 586 Stateful technologies, 464XLAT and DS-Lite (and also NAT444) can 587 therefore be much more efficient in terms of port allocation and thus 588 public IP address saving. The price is the stateful operation in the 589 service provider network, which allegedly does not scale up well. It 590 should be noticed that in many cases, all those factors may depend on 591 how it is actually implemented. 593 XXX MEASUREMENTS ARE PLANNED TO TEST IF THE ABOVE IS TRUE. XXX 595 We note that some CGN-type solutions can allocate ports dynamically 596 "on the fly". Depending on configuration, this can result in the 597 same customer being allocated ports from different source addresses. 598 This can cause operational issues for protocols and applications that 599 expect multiple flows to be sourced from the same address. E.g., 600 ECMP hashing, STUN, gaming, content delivery networks. However, it 601 should be noticed that this is the same problem when a network has a 602 NAT44 with multiple public IPv4 addresses, or even when applications 603 in a dual-stack case, behave wrongly if happy eyeballs is flapping 604 the flow address between IPv4 and IPv6. 606 The consequences of IPv4 address sharing [RFC6269] may impact all 607 five technologies. However, when ports are allocated statically, 608 more customers may get ports from the same public IPv4 address, which 609 may results in negative consequences with higher probability, e.g. 610 many applications and service providers (Sony PlayStation Network, 611 OpenDNS, etc.) permanently black-list IPv4 ranges if they detect that 612 they are used for address sharing. 614 Both cases are, again, implementation dependent. 616 We note that although it is not of typical use, one can do 617 deterministic, stateful NAT and reserve a fixed set of ports for each 618 customer, as well. 620 4.3. Support for Public Server Operation 622 Mechanisms that rely on operator side per-flow state do not, by 623 themselves, offer a way for customers to present services on publicly 624 accessible layer-4 ports. 626 Port Control Protocol (PCP) [RFC6877] provides a mechanism for a 627 client to request an external public port from a CGN device and is 628 supported in some DS-Lite AFTR implementations. 630 A+P based mechanisms distribute a public IPv4 address and restricted 631 range of layer-4 ports to the client. In this case, it is possible 632 for the user to configure their device to offer a publicly accessible 633 server on one of their allocated ports. It should be noted that 634 commonly operators do not assign the Well-Known-Ports to users 635 (unless they are allocating a full IPv4 address), so the user will 636 need to run the service on an allocated port, or configure port 637 translation. 639 Lw4o6, MAP-E and MAP-T may be configured to allocated clients with a 640 full IPv4 address, allowing exclusive use of all ports, and non-port- 641 based layer 4 protocols. Thus, they may also be used to support 642 server/services operation on their default ports. However, when 643 public IPv4 addresses are assigned to the CE router without address 644 sharing, obviously there is no advantage in terms of IPv4 public 645 addresses saving. 647 It is also possible to configure specific ports mapping in 464XLAT/ 648 NAT64 using EAMT [RFC7757], which means that only those ports are 649 "lost" from the pool of addresses, so there is a higher maximization 650 of the total usage of IPv4/port resources. 652 4.4. Support and Implementations 654 4.4.1. OS Support 656 A 464XLAT client (CLAT) is implemented in Windows 10, Linux 657 (including Android), Windows Mobile, Chrome OS and iOS, but at the 658 time of writing is not available in MacOS. 660 The remaining four solutions are commonly deployed as functions in 661 the CE device only, however in general, except DS-Lite, the vendors 662 support is poor. 664 The OpenWRT Linux based open-source OS designed for CE devices offers 665 a number of different 'opkg' packages as part of the distribution: 667 o '464xlat' enables support for 464XLAT CLAT functionality 669 o 'ds-lite' enables support for DSLite B4 functionality 671 o 'map' enables support for MAP-E and lw4o6 CE functionality 673 o 'map-t' enables support for MAP-T CE functionality 675 For the operator side functionality, some free open-source 676 implementations exist: 678 CLAT, NAT64, EAMT: http://www.jool.mx 680 MAP-BR, lwAFTR, CGN, CLAT, NAT64: VPP/fd.io 681 https://gerrit.fd.io/r/#/admin/projects/ 683 lwAFTR: https://github.com/Igalia/snabb 685 DSLite AFTR: https://www.isc.org/downloads/ 687 4.4.2. Support in Cellular and Broadband Networks 689 Several cellular networks use 464XLAT, whereas we are not aware of 690 any deployment of the four other technologies in cellular networks, 691 as they are not implemented in UE devices. 693 In broadband networks, there are some deployments of 464XLAT, MAP-E 694 and MAP-T. lw4o6 and DS-Lite have more deployments, with DS-Lite 695 being the most common, but lw4o6 taking over in the last years. 697 4.4.3. Implementation Code Sizes 699 As hint to the relative complexity of the mechanisms, the following 700 code sizes are reported from the OpenWRT implementations of each 701 technology are 17kB, 35kB, 15kB, 35kB, and 48kB for 464XLAT, lw4o6, 702 DS-Lite, MAP-E, MAP-T, and lw4o6, respectively 703 (https://openwrt.org/packages/start). 705 We note that the support for all five technologies requires much less 706 code size than the total sum of the above quantities, because they 707 contain a lot of common functions (data plane is shared among several 708 of them). 710 4.5. Typical Deployment and Traffic Volume Considerations 712 4.5.1. Deployment Possibilities 714 Theoretically, all five IPv4aaS technologies could be used together 715 with DNS64 + stateful NAT64, as it is done in 464XLAT. In this case 716 the CE router would treat the traffic between an IPv6-only client and 717 IPv4-only server as normal IPv6 traffic, and the stateful NAT64 718 gateway would do a single translation, thus offloading this kind of 719 traffic from the IPv4aaS technology. The cost of this solution would 720 be the need for deploying also DNS64 + stateful NAT64. 722 However, this has not been implemented in clients or actual 723 deployments, so only 464XLAT always uses this optimization and the 724 other four solutions do not use it at all. 726 4.5.2. Cellular Networks with 464XLAT 728 Actual figures from existing deployments, show that the typical 729 traffic volumes in an IPv6-only cellular network, when 464XLAT 730 technology is used together with DNS64, are: 732 o 75% of traffic is IPv6 end-to-end (no translation) 734 o 24% of traffic uses DNS64 + NAT64 (1 translation) 736 o Less than 1% of traffic uses the CLAT in addition to NAT64 (2 737 translations), due to an IPv4 socket and/or IPv4 literal. 739 Without using DNS64, 25% of the traffic would undergo double 740 translation. 742 4.6. Load Sharing 744 If multiple network-side devices are needed as PLAT/AFTR/BR for 745 capacity, then there is a need for a load sharing mechanism. ECMP 746 (Equal-Cost Multi-Path) load sharing can be used for all 747 technologies, however stateful technologies will be impacted by 748 changes in network topology or device failure. 750 Technologies utilizing DNS64 can also distribute load across PLAT/ 751 AFTR devices, evenly or unevenly, by using different prefixes. 752 Different network specific prefixes can be distributed for 753 subscribers in appropriately sized segments (like split-horizon DNS, 754 also called DNS views). 756 Stateless technologies, due to the lack of per-flow state, can make 757 use of anycast routing for load sharing and resiliency across 758 network-devices, both ingress and egress; flows can take asymmetric 759 paths through the network, i.e., in through one lwAFTR/BR and out via 760 another. 762 Mechanisms with centralized NAPT44 state have a number of challenges 763 specifically related to scaling and resilience. As the total amount 764 of client traffic exceeds the capacity of a single CGN instance, 765 additional nodes are required to handle the load. As each CGN 766 maintains a stateful table of active client sessions, this table may 767 need to be syncronised between CGN instances. This is necessary for 768 two reasons: 770 o To prevent all active customer sessions being dropped in event of 771 a CGN node failure. 773 o To ensure a matching state table entry for an active session in 774 the event of asymetric routing through different egress and 775 ingress CGN nodes. 777 4.7. Logging 779 In the case of 464XLAT and DS-Lite, the user of any given public IPv4 780 address and port combination will will vary over time, therefore, 781 logging is necessary to meet data retention laws. Each entry in the 782 PLAT/AFTR's generates a logging entry. As discussed in Section 4.2, 783 a client may open hundreds of sessions during common tasks such as 784 web-browsing, each of which needs to be logged so the overall logging 785 burden on the network operator is significant. In some countries, 786 this level of logging is required to comply with data retention 787 legislation. 789 One common optimization available to reduce the logging overhead is 790 the allocation of a block of ports to a client for the duration of 791 their session. This means that logging entry only needs to be made 792 when the client's port block is released, which dramatically reducing 793 the logging overhead. This comes as the cost of less efficient 794 public address sharing as clients need to be allocated a port block 795 of a fixed size regardless of the actual number of ports that they 796 are using. 798 Stateless technologies that pre-allocate the IPv4 addresses and ports 799 only require that copies of the active MAP rules (for MAP-E and MAP- 800 T), or binding-table (for lw4o6) are retained along with timestamp 801 information of when they have been active. Support tools (e.g., 802 those used to serve data retention requests) may need to be updated 803 to be aware of the mechanism in use (e.g., implementing the MAP 804 algorithm so that IPv4 information can be linked to the IPv6 prefix 805 delegated to a client). As stateless technologies do not have a 806 centralized stateful element which customer traffic needs to pass 807 through, so if data retention laws mandate per-session logging, there 808 is no simple way of meeting this requirement with a stateless 809 technology alone. 811 5. Acknowledgements 813 The authors would like to thank Ole Troan for his thorough review of 814 this draft and acknowledge the inputs of Ole Troan, Mark Andrews, 815 Edwin Cordeiro, Fred Baker, Alexandre Petrescu, Cameron Byrne, Tore 816 Anderson, Alexandre Petrescu, Mikael Abrahamsson, Gert Doering, 817 Satoru Matsushima, and TBD ... 819 6. IANA Considerations 821 This document does not make any request to IANA. 823 7. Security Considerations 825 According to the simplest model, the number of bugs is proportional 826 to the number of code lines. Please refer to Section 4.4.3 for code 827 sizes of CE implementations. 829 For all five technologies, the CE device should contain a DNS proxy. 830 However, the user may change DNS settings. If it happens and lw4o6, 831 MAP-E and MAP-T are used with significantly restricted port set, 832 which is required for an efficient public IPv4 address sharing, the 833 entropy of the source ports is significantly lowered (e.g. from 16 834 bits to 10 bits, when 1024 port numbers are assigned to each 835 subscriber) and thus these technologies are theoretically less 836 resilient against cache poisoning, see [RFC5452]. However, an 837 efficient cache poisoning attack requires that the subscriber 838 operates an own caching DNS server and the attack is performed in the 839 service provider network. Thus, we consider the chance of the 840 successful exploitation of this vulnerability as low. 842 An in-depth security analysis of all five IPv6 transition 843 technologies and their most prominent free software implementations 844 according to the methodology defined in [LEN2018] is planned. 846 8. References 848 8.1. Normative References 850 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 851 Requirement Levels", BCP 14, RFC 2119, 852 DOI 10.17487/RFC2119, March 1997, 853 . 855 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 856 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 857 December 1998, . 859 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 860 Translator (NAT) Terminology and Considerations", 861 RFC 2663, DOI 10.17487/RFC2663, August 1999, 862 . 864 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 865 Resilient against Forged Answers", RFC 5452, 866 DOI 10.17487/RFC5452, January 2009, 867 . 869 [RFC6050] Drage, K., "A Session Initiation Protocol (SIP) Extension 870 for the Identification of Services", RFC 6050, 871 DOI 10.17487/RFC6050, November 2010, 872 . 874 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 875 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 876 DOI 10.17487/RFC6052, October 2010, 877 . 879 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 880 NAT64: Network Address and Protocol Translation from IPv6 881 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 882 April 2011, . 884 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 885 Beijnum, "DNS64: DNS Extensions for Network Address 886 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 887 DOI 10.17487/RFC6147, April 2011, 888 . 890 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 891 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 892 DOI 10.17487/RFC6269, June 2011, 893 . 895 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 896 Stack Lite Broadband Deployments Following IPv4 897 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 898 . 900 [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to 901 the IPv4 Address Shortage", RFC 6346, 902 DOI 10.17487/RFC6346, August 2011, 903 . 905 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 906 Combination of Stateful and Stateless Translation", 907 RFC 6877, DOI 10.17487/RFC6877, April 2013, 908 . 910 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 911 Farrer, "Lightweight 4over6: An Extension to the Dual- 912 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 913 July 2015, . 915 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 916 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 917 Port with Encapsulation (MAP-E)", RFC 7597, 918 DOI 10.17487/RFC7597, July 2015, 919 . 921 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 922 and T. Murakami, "Mapping of Address and Port using 923 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 924 2015, . 926 [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address 927 Mappings for Stateless IP/ICMP Translation", RFC 7757, 928 DOI 10.17487/RFC7757, February 2016, 929 . 931 [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, 932 "IP/ICMP Translation Algorithm", RFC 7915, 933 DOI 10.17487/RFC7915, June 2016, 934 . 936 [RFC8114] Boucadair, M., Qin, C., Jacquenet, C., Lee, Y., and Q. 937 Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients 938 over an IPv6 Multicast Network", RFC 8114, 939 DOI 10.17487/RFC8114, March 2017, 940 . 942 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 943 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 944 May 2017, . 946 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 947 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 948 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 949 RFC 8415, DOI 10.17487/RFC8415, November 2018, 950 . 952 8.2. Informative References 954 [I-D.ietf-v6ops-nat64-deployment] 955 Palet, J., "NAT64/464XLAT Deployment Guidelines in 956 Operator and Enterprise Networks", draft-ietf-v6ops- 957 nat64-deployment-03 (work in progress), October 2018. 959 [LEN2017] Lencse, G. and Y. Kadobayashi, "Survey of IPv6 Transition 960 Technologies for Security Analysis", IEICE Communications 961 Society Internet Architecture Workshop, Tokyo, Japan, 962 IEICE Tech. Rep., vol. 117, no. 187, pp. 19-24, Aug 963 2017, . 966 [LEN2018] Lencse, G. and Y. Kadobayashi, "Methodology for the 967 identification of potential security issues of different 968 IPv6 transition technologies: Threat analysis of DNS64 and 969 stateful NAT64", Computers & Security (Elsevier), vol. 970 77, no. 1, pp. 397-411, DOI: 10.1016/j.cose.2018.04.012, 971 Aug 2018, . 974 [MIY2010] Miyakawa, S., "IPv4 to IPv6 transformation schemes", 975 IEICE Trans. Commun., vol.E93-B, no.5, pp. 1078-1084, 976 DOI:10.1587/transcom.E93.B.10, May 2010, 977 . 980 [REP2014] Repas, S., Hajas, T., and G. Lencse, "Port number 981 consumption of the NAT64 IPv6 transition technology", 982 Proc. 37th Internat. Conf. on Telecommunications and 983 Signal Processing (TSP 2014), Berlin, Germany, DOI: 984 10.1109/TSP.2015.7296411, July 2014. 986 Appendix A. Change Log 988 A.1. 01 - 02 990 o Ian Farrer has joined us as an author. 992 o Restructuring: the description of the five IPv4aaS technologies 993 was moved to a separate section. 995 o More details and figures were added to the description of the five 996 IPv4aaS technologies. 998 o Section titled "High-level Architectures and their Consequences" 999 has been completely rewritten. 1001 o Several additions/clarification throughout Section titled 1002 "Detailed Analysis". 1004 o Section titled "Performance Analysis" was dropped due to lack of 1005 results yet. 1007 o Word based text ported to XML. 1009 o Further text cleanups, added text on state sync and load 1010 balancing. Additional comments inline that should be considered 1011 for future updates. 1013 Authors' Addresses 1015 Gabor Lencse 1016 Budapest University of Technology and Economics 1017 Magyar Tudosok korutja 2. 1018 Budapest H-1117 1019 Hungary 1021 Email: lencse@hit.bme.hu 1022 Jordi Palet Martinez 1023 The IPv6 Company 1024 Molino de la Navata, 75 1025 La Navata - Galapagar, Madrid 28420 1026 Spain 1028 Email: jordi.palet@theipv6company.com 1029 URI: http://www.theipv6company.com/ 1031 Lee Howard 1032 Retevia 1033 9940 Main St., Suite 200 1034 Fairfax, Virginia 22031 1035 USA 1037 Email: lee@asgard.org 1039 Richard Patterson 1040 Sky UK 1041 1 Brick Lane 1042 London EQ 6PU 1043 United Kingdom 1045 Email: richard.patterson@sky.uk 1047 Ian Farrer 1048 Deutsche Telekom AG 1049 Landgrabenweg 151 1050 Bonn 53227 1051 Germany 1053 Email: ian.farrer@telekom.de