idnits 2.17.1 draft-lencse-v6ops-transition-benchmarking-01.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6877], [RFC6333], [RFC6147], [RFC7596], [RFC7597], [RFC7599]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (2 May 2022) is 722 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-transition-comparison-03 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops G. Lencse 3 Internet-Draft Szechenyi Istvan University 4 Intended status: Informational 2 May 2022 5 Expires: 3 November 2022 7 Performance Analysis of IPv6 Transition Technologies for IPv4aaS 8 draft-lencse-v6ops-transition-benchmarking-01 10 Abstract 12 Several IPv6 transition technologies have been developed to provide 13 customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only 14 access and/or core network. All these technologies have their 15 advantages and disadvantages, and depending on existing topology, 16 skills, strategy and other preferences, one of these technologies may 17 be the most appropriate solution for a network operator. 19 This document examines and compares the performance of some free 20 software implementations of the five most prominent IPv4aaS 21 technologies (464XLAT [RFC6877], Dual Stack Lite [RFC6333], 22 Lightweight 4over6 [RFC7596], MAP-E [RFC7597] and MAP-T [RFC7599]) 23 and DNS64 [RFC6147]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 3 November 2022. 42 Copyright Notice 44 Copyright (c) 2022 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Performance Analysis and Comparison of DNS64 60 Implementations . . . . . . . . . . . . . . . . . . . . . 2 61 2.1. Purpose and Significance of DNS64 . . . . . . . . . . . . 3 62 2.2. Measurement Method and Parameters . . . . . . . . . . . . 3 63 2.3. Measurement Results . . . . . . . . . . . . . . . . . . . 4 64 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 69 6.2. Informative References . . . . . . . . . . . . . . . . . 6 70 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 7 71 A.1. 00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 A.2. 01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 IETF has standardized several IPv6 transition technologies [LEN2019] 78 and occupied a neutral position trusting the selection of the most 79 appropriate ones to the market. 80 [I-D.ietf-v6ops-transition-comparison] provides a comprehensive 81 comparative analysis of the five most prominent IPv4aaS technologies 82 to assist operators with this problem. This document adds one more 83 detail: performance analysis and comparison of the most important 84 free software implementations of the examined IPv4aaS technologies 85 and DNS64. 87 2. Performance Analysis and Comparison of DNS64 Implementations 88 2.1. Purpose and Significance of DNS64 90 DNS64 [RFC6147] can be used together with stateful NAT64 [RFC6146] to 91 facilitate the communication of an IPv6-only client with an IPv4-only 92 server. In typical deployments, 464XLAT is used together with DNS64 93 [RFC6147], see Section 3.1.2 of [RFC8683]. In this case, the 94 stateful NAT64 gateway is granted as the PLAT of 464XLAT. 95 Theoretically, DNS64 could be used together with any of the other 96 IPv4aaS technologies, but then it would require the operation of a 97 stateful NAT64 gateway. So DNS64 performance is important for those, 98 who choose to use 464XLAT. 100 As elaborated in Sections 4.5.2 and 4.5.3 of 101 [I-D.ietf-v6ops-transition-comparison], the usage of DNS64 reduces 102 the amount of the traffic that undergoes double translation at least 103 by an order of magnitude, because the traffic of an IPv6-only client 104 and an IPv4-only server undergoes only a single translation. 106 2.2. Measurement Method and Parameters 108 The benchmarking method for DNS64 servers is defined in Section 9 of 109 [RFC8219]. Further details of the method and its design 110 considerations are elaborated in [LEN2017]. 112 In short, the performance of the DNS64 servers is characterized by 113 the number of queries resolved per second, provided that the 114 resolution happens within (one second) timeout time and all the sent 115 queries are resolved. (This is the usual "zero loss" criterion 116 traditionally used in [RFC2544] and its derivatives.) 118 The worst case test, when there is no cache hit and no "AAAA" record 119 exists, thus the DNS64 server needs to send two queries (one query 120 for the "AAAA" record and another one for the "A" record) for each 121 received query is compulsory, and additional tests with varios rates 122 of cache hits and existing "AAAA" records are optional. 124 All the details of the actual measurements are described in 125 [LEN2018], where all the information given in the rest of Section 2 126 is taken from. 128 As for implementations, we have benchmarked all usable free software 129 DNS64 implementations we were aware of, namely: BIND 130 (9.10.3-P4-Debian), PowerDNS Recursor (4.0.4) and Unbound (1.6.0). 131 Their performance was examined as the function of the number of 132 active CPU cores using 1, 2, 4, 8 and 16 CPU cores. Besides the 133 compulsory and optional tests defined by [RFC8219], we have also 134 examined the computing power relative DNS64 performance, that is the 135 number of processed queries per second divided by the CPU utilization 136 of the computer. 138 The measurements were performed using the resources of NICT StarBED, 139 Japan. The used Dell PowerEdge C6220 servers had two Intel Xeon 140 E5-2650 2GHz CPUs, having 8 cores each, and 16x8GB 1333MHz DDR3 141 SDRAM. They were interconnected by 1Gbps speed VLANs. Debian GNU/ 142 Linux 9.2 operating system with kernel version 4.9.0-4-amd64 was used 143 on all computers. 145 All measurements were executed 20 times, and then median, minimum and 146 maximum of the 20 results were calculated. 148 2.3. Measurement Results 150 Only the most important results (median values of the worst case 151 peformance) are summarized here. All the details can be found in 152 [LEN2018]. 154 The performance of BIND was 2,425qps (queries per second) at a single 155 core, and it scaled up to 4,788qps and 6,659qps at 2 and 4 cores, 156 respectively. However its performance did not increase at 8 cores 157 and it was practically the same (6,661qps) at 16 cores. Strangely, 158 the minimum and maximum performance was exactly the same as the 159 median at 4, 8 and 16 cores. We have reported this strange issue to 160 the developers of BIND, but we did not receive any reply or bugfix. 162 The performance of PowerDNS was 3,077qps at a single core, and it 163 scaled up quite well up to 26,620qps at 16 cores. The results were 164 consistent: the difference between the maximum and minimum values was 165 acceptable (under 13% of the median) at any number of CPU cores. 167 The performance of Unbound was 8,708qps at a single core with only a 168 low difference between the maximum and minimum values (about 4% of 169 the median). Its median performance showed and acceptable scale-up 170 to 31,502qps at 8 cores, but then it dropped to 17,131qps at 16 171 cores. And the results were rather inconsistent from 2 to 16 cores. 172 (E.g. the difference of the maximum and minimum values was more than 173 58% of the median at 16 cores.) 174 All-in-all, PowerDNS has shown the best scale-up and the most 175 consitent and predictable results, therefore we recommend its usage 176 in the case of a modern server with 16 or more CPU cores. 178 In the case of a single core server (e.g. a virtual machine) Unbound 179 can give the highest performance. 181 BIND has shown the lowest single core performance and poor scale-up. 182 It can only be used, if very moderate performance is needed. 184 3. Acknowledgements 186 TBD. 188 4. IANA Considerations 190 This document does not make any request to IANA. 192 5. Security Considerations 194 TBD. 196 6. References 198 6.1. Normative References 200 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 201 Network Interconnect Devices", RFC 2544, 202 DOI 10.17487/RFC2544, March 1999, 203 . 205 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 206 NAT64: Network Address and Protocol Translation from IPv6 207 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 208 April 2011, . 210 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 211 Beijnum, "DNS64: DNS Extensions for Network Address 212 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 213 DOI 10.17487/RFC6147, April 2011, 214 . 216 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 217 Stack Lite Broadband Deployments Following IPv4 218 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 219 . 221 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 222 Combination of Stateful and Stateless Translation", 223 RFC 6877, DOI 10.17487/RFC6877, April 2013, 224 . 226 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 227 Farrer, "Lightweight 4over6: An Extension to the Dual- 228 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 229 July 2015, . 231 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 232 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 233 Port with Encapsulation (MAP-E)", RFC 7597, 234 DOI 10.17487/RFC7597, July 2015, 235 . 237 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 238 and T. Murakami, "Mapping of Address and Port using 239 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 240 2015, . 242 [RFC8219] Georgescu, M., Pislaru, L., and G. Lencse, "Benchmarking 243 Methodology for IPv6 Transition Technologies", RFC 8219, 244 DOI 10.17487/RFC8219, August 2017, 245 . 247 [RFC8683] Palet Martinez, J., "Additional Deployment Guidelines for 248 NAT64/464XLAT in Operator and Enterprise Networks", 249 RFC 8683, DOI 10.17487/RFC8683, November 2019, 250 . 252 6.2. Informative References 254 [I-D.ietf-v6ops-transition-comparison] 255 Lencse, G., Martinez, J. P., Howard, L., Patterson, R., 256 and I. Farrer, "Pros and Cons of IPv6 Transition 257 Technologies for IPv4aaS", Work in Progress, Internet- 258 Draft, draft-ietf-v6ops-transition-comparison-03, 5 April 259 2022, . 262 [LEN2017] Lencse, G. and Y. Kadobayashi, "Benchmarking Methodology 263 for DNS64 Servers", Computer Communications, vol. 109, 264 no. 1, pp. 162-175, DOI: 10.1016/j.comcom.2017.06.004, 1 265 September 2017, 266 . 269 [LEN2018] Lencse, G. and Y. Kadobayashi, "Benchmarking DNS64 270 Implementations: Theory and Practice", Computer 271 Communications, vol. 127, no. 1, pp. 272 61-74, 10.1016/j.comcom.2018.05.005, 1 September 2018, 273 . 276 [LEN2019] Lencse, G. and Y. Kadobayashi, "Comprehensive Survey of 277 IPv6 Transition Technologies: A Subjective Classification 278 for Security Analysis", IEICE Transactions on 279 Communications, vol. E102-B, no.10, pp. 2021-2035., DOI: 280 10.1587/transcom.2018EBR0002, 1 October 2019, 281 . 284 Appendix A. Change Log 286 A.1. 00 288 Initial version. 290 A.2. 01 292 DNS64 benchmarking was added. 294 Author's Address 296 Gabor Lencse 297 Szechenyi Istvan University 298 Gyor 299 Egyetem ter 1. 300 H-9026 301 Hungary 302 Email: lencse@sze.hu