Subject: [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

From: Lencse Gábor <[email-masked]>
Date: Sat, 6 Oct 2018 15:07:11 +0200

Dear v6ops Members,

We have prepared the "-00" version of our I-D "Pros and Cons of IPv6 
Transition Technologies for IPv4aaS".

Thank you very much for everyone, who have given us input through the 
previous discussion on this list or through the Google spreadsheet, 
which is still available at: 
https://docs.google.com/spreadsheets/d/1W3Px8I_RyLA_tnmmNkJj6qJS0tvg93oCU0XfZzlljto/edit#gid=0

Could you give us further feedback?

Thank you very much for your help in advance!

Best regards,

Gábor Lencse

-------- Továbbított üzenet --------
Tárgy: 	New Version Notification for 
draft-lmhp-v6ops-transition-comparison-00.txt
Dátum: 	Sat, 06 Oct 2018 05:52:11 -0700
Feladó: 	[email-masked]
Címzett: 	Lee Howard <[email-masked]>, Jordi Palet 
<[email-masked]>, Jordi Palet Martinez 
<[email-masked]>, Gabor Lencse <[email-masked]>, 
Richard Patterson <[email-masked]>

A new version of I-D, draft-lmhp-v6ops-transition-comparison-00.txt
has been successfully submitted by Gabor Lencse and posted to the
IETF repository.

Name:		draft-lmhp-v6ops-transition-comparison
Revision:	00
Title:		Pros and Cons of IPv6 Transition Technologies for IPv4aaS
Document date:	2018-10-06
Group:		Individual Submission
Pages:		11
URL:            https://www.ietf.org/internet-drafts/draft-lmhp-v6ops-transition-comparison-00.txt
Status:         https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/
Htmlized:       https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-lmhp-v6ops-transition-comparison

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.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Fred Baker <[email-masked]>
Date: Sat, 6 Oct 2018 23:34:05 -0700

What may not be clear from Lencse's email (I managed to miss it at first glance) is that he not only has a google sheet up, but a posted draft. We'd be interested in folks' comments on the draft as well.

> On Oct 6, 2018, at 6:07 AM, Lencse Gábor <[email-masked]> wrote:
> 
> Dear v6ops Members,
> 
> We have prepared the "-00" version of our I-D "Pros and Cons of IPv6 Transition Technologies for IPv4aaS".
> 
> Thank you very much for everyone, who have given us input through the previous discussion on this list or through the Google spreadsheet, which is still available at: https://docs.google.com/spreadsheets/d/1W3Px8I_RyLA_tnmmNkJj6qJS0tvg93oCU0XfZzlljto/edit#gid=0
> 
> Tárgy:	New Version Notification for draft-lmhp-v6ops-transition-comparison-00.txt
> Címzett:	Lee Howard <[email-masked]>, Jordi Palet <[email-masked]>, Jordi Palet Martinez <[email-masked]>, Gabor Lencse <[email-masked]>, Richard Patterson <[email-masked]>
> 
> URL:
> https://www.ietf.org/internet-drafts/draft-lmhp-v6ops-transition-comparison-00.txt
> 
> Status:
> https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/
> 
> Htmlized:
> https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-00
> 
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-lmhp-v6ops-transition-comparison
> 
> 
> 
> Abstract:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

--------------------------------------------------------------------------------
The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...

---

From: Ole Troan <[email-masked]>
Date: Mon, 8 Oct 2018 10:35:15 +0200

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

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: [email-masked]

   Jordi Palet Martinez
   The IPv6 Company
   Molino de la Navata, 75
   La Navata - Galapagar, Madrid - 28420
   Spain

   Email: [email-masked]

   Lee Howard
   Retevia
   9940 Main St., Suite 200
   Fairfax
   Virginia
   22031, USA
   Email: [email-masked]

   Richard Patterson
   Sky UK
   1 Brick Lane
   London, E1 6PU
   United Kingdom

   Email: [email-masked]

Lencse et al.           Expires April 6, 2019                [Page 11]

---

From: Lencse Gábor <[email-masked]>
Date: Mon, 8 Oct 2018 13:53:11 +0200

Dear Ole,

Thank you very much for your detailed review!

I try to answer your questions. I keep only the relevant parts to reduce 
the length of the text below.

> Comments inline. Look for @@OT.
[...]
> Both MAP-T and 464XLAT uses double translation.

Yes, you are completely right! (Sometimes 464XLAT is used together with 
NAT64, but I agree with you that they are two separate solutions, even 
if the PLAT of 464XLAT is the same device as the NAT64 gateway.)

> If you want to include it, treat it as a separate solution.

Yes, I agree that we should move it into a separate paragraph. Perhaps 
the following text would do:

"As for the high-level solution of the IPv6 service provider network
    traversal, both 464XLAT and 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)."

And later in a separate paragraph:

"We note that 464XLAT is often used together with stateful NAT64 
[RFC6146], which allows IPv6 only host to communicate with IPv4 only 
servers. In this case, the stateful NAT64 gateway is the same device as 
the PLAT device of 464XLAT."

> s/compared with only the IPv4 one/compared with only the IPv6 one

The size of the IPv4 header is 20 bytes, whereas the size of the IPv6 
header is 20 bytes. If we say that "overhead of the encapsulation is 40 
bytes" then it is compared with the IPv4. (The outer IPv6 header gives 
the extra 40 bytes.)

> None of the sharing solutions would “natively” do multicast.

Thank you for thinking of it.  We should include it.

> This isn’t what we tradtionally think of as DPI.

OK.

> might want to “treat” the packet as an IPv4 one, and have to 

I am not sure I completely understand what you mean. I would argue that 
in the case of 464XLAT one can simply use an IPv6 firewall instead of an 
IPv4 firewall. Can it be done also in the case of MAP-T? I do not know. 
But it is definitely a problem with the encapsulation solutions, they 
require reverse engineering.

> Actually the worst case is typical deployments of 464XLAT which does 3 

Is it really typical? Why would someone do that? There are a lot of IPv6 
addresses. Why cannot they assign a dedicated /64 for translation?

> breaks that (since you must forward based on L4 information).

Yes, this is what I meant. Please see the text above: "when they are 
used withIPv4 address sharing".

> address (or prefix) to customers who require use of other protocols than

It is discussed in Section 3.3. Should we add something over there?

> as state in the middle of the network.

Correct. Perhaps the following text would do:

   In the simplest case, 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].

Alternatively, when a dedicated /64 is not available for translation, 
the CLAT device uses a stateful NAT44 translation before the stateful 
NAT46 translation.

Note that we generally don’t see state close to the end-user as equally 
problematic
as state in the middle of the network.

(The last sentence is taken verbatim from you.)

What do you think of this text?

> the same port mapping algorithm, and is indistinguishable from MAP-E 

What do you think of keeping the original text and adding the following one:

Alternatively, one can say that lw4o6 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.

> so this statement is not strictly speaking correct.

Yes, we shall include it. And please see my answer below.

> Also note that the same NAT44 process happens with MAP-E, and LW46.

Yes, it is a kind of editing mistake. (Originally, the five technologies 
were in the same order as they appeared in the Google spreadsheet. Then 
they were put into alphabetical order, but the "long" text describing 
the operation remained with MAP-T, only the short reference disappeared 
from MAP-E, which said that it worked similarly to MAP-T)

We shall put it right.

> Note, that all CGN solutions will limie the port numbers available.

Can you mention typical limits?

>    it depends on several factors [Miy2010]. And there may be several

OK, I will elaborate the problem and add some numbers from the above 
mentioned [Miy2010] and [Miy2010].

> but you can reuse those 16 ports to destination A port P+1, and 

Yes, they can be reused, but E.g. 16 is very low for several 
applications or web pages. Miyakawa [Miy2010] has demonstrated what 
happens with a Google map, when the number of sessions limited to 15. 
(Several block were missing, and the map was unusable.) He also provided 
several examples for the session numbers of different applications (the 
highest one was iTunes: 230-270). Unfortunately his paper is not open 
access (and perhaps very few of the v6ops list members are also IEICE 
members to be able to access the paper; if you are interested, I can 
send a private copy to you) but the paper written by Sándor Répás has a 
green open access copy here: 
http://www.hit.bme.hu/~lencse/publications/TSP-2014-PC.pdf Please see 
Fig. 3 and Fig. 5. The number of ports used is between 100 and 150. 
Therefore, when dimensioning a system with MAP-T/E, one should assign 
several hundreds os source ports per subscriber to make sure that no 
quality of experience issue will occur.

BTW: When I was doing measurements for my paper below, I have considered 
only NAT64 and therefore, I was dealing with the weighted average of the 
port numbers required by different web pages.

G. Lencse, "Estimation of the Port Number Consumption of Web Browsing", 
/IEICE Transactions on Communications/, Vol. E98-B, No. 8. pp. 
1580-1588. DOI: 10.1587/transcom.E98.B.1580, 
http://www.hit.bme.hu/~lencse/publications/e98-b_8_1580.pdf

However, it would be interesting:
- to find the maximum port numbers used by the most popular sites
- to test what happens, if the port numbers are limited to significantly 
lower values.

Do you think that the results would be useful for dimensioning systems 
using MAP-T/E?

> all the solutions that use CGN. NAT444, DS-lite, NAT64.

I agree.

> Now for stateful NAT, tell me how you want to do it.

I would do some hashing on the basis of IP addresses to distribute the 
traffic among the 10 devices.

Is there any reason, why it would not working?

> is nothing inherit in the mechanism in NAT64.

Thank you for mentioning it.

> are much higher. You should add logging as a separate section, if you 

You are completely right. Logging was included in the table, but we have 
unfortunately left if out from the draft. (We had very limited time and 
wanted to give a chance to v6ops members to review it and we plan to 
publish a "-01" version before the cut-off date.) We shall definitely 
add logging!

TBD.

> so I’m not sure this section adds very much.

I am also aware of only the CLAT of 464XLAT is running on a mobile 
phone. Perhaps my co-authors know about other solutions.

> decide is a terrible strategy. ;-)

:-)

[...]

> For any IPv4aaS mechanism it looks exactly like an IPv4 link and you 

This solution is called as "Dual DUT Setup" in RFC 8219. However, is has 
a significant drawback, that the two devices (e.g. CLAT and PLAT) are 
benchmarked together, which hides any possible asymmetric behavior. E.g. 
CLAT is stateless NAT46, PLAT is stateful NAT64. Besides that, the CE 
devices (like CLAT, B4) are normally tiny devices (both in size and 
performance), whereas the ISP side devices (PLAT, AFTR, MAP BR) are huge 
ones. IMHO, they should be tested separately, which requires special 
testers.

I think that relatively good software testers can be implemented in 
DPDK. One of my PhD students is currently working on an RFC 8219 
compliant stateless NAT46/NAT64 tester. We are planning to publish his 
code as a free software under GPL license, within a few months. Based on 
his code, similar testers may be implemented for other technologies, too.

>    For all five technologies, the CE device should contain a DNS proxy.

As I remember, all five RFC-s mention that. I will check. (As for 
464XLAT, a DNS64 proxy save the double translation for DNS traffic.)

> And why is that in the security considerations?

It is here because of what follows.

> You might want to add that.

How can it be done if you have an IPv4 only device or an IPv4 only 
application?

I really appreciate your going thorough the draft and commenting it. I 
am sure that your contributions make it much better.

Best regards,

Gábor Lencse

---

From: Ole Troan <[email-masked]>
Date: Mon, 8 Oct 2018 14:19:05 +0200

Lencse,

> This solution is called as "Dual DUT Setup" in RFC 8219. However, is has a significant drawback, that the two devices (e.g. CLAT and PLAT) are benchmarked together, which hides any possible asymmetric behavior. E.g. CLAT is stateless NAT46, PLAT is stateful NAT64. Besides that, the CE devices (like CLAT, B4) are normally tiny devices (both in size and performance), whereas the ISP side devices (PLAT, AFTR, MAP BR) are huge ones. IMHO, they should be tested separately, which requires special testers.

Sure, but can’t all testers do that?
Just send an IPv4 in IPv6 stream one way, receive IPv4 the other direction.

> I think that relatively good software testers can be implemented in DPDK. One of my PhD students is currently working on an RFC 8219 compliant stateless NAT46/NAT64 tester. We are planning to publish his code as a free software under GPL license, within a few months. Based on his code, similar testers may be implemented for other technologies, too. 

For software based testers I mostly use:
https://trex-tgn.cisco.com/

Moongen is also good, and there are few other open source ones too.

Cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Mon, 8 Oct 2018 14:26:56 +0200

Lencse,

splitting up threads a bit.

> On 8 Oct 2018, at 13:53, Lencse Gábor <[email-masked]> wrote:
> 
>> 
> I would do some hashing on the basis of IP addresses to distribute the traffic among the 10 devices.
> 

What do you do when you need to add one more node to the “cluster”?
Remove a node?

You also need to ensure traffic is symmetric. So if you are hashing you need some sort of hash that is bidirectional.
You _can_ make that work, by allocting ports / addresses cleverly enough, but it’s far from trivial.
And don’t expect your NICs RSS to handle that. Nor your hardware router.

You typically are forced into some flavour of:
https://www.jool.mx/en/session-synchronization.html

Cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Mon, 8 Oct 2018 14:44:37 +0200

Lencse,

> I am not sure I completely understand what you mean. I would argue that in the case of 464XLAT one can simply use an IPv6 firewall instead of an IPv4 firewall. Can it be done also in the case of MAP-T? I do not know. But it is definitely a problem with the encapsulation solutions, they require reverse engineering.

_Iff_ the middlebox feature required the IPv4 address for some reason. e.g. to apply an IPv4 ACL, then the translation solutions would require “reverse engineering” the IPV4 header.
That’s of course not required for the encapsulation solution. Which only requires “tunnel vision (thanks Mark T for that one)”.

So it depends, in some cases a middlebox could treat it as any other IPv6 traffic, in some cases it might not. And it might also in some cases force injection of IPv4 routing into IPv6.
So short answer is, is that a good or bad thing? It depends.

Cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Mon, 8 Oct 2018 14:47:06 +0200

> Is it really typical? Why would someone do that? There are a lot of IPv6 addresses. Why cannot they assign a dedicated /64 for translation?

Yes, I believe this is the by far largest 464XLAT deployment.
I’m sure others on the list can confirm.

Cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Mon, 8 Oct 2018 14:50:19 +0200

Lencse,

> Yes, they can be reused, but E.g. 16 is very low for several applications or web pages. Miyakawa [Miy2010] has demonstrated what happens with a Google map, when the number of sessions limited to 15. (Several block were missing, and the map was unusable.) He also provided several examples for the session numbers of different applications (the highest one was iTunes: 230-270). Unfortunately his paper is not open access (and perhaps very few of the v6ops list members are also IEICE members to be able to access the paper; if you are interested, I can send a private copy to you) but the paper written by Sándor Répás has a green open access copy here:http://www.hit.bme.hu/~lencse/publications/TSP-2014-PC.pdf Please see Fig. 3 and Fig. 5. The number of ports used is between 100 and 150. Therefore, when dimensioning a system with MAP-T/E, one should assign several hundreds os source ports per subscriber to make sure that no quality of experience issue will occur.
> 
> BTW: When I was doing measurements for my paper below, I have considered only NAT64 and therefore, I was dealing with the weighted average of the port numbers required by different web pages. 
> 
> G. Lencse, "Estimation of the Port Number Consumption of Web Browsing", IEICE Transactions on Communications, Vol. E98-B, No. 8. pp. 1580-1588. DOI: 10.1587/transcom.E98.B.1580, http://www.hit.bme.hu/~lencse/publications/e98-b_8_1580.pdf
> 
> - to test what happens, if the port numbers are limited to significantly lower values.
> 
> Do you think that the results would be useful for dimensioning systems using MAP-T/E?

Well, equally dimensioning sharing ratios of CGNs.

You also need to take new transports into consideration. E.g. QUIC.

I’m quite convinced I could run a big network behind 16 ports, with a clever enough NAT.
I guess I should try. ;-)

Cheers,
Ole

---

From: Ca By <[email-masked]>
Date: Mon, 8 Oct 2018 05:59:40 -0700

> I’m sure others on the list can confirm.

I would say: not quite

Using round numbers on a mobile network, one can expect in HEv2 and 464xlat:

75+% of traffic to be ipv6 e2e (no translation)
24% to use dns64/nat64 (1 translation)
And less than 1% having a nat46 and nat64 (double translation due to ipv4
socket and / or literal)

In this effort, you may want to call out specifically 464xlat and HEv2.
They are similar but seperately specified. Both have tens of millions of
units deployed.

https://tools.ietf.org/html/rfc8305

---

From: Ca By <[email-masked]>
Date: Mon, 8 Oct 2018 06:05:53 -0700

On Mon, Oct 8, 2018 at 5:27 AM Ole Troan <[email-masked]> wrote:

> You also need to ensure traffic is symmetric. So if you are hashing you
> need some sort of hash that is bidirectional.

I know a large deployment where the pref64 is load shared with ECMP. Works
well IRL.

Another approach that i am fond of: Allow the dns64 to offer different
pref64 to target load against different nat64 units of capacity, think dns
views

In both cases, scaling is linear. Just add another box to ecmp or dns64.

CB

---

From: Ole Troan <[email-masked]>
Date: Mon, 8 Oct 2018 15:09:45 +0200

Cameron,

> 75+% of traffic to be ipv6 e2e (no translation)

Sure, but those numbers aren’t relevant here.

> 24% to use dns64/nat64 (1 translation)

And probably not these either, since we’re talking about IPv4aaS mechanisms.

> And less than 1% having a nat46 and nat64 (double translation due to ipv4 socket and / or literal)

Right. And how many of those are triple translation.
I don’t know know if host implementation of the IPv4aaS should be called out speciifcally in comparison with CE router implementation.

> In this effort, you may want to call out specifically 464xlat and HEv2. They are similar but seperately specified. Both have tens of millions of units deployed. 
> 

I’m not sure how HE is relevant either?

Cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Mon, 8 Oct 2018 15:12:39 +0200

Cameron,

> I know a large deployment where the pref64 is load shared with ECMP. Works well IRL. 

Only if you can ensure ECMP give you the same hash in both directions, right?

> Another approach that i am fond of: Allow the dns64 to offer different pref64 to target load against different nat64 units of capacity, think dns views

Only if this draft considers NAT64 in scope. ;-)

> In both cases, scaling is linear. Just add another box to ecmp or dns64. 

Well, adding another box to ECMP, isn’t that simple. You want to be able to add another box without affecting existing sessions.
Normally adding to an ECMP would change the hash.

Ole

---

From: Tore Anderson <[email-masked]>
Date: Mon, 8 Oct 2018 15:21:16 +0200

* Ole Troan

> Only if you can ensure ECMP give you the same hash in both directions, right?

Not necessary if each NAT64 node has its own unique IPv4 pool.

(This precludes use of RFC 6384 unless you're hashing on the 3-tuple.)

> Well, adding another box to ECMP, isn’t that simple. You want to be able to add another box without affecting existing sessions.

Sessions breaking when the cluster changes size is not ideal, but it is
an acceptable trade-off (speaking only for myself).

Tore

---

From: Ca By <[email-masked]>
Date: Mon, 8 Oct 2018 06:29:57 -0700

On Mon, Oct 8, 2018 at 6:21 AM Tore Anderson <[email-masked]> wrote:

> > Well, adding another box to ECMP, isn’t that simple. You want to be able
> to add another box without affecting existing sessions.
>

Yes, in real life, this all works. Your straw man results may vary.

CB

---

From: Ole Troan <[email-masked]>
Date: Mon, 8 Oct 2018 15:41:38 +0200

> Yes, in real life, this all works. Your straw man results may vary. 

For some definition of works indeed.
I consider my point proven that scaling a stateless service is not only much easier but much more robust.

Ole

---

From: Lencse Gábor <[email-masked]>
Date: Mon, 8 Oct 2018 16:21:57 +0200

Dear Ole,

I send a copy of my reply to Marius Georgescu, who has written RFC 8219 
(except the DNS64 benchmarking part).

> Sure, but can’t all testers do that?

I think you can buy testers, which comply with RFC 2544 and the newer 
ones also comply with RFC 5180, which addresses IPv6 specific issues. 
However, RFC 5180 explicitly states that:

"IPv6 transition mechanisms are outside the scope of this document."

RFC 8219, which defines benchmarking methodology for IPv6 transition 
technologies, was published in 2017. Thus, I do not expect that any 
commercially available testers would support its measurement procedures.

> Just send an IPv4 in IPv6 stream one way, receive IPv4 the other direction.

It will not work. Let us see an example. If you want to test MAP-E BR 
using the single DUT setup, then you need to send special IPv6 packets, 
which contain IPv4 packets. The RFC 5180 compliant testers send either 
IPv4 or IPv6 packets, but not these kinds of packets.

Besides the fact, that the traditional testers cannot create these 
special packets, they also lack other functionalities: although some of 
the measurement procedures of RFC 8219 are from RFC 2544, but there were 
also further ones defined. Please refer to RFC 8219 for more details.

Best regards,

Gábor

---

From: Lencse Gábor <[email-masked]>
Date: Mon, 8 Oct 2018 16:45:25 +0200

Dear Cameron,

> ipv4 socket and / or literal)

Could you mention some citable sources, which support your numbers?

I would like to include these numbers not only in this draft, but in 
some other publications, thus some citable source would be of a great help.

Thank you very much in advance,

Gábor

> In this effort, you may want to call out specifically 464xlat and 
> HEv2. They are similar but seperately specified. Both have tens of 
> millions of units deployed.
>
>     [email-masked] <mailto:[email-masked]>

---

From: Ole Troan <[email-masked]>
Date: Mon, 8 Oct 2018 18:10:12 +0200

Lencse,

> It will not work. Let us see an example. If you want to test MAP-E BR using the single DUT setup, then you need to send special IPv6 packets, which contain IPv4 packets. The RFC 5180 compliant testers send either IPv4 or IPv6 packets, but not these kinds of packets.
> 
> Besides the fact, that the traditional testers cannot create these special packets, they also lack other functionalities: although some of the measurement procedures of RFC 8219 are from RFC 2544, but there were also further ones defined. Please refer to RFC 8219 for more details.

Most testers allow you to configure packets to look like whatever you like.
I’ve tested MAP-E and MAP-T with both proprietary IXIA and open source TREX. Sure, you might need to do a little bit of work to set it all up.

Cheers,
Ole

---

From: Lencse Gábor <[email-masked]>
Date: Mon, 8 Oct 2018 19:49:26 +0200

Hi Ole,

Thank you very much for mentioning TRex: https://trex-tgn.cisco.com/

It seems to be much easier to put together benchmarking tests using high 
level programming in Scapy for TRex than using bare DPDK programming in 
C. I have found some documentation here: 
https://trex-tgn.cisco.com/trex/doc/trex_stateless.html

I think we will definitely give it a try.

Best regards,

Gábor

---

From: Ca By <[email-masked]>
Date: Mon, 8 Oct 2018 20:46:41 -0700

On Mon, Oct 8, 2018 at 7:45 AM Lencse Gábor <[email-masked]> wrote:

> I would like to include these numbers not only in this draft, but in some
> other publications, thus some citable source would be of a great help.
>

If you can estimate how much traffic major ipv6 sources like Google / YT,
facebook, Apple, and netflix are then you sprinkle in some Ipv6 from
Spotify, pandora, Akamai and Amazon, you are probably pretty close to 75%
of content

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 9 Oct 2018 12:52:01 +0200

Thank you for this draft.

For my clarification:

draft says:
> [...] while the ISPs have only IPv6
>    in their access and or core network. [...]

Is it common to have IPv6 only in the access network?

As far as I remember, cellular ISPs carry GTP on IPv4 at the lowest layer.

Alex

Le 06/10/2018 à 15:07, Lencse Gábor a écrit :
> URL:https://www.ietf.org/internet-drafts/draft-lmhp-v6ops-transition-comparison-00.txt
> Status:https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/
> Htmlized:https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-00
> Htmlized:https://datatracker.ietf.org/doc/html/draft-lmhp-v6ops-transition-comparison
> 
> 
> Abstract:

---

From: Richard Patterson <[email-masked]>
Date: Tue, 9 Oct 2018 12:02:00 +0100

> Is it common to have IPv6 only in the access network?

Perhaps not "common" yet, but for those that are building greenfield
networks, it's very appealing.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 9 Oct 2018 13:16:41 +0200 (CEST)

> Is it common to have IPv6 only in the access network?

DOCSIS and ds.lite has millions of customers deployed, so yes.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 09 Oct 2018 13:25:44 +0200

Add to that some lw4o6 deployments, a few MAP-E/T and many 464XLAT ones (which are actually the bigger ones if we include the cellular networks).

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Mikael Abrahamsson <[email-masked]>
Organización: People's Front Against WWW
Fecha: martes, 9 de octubre de 2018, 13:17
Para: Alexandre Petrescu <[email-masked]>
CC: <[email-masked]>
Asunto: 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

    

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Gert Doering <[email-masked]>
Date: Tue, 9 Oct 2018 14:21:20 +0200

Hi,

> Is it common to have IPv6 only in the access network?

It's one possible deployment of "IP to the mobile clients".

> As far as I remember, cellular ISPs carry GTP on IPv4 at the lowest layer.

What they do in the underlay has no relevance.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 9 Oct 2018 14:50:33 +0200

> What they do in the underlay has no relevance.

It does have relevance to me, thank you.

Alex

---

From: Gert Doering <[email-masked]>
Date: Wed, 10 Oct 2018 18:23:48 +0200

Hi,

> It does have relevance to me, thank you.

That might be, but this is not of relevance to us.

Gert Doering
        -- NetMaster

---

From: Satoru Matsushima <[email-masked]>
Date: Thu, 11 Oct 2018 13:20:31 +0900

Hmm…

I don’t know if it is a hidden fact but millions of MAP-E CPEs are deployed and in operation here in our country while no 464xlat deployment even in the cellular operators who adopt v4v6 PDN with NAT44 CGN afaik. What a diversity in earth.

Cheers,
--satoru

> 2018/10/09 20:25、JORDI PALET MARTINEZ <jordi.palet=[email-masked]>のメール:
>

---

From: Ca By <[email-masked]>
Date: Thu, 11 Oct 2018 05:12:26 -0700

On Wed, Oct 10, 2018 at 9:21 PM Satoru Matsushima <
[email-masked]> wrote:

> Hmm…
>
> I don’t know if it is a hidden fact but millions of MAP-E CPEs are
> deployed and in operation here in our country while no 464xlat deployment
> even in the cellular operators who adopt v4v6 PDN with NAT44 CGN afaik.
> What a diversity in earth.
>

Can you please help us understand?

Which network deployed map-e? Is it rfc compliant?  When and at what scale
? How many customers, roughly , are on mape?  Any lessons learned from
deployment?

Thanks,
CB

> > Add to that some lw4o6 deployments, a few MAP-E/T and many 464XLAT ones
> (which are actually the bigger ones if we include the cellular networks).
> >
> > Regards,
> > Jordi
> >
> >
> >
> > Asunto: Re: [v6ops] New I-D: "Pros and Cons of IPv6 Transition
> Technologies for IPv4aaS" -- Fwd: New Version Notification for
> > This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
> >
> >
> >

---

From: Fred Baker <[email-masked]>
Date: Thu, 11 Oct 2018 11:24:53 -0700

> On Oct 11, 2018, at 5:12 AM, Ca By <[email-masked]> wrote:
> 
> Which network deployed map-e? Is it rfc compliant?  When and at what scale ? How many customers, roughly , are on mape?  Any lessons learned from deployment?

For the record, Akira Kato told v6ops about this a while back:
https://tools.ietf.org/html/draft-akira-v6ops-mape-experience
https://www.ietf.org/proceedings/92/slides/slides-92-v6ops-2.pdf