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

[Jordi Palet Martínez <[e-mail]>]

Hi Med, all,

 

I made the distinction among the different IPv4aaS technologies trying to find both, references in each technology RFC and actual vendor support of hairpinning.

 

Not all the vendors seem to support hairpinning in NAT444, while often all the NAT64 ones do. I’m happy to change my mind on this and consequently change the text. However, I believe the text that we have proposed, ensures that the reader will double check with the vendors the specific situation, so looks to me more useful than saying “the standard supports it, so no worried, you don’t need to double check”.

 

For lw4o6, we used precisely the text that you pointed out (end of our section 2.3).

 

Regards,

Jordi

@jordipalet

 

 

El 20/5/22, 15:55, "[e-mail]" <[e-mail]> escribió:

 

Hi Gábor, 

 

I don’t understand why the same wording is not used for NAT64 and AFTR as hairpinning is a basis feature (https://datatracker.ietf.org/doc/html/rfc4787#section-6):

 

RFC6333 says: 

   A Dual-Stack Lite AFTR MUST implement behavior conforming to the best

   current practice, currently documented in [RFC4787], [RFC5508], and

   [RFC5382].  More discussions about carrier-grade NATs can be found in

   [LSN-REQS].

 

RFC6146 says the following:

   o  NAT64 is compliant with the recommendations for how NATs should

      handle UDP [RFC4787], TCP [RFC5382], and ICMP [RFC5508]. 

 

For the BR part, please note that, e.g., rfc7596 says: 

 

   The lwAFTR MUST support hairpinning of traffic between two lwB4s, by

   performing decapsulation and re-encapsulation of packets from one

   lwB4 that need to be sent to another lwB4 associated with the same

   AFTR.  The hairpinning policy MUST be configurable.

 

Not sure I would reason about implems, but the expected behavior. 

 

Thank you. 

 

Cheers,

Med

 

De : v6ops <[e-mail]> De la part de Gábor LENCSE
Envoyé : vendredi 20 mai 2022 15:41
À : Eric Vyncke (evyncke) <[e-mail]>; The IESG <[e-mail]>
Cc : [e-mail]; [e-mail]; [e-mail]; [e-mail]
Objet : Re: [v6ops] Éric Vyncke's Discuss on draft-ietf-v6ops-transition-comparison-03: (with DISCUSS and COMMENT)

 

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
 
 
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.



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