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.
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.
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).
The worst case is DS-Lite, which is also doing double stateful
translation (NAT44 at the CE, NAT44 at the AFTR).
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.
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.
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].
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.
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.
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].
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
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. 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
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
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.
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.
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.
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?
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.
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.
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]