Re: [v6ops] New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" -- Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-00.txt
Ole Troan <otroan@employees.org> Mon, 08 October 2018 08:35 UTC
Return-Path: <otroan@employees.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDFBD12F295 for <v6ops@ietfa.amsl.com>; Mon, 8 Oct 2018 01:35:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksS7toWry-_K for <v6ops@ietfa.amsl.com>; Mon, 8 Oct 2018 01:35:28 -0700 (PDT)
Received: from bugle.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F8BD12F1A6 for <v6ops@ietf.org>; Mon, 8 Oct 2018 01:35:28 -0700 (PDT)
Received: from astfgl.hanazo.no (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bugle.employees.org (Postfix) with ESMTPSA id DB444FECBFF9; Mon, 8 Oct 2018 08:35:23 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 595A370DEE9; Mon, 8 Oct 2018 10:35:16 +0200 (CEST)
From: Ole Troan <otroan@employees.org>
Message-Id: <95842EFB-62F3-4F1D-89DD-385D22BDC855@employees.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_BF73F264-9AA5-4F9B-9C3D-59332BEBF17A"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Mon, 08 Oct 2018 10:35:15 +0200
In-Reply-To: <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu>
Cc: "v6ops@ietf.org list" <v6ops@ietf.org>
To: Lencse Gábor <lencse@hit.bme.hu>
References: <153883033146.19131.5179457798086796739.idtracker@ietfa.amsl.com> <25edd27e-7876-cd88-c870-e2bf314f7453@hit.bme.hu>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Jv-8b5QapQibr7fLCQXJ2Gr6c6I>
Subject: Re: [v6ops] New I-D: "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" -- Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Oct 2018 08:35:33 -0000
Comments inline. Look for @@OT. Ole IPv6 Operations Working Group G. Lencse Internet Draft BUTE Intended status: Informational J. Palet Martinez Expires: April 2018 The IPv6 Company L. Howard Retevia R. Patterson Sky UK October 6, 2018 Pros and Cons of IPv6 Transition Technologies for IPv4aaS draft-lmhp-v6ops-transition-comparison-00.txt Abstract Several IPv6 transition technologies can be used to provide IPv4-as- a-service (IPv4aaS) to the customers, while the ISPs have only IPv6 in their access and or core network. All these technologies have their advantages and disadvantages. Depending on several various conditions and preferences, different technologies may prove to be the most appropriate solution. This document examines the five most prominent IPv4aaS technologies considering several different aspects in order to provide network operators with an easy to use guideline for selecting the technology that suit their needs the best. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Lencse et al. Expires April 6, 2019 [Page 1] Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018 This Internet-Draft will expire on April 6, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ................................................ 3 2. High-level Architectures and their Consequences ............. 3 2.1. Service Provider Network Traversal ..................... 3 2.2. IPv4 Address Sharing ................................... 4 3. More Detailed Analysis ...................................... 4 3.1. Details of Architectural Differences ................... 4 3.1.1. 464XLAT ........................................... 4 3.1.2. DS-Lite ........................................... 4 3.1.3. Lw4o6 ............................................. 4 3.1.4. MAP-E ............................................. 5 3.1.5. MAP-T ............................................. 5 3.2. Tradeoff between Port Number Efficiency and Stateless Operation .............................................. 5 3.3. Support for Server Operation ........................... 6 3.4. Support and Implementations ............................ 6 3.4.1. OS Support......................................... 6 3.4.2. Support in Cellular and Broadband Networks......... 6 3.4.3. Implementation Code Sizes ......................... 6 4. Performance Comparison ...................................... 7 5. Security Considerations ..................................... 7 6. IANA Considerations ........................................ 8 7. Conclusions ................................................. 8 8. References .................................................. 8 8.1. Normative References ................................... 8 8.2. Informative References ................................. 9 9. Acknowledgments ............................................ 10 Lencse et al. Expires April 6, 2019 [Page 2] Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018 1. Introduction IETF has standardized a high number of IPv6 transition technologies [Len2017] and occupied a neutral position trusting the selection to the market. In the upcoming years, several network operators would like to get rid of the burden of maintaining IPv4 in their access and/or core networks. This document deals with five different solutions, each of which can be used to provide an IPv4 service using an IPv6-only access/core network. The following IPv6 transition technologies are covered: 464XLAT [RFC6877], DS-Lite (Dual Stack Lite) [RFC6333], lw4o6 (Lightweight 4over6) [RFC7596], MAP-E [RFC7597] and MAP-T [RFC7599]. 2. High-level Architectures and their Consequences 2.1. Service Provider Network Traversal As for the high-level solution of the IPv6 service provider network traversal, MAP-T use double translation (first at the CE from IPv4 to IPv6, NAT46, and then from IPv6 to IPv4, NAT64, at the service provider network), 464XLAT may use single (NAT64, IPv6 to IPv4) or double translation (as MAP-T), depending on different factors, such as the use of DNS by the applications and the availability of a DNS64. DS-Lite, lw4o6 and MAP-E encapsulate the IPv4 packets into IPv6 packets. Each solution has its own advantages and drawbacks. Double translation results in only 20 bytes overhead (the difference in the minimum header size between IPv4 and IPv6), whereas the overhead of the encapsulation is 40 bytes (because both, the IPv4 and IPv6 headers are needed, compared with only the IPv4 one). The difference may be significant in the case of small packet sizes or when the larger one results in fragmentation. @@OT: Both MAP-T and 464XLAT uses double translation. Traditionally NAT64 hasn’t been considered an IPv4aaS solution. If you want to include it, treat it as a separate solution. The NAT64 in both solution can be “reused" in a IPv6 host/application scenario. s/compared with only the IPv4 one/compared with only the IPv6 one On the one hand, the first step of the double translation case is a stateless NAT from IPv4 to IPv6 implemented as SIIT (Stateless IP/ICMP Translation Algorithm) [RFC7915], which does not translate IPv4 options and/or multicast IP/ICMP packets, whereas with encapsulation-based technologies these remain intact. @@OT None of the sharing solutions would “natively” do multicast. On the other hand, single and double translation results in "normal" IPv6 traffic which can be inspected, e.g., by hashing algorithms, and firewalls, whereas encapsulation results in IPv4-embedded IPv6 packets and their interpretation requires special software/hardware for DPI (deep-packet-inspection). @@OT Replace “DPI" with, looking further into the packet. This isn’t what we tradtionally think of as DPI. Note that this argument goes both ways. Because these middleboxes might want to “treat” the packet as an IPv4 one, and have to reverse-engineer the IPv4 header. The worst case is DS-Lite, which is also doing double stateful translation (NAT44 at the CE, NAT44 at the AFTR). @@OT Actually the worst case is typical deployments of 464XLAT which does 3 stateful translations. NAT44, NAT46 and NAT64. Lencse et al. Expires April 6, 2019 [Page 3] Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018 Another consequence is that the solutions using double translation can carry only TCP, UDP or ICMP over IP, when they are used with IPv4 address sharing (please refer to section 3.3 for more details), whereas the solutions using encapsulation can carry any other protocols over IP, too. @@OT That’s incorrect. There is nothing in the translation/encapsulation difference that affects carrying other IP protocols. IP address sharing is the one that breaks that (since you must forward based on L4 information). 2.2. IPv4 Address Sharing All five technologies support IPv4 address sharing, which has severe consequences described in [RFC6269]. The efficiency of the address sharing of the five technologies is significantly different, it is discussed in section 3.2. We note that lw4o6, MAP-E and MAP-T may not necessarily be configured to do IPv4 address sharing, see the details in Section 3.3, however in that case there is no advantage in terms of public IPv4 addresses saving. @@OT Correct, but there is an advantage in that you can deliver a complete IPv4 address (or prefix) to customers who require use of other protocols than TCP or UDP. 3. More Detailed Analysis 3.1. Details of Architectural Differences 3.1.1. 464XLAT CLAT performs a stateless translation from IPv4 to IPv6 [RFC7915]. It uses IPv4-embedded IPv6 addresses [RFC6052] for both source address and destination address. PLAT performs stateful NAT64 [RFC6146]. @@OT Or in the case of the use of a single IPv6 address it uses stateful translation. So in the case of a 464XLAT router, it has stateful NAT44, stateful NAT46 and stateful NAT64. Note that we generally don’t see state close to the end-user as equally problematic as state in the middle of the network. 3.1.2. DS-Lite The B4 (Basic Bridging BroadBand) element encapsulates the IPv4 packets into IPv6 packets. The AFTR (Address Family Transition Router) de-encapsulates the IPv4 packets from the IPv6 packets and performs stateful NAPT (Network Address and Port Translation). 3.1.3. Lw4o6 Lightweight 4over6 is a variant of DS-Lite. The difference is, that the stateful NAPT is moved from the AFTR to the B4 element. It uses a provisioning mechanism to determine the size of the limited port set per user. @@OT Or you can say that LW46 is a subset of MAP, as it uses the same provisioning, the same port mapping algorithm, and is indistinguishable from MAP-E in 1:1 mode. Lencse et al. Expires April 6, 2019 [Page 4] Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018 3.1.4. MAP-E The CE (Customer-Edge) router first encapsulates IPv4-in-IPv6. Packets must traverse a MAP BR to be [de-]encapsulated. @OT All MAP based solutions also support mesh, i.e. direct communication between CEs, so this statement is not strictly speaking correct. 3.1.5. MAP-T The CE (Customer Edge) router first performs a NAT44 to transform the source addresses and source port numbers of the IPv4 packets into a predefined range, the size of which is a design parameter. The CE router then performs stateless translation from IPv4 to IPv6 [RFC7915], which translates the IPv4 address and the port numbers into the IPv6 address space. The transformations may be fine-tuned by the mapping rules. The MAP BR (Border Relay) performs stateless translation from IPv4 to IPv6 [RFC7915]. @@OT You might qualify this with “When doing IPv4 address sharing”. Also note that the same NAT44 process happens with MAP-E, and LW46. 3.2. Tradeoff between Port Number Efficiency and Stateless Operation 464XLAT and DS-Lite use stateful NAPT at the PLAT and AFTR devices, respectively. This may cause scalability issues. Lw4o6, MAP-E and MAP-T avoid using NAPT in the service provider network. Its cost is that they have to limit the port numbers available for a user, which is also the case for DS-Lite. Determining the optimal size of the @@OT Incorrect with regards to DS-lite. Note, that all CGN solutions will limie the port numbers available. The difference is that in A+P solutions then the port range is fixed. But customers can get a full IPv4 address if required. While in the CGN solutions the limit is more dynamic / centrally adjustable. port set is not an easy task. On the one hand, the lack of port situation may cause serious problems in the operation of certain programs (e.g. the consequences of the session number limitation due to port number shortage were impressively demonstrated using Google Map in [Miy2010]). The port number consumption of different applications is highly varying and e.g. in the case of web browsing it depends on several factors [Rep2014]. And there may be several users behind a CPE, especially in the wired case (e.g. Internet is used by different members of a family simultaneously), thus sometimes even a few thousands ports may not be enough. @@OT This sounds a little opinionated. Adding some numbers/references to this section might help. In an endpoint-dependent NAT, you only need enough ports to cover the number of sessions to the same destination address / port. So with 16 ports, you are restricted to 16 sessions to destination A port P, but you can reuse those 16 ports to destination A port P+1, and destination B, port P. However, on the other hand, assigning too many ports per user will result in waste of public IPv4 addresses, which is a scarce and expensive resource. Therefore, 464XLAT is much more efficient in terms of port number and thus public IP address saving. The price is the stateful operation in the service provider network, which is allegedly does not scale up well. XXX MEASUREMENTS ARE PLANNED TO DECIDE IF IT IS TRUE. XXX @@OT Replace 464XLAT with CGN or centralized NAT, cause this applies to all the solutions that use CGN. NAT444, DS-lite, NAT64. With regards to the “allegedly scale”… I would think that obvious, but apparently not. Let me give you a challenge then. Let’s say you have a device that can do 500Gbps ofg IPv4aaS traffic. The total amount of IPv4 traffic the site must handle is 5Tbps. How do you scale this? With A+P solutions you simply stack 10 of these devices and run ECMP to load-balance across them. If you want to take one out of service you simply pull that one out of the ECMP bundle. Now for stateful NAT, tell me how you want to do it. We also note that NAT64 does not pre-allocate ports for customers but allocates them "on the fly" (which means that even the same customer is using ports from different addresses, and most of the time, different customers get ports from any given addresses), and in fact this creates many application/service providers (Sony @@OT That’s dependent on the NAT64 setup. We can very well do deterministic stateful NAT too. And you could reserve a fixed set of ports for each customer, just like A+P. There is nothing inherit in the mechanism in NAT64. The downside of not pre-allocated ports / indeterministic NAT, is logging requirements are much higher. You should add logging as a separate section, if you don’t have it. Lencse et al. Expires April 6, 2019 [Page 5] Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018 PlayStation Network, OpenDNS, etc.) to permanently black-list the IPv4 ranges once they are detected to be used for address sharing. 3.3. Support for Server Operation Lw4o6, MAP-E and MAP-T may be configured without IPv4 address sharing, allowing exclusive use of all ports, and non-port-based layer 4 protocols. Thus, they may also be used to support server operation, when public IPv4 addresses are assigned to the subscribers, however, then there is no advantage in terms of IPv4 public addresses saving. It is also possible to configure specific ports mapping in 464XLAT/NAT64 using EAMT [RFC7757], which means that only those ports are "lost" from the pool of addresses, so there is a higher maximization of the total usage of IPv4/port resources. @@OT That is also possible in A+P. E.g. you can route port 80 to a particular CPE. In both cases that complicates provisioning. Which is another section you should probably add. 3.4. Support and Implementations 3.4.1. OS Support As for 464XLAT, client support exists in Windows 10, Linux (including Android), Windows Mobile, and Chrome OS, but it is missing from iOS and MacOS. For the other four solutions, we are not aware of any OS support. @@OT IPv4aaS is typically thought of as something running on an CE router. You may run it on a host, and in the 464XLAT that is a mobile phone, acting as a NAT/router. At least I’m not aware of very much of a use case for IPv4aaS host support, so I’m not sure this section adds very much. 3.4.2. Support in Cellular and Broadband Networks Several cellular networks use 464XLAT, whereas we are not aware of any deployment of the four other technologies in cellular networks, as they are not supported. In broadband networks, there are some deployments of 464XLAT, MAP-E and MAP-T. Both, lw4o6 and DS-Lite have more deployments, having been up now DS-Lite the most used one, but lw4o6 taking over in the last years. @@OT This seems like speculation. I think the best you can do is to say there are large deployments of all mechanism. Proving that letting the market decide is a terrible strategy. ;-) 3.4.3. Implementation Code Sizes As for complexity hint, the code size reported from OpenWRT implementation is 17kB, 35kB, 15kB, 35kB, and 48kB for 464XLAT, lw4o6, DS-Lite, MAP-E, MAP-T, and lw4o6, respectively (https://openwrt.org/packages/start). We note that the support for all five technologies requires much less code size than the total sum of the above quantities, because Lencse et al. Expires April 6, 2019 [Page 6] Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018 they contain a lot of common functions (data plane is shared among several of them). 4. Performance Comparison We plan to compare the performances of the most prominent free software implementations of the five IPv6 transition technologies using the methodology described in "Benchmarking Methodology for IPv6 Transition Technologies" [RFC8219]. On the one hand, the Dual DUT Setup of RFC8219 makes it possible to use the existing "Benchmarking Methodology for Network Interconnect Devices" [RFC2544] compliant measurement devices, however, this setup has the drawback that the performances of the CE and of the ISP side device (e.g. the CLAT and the PLAT of 464XLAT) are measured together. In order to measure the performance of only one of them, we need to ensure that the desired one is the bottleneck. On the other hand, the Single DUT Setup of [RFC8219] makes it possible to benchmark the selected device separately, however, no [RFC8219] compliant testers available yet. A DPDK-based software Tester for stateless NAT64 is currently under development and it is expected to be available this autumn as a free software. XXX FROM WHERE XXX Any volunteers for developing [RFC8219] compliant measurement software? @OT For any IPv4aaS mechanism it looks exactly like an IPv4 link and you can test it as such. The only exception is NAT64, which would have IPv6 on one side and IPv4 on the other, but from the document I am unsure if you consider NAT64 in or out of scope. 5. Security Considerations According to the simplest model, the number of bugs is proportional to the number of code lines. Please refer to section 3.4.3 for code sizes of CE implementations. For all five technologies, the CE device should contain a DNS proxy. @@OT Why? And why is that in the security considerations? However, the user may change DNS settings. If it happens and lw4o6, MAP-E and MAP-T are used with significantly restricted port set, which is required for an efficient public IPv4 address sharing, the entropy of the source ports is significantly lowered (e.g. from 16 bits to 10 bits, when 1024 port numbers are assigned to each subscriber) and thus these technologies are theoretically less resilient against cache poisoning, see [RFC5452]. However, an efficient cache poisoning attack requires that the subscriber operates an own caching DNS server and the attack is performed in the service provider network. Thus, we consider the chance of the successful exploitation of this vulnerability as low. @@OT For MAP-E, -T and LW46 it is strongly recommended that IPv6 is used for DNS transport. You might want to add that. Lencse et al. Expires April 6, 2019 [Page 7] Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018 An in-depth security analysis of all five IPv6 transition technologies and their most prominent free software implementations according to the methodology defined in [Len2018] is planned. 6. IANA Considerations TBD. 7. Conclusions TBD. 8. References 8.1. Normative References [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, DOI 10.17487/RFC2544, March 1999, <http://www.rfc- editor.org/info/rfc2544>. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, DOI 10.17487/RFC6052, October 2010, <http://www.rfc- editor.org/info/rfc6052>. [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <http://www.rfc-editor.org/info/rfc6146. [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, DOI 10.17487/RFC6269, June 2011, <http://www.rfc- editor.org/info/rfc6269. [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, <http://www.rfc-editor.org/info/rfc6333>. [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, April 2013, <http://www.rfc- editor.org/info/rfc6877>. Lencse et al. Expires April 6, 2019 [Page 8] Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the Dual- Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, July 2015, <http://www.rfc-editor.org/info/rfc7596>. [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, Ed., "Mapping of Address and Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/RFC7597, July 2015, <http://www.rfc- editor.org/info/rfc7597>. [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., and T. Murakami, "Mapping of Address and Port using Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 2015, <http://www.rfc-editor.org/info/rfc7599>. [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, "IP/ICMP translation algorithm", RFC 7915, DOI: 10.17487/RFC7915, June 2016, <http://www.rfc- editor.org/info/rfc7915>. [RFC7757] Anderson, T., and A. Leiva Popper "Explicit Address Mappings for Stateless IP/ICMP Translation", RFC 7757, DOI 10.17487/RFC7757, February 2016, <http://www.rfc- editor.org/info/rfc77757>. [RFC8219] Georgescu, M., Pislaru, L., and G. Lencse, "Benchmarking Methodology for IPv6 Transition Technologies", IETF RFC 8219, DOI: 10.17487/RFC8219, Aug. 2017, <http://www.rfc- editor.org/info/rfc8219>. 8.2. Informative References [Len2017] Lencse, G., and Y. Kadobayashi, "Survey of IPv6 Transition Technologies for Security Analysis", IEICE Communications Society Internet Architecture Workshop, Tokyo, Japan, Aug. 28, 2017, IEICE Tech. Rep., vol. 117, no. 187, pp. 19-24. http://www.hit.bme.hu/~lencse/publications/IEICE-IA-2017- survey.pdf Lencse et al. Expires April 6, 2019 [Page 9] Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018 [Len2018] Lencse, G., and Y. Kadobayashi, "Methodology for the identification of potential security issues of different IPv6 transition technologies: Threat analysis of DNS64 and stateful NAT64", Computers & Security (Elsevier), vol. 77, no. 1, pp. 397-411, August 1, 2018, DOI: 10.1016/j.cose.2018.04.012, http://www.hit.bme.hu/~lencse/publications/ECS-2018- Methodology-revised.pdf [Miy2010] Miyakawa, S., "IPv4 to IPv6 transformation schemes", IEICE Trans. Commun., vol.E93-B, no.5, pp.1078-1084, May 2010. DOI:10.1587/transcom.E93.B.1078 [Rep2014] Repas, S., Hajas, T., and G. Lencse, "Port number consumption of the NAT64 IPv6 transition technology", Proc. 37th Internat. Conf. on Telecommunications and Signal Processing (TSP 2014), Berlin, Germany, pp.66-72, Jul. 1-3, 2014. DOI: 10.1109/TSP.2015.7296411 9. Acknowledgments The authors would like to acknowledge the inputs of Ole Troan, Mark Andrews, Edwin Cordeiro, Fred Baker, Alexandre Petrescu, and TBD. This document was prepared using 2-Word-v2.0.template.dot. Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). Lencse et al. Expires April 6, 2019 [Page 10] Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018 Authors' Addresses Gabor Lencse Budapest University of Technology and Economics Magyar Tudosok korutja 2. H-1117 Budapest, Hungary Email: lencse@hit.bme.hu Jordi Palet Martinez The IPv6 Company Molino de la Navata, 75 La Navata - Galapagar, Madrid - 28420 Spain Email: jordi.palet@theipv6company.com Lee Howard Retevia 9940 Main St., Suite 200 Fairfax Virginia 22031, USA Email: lee@asgard.org Richard Patterson Sky UK 1 Brick Lane London, E1 6PU United Kingdom Email: richard.patterson@sky.uk Lencse et al. Expires April 6, 2019 [Page 11]
- [v6ops] New I-D: "Pros and Cons of IPv6 Transitio… Lencse Gábor
- Re: [v6ops] New I-D: "Pros and Cons of IPv6 Trans… Fred Baker
- Re: [v6ops] New I-D: "Pros and Cons of IPv6 Trans… Ole Troan
- Re: [v6ops] New I-D: "Pros and Cons of IPv6 Trans… Lencse Gábor
- [v6ops] Testing of transition mechanisms [Re: New… Ole Troan
- [v6ops] Scaling stateful transition mechanisms [R… Ole Troan
- Re: [v6ops] New I-D: "Pros and Cons of IPv6 Trans… Ole Troan
- Re: [v6ops] New I-D: "Pros and Cons of IPv6 Trans… Ole Troan
- Re: [v6ops] New I-D: "Pros and Cons of IPv6 Trans… Ole Troan
- Re: [v6ops] New I-D: "Pros and Cons of IPv6 Trans… Ca By
- Re: [v6ops] Scaling stateful transition mechanism… Ca By
- Re: [v6ops] New I-D: "Pros and Cons of IPv6 Trans… Ole Troan
- Re: [v6ops] Scaling stateful transition mechanism… Ole Troan
- Re: [v6ops] Scaling stateful transition mechanism… Tore Anderson
- Re: [v6ops] Scaling stateful transition mechanism… Ca By
- Re: [v6ops] Scaling stateful transition mechanism… Ole Troan
- Re: [v6ops] Testing of transition mechanisms [Re:… Lencse Gábor
- [v6ops] source of traffic share information -- Re… Lencse Gábor
- Re: [v6ops] Testing of transition mechanisms [Re:… Ole Troan
- Re: [v6ops] Testing of transition mechanisms [Re:… Lencse Gábor
- Re: [v6ops] source of traffic share information -… Ca By
- Re: [v6ops] New I-D: "Pros and Cons of IPv6 Trans… Alexandre Petrescu
- Re: [v6ops] New I-D: "Pros and Cons of IPv6 Trans… Richard Patterson
- Re: [v6ops] New I-D: "Pros and Cons of IPv6 Trans… Mikael Abrahamsson
- Re: [v6ops] New I-D: "Pros and Cons of IPv6 Trans… JORDI PALET MARTINEZ
- Re: [v6ops] New I-D: "Pros and Cons of IPv6 Trans… Gert Doering
- Re: [v6ops] New I-D: "Pros and Cons of IPv6 Trans… Alexandre Petrescu
- Re: [v6ops] New I-D: "Pros and Cons of IPv6 Trans… Gert Doering
- Re: [v6ops] New I-D: "Pros and Cons of IPv6 Trans… Satoru Matsushima
- Re: [v6ops] New I-D: "Pros and Cons of IPv6 Trans… Ca By
- Re: [v6ops] New I-D: "Pros and Cons of IPv6 Trans… Fred Baker