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

["Eric Vyncke (evyncke)" <[e-mail]>]

Hello Jordi,

Thank you for your quick reply, and also addressing most of my points. Look below for EV> (all points that we agree on have been elided).

Regards

-éric

PS: once a revised I-D is uploaded, then I am clearing my DISCUSS of course.

-----Original Message-----
From: JORDI PALET MARTINEZ <[e-mail]>
Date: Thursday, 21 April 2022 at 18:51
To: Eric Vyncke <[e-mail]>, The IESG <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Ron Bonica <[e-mail]>, "[e-mail]" <[e-mail]>

        ## 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)?

EV> Jordi, please accept my apologies on this one, you are correct, and I wonder why I did not see NAT64 :-(

        ## 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?

EV> you could indeed add the above references in 4.2 for "may also be impacted by local regulatory law" (and in the Belgian case it is not a law but more a MoU / BCP)

EV> but my main point if that the beginning of section 3.4 should have a sentence about "technical limitations are not the only point to consider for port sharing, there are also local regulations or BCP".

        # 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?

EV> correct just something long the words above about UE & 464XLAT 

        ## Section 2.1


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

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

EV> simply because the WKP has been allocated by RFC 8215

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

EV> true, forget about my comment

        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.

EV> indeed, I was confused by the current text. The /64 not being the 64::ff9b:: one but the prefix assigned to the CE/UE. The current text should perhaps be clearer for that "when a /64 is not assigned to the hosts" ? Also, if there is a single host (UE) even a /128 should work.

        ## 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" ?

EV> sounds good to me

        ## 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"?

EV> indeed

        ## Section 3.4


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

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

EV> I failed to see them but I trust you

        ## 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."

EV> yes please