[v6ops] Our recommended corrections -- Re: AD Review of draft-ietf-v6ops-transition-comparison

[Gábor LENCSE <[e-mail]>]

Dear Warren,

Thank you very much for your review!

First, I would like to check, if you agree with our responses, so I did 
not submit the revised version yet, but I give a detailed answer about 
each of your comments, how we addressed it.

(However, if you think, that it would be easier for you to check the 
changes using the "diff", I have the modified XML file ready, and I can 
upload in it a few minutes. I just did not want to publish a version, 
which may need to be replaced in a few days.)


2/2/2022 1:17 AM keltezéssel, Warren Kumari írta:
> Firstly, thank you very much to the authors and WG for writing this, 
> and apologies for the delay in reviewing it -- I did the review, but 
> then forgot to transfer my notes.
> I think that it is a very useful document; there are many different 
> transition technologies to choose from, and it can be really 
> intimidating for an operator to have to choose which one(s) to deploy.
>
> I do have a number of concerns that I’d like to see addressed before 
> moving this forward. Many / most of them will be really easy to 
> address, and getting them done before IETF LC and IESG will make the 
> whole process go much smoother (and should result in less drama :-) )
>
> Questions / comments / issues:
>
> Section 2.1:
> 1: “464XLAT is a single/dual translation model, …” - please explain 
> what a “single” vs “dual” translation model *is*. This is a bit of a 
> common theme throughout the document - you are using terms which are 
> well known within the V6 operator world, but your audience is not 
> really IPv6 experts…

OLD:

    464XLAT is a single/dual translation model, which uses a customer-
    side translator (CLAT) located in the customer's device to perform
    stateless NAT64 translation [RFC7915] (more precisely, stateless
    NAT46, a stateless IP/ICMP translation from IPv4 to IPv6).


NEW:

    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).

    The customer-side translator (CLAT) is located in the customer's
    device, and it performs stateless NAT64 translation [RFC7915] (more
    precisely, stateless NAT46, a stateless IP/ICMP translation from IPv4
    to IPv6).


> 2: “Note that we generally do not see state close to the end-user as 
> equally problematic as state in the middle of the network.”
> - Who is this “we” of which you speak? (The authors? The IETF? Operators?)

OLD:

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

  NEW:

    In general, state close to the end-user network (i.e. at the CE) is
    not perceived as problematic as state in the operators network.


What do you think of it?

We wrote it in that way, as we (the authors) believe that it is not only 
our view, but a kind of general belief. But if you would like the 
authors to take the responsibility, I am ready to write that:

    The authors generally do not see state close to the end-user as
    equally problematic as state in the middle of the network.


>
> 3: “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.”
> The “thus” is confusing. Perhaps “and”?

OLD:

    thus CLAT functions

NEW:

    and the CLAT functions


> 4: “Alternatively, one can say that the DNS64 + stateful NAT64 is used 
> to …”
> The “the” seems superfluous -> “Alternatively, one can say that DNS64 
> + stateful NAT64 is used to …”

Corrected.

> Section 2.2:
> 1: “The AFTR performs encapsulation/decapsulation of the 4in6 traffic 
> and translates the IPv4 payload to public IPv4 source address using a 
> stateful NAPT44 function.“
> What is “4in6” and “NAPT44”? (yeah, obviously I know, but please add 
> references / an explanation)

We added the references as:

OLD:

    Router' (AFTR).  The AFTR performs encapsulation/decapsulation of the
    4in6 traffic and translates the IPv4 payload to public IPv4 source
    address using a stateful NAPT44 function.
  

NEW:

    Router' (AFTR).  The AFTR performs encapsulation/decapsulation of the
    4in6 [RFC2473] traffic and translates the IPv4 payload to public IPv4
    source address using a stateful NAPT44 [RFC2663] function.



> Section 2.3:
> 1: “... of provisioning each lwB4 with a unique tuple of IPv4 address 
> unique range of layer-4 ports.“
> Unable to parse. I think you are missing “and a” between “address” and 
> “unique”.

Corrected.

>
> 2: “Direct communication between two lwB4s is performed by 
> hair-pinning traffic through the lwAFTR.”
> Very minor issue, but it’s a little hard to figure out what is meant 
> by “Direct” - if it hairpins through something else, then it feels 
> like it isn't really “direct” any more. I don’t have any useful 
> suggestions to offer though (unless you say things about “on the same 
> network” or “that don’t need translation” or something, but that feels 
> messy)

We suggest the following:

OLD:

    Direct communication between two lwB4s is performed by hair-pinning
    traffic through the lwAFTR.

NEW:

    Direct communication (that is, without translation) between two lwB4s
    is performed by hair-pinning traffic through the lwAFTR.


What do you think about it?

> Section 2.4:
> 1: “MAP-E uses a stateless algorithm to embed portions of the 
> customer's allocated IPv4 address (or part of an address with A+P 
> routing) into the IPv6 prefix delegated to the client.”
> Ok, fine, but in Section 2.1 you say “IPv4-embedded IPv6 addresses 
> [RFC6052] are used for both source and destination addresses.” - how 
> is this different?

464XLAT (discussed in Section 2.1) uses [RFC6052] IPv4-embedded IPv6 
addresses. They are very easy to construct: we simply append the 32 bits 
of an IPv4 address to the proper IPv6 prefix.

The MAP protocols (MAP-E and MAP-T) also use [RFC6052] IPv4-embedded 
IPv6 addresses to represent IPv4 hosts outside the MAP domain. (E.g. the 
address of an IPv4 only server.)

However, the so called /MAP addresses/ (IPv6 addresses referring to IPv4 
hosts in the MAP domain) are MUCH-MUCH more complicated to construct.  
Please see Section 5 of RFC 7597.

An illustrated and (IMHO) easy to follow explanation can be found here: 
https://www.jool.mx/en/run-mapt.html

I am not sure, how much we should talk about it. Or if we should do it 
at all.

>
> 2: “The CE (Customer-Edge) router typically performs stateful 
> NAPT44[RFC2663] to translate the private IPv4 source addresses and 
> source ports into an address and port range defined by applying the 
> MAP rule applied to the delegated IPv6 prefix.”
> Too many “applies” (“applying the MAP rule applied”) - perhaps just 
> drop the second?

Done. :-)

OLD:

    ports into an address and port range defined by applying the MAP rule
    applied to the delegated IPv6 prefix.  The client address/port

NEW:

    ports into an address and port range defined by applying the MAP rule
    to the delegated IPv6 prefix.  The client address/port allocation


>
> Sec 2.5:
> 1:”A MAP CE typically performs stateful NAPT44 to translate traffic …“
> Please expand “CE”. Actually, while writing this I tried to find a 
> good expansion – the RFC Editor list has “Customer Edge”, but you 
> first use CE on page 5 ("customer’s CE router”), so perhaps just fix 
> it there and drop the first “customer’s”?

In Section 2.4, CE has already been expanded as: "The CE (Customer-Edge) 
router". (We intended to expand abbreviation only the first time they 
are used.)

Do you think that people do not read the document sequentially, but 
rather use it as a "handbook", I mean just looking up different parts in 
random order?

Now I have made the following change:

OLD:

    A MAP CE typically performs stateful NAPT44 to translate traffic to a
    public IPv4 address and port-range calculated by applying the

NEW:

    The CE (Customer-Edge) router typically performs stateful NAPT44
    [RFC2663] to translate traffic to a public IPv4 address and port-


>
> Sec 3.1:
> 1: General note: This entire section (“High-level architectures and 
> their Consequences”) seems to me to do a much better job of explaining 
> what the document is all about, explains 464 and 6-in4, etc. I’d 
> strongly suggest moving at least 3.1, 3.2 and 3.3 before Section 2. I 
> realize that this is a fair bit of work / shuffling, but I’m also 
> fairly sure that someone will raise it during LC / IESG eval, so 
> probably worth doing now…

I believe that some of our readers are not familiar with the five 
IPv4aaS technologies, and thus they would not understand Sections 3.1 to 
3.3 without a short introduction to them in Section 2. Originally, 
current Section 2 ("Overview of the Technologies") was not a part of our 
draft, and it was added to fill this gap.

> Sec 3.4:
> 1: “ From the 65,535 ports available per IPv4 address, we could even 
> consider reserving 1,024 ports, in order to allow customers that need 
> EAMT entries for incoming connections to well-known ports, …“
> Please try to find a reference for “well-known ports”. I figured that 
> the IANA port list would work 
> (https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml) 
> but it actually calls them “system ports” (“Port numbers are assigned 
> in various ways, based on three ranges: System Ports (0-1023), …” 
> Maybe just change to “system ports” instead?

OLD:

    EAMT entries for incoming connections to well-known ports, which
    means 64,511 ports actually available per each IPv4 address.

NEW:

    EAMT entries for incoming connections to System Ports (0-1023, also
    called well-known ports) [RFC7605], which means 64,511 ports actually
    available per each IPv4 address.



> 2: “ Further to that, the NAT46 in the CLAT will actually hide the 
> subscriber LANs port usage …”
> “Further to that, “ feels like a fragment, largely because it is a new 
> paragraph / does not follow on from the previous paragraph. Perhaps 
> just drop it.

OLD:

    Further to that, the NAT46 in the CLAT will actually hide the
    subscriber LANs port usage and only that will be the limiting factor.
    So even subscribers with higher demands of ports, will not make a big
    difference.

NEW:

    The NAT46 in the CLAT will actually hide the subscriber LANs port
    usage and only that will be the limiting factor.  So even subscribers
    with higher demands of ports, will not make a big difference.
  

But I think some further corrections may be necessary, as the NAT46 in 
the CLAT is a stateless NAT46. It does NOT touch the port numbers, thus 
it may not hide the subscriber LANs port usage.

Of course, the CLAT device (as a home router) may well do stateful NAT44 
(also called NAPT44), but then this sentence should be further clarified...

>
> Sec 4.4.1:
> 1: “For the operator side functionality, some free open-source 
> implementations exist:”
> This will not age well. Perhaps add something about “At the time of 
> publication…”

OLD:

    For the operator side functionality, some free open-source
    implementations exist:
  

NEW:

    At the time of publication some free open-source implementations
    exist for the operator side functionality:

In addition to that, one of my BSc students did measurements with the 
Jool implementation of MAP-T. So I know it for sure, that Jool 4.2 has a 
working MAP-T implementation.

So I made the following change:

OLD:

    CLAT, NAT64, EAMT:http://www.jool.mx

NEW:

    CLAT, NAT64, EAMT, MAP-T CE, MAP-T BR:http://www.jool.mx


> Sec 4.4.2:
> 1: “ Several cellular networks use 464XLAT, whereas we are not aware 
> of any deployment of the four other technologies …”
> Again, who is this “we”?

OLD:

    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 standardised neither implemented in UE devices.


NEW:

    Several cellular networks use 464XLAT, whereas there are no
    deployments of the four other technologies in cellular networks, as
    they are not standardised neither implemented in UE devices.

>
> Section 8:
> 1: “For all five technologies, the CE device should contain a DNS proxy.”
> Erm. I’m quite uncomfortable with this being suggested here. I’d think 
> that a recommendation like this would need some much wider discussion. 
> I suspect that many DNS operators would seriously disagree with a 
> suggestion like this. I suggest you remove it. Even if most CPE *do* 
> include a proxy, having it recommended in an RFC is another matter 
> entirely.

OLD:

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

NEW:

    For all five technologies, the CE device typically contains a DNS
    proxy.

>
> Please shout LOUDLY once you've had a change to address these, or with 
> any questions, etc.
> W

Please let us know, if you are satisfied with our corrections.

And, of course, we are happy to receive comments from any of the WG 
members, too.

Best regards,

Gábor