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 22, 2018
Pros and Cons of IPv6 Transition Technologies for IPv4aaS
draft-lmhp-v6ops-transition-comparison-01.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 22, 2019 [Page 1]
Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018
This Internet-Draft will expire on April 22, 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. Detailed Analysis ............................................ 4
3.1. Architectural Differences ............................... 4
3.1.1. 464XLAT ............................................ 4
3.1.2. DS-Lite ............................................ 5
3.1.3. Lw4o6 .............................................. 5
3.1.4. MAP-E .............................................. 6
3.1.5. MAP-T .............................................. 6
3.1.6. Basic Comparison ................................... 6
3.2. Tradeoff between Port Number Efficiency and Stateless
Operation ............................................. 7
3.3. Support for Server Operation ............................ 9
3.4. Support and Implementations ............................. 9
3.4.1. OS Support ......................................... 9
3.4.2. Support in Cellular and Broadband Networks ......... 9
3.4.3. Implementation Code Sizes ......................... 10
3.5. Typical Deployment and Traffic Volume Considerations ... 10
3.5.1. Deployment Possibilities .......................... 10
3.5.2. Cellular Networks with 464XLAT .................... 10
3.6. Load Sharing ........................................... 11
3.7. Logging ................................................ 11
4. Performance Comparison ...................................... 11
5. Security Considerations ..................................... 12
6. IANA Considerations ......................................... 12
7. Conclusions ................................................. 12
Lencse et al. Expires April 22, 2019 [Page 2]
Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018
8. References .................................................. 13
8.1. Normative References ................................... 13
8.2. Informative References ................................. 14
9. Acknowledgments ............................................. 15
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 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 double translation (stateless NAT46 + stateful
NAT64) or single translation (stateful NAT64), depending on
different factors, such as the use of DNS by the applications and
the availability of a DNS64 function (in the host or in the service
provider network). For deployment guidelines, please refer to [I-
D.draft-ietf-v6ops-nat64-deployment].
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 included). The difference may be significant in the case
of small packet sizes or when the overhead results in fragmentation.
Lencse et al. Expires April 22, 2019 [Page 3]
Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018
The first step of the double translation cases 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 looking further into the packet.
The worst case is DS-Lite, which is also doing double stateful
translation (NAT44 at the CE and NAT44 at the AFTR).
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.
We also note that none of the five solutions support "native" IPv4
multicast. Please refer to Section 4 of [I-D.draft-ietf-v6ops-
transition-ipv4aas] for the planned requirements for CE routers.
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 can also be configured without
IPv4 address sharing, see the details in Section 3.3. However in
that case, there is no advantage in terms of public IPv4 address
saving.
3. Detailed Analysis
3.1. Architectural Differences
3.1.1. 464XLAT
When 464XLAT is used, in the simplest case, CLAT performs a
stateless translation from IPv4 to IPv6 [RFC7915]. It uses IPv4-
Lencse et al. Expires April 22, 2019 [Page 4]
Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018
embedded IPv6 addresses [RFC6052] for both source address and
destination address. PLAT performs stateful NAT64 [RFC6146].
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.draft-ietf-v6ops-nat64-deployment]. When an
IPv6-only client 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.
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.
3.1.2. DS-Lite
The B4 (Basic Bridging BroadBand) element performs a stateful NAT44
and 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 lwB4 element, so a
single stateful NAT44 is performed. It uses a provisioning mechanism
to determine the size of the limited port-set per user. The AFTR
becomes a lwAFTR.
Alternatively, one can say that lw4o6 is a subset of MAP-E, as it
uses the same provisioning, the same port mapping algorithm, and is
indistinguishable from MAP-E when used without IPv4 address sharing.
Lencse et al. Expires April 22, 2019 [Page 5]
Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018
3.1.4. MAP-E
The CE (Customer-Edge) router first performs a stateful NAPT44
[RFC2663] 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 encapsulates the IPv4 packet in
an IPv6 packet [RFC2473]. MAP defines a special stateless mapping
algorithm, which encodes the relevant IPv4 address[es] into the IPv6
address, either wholly or partially depending on the BMR.
Optionally, when used with IPv4 address sharing, port set bits may
also be encoded in to the IPv6 source address. This transformation
may be fine-tuned by the mapping rules. Packets destined outside of
the MAP domain must traverse a MAP BR to be de-encapsulated. Packets
destined for another CE router within the MAP domain may be
forwarded directly with an appropriate FMR, and de-encapsulated by
the destination CE router.
3.1.5. MAP-T
MAP-T works very similarly to MAP-E, with the difference that it
uses double translation instead of encapsulation. It can also be
compared to 464XLAT when there is a double translation.
After performing the above mentioned stateful NAPT44, the CE router
performs stateless translation from IPv4 to IPv6 [RFC7915], which
also translates the IPv4 address and port set ID into the IPv6
address space, based on the BMR. The MAP BR (Border Relay) performs
stateless translation from IPv4 to IPv6 [RFC7915].
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.
3.1.6. Basic Comparison
The five IPv4aaS technologies can be classified into 2x2=4
categories on the basis of two aspects:
. Technology used for service provider network traversal. It can be
single/double translation or encapsulation.
. Presence or absence of state in the operator network.
Lencse et al. Expires April 22, 2019 [Page 6]
Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018
State in the | Service provider network traversal technology
operator | single/double | encapsulation/
network | translation | de-encapsulation
----------------+-----------------+-----------------------
Present | 464XLAT | DS-Lite
----------------+-----------------+-----------------------
Absent | MAP-T | MAP-E, lw4o6
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.
Although the number of ports available for a user is limited with
all five technologies, when used with address sharing, the stateful
technologies, such as 464XLAT and DS-Lite, allow for dynamic and
centrally adjustable port allocations, whereas port ranges are
predetermined and fixed with the three A+P (Address plus Port) based
technologies, lw4o6, MAP-E, and MAP-T.
Determining the optimal size of the fixed port set is not an easy
task, but 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 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
Lencse et al. Expires April 22, 2019 [Page 7]
Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018
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).
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.
However, on the other hand, assigning too many ports per CE router
will result in waste of public IPv4 addresses, which is a scarce and
expensive resource.
We note that common CE router NAT44 implementations utilizing
Netfilter, use a 3-tuple (source address, destination address, and
destination port) approach for source port allocation; external
source ports will be reused for unique internal source and
destination address and port flows. It is also noted, that
Netfilter cannot currently make use of multiple source port ranges,
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 is 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 DECIDE IF IT IS TRUE. XXX
We note that these 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.
The consequences of IPv4 address sharing [RFC6269] may impact all
five technologies. However, when ports are allocated dynamically,
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
Lencse et al. Expires April 22, 2019 [Page 8]
Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018
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, too.
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/services operation. 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.
We note that MAP-E and MAP-T may also provide more than one IP
address (that is a complete prefix) to the customers.
3.4. Support and Implementations
3.4.1. OS Support
As for 464XLAT, client support (CLAT) exists in Windows 10, Linux
(including Android), Windows Mobile, Chrome OS and iOS, but it is
missing from 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.
Lencse et al. Expires April 22, 2019 [Page 9]
Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018
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
they contain a lot of common functions (data plane is shared among
several of them).
3.5. Typical Deployment and Traffic Volume Considerations
3.5.1. Deployment Possibilities
Theoretically, all five covered IPv4aaS technologies could be used
together with DNS64 + stateful NAT64, as it is done in 464XLAT. In
this case the CE router would treat the traffic between an IPv6-only
client and IPv4-only server as normal IPv6 traffic, and the stateful
NAT64 gateway would do a single translation, thus offloading this
kind of traffic from the IPv4aaS technology. The cost of this
solution would be the need for deploying also DNS64 + stateful
NAT64.
However, this has not been implemented in clients or actual
deployments, so only 464XLAT always uses this optimization and the
other four solutions do not use it at all.
3.5.2. Cellular Networks with 464XLAT
Actual figures from existing deployments, show that the typical
traffic volumes in an IPv6-only cellular network, when 464XLAT
technology is used together with DNS64, are:
. 75% of traffic is IPv6 end-to-end (no translation)
. 24% of traffic is uses DNS64 + NAT64 (1 translation)
. Less than 1% of traffic use the CLAT in addition to NAT64 (2
translations), due to an IPv4 socket and/or IPv4 literal.
Without using DNS64, 25% of the traffic would undergo double
translation.
Lencse et al. Expires April 22, 2019 [Page 10]
Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018
3.6. Load Sharing
If multiple network-side devices are needed as PLAT/AFTR/BR for
capacity, then there is a need for a load sharing technology. ECMP
(Equal-Cost Multi-Path) load sharing can be used for all
technologies, however stateful technologies will be impacted by
changes in network topology or device failure.
Technologies utilizing DNS64 can also distribute load across
PLAT/AFTR devices, evenly or unevenly, by using different prefixes.
Different network specific prefixes can be distributed for
subscribers in appropriately sized segments (like split-horizon DNS,
also called DNS views).
Stateless technologies, due to the lack of flow tracking, can make
use of anycast routing for load sharing and resiliency across
network-devices, both ingress and egress; flows can take asymmetric
paths through the network, i.e., in through one lwAFTR/BR and out
via another.
3.7. Logging
In the case of 464XLAT and DS-Lite, it varies with time who uses a
given public IPv4 address and port combination, therefore, logging
is necessary to be able to investigate possible abuses.
Configurations that dynamically assign ports "on the fly", will have
a much higher capacity requirement for logging, than those that
assign port blocks or ranges.
Stateless technologies that algorithmically assign addresses and
ports, e.g., lw4o6, MAP-T, MAP-E, may require additional support
tools to assist in resolving assignments, but require no additional
logging.
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
Lencse et al. Expires April 22, 2019 [Page 11]
Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018
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.
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.
Lencse et al. Expires April 22, 2019 [Page 12]
Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018
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>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <http://www.rfc-editor.org/info/rfc2473>.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, DOI 10.17487/RFC2663, August 1999, <http://www.rfc-
editor.org/info/rfc2663>.
[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.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
DOI 10.17487/RFC6147, April 2011.
[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 22, 2019 [Page 13]
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
[I-D.draft-ietf-v6ops-nat64-deployment] J. Palet, "NAT64/464XLAT
Deployment Guidelines in Operator and Enterprise
Networks", draft-ietf-v6ops-nat64-deployment-03, (work in
progress), October 2018.
[I-D.draft-ietf-v6ops-transition-ipv4aas] Palet, J., Liu, H., and M.
Kawashima, "Requirements for IPv6 Customer Edge Routers to
Support IPv4 Connectivity as-a-Service", draft-ietf-v6ops-
transition-ipv4aas-10, (work in progress), October 2018.
Lencse et al. Expires April 22, 2019 [Page 14]
Internet-Draft Pros and Cons of IPv4aaS Technologies October 2018
[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
[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 thank Ole Troan for his thorough review of
this draft and acknowledge the inputs of Ole Troan, Mark Andrews,
Edwin Cordeiro, Fred Baker, Alexandre Petrescu, Cameron Byrne, Tore
Anderson, Alexandre Petrescu, Mikael Abrahamsson, Gert Doering,
Satoru Matsushima, 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 22, 2019 [Page 15]
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 22, 2019 [Page 16]