idnits 2.17.1 draft-lmhp-v6ops-transition-comparison-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 6, 2018) is 2027 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC5452' is mentioned on line 316, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPv6 Operations Working Group G. Lencse 2 Internet Draft BUTE 3 Intended status: Informational J. Palet Martinez 4 Expires: April 2018 The IPv6 Company 5 L. Howard 6 Retevia 7 R. Patterson 8 Sky UK 9 October 6, 2018 11 Pros and Cons of IPv6 Transition Technologies for IPv4aaS 12 draft-lmhp-v6ops-transition-comparison-00.txt 14 Abstract 16 Several IPv6 transition technologies can be used to provide IPv4-as- 17 a-service (IPv4aaS) to the customers, while the ISPs have only IPv6 18 in their access and or core network. All these technologies have 19 their advantages and disadvantages. Depending on several various 20 conditions and preferences, different technologies may prove to be 21 the most appropriate solution. This document examines the five most 22 prominent IPv4aaS technologies considering several different aspects 23 in order to provide network operators with an easy to use guideline 24 for selecting the technology that suit their needs the best. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six 37 months and may be updated, replaced, or obsoleted by other documents 38 at any time. It is inappropriate to use Internet-Drafts as 39 reference material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 46 This Internet-Draft will expire on April 6, 2019. 48 Copyright Notice 50 Copyright (c) 2018 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 (http://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 58 respect to this document. Code Components extracted from this 59 document must include Simplified BSD License text as described in 60 Section 4.e of the Trust Legal Provisions and are provided without 61 warranty as described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction ................................................ 3 66 2. High-level Architectures and their Consequences ............. 3 67 2.1. Service Provider Network Traversal ..................... 3 68 2.2. IPv4 Address Sharing ................................... 4 69 3. More Detailed Analysis ...................................... 4 70 3.1. Details of Architectural Differences ................... 4 71 3.1.1. 464XLAT ........................................... 4 72 3.1.2. DS-Lite ........................................... 4 73 3.1.3. Lw4o6 ............................................. 4 74 3.1.4. MAP-E ............................................. 5 75 3.1.5. MAP-T ............................................. 5 76 3.2. Tradeoff between Port Number Efficiency and Stateless 77 Operation .............................................. 5 78 3.3. Support for Server Operation ........................... 6 79 3.4. Support and Implementations ............................ 6 80 3.4.1. OS Support......................................... 6 81 3.4.2. Support in Cellular and Broadband Networks......... 6 82 3.4.3. Implementation Code Sizes ......................... 6 83 4. Performance Comparison ...................................... 7 84 5. Security Considerations ..................................... 7 85 6. IANA Considerations ........................................ 8 86 7. Conclusions ................................................. 8 87 8. References .................................................. 8 88 8.1. Normative References ................................... 8 89 8.2. Informative References ................................. 9 90 9. Acknowledgments ............................................ 10 92 1. Introduction 94 IETF has standardized a high number of IPv6 transition technologies 95 [Len2017] and occupied a neutral position trusting the selection to 96 the market. In the upcoming years, several network operators would 97 like to get rid of the burden of maintaining IPv4 in their access 98 and/or core networks. This document deals with five different 99 solutions, each of which can be used to provide an IPv4 service 100 using an IPv6-only access/core network. The following IPv6 101 transition technologies are covered: 464XLAT [RFC6877], DS-Lite 102 (Dual Stack Lite) [RFC6333], lw4o6 (Lightweight 4over6) [RFC7596], 103 MAP-E [RFC7597] and MAP-T [RFC7599]. 105 2. High-level Architectures and their Consequences 107 2.1. Service Provider Network Traversal 109 As for the high-level solution of the IPv6 service provider network 110 traversal, MAP-T use double translation (first at the CE from IPv4 111 to IPv6, NAT46, and then from IPv6 to IPv4, NAT64, at the service 112 provider network), 464XLAT may use single (NAT64, IPv6 to IPv4) or 113 double translation (as MAP-T), depending on different factors, such 114 as the use of DNS by the applications and the availability of a 115 DNS64. DS-Lite, lw4o6 and MAP-E encapsulate the IPv4 packets into 116 IPv6 packets. Each solution has its own advantages and drawbacks. 117 Double translation results in only 20 bytes overhead (the difference 118 in the minimum header size between IPv4 and IPv6), whereas the 119 overhead of the encapsulation is 40 bytes (because both, the IPv4 120 and IPv6 headers are needed, compared with only the IPv4 one). The 121 difference may be significant in the case of small packet sizes or 122 when the larger one results in fragmentation. 124 On the one hand, the first step of the double translation case is a 125 stateless NAT from IPv4 to IPv6 implemented as SIIT (Stateless 126 IP/ICMP Translation Algorithm) [RFC7915], which does not translate 127 IPv4 options and/or multicast IP/ICMP packets, whereas with 128 encapsulation-based technologies these remain intact. 130 On the other hand, single and double translation results in "normal" 131 IPv6 traffic which can be inspected, e.g., by hashing algorithms, 132 and firewalls, whereas encapsulation results in IPv4-embedded IPv6 133 packets and their interpretation requires special software/hardware 134 for DPI (deep-packet-inspection). 136 The worst case is DS-Lite, which is also doing double stateful 137 translation (NAT44 at the CE, NAT44 at the AFTR). 139 Another consequence is that the solutions using double translation 140 can carry only TCP, UDP or ICMP over IP, when they are used with 141 IPv4 address sharing (please refer to section 3.3 for more details), 142 whereas the solutions using encapsulation can carry any other 143 protocols over IP, too. 145 2.2. IPv4 Address Sharing 147 All five technologies support IPv4 address sharing, which has severe 148 consequences described in [RFC6269]. 150 The efficiency of the address sharing of the five technologies is 151 significantly different, it is discussed in section 3.2. 153 We note that lw4o6, MAP-E and MAP-T may not necessarily be 154 configured to do IPv4 address sharing, see the details in Section 155 3.3, however in that case there is no advantage in terms of public 156 IPv4 addresses saving. 158 3. More Detailed Analysis 160 3.1. Details of Architectural Differences 162 3.1.1. 464XLAT 164 CLAT performs a stateless translation from IPv4 to IPv6 [RFC7915]. 165 It uses IPv4-embedded IPv6 addresses [RFC6052] for both source 166 address and destination address. PLAT performs stateful NAT64 167 [RFC6146]. 169 3.1.2. DS-Lite 171 The B4 (Basic Bridging BroadBand) element encapsulates the IPv4 172 packets into IPv6 packets. The AFTR (Address Family Transition 173 Router) de-encapsulates the IPv4 packets from the IPv6 packets and 174 performs stateful NAPT (Network Address and Port Translation). 176 3.1.3. Lw4o6 178 Lightweight 4over6 is a variant of DS-Lite. The difference is, that 179 the stateful NAPT is moved from the AFTR to the B4 element. It uses 180 a provisioning mechanism to determine the size of the limited port 181 set per user. 183 3.1.4. MAP-E 185 The CE (Customer-Edge) router first encapsulates IPv4-in-IPv6. 186 Packets must traverse a MAP BR to be [de-]encapsulated. 188 3.1.5. MAP-T 190 The CE (Customer Edge) router first performs a NAT44 to transform 191 the source addresses and source port numbers of the IPv4 packets 192 into a predefined range, the size of which is a design parameter. 193 The CE router then performs stateless translation from IPv4 to IPv6 194 [RFC7915], which translates the IPv4 address and the port numbers 195 into the IPv6 address space. The transformations may be fine-tuned 196 by the mapping rules. The MAP BR (Border Relay) performs stateless 197 translation from IPv4 to IPv6 [RFC7915]. 199 3.2. Tradeoff between Port Number Efficiency and Stateless Operation 201 464XLAT and DS-Lite use stateful NAPT at the PLAT and AFTR devices, 202 respectively. This may cause scalability issues. Lw4o6, MAP-E and 203 MAP-T avoid using NAPT in the service provider network. Its cost is 204 that they have to limit the port numbers available for a user, which 205 is also the case for DS-Lite. Determining the optimal size of the 206 port set is not an easy task. On the one hand, the lack of port 207 situation may cause serious problems in the operation of certain 208 programs (e.g. the consequences of the session number limitation due 209 to port number shortage were impressively demonstrated using Google 210 Map in [Miy2010]). The port number consumption of different 211 applications is highly varying and e.g. in the case of web browsing 212 it depends on several factors [Rep2014]. And there may be several 213 users behind a CPE, especially in the wired case (e.g. Internet is 214 used by different members of a family simultaneously), thus 215 sometimes even a few thousands ports may not be enough. However, on 216 the other hand, assigning too many ports per user will result in 217 waste of public IPv4 addresses, which is a scarce and expensive 218 resource. Therefore, 464XLAT is much more efficient in terms of port 219 number and thus public IP address saving. The price is the stateful 220 operation in the service provider network, which is allegedly does 221 not scale up well. XXX MEASUREMENTS ARE PLANNED TO DECIDE IF IT IS 222 TRUE. XXX 224 We also note that NAT64 does not pre-allocate ports for customers 225 but allocates them "on the fly" (which means that even the same 226 customer is using ports from different addresses, and most of the 227 time, different customers get ports from any given addresses), and 228 in fact this creates many application/service providers (Sony 229 PlayStation Network, OpenDNS, etc.) to permanently black-list the 230 IPv4 ranges once they are detected to be used for address sharing. 232 3.3. Support for Server Operation 234 Lw4o6, MAP-E and MAP-T may be configured without IPv4 address 235 sharing, allowing exclusive use of all ports, and non-port-based 236 layer 4 protocols. Thus, they may also be used to support server 237 operation, when public IPv4 addresses are assigned to the 238 subscribers, however, then there is no advantage in terms of IPv4 239 public addresses saving. 241 It is also possible to configure specific ports mapping in 242 464XLAT/NAT64 using EAMT [RFC7757], which means that only those 243 ports are "lost" from the pool of addresses, so there is a higher 244 maximization of the total usage of IPv4/port resources. 246 3.4. Support and Implementations 248 3.4.1. OS Support 250 As for 464XLAT, client support exists in Windows 10, Linux 251 (including Android), Windows Mobile, and Chrome OS, but it is 252 missing from iOS and MacOS. For the other four solutions, we are not 253 aware of any OS support. 255 3.4.2. Support in Cellular and Broadband Networks 257 Several cellular networks use 464XLAT, whereas we are not aware of 258 any deployment of the four other technologies in cellular networks, 259 as they are not supported. 261 In broadband networks, there are some deployments of 464XLAT, MAP-E 262 and MAP-T. Both, lw4o6 and DS-Lite have more deployments, having 263 been up now DS-Lite the most used one, but lw4o6 taking over in the 264 last years. 266 3.4.3. Implementation Code Sizes 268 As for complexity hint, the code size reported from OpenWRT 269 implementation is 17kB, 35kB, 15kB, 35kB, and 48kB for 464XLAT, 270 lw4o6, DS-Lite, MAP-E, MAP-T, and lw4o6, respectively 271 (https://openwrt.org/packages/start). 273 We note that the support for all five technologies requires much 274 less code size than the total sum of the above quantities, because 275 they contain a lot of common functions (data plane is shared among 276 several of them). 278 4. Performance Comparison 280 We plan to compare the performances of the most prominent free 281 software implementations of the five IPv6 transition technologies 282 using the methodology described in "Benchmarking Methodology for 283 IPv6 Transition Technologies" [RFC8219]. 285 On the one hand, the Dual DUT Setup of RFC8219 makes it possible to 286 use the existing "Benchmarking Methodology for Network Interconnect 287 Devices" [RFC2544] compliant measurement devices, however, this 288 setup has the drawback that the performances of the CE and of the 289 ISP side device (e.g. the CLAT and the PLAT of 464XLAT) are measured 290 together. In order to measure the performance of only one of them, 291 we need to ensure that the desired one is the bottleneck. 293 On the other hand, the Single DUT Setup of [RFC8219] makes it 294 possible to benchmark the selected device separately, however, no 295 [RFC8219] compliant testers available yet. A DPDK-based software 296 Tester for stateless NAT64 is currently under development and it is 297 expected to be available this autumn as a free software. XXX FROM 298 WHERE XXX 300 Any volunteers for developing [RFC8219] compliant measurement 301 software? 303 5. Security Considerations 305 According to the simplest model, the number of bugs is proportional 306 to the number of code lines. Please refer to section 3.4.3 for code 307 sizes of CE implementations. 309 For all five technologies, the CE device should contain a DNS proxy. 310 However, the user may change DNS settings. If it happens and lw4o6, 311 MAP-E and MAP-T are used with significantly restricted port set, 312 which is required for an efficient public IPv4 address sharing, the 313 entropy of the source ports is significantly lowered (e.g. from 16 314 bits to 10 bits, when 1024 port numbers are assigned to each 315 subscriber) and thus these technologies are theoretically less 316 resilient against cache poisoning, see [RFC5452]. However, an 317 efficient cache poisoning attack requires that the subscriber 318 operates an own caching DNS server and the attack is performed in 319 the service provider network. Thus, we consider the chance of the 320 successful exploitation of this vulnerability as low. 322 An in-depth security analysis of all five IPv6 transition 323 technologies and their most prominent free software implementations 324 according to the methodology defined in [Len2018] is planned. 326 6. IANA Considerations 328 TBD. 330 7. Conclusions 332 TBD. 334 8. References 336 8.1. Normative References 338 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 339 Network Interconnect Devices", RFC 2544, DOI 340 10.17487/RFC2544, March 1999, . 343 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 344 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 345 DOI 10.17487/RFC6052, October 2010, . 348 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 349 NAT64: Network Address and Protocol Translation from IPv6 350 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 351 April 2011, . 363 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 364 Combination of Stateful and Stateless Translation", RFC 365 6877, DOI 10.17487/RFC6877, April 2013, . 368 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 369 Farrer, "Lightweight 4over6: An Extension to the Dual- 370 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 371 July 2015, . 373 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 374 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 375 Port with Encapsulation (MAP-E)", RFC 7597, DOI 376 10.17487/RFC7597, July 2015, . 379 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 380 and T. Murakami, "Mapping of Address and Port using 381 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 382 2015, . 384 [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, 385 "IP/ICMP translation algorithm", RFC 7915, DOI: 386 10.17487/RFC7915, June 2016, . 389 [RFC7757] Anderson, T., and A. Leiva Popper "Explicit Address 390 Mappings for Stateless IP/ICMP Translation", RFC 7757, DOI 391 10.17487/RFC7757, February 2016, . 394 [RFC8219] Georgescu, M., Pislaru, L., and G. Lencse, "Benchmarking 395 Methodology for IPv6 Transition Technologies", IETF RFC 396 8219, DOI: 10.17487/RFC8219, Aug. 2017, . 399 8.2. Informative References 401 [Len2017] Lencse, G., and Y. Kadobayashi, "Survey of IPv6 Transition 402 Technologies for Security Analysis", IEICE Communications 403 Society Internet Architecture Workshop, Tokyo, Japan, Aug. 404 28, 2017, IEICE Tech. Rep., vol. 117, no. 187, pp. 19-24. 405 http://www.hit.bme.hu/~lencse/publications/IEICE-IA-2017- 406 survey.pdf 408 [Len2018] Lencse, G., and Y. Kadobayashi, "Methodology for the 409 identification of potential security issues of different 410 IPv6 transition technologies: Threat analysis of DNS64 and 411 stateful NAT64", Computers & Security (Elsevier), vol. 77, 412 no. 1, pp. 397-411, August 1, 2018, DOI: 413 10.1016/j.cose.2018.04.012, 414 http://www.hit.bme.hu/~lencse/publications/ECS-2018- 415 Methodology-revised.pdf 417 [Miy2010] Miyakawa, S., "IPv4 to IPv6 transformation schemes", IEICE 418 Trans. Commun., vol.E93-B, no.5, pp.1078-1084, May 2010. 419 DOI:10.1587/transcom.E93.B.1078 421 [Rep2014] Repas, S., Hajas, T., and G. Lencse, "Port number 422 consumption of the NAT64 IPv6 transition technology", 423 Proc. 37th Internat. Conf. on Telecommunications and 424 Signal Processing (TSP 2014), Berlin, Germany, pp.66-72, 425 Jul. 1-3, 2014. DOI: 10.1109/TSP.2015.7296411 427 9. Acknowledgments 429 The authors would like to acknowledge the inputs of Ole Troan, Mark 430 Andrews, Edwin Cordeiro, Fred Baker, Alexandre Petrescu, and TBD. 432 This document was prepared using 2-Word-v2.0.template.dot. 434 Copyright (c) 2018 IETF Trust and the persons identified as authors 435 of the code. All rights reserved. 437 Redistribution and use in source and binary forms, with or without 438 modification, is permitted pursuant to, and subject to the license 439 terms contained in, the Simplified BSD License set forth in Section 440 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 441 (http://trustee.ietf.org/license-info). 443 Authors' Addresses 445 Gabor Lencse 446 Budapest University of Technology and Economics 447 Magyar Tudosok korutja 2. 448 H-1117 Budapest, Hungary 450 Email: lencse@hit.bme.hu 452 Jordi Palet Martinez 453 The IPv6 Company 454 Molino de la Navata, 75 455 La Navata - Galapagar, Madrid - 28420 456 Spain 458 Email: jordi.palet@theipv6company.com 460 Lee Howard 461 Retevia 462 9940 Main St., Suite 200 463 Fairfax 464 Virginia 465 22031, USA 466 Email: lee@asgard.org 468 Richard Patterson 469 Sky UK 470 1 Brick Lane 471 London, E1 6PU 472 United Kingdom 474 Email: richard.patterson@sky.uk