Re: [v6ops] Éric Vyncke's Discuss on draft-ietf-v6ops-transition-comparison-03: (with DISCUSS and COMMENT)

[JORDI PALET MARTINEZ <[e-mail]>]

Hi Eric,

Tks a lot for the inputs, see below in-line.
 
    ## Section 2.2

    A important and trivial to fix "translates the IPv4 payload to public IPv4
    source address using a stateful NAPT44" => "translates the IPv4 source address
    in the payload to public IPv4 source address using a stateful NAPT44"

[Jordi] Tks!

    ## Section 3.3

    "Here, the centralized network function (lwAFTR or BR) only needs to perform
    stateless encapsulation/decapsulation or NAT64", actually in MAP-T, BR does
    translation.

[Jordi] I'm lost here, we say stateless encapsulation/decapsulation or NAT64 (so translation)?

    ## Section 3.4

    I am afraid that the number of IPv4 public addresses that are required goes
    beyond this "simple" computation. There are also other constraints such as
    laws, MoU, rules and operators BCP, see:

    -
    https://bipt.be/operators/publication/consultation-of-11-october-2016-regarding-the-conditions-of-use-of-ipv4cgn
    (alas in French/Dutch) but meaning that in my country, Belgium, an IP address
    can be shared by 16 subscribers max

    -
    https://www.europol.europa.eu/media-press/newsroom/news/are-you-sharing-same-ip-address-criminal-law-enforcement-call-for-end-of-carrier-grade-nat-cgn-to-increase-accountability-online

[Jordi] We have a mention of that in section 4.2. Do you mean to add those references as well?

    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------

    # COMMENTS

    Note for the shepherding AD: missing consensus boilerplate.

    Generally, I would have appreciated some text about the difference between a
    residential CE (serving multiple hosts) and a mobile hand-set (serving usually
    a single host -- except when tethering)

[Jordi] I'm not sure this is useful considering that in the case of UE, only 464XLAT is supported. Anyway, if you think it is useful, you will like to have some text in the intro?

    ## Section 1

    "As the deployment of IPv6 becomes more prevalent", I hope that this sentence
    is a little outdated in 2022...

[Jordi] We can update it as:

"As the deployment of IPv6 continue to be prevalent, it becomes clearer that
   network operators must move to building single-stack IPv6 core and
   access networks to simplify network planning and operations."

    s/The following IPv6 transition technologies are covered:/The following IPv4aaS
    technologies are covered:/ ?

[Jordi] Good, tks!

    ## Section 2.1

    s/it performs stateless NAT64 translation/it performs stateless NAT46
    translation/ ?

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

    About "64:ff9b::/96 Well-Known Prefix", suggest adding a reference to RFC 8215.

[Jordi] I fail to see the relevance of RFC8215 here.

    s/In the operator's network, the provider-side translator/At the edge the
    operator's network, the provider-side translator/ ?

[Jordi] I some cases the NAT64 may not be at the "edge" ...

    Hummm "when a dedicated /64 "... RFC 8215 is a /48, the text above is /96 and
    now it is a /64 ?

[Jordi] I think we are talking about different things. /96 is needed for the operator. /48 is needed if the translation is done "per site", a dedicated /64 is optional in 464XLAT in order to avoid doing NAT44 then NAT46 (stateless) - it is CE CLAT implementation dependent. In a UE usually is not possible, because DHCPv6-PD is not commonly being used. See section 4.8 of RFC8683 for a more detailed explanation. We can add a reference to that.

    While I appreciate the text "When an IPv6-only client or application
    communicates with an IPv4-only server", the reader may benefit of the dual text
    for IPv4-only client app communicates with IPv4-only server.

[Jordi] Such as:
"Similarly, when an IPv4-only client or application communicates with and IPv4-only server, the CLAT will statesly translate to IPv6 so it can traverse the ISP network up to the PLAT (NAT64), which in turn will translate to IPv4."

    Should figure 1 use "IPv4-only app" rather than "IPv4-only device" ? Especially
    when the actual device/handset is IPv6 only ?

[Jordi] Actually is both, device (example older SmartTV) or app, but it doesn't fit easily in the figure. We will make it ...

    ## Section 2.3

    Please explain / expand what is "only performs A+P routing" at the first use.

    I like the last paragraph about hair-pinning the IPv4 traffic BUT this should
    also be explained in all sub-sections of section 2.

[Jordi] Will work out both.

    ## Section 3.1

    Is it worth mentioning whether the tunnels require any control plane ?

[Jordi] If I recall correctly is only relevant in the case of DS-Lite (PCP), so not convinced about it.

    How can a tunnel not require additional header ? While I understand what the
    authors mean, I suggest to use the word "overhead".

[Jordi] Yep, I think that will be clearer.

    "to implement buffering and fragment re-assembly in the BR node" but "BR node"
    is only applicable to MAP-[ET].

[Jordi] Such as:
"It may
   also result in the need to implement buffering and fragment re-
   assembly in the BR node, in the case of MAP-E/T."

    ## Section 3.2

    The 3rd paragraph is more on multicast and deserves a section on its own (or
    added in section 3.6). Especially the last sentence, which is about
    encapsulation in a NAT section ;-)

[Jordi] I think only the last sentence is about multicast, but in the context of the rest of the section. We are just making clear the differences between tunneling and translation in the scope of IPv4aaS.

    The 4th paragraph has also little to do with NAT but more with L4 visibility
    for ECMP/ACL, suggest to make its own section.

[Jordi] Again it is a problem of context. May be the solution to resolve both issues is to rename the section to "Network Address Translation among the different IPv4aaS technologies" ?

    ## Section 3.3

    Should "CGN" be introduced before ? (at least expanded ?)

[Jordi] We have introduced AFTR in 2.2. May be we missed there to say that CGN is the "commercial" name for "AFTR"?

    Please expand "EAMT" even if a reference is given.

[Jordi] Done already.

    ## Section 3.4

    Even if somehow obvious, please prefix "port" with "TCP/UDP"

[Jordi] Yes, tks!

    Please provide references to the numbers of 300 ports and 4 devices.

[Jordi] We are already addressing that with some text and a reference.

    Does the above also apply to 464XLAT ?

[Jordi] In 464XLAT, you don't setup a limit of ports per subscriber.

    ## Section 4.1.1

    A little strange to see a 3-row table associated to "on the basis of two
    aspects"... Suggest to have a single row indicating T/E.

[Jordi] Yep, definitively we enhanced the table without rewording the text correctly ... will Do.

    ## Section 4.2

    This section would benefit from version / date for the browser data and for
    Netfilter implementation. A reference to Netfilter would be another plus.

[Jordi] I'm not sure if the references we provided show the version and date of the browser ... No problem in adding the Netfilter reference.

    ## Section 4.4.1

    Please add version for the miscellaneous OS and add a date for "at the time of
    writing is not available in MacOS."

[Jordi] Yep, we already discussed that among us.

    ## Section 8

    Should DNSSEC interactions with translation (and not with encapsulation) be
    discussed ?

[Jordi] I think we can make it very short making a reference to RFC8683, a new p. such as:
"IPv4aaS technologies based in encapsulation have not DNSSEC implications. However, those based in translation may have implications as discussed in section 4.1 of RFC8683."

    # NITS

    ## Section 2.1

    Figure 1, mostly cosmetic the "stateless/stateful" qualification is once before
    xLAT once after ;-) Let's try to be consistent.

[Jordi] Yep, easy to solve!

    ## Section 2.2

    "Basic Broadband Bridging' (B4)" while RFC 6333 uses "Basic Bridging BroadBand
    (B4)" ;-)

[Jordi] Yep, that happens when you rely too much on your memory! Easy to fix.

    ## Section 2.4

    "The CE (Customer-Edge)", CE has already been expanded before.

[Jordi] Right, my fault from last version ... I found it was not expanded before, but forgot to "un-expand" later. Will fix.

    s/The client address/port allocation size is a design parameter/The client
    address/port allocation size is a configuration parameter/

[Jordi] Yep, easy to fix.

    ## Section 4.4.2

    A table would be easier to read rather than a list ;-)

[Jordi] I'm lost here. You mean 4.4.1 maybe?

    ## Section 4.5.2 and 4.5.3

    Do the authors have more recent data than in 2018 and 2020 ?

[Jordi] We are going to add text here, already discussed. The data from 2018 was discussed publicly in v6ops in 2018, that's why we used that date as an initial reference. Actual data shows even better than 75% of end-to-end IPv6, but is not public. In the case of 2020, we used that from non-public data (customers) and it has been consistent with newer deployments. We could amend both data with a time range (2018-2022 and 2020-2022). Also, we have a new short paragraph to explain it.






**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
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.