Internet Engineering Task Force G. Lencse Internet-Draft BUTE Intended status: Informational J. Palet Martinez Expires: July 28, 2019 The IPv6 Company L. Howard Retevia R. Patterson Sky UK I. Farrer Deutsche Telekom AG January 24, 2019 Pros and Cons of IPv6 Transition Technologies for IPv4aaS draft-lmhp-v6ops-transition-comparison-02 Abstract Several IPv6 transition technologies have been developed to provide customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only access and/or core network. All these technologies have their advantages and disadvantages, and depending on existing topology, skills, strategy and other preferences, one of these technologies may be the most appropriate solution for a network operator. This document examines the five most prominent IPv4aaS technologies considering a number of different aspects to provide network operators with an easy to use reference to assist in selecting the technology that best suits their needs. 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on July 28, 2019. Lencse, et al. Expires July 28, 2019 [Page 1]

Internet-Draft Pros and Cons of IPv4aaS Technologies January 2019 Copyright Notice Copyright (c) 2019 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 (https://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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Overview of the Technologies . . . . . . . . . . . . . . . . 4 2.1. 464XLAT . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Dual-Stack Lite . . . . . . . . . . . . . . . . . . . . . 5 2.3. Lightweight 4over6 . . . . . . . . . . . . . . . . . . . 5 2.4. MAP-E . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.5. MAP-T . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. High-level Architectures and their Consequences . . . . . . . 8 3.1. Service Provider Network Traversal . . . . . . . . . . . 8 3.2. Network Address Translation . . . . . . . . . . . . . . . 9 3.3. IPv4 Address Sharing . . . . . . . . . . . . . . . . . . 9 3.4. CE Provisioning Considerations . . . . . . . . . . . . . 10 3.5. Support for Multicast . . . . . . . . . . . . . . . . . . 11 4. Detailed Analysis . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Architectural Differences . . . . . . . . . . . . . . . . 11 4.1.1. Basic Comparison . . . . . . . . . . . . . . . . . . 11 4.2. Tradeoff between Port Number Efficiency and Stateless Operation . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3. Support for Public Server Operation . . . . . . . . . . . 14 4.4. Support and Implementations . . . . . . . . . . . . . . . 15 4.4.1. OS Support . . . . . . . . . . . . . . . . . . . . . 15 4.4.2. Support in Cellular and Broadband Networks . . . . . 15 4.4.3. Implementation Code Sizes . . . . . . . . . . . . . . 16 4.5. Typical Deployment and Traffic Volume Considerations . . 16 4.5.1. Deployment Possibilities . . . . . . . . . . . . . . 16 4.5.2. Cellular Networks with 464XLAT . . . . . . . . . . . 16 4.6. Load Sharing . . . . . . . . . . . . . . . . . . . . . . 17 4.7. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 Lencse, et al. Expires July 28, 2019 [Page 2]

Internet-Draft Pros and Cons of IPv4aaS Technologies January 2019 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . 21 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 22 A.1. 01 - 02 . . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1 . Introduction LEN2017] based on differing requirements and deployment scenarios. The number of technologies that have been developed makes it time consuming for a network operator to identify the most appropriate mechanism for their specific deployment. This document provides a comparative analysis of the most commonly used mechanisms to assist operators with this problem. Five different IPv4aaS solutions are considered. The following IPv6 transition technologies are covered: 1. 464XLAT [RFC6877] 2. Dual Stack Lite [RFC6333] 3. lw4o6 (Lightweight 4over6) [RFC7596] 4. MAP-E [RFC7597] 5. MAP-T [RFC7599] 1.1 . Requirements Language BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Lencse, et al. Expires July 28, 2019 [Page 3]

Internet-Draft Pros and Cons of IPv4aaS Technologies January 2019 2 . Overview of the Technologies 2.1 . 464XLAT RFC7915] (more precisely, stateless NAT46, a stateless IP/ICMP translation from IPv4 to IPv6). IPv4-embedded IPv6 addresses [RFC6052] are used for both source and destination addresses. Commonly, a /96 prefix (either the 64:ff9b::/96 Well-Known Prefix, or a Network-Specific Prefix) is used as the IPv6 destination for the IPv4-embedded client traffic. In the operator's network, the provider-side translator (PLAT) performs stateful NAT64 [RFC6146] to translate the traffic. The destination IPv4 address is extracted from the IPv4-embedded IPv6 packet destination address and the source address is from a pool of public IPv4 addresses. Alternatively, when a dedicated /64 is not available for translation, the CLAT device uses a stateful NAT44 translation before the stateless NAT46 translation. Note that we generally do not see state close to the end-user as equally problematic as state in the middle of the network. In typical deployments, 464XLAT is used together with DNS64, see Section 3.1.2 of [I-D.ietf-v6ops-nat64-deployment]. When an IPv6-only client or application communicates with an IPv4-only server, the DNS64 server returns the IPv4-embedded IPv6 address of the IPv4-only server. In this case, the IPv6-only client sends out IPv6 packets, thus CLAT functions as an IPv6 router and the PLAT performs a stateful NAT64 for these packets. In this case, there is a single translation. Alternatively, one can say that the DNS64 + stateful NAT64 is used to carry the traffic of the IPv6-only client and the IPv4-only server, and the CLAT is used only for the IPv4 traffic from applications or devices that use literal IPv4 addresses or non-IPv6 compliant APIs. Lencse, et al. Expires July 28, 2019 [Page 4]

Internet-Draft Pros and Cons of IPv4aaS Technologies January 2019 Private +----------+ Translated +----------+ _______ +------+ IPv4 | CLAT | 4-6-4 | Stateful | ( IPv4 ) | IPv4 |------->| Stateless|------------>| PLAT +--( Internet ) |Device|<-------| NAT46 |<------------| NAT64 | (________) +------+ +----------+ ^ +----------+ | Operator IPv6 network Figure 1: Overview of the 464XLAT architecture Note: in mobile networks, CLAT is commonly implemented in the user's equipment (UE or smartphone). 2.2 . Dual-Stack Lite RFC6333] was the first of the considered transition mechanisms to be developed. DS-Lite uses a 'Basic Broadband Bridging' (B4) function in the customer's CE router that encapsulates IPv4 in IPv6 traffic and sends it over the IPv6 native service-provider network to a centralized 'Address Family Transition Router' (AFTR). The AFTR performs encapsulation/decapsulation of the 4in6 traffic and translates the IPv4 payload to public IPv4 source address using a stateful NAPT44 function. +-------------+ Private +----------+ IPv4-in-IPv6|Stateful AFTR| +------+ IPv4 | B4 | tunnel |------+------+ _______ | IPv4 |------->| Encap./ |------------>|Encap.| | ( IPv4 ) |Device|<-------| decap. |<------------| / | NAPT +--( Internet ) +------+ +----------+ ^ |Decap.| 44 | (________) | +------+------+ Operator IPv6 network Figure 2: Overview of the DS-Lite architecture 2.3 . Lightweight 4over6 RFC6346] of provisioning each Lencse, et al. Expires July 28, 2019 [Page 5]

Internet-Draft Pros and Cons of IPv4aaS Technologies January 2019 lwB4 with a unique tuple of IPv4 address unique range of layer-4 ports. The client uses these for NAPT44. The lwAFTR implements a binding table, which has a per-client entry linking the customer's source IPv4 address and allocated range of layer-4 ports to their IPv6 tunnel endpoint address. The binding table allows egress traffic from customers to be validated (to prevent spoofing) and ingress traffic to be correctly encapsulated and forwarded. As there needs to be a per-client entry, an lwAFTR implementation needs to be optimized for performing a per-packet lookup on the binding table. Direct communication between two lwB4s is performed by hair-pinning traffic through the lwAFTR. +-------------+ +----------+ Private | lwB4 | IPv4-in-IPv6| Stateless| +------+ IPv4 |------+------| tunnel | lwAFTR | _______ | IPv4 |------->| |Encap.|------------>|(encap/A+P| ( IPv4 ) |Device|<-------| NAPT | / |<------------|bind. tab +--( Internet ) +------+ | 44 |Decap.| ^ | routing) | (________) +------+------+ | +----------+ Operator IPv6 network Figure 3: Overview of the lw4o6 architecture 2.4 . MAP-E RFC2663] to translate the private IPv4 source addresses and source ports into an address and port range defined by applying the MAP rule applied to the delegated IPv6 prefix. The client address/port allocation size is a design parameter. The CE router then encapsulates the IPv4 packet in an IPv6 packet [RFC2473] and sends it directly to another host in the MAP domain (for peer-to-peer) or to a Border Router (BR) if the IPv4 destination is not covered in one of the CE's MAP rules. The MAP BR is provisioned with the set of MAP rules for the MAP domains it serves. These rules determine how the MAP BR is to Lencse, et al. Expires July 28, 2019 [Page 6]

Internet-Draft Pros and Cons of IPv4aaS Technologies January 2019 decapsulate traffic that it receives from client, validating the source IPv4 address and layer 4 ports assigned, as well as how to calculate the destination IPv6 address for ingress IPv4 traffic. +-------------+ +----------+ Private | MAP CE | IPv4-in-IPv6| Stateless| +------+ IPv4 |------+------| tunnel | MAP BR | _______ | IPv4 |------->| |Encap.|------------>|(encap/A+P| ( IPv4 ) |Device|<-------| NAPT | / |<------------|algorithm +--( Internet ) +------+ | 44 |Decap.| ^ | routing) | (________) +------+------+ | +----------+ Operator IPv6 network Figure 4: Overview of the MAP-E architecture 2.5 . MAP-T RFC7915]. The MAP BR is provisioned with the same BMR as the client, enabling the received IPv6 traffic to be statelessly NAT64 translated back to the public IPv4 source address used by the client. Using translation instead of encapsulation also allows IPv4-only nodes to correspond directly with IPv6 nodes in the MAP-T domain that have IPv4-embedded IPv6 addresses. +-------------+ +----------+ Private | MAP CE | Translated | Stateless| +------+ IPv4 |------+------| 4-6-4 | MAP BR | _______ | IPv4 |------->| |State-|------------>|(NAT64/A+P| ( IPv4 ) |Device|<-------| NAPT | less |<------------|algorithm +--( Internet ) +------+ | 44 |NAT46 | ^ | routing) | (________) +------+------+ | +----------+ Operator IPv6 network Figure 5: Overview of the MAP-T architecture Lencse, et al. Expires July 28, 2019 [Page 7]

Internet-Draft Pros and Cons of IPv4aaS Technologies January 2019 3 . High-level Architectures and their Consequences 3.1 . Service Provider Network Traversal RFC2473]. This is a stateless tunneling mechanism which does not require any additional tunnel headers. It should be noted that both of these approaches result in an increase in the size of the packet that needs to be transported across the operator's network when compared to native IPv4. 4-6-4 translation adds a 20-bytes overhead (the 20-byte IPv4 header is replaced with a 40-byte IPv6 header). Encapsulation has a 40-byte overhead (an IPv6 header is prepended to the IPv4 header). The increase in packet size can become a significant problem if there is a link with a smaller MTU in the traffic path. This may result in traffic needing to be fragmented at the ingress point to the IPv6 only domain (i.e., the NAT46 or 4in6 encapsulation endpoint). It may also result in the need to implement buffering and fragment re- assembly in the BR node. The advice given in [RFC7597] Section 8.3.1 is applicable to all of these mechanisms: It is strongly recommended that the MTU in the IPv6-only domain be well managed and that the IPv6 MTU on the CE WAN- side interface be set so that no fragmentation occurs within the boundary of the IPv6-only domain. Lencse, et al. Expires July 28, 2019 [Page 8]

Internet-Draft Pros and Cons of IPv4aaS Technologies January 2019 3.2 . Network Address Translation I-D.ietf-v6ops-nat64-deployment]. The first step for the double translation mechanisms is a stateless NAT from IPv4 to IPv6 implemented as SIIT (Stateless IP/ICMP Translation Algorithm) [RFC7915], which does not translate IPv4 header options and/or multicast IP/ICMP packets. With encapsulation- based technologies the header is transported intact and multicast can also be carried. Single and double translation results in native IPv6 traffic with a layer-4 next-header. The fields in these headers can be used for functions such as hashing across equal-cost multipaths or ACLs. For encapsulation, there is an IPv6 header followed by an IPv4 header. This results in less entropy for hashing algorithms, and may mean that devices in the traffic path that perform header inspection (e.g. router ACLs or firewalls) require the functionality to look into the payload header. Solutions using double translation can only carry port-aware IP protocols (e.g. TCP, UDP) and ICMP when they are used with IPv4 address sharing (please refer to Section 4.3 for more details). Encapsulation based solutions can carry any other protocols over IP, too. 3.3 . IPv4 Address Sharing Lencse, et al. Expires July 28, 2019 [Page 9]

Internet-Draft Pros and Cons of IPv4aaS Technologies January 2019 o Centralized Stateful NAPT44 (DS-Lite, 464XLAT) o Distributed Stateful NAPT44 (lw4o6, MAP-E, MAP-T) In the centralized model, a device such as a CGN/AFTR or NAT64 performs the NAPT44 function and maintains per-session state for all of the active client's traffic. The customer's device does not require per-session state for NAPT. In the distributed model, a device (usually a CE) performs stateful NAPT44 and maintains per-session state only co-located devices, e.g. in the customer's home network. Here, the centralised network function (lwAFTR or BR) only needs to perform stateless encapsulation/decapsulation or NAT64. However, it is also worth noting that if the data retention regulatory requirements in force mandate per-flow logging, then a centralised NAPT44 model may be the only way to meet this requirement. Issues related to IPv4 address sharing mechanisms are described in [RFC6269] and should also be considered. The address sharing efficiency of the five technologies is significantly different, it is discussed in Section 4.2 lw4o6, MAP-E and MAP-T can also be configured without IPv4 address sharing, see the details in Section 4.3. However, in that case, there is no advantage in terms of public IPv4 address saving. In the case of 464XLAT, this can be achieved as well through EAMT [RFC7757]. Conversely, both MAP-E and MAP-T may be configured to provide more than one public IPv4 address (i.e., an IPv4 prefix shorter than a /32) to customers. 3.4 . CE Provisioning Considerations Lencse, et al. Expires July 28, 2019 [Page 10]

Internet-Draft Pros and Cons of IPv4aaS Technologies January 2019 +------------------+---------+---------+-------+-------+-------+ | | 464XLAT | DS-Lite | lw4o6 | MAP-E | MAP-T | +------------------+---------+---------+-------+-------+-------+ | DHCPv6 [RFC8415] | | X | X | X | X | | RADIUS Attr. | | X | X | X | X | | TR-69 | X | X | | X | X | | DNS64 [RFC6147] | X | | | | | | YANG [RFC6050] | | X | X | X | X | | DHCP4o6 | | | X | X | | +------------------+---------+---------+-------+-------+-------+ Table 2: Available Provisioning Mechanisms 3.5 . Support for Multicast RFC8114] describes a method for carrying encapsulated IPv4 multicast traffic over an IPv6 multicast network. This could be deployed in parallel to any of the operator's chosen IPv4aaS mechanism. 4 . Detailed Analysis 4.1 . Architectural Differences 4.1.1 . Basic Comparison Lencse, et al. Expires July 28, 2019 [Page 11]

Internet-Draft Pros and Cons of IPv4aaS Technologies January 2019 4.2 . Tradeoff between Port Number Efficiency and Stateless Operation Section 4.7 below. Determining the optimal number of ports for a fixed port set is not an easy task, and may also be impacted by local regulatory law, which may define a maximum number of users per IP address, and consequently a minimum number of ports per user. On the one hand, the "lack of ports" situation may cause serious problems in the operation of certain applications. For example, Miyakawa has demonstrated the consequences of the session number limitation due to port number shortage on the example of Google Maps [MIY2010]. When the limit was 15, several blocks of the map were missing, and the map was unusable. This study also provided several examples for the session numbers of different applications (the highest one was Apple's iTunes: 230-270 ports). The port number consumption of different applications is highly varying and e.g. in the case of web browsing it depends on several factors, including the choice of the web page, the web browser, and sometimes even the operating system [REP2014]. For example, under certain conditions, 120-160 ports were used (URL: sohu.com, browser: Firefox under Ubuntu Linux), and in some other cases it was only 3-12 ports (URL: twitter.com, browser: Iceweasel under Debian Linux). Lencse, et al. Expires July 28, 2019 [Page 12]

Internet-Draft Pros and Cons of IPv4aaS Technologies January 2019 There may be several users behind a CE router, especially in the broadband case (e.g. Internet is used by different members of a family simultaneously), so sufficient ports must be allocated to avoid impacting user experience. Furthermore, assigning too many ports per CE router will result in waste of public IPv4 addresses, which is a scarce and expensive resource. Clearly this is a big advantage in the case of 464XLAT where they are dynamically managed, so that the number of IPv4 addresses for the sharing-pool is smaller while the availability of ports per user don't need to be pre-defined and is not a limitation for them. There is a direct tradeoff between the optimization of client port allocations and the associated logging overhead. Section 4.7 discusses this in more depth. We note that common CE router NAT44 implementations utilizing Netfilter, multiplexes active sessions using a 3-tuple (source address, destination address, and destination port). This means that external source ports can be reused for unique internal source and destination address and port sessions. It is also noted, that Netfilter cannot currently make use of multiple source port ranges (i.e. several blocks of ports distributed across the total port space as is common in MAP deployments), this may influence the design when using stateless technologies. Stateful technologies, 464XLAT and DS-Lite (and also NAT444) can therefore be much more efficient in terms of port allocation and thus public IP address saving. The price is the stateful operation in the service provider network, which allegedly does not scale up well. It should be noticed that in many cases, all those factors may depend on how it is actually implemented. XXX MEASUREMENTS ARE PLANNED TO TEST IF THE ABOVE IS TRUE. XXX We note that some CGN-type solutions can allocate ports dynamically "on the fly". Depending on configuration, this can result in the same customer being allocated ports from different source addresses. This can cause operational issues for protocols and applications that expect multiple flows to be sourced from the same address. E.g., ECMP hashing, STUN, gaming, content delivery networks. However, it should be noticed that this is the same problem when a network has a NAT44 with multiple public IPv4 addresses, or even when applications in a dual-stack case, behave wrongly if happy eyeballs is flapping the flow address between IPv4 and IPv6. Lencse, et al. Expires July 28, 2019 [Page 13]

Internet-Draft Pros and Cons of IPv4aaS Technologies January 2019 The consequences of IPv4 address sharing [RFC6269] may impact all five technologies. However, when ports are allocated statically, more customers may get ports from the same public IPv4 address, which may results in negative consequences with higher probability, e.g. many applications and service providers (Sony PlayStation Network, OpenDNS, etc.) permanently black-list IPv4 ranges if they detect that they are used for address sharing. Both cases are, again, implementation dependent. We note that although it is not of typical use, one can do deterministic, stateful NAT and reserve a fixed set of ports for each customer, as well. 4.3 . Support for Public Server Operation RFC6877] provides a mechanism for a client to request an external public port from a CGN device and is supported in some DS-Lite AFTR implementations. A+P based mechanisms distribute a public IPv4 address and restricted range of layer-4 ports to the client. In this case, it is possible for the user to configure their device to offer a publicly accessible server on one of their allocated ports. It should be noted that commonly operators do not assign the Well-Known-Ports to users (unless they are allocating a full IPv4 address), so the user will need to run the service on an allocated port, or configure port translation. Lw4o6, MAP-E and MAP-T may be configured to allocated clients with a full IPv4 address, allowing exclusive use of all ports, and non-port- based layer 4 protocols. Thus, they may also be used to support server/services operation on their default ports. However, when public IPv4 addresses are assigned to the CE router without address sharing, obviously 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. Lencse, et al. Expires July 28, 2019 [Page 14]

Internet-Draft Pros and Cons of IPv4aaS Technologies January 2019 4.4 . Support and Implementations 4.4.1 . OS Support http://www.jool.mx MAP-BR, lwAFTR, CGN, CLAT, NAT64: VPP/fd.io https://gerrit.fd.io/r/#/admin/projects/ lwAFTR: https://github.com/Igalia/snabb DSLite AFTR: https://www.isc.org/downloads/ 4.4.2 . Support in Cellular and Broadband Networks Lencse, et al. Expires July 28, 2019 [Page 15]

Internet-Draft Pros and Cons of IPv4aaS Technologies January 2019 4.4.3 . Implementation Code Sizes 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 they contain a lot of common functions (data plane is shared among several of them). 4.5 . Typical Deployment and Traffic Volume Considerations 4.5.1 . Deployment Possibilities 4.5.2 . Cellular Networks with 464XLAT Lencse, et al. Expires July 28, 2019 [Page 16]

Internet-Draft Pros and Cons of IPv4aaS Technologies January 2019 4.6 . Load Sharing 4.7 . Logging Section 4.2, a client may open hundreds of sessions during common tasks such as web-browsing, each of which needs to be logged so the overall logging burden on the network operator is significant. In some countries, this level of logging is required to comply with data retention legislation. Lencse, et al. Expires July 28, 2019 [Page 17]

Internet-Draft Pros and Cons of IPv4aaS Technologies January 2019 One common optimization available to reduce the logging overhead is the allocation of a block of ports to a client for the duration of their session. This means that logging entry only needs to be made when the client's port block is released, which dramatically reducing the logging overhead. This comes as the cost of less efficient public address sharing as clients need to be allocated a port block of a fixed size regardless of the actual number of ports that they are using. Stateless technologies that pre-allocate the IPv4 addresses and ports only require that copies of the active MAP rules (for MAP-E and MAP- T), or binding-table (for lw4o6) are retained along with timestamp information of when they have been active. Support tools (e.g., those used to serve data retention requests) may need to be updated to be aware of the mechanism in use (e.g., implementing the MAP algorithm so that IPv4 information can be linked to the IPv6 prefix delegated to a client). As stateless technologies do not have a centralized stateful element which customer traffic needs to pass through, so if data retention laws mandate per-session logging, there is no simple way of meeting this requirement with a stateless technology alone. 5 . Acknowledgements 6 . IANA Considerations 7 . Security Considerations Section 4.4.3 for code sizes of CE implementations. For all five technologies, the CE device should contain a DNS proxy. 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 Lencse, et al. Expires July 28, 2019 [Page 18]

Internet-Draft Pros and Cons of IPv4aaS Technologies January 2019 [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, DOI: 10.1109/TSP.2015.7296411, July 2014. Appendix A . Change Log A.1 . 01 - 02 Lencse, et al. Expires July 28, 2019 [Page 22]

Internet-Draft Pros and Cons of IPv4aaS Technologies January 2019 Jordi Palet Martinez The IPv6 Company Molino de la Navata, 75 La Navata - Galapagar, Madrid 28420 Spain Email: jordi.palet@theipv6company.com URI: http://www.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 EQ 6PU United Kingdom Email: richard.patterson@sky.uk Ian Farrer Deutsche Telekom AG Landgrabenweg 151 Bonn 53227 Germany Email: ian.farrer@telekom.de Lencse, et al. Expires July 28, 2019 [Page 23]