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

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

Dear Éric,

We have checked our proposed text for version "04" internally, and Jordi 
has noticed that I forgot to include the sentence below. Now I have 
added it as:

    In deployments where NAT64 load-balancing [RFC7269] section 4.2 is
    enabled, multiple WKPs [RFC8215] may be used.

In addition to that I promised that Jordi would propose some text for 
hair-pinning (for every single technology).

They are as follows:

At the end of Section 2.1:

    Often NAT64 vendors support direct communication (that is, without
    translation) between two CLATs by means of hair-pinning through the
    NAT64.


At the end of Section 2.2:

    Some AFTR vendors support direct communication between two B4s by
    means of hair-pinning through the AFTR.


(Section 2.3 had already the text about hair-pinning.)

At the end of Sections 2.4 and 2.5:

    Some BR vendors support direct communication between two MAP CEs by
    means of hair-pinning through the BR.

I hope that no more things are missing.

I plan to submit version 04 soon.

Best regards,

Gábor


4/26/2022 4:48 PM keltezéssel, JORDI PALET MARTINEZ írta:
> Hi Eric,
>
> Discussing this with Med (tks a lot!), we reached the conclusion that as the NAT64 prefix is only required for 464XLAT, we don't need to have the text that I drafted. However, this text makes much better sense:
>
> "In deployments where NAT64 load-balancing [RFC7269 section 4.2] is enabled, multiple WKPs [RFC8215] may be used."
>   
>   
> Regards,
> Jordi
> @jordipalet
>   
>   
>
> El 22/4/22, 12:35, "Eric Vyncke (evyncke)"<[e-mail]>  escribió:
>
>      Jordi,
>
>      My bad for 64::ff9b::/96, it is indeed RFC 6052 so please use this reference and not RFC 8215 in section 2.1.
>
>      You may also want to add your 'very draft' (but good) idea of course.
>
>      Regards
>
>      -éric
>
>
>      -----Original Message-----
>      From: JORDI PALET MARTINEZ<[e-mail]>
>      Date: Friday, 22 April 2022 at 12:02
>      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]>
>      Subject: Re: Éric Vyncke's Discuss on draft-ietf-v6ops-transition-comparison-03: (with DISCUSS and COMMENT)
>
>          Hi Eric,
>
>          All points taken and we will submit a new version ASAP.
>
>          Just one minor point about the WKP 64:ff9b::/96. It is defined in RFC6052, which we citted already.
>
>          RFC8215 is defining a "local" WKP, which is only needed if you are going to use multiple translation mechanism.
>
>          Our document is arguing to choose one, not multiple. We could have a new very short section "Use of Multiple IPv4aaS technologies in the same network", may be towards the end of the document that just states something in the line of:
>
>          "This document is suggesting, for obvious deployment and operational simplicity reasons, to choose a single IPv4aaS technology in a given operators network. However, in some cases, it may be neccesary to choose several of them in different parts of the network. In that case, if multiple IPv4/IPv6 translation mechanisms have to coexist, RFC8215 needs to be taken in consideration."
>
>          (very draft ... just a quick idea)
>
>          Regards,
>          Jordi
>          @jordipalet
>
>
>
>          El 22/4/22, 11:40, "Eric Vyncke (evyncke)"<[e-mail]>  escribió:
>
>              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
>
>
>
>
>
>          **********************************************
>          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.
>
>
>
>
>
>
>
> **********************************************
> 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.
>
>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>