Re: [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04

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

Hi Mikael, all,

Sorry, it took much more work (and time) than expected.

I just finished doing all the edits, including the several inputs in the list (including your own ones), some received in private, and the ones from Med, which provided also a very detailed review. In some cases, I've clarified directly with some folks some of the inputs.

https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/?include_text=1

I've reinforced that this document is not a "selling tool" for NAT64/464XLAT, but a tool to understand implications and relevant documents and a guideline for those that already took the decision and how to approach specific details.

Once more, thanks a lot to all!

Some questions:

1) I'm using NAT64 and DNS64 when referring to the "protocols", but using NAT64 function/DNS64 function when talking about how it is/can be deployed at the operator. I tried to make sure to use them consistently across the document and that they are easier to differentiate across the document. I think it helps, but happy to hear about this.

2) Section 5, "summary", I reworded it already (as well as some other rewordings across the documents considering all the inputs), but as said in the previous email (below), I'm still not sure to call it summary or something else. The idea is not just to be a summary, but also "flow guide" for somebody to follow when already decided to use NAT64. Thinking loud, I still think it is a summary, but just in case there is any other idea from the WG.

3) In the intro I had already a reference to RFC7269, which is a 2014 document providing other NAT64 deployment options and experience. Discussing with Med, he suggested to modify a bit the title of this one, so I added "Additional" in front of the previous title, because both documents work together as complementary. I'm wondering if it makes sense to "update" RFC7269 from this document, I don't think there anything actually updated, but in the sense that it will be convenient for a reader to actually read both of them, so somehow "linking" them "bidirectionally" makes a lot of sense because the complementarity.

4) Considering the number of inputs, the new version from that, that I was slower to react to those edits, and that part of the WGLC happened in a holiday season, I understand that some folks may be available to read this version and provide additional inputs. So, I will like to suggest to the chairs, I think Mikael, already mention that, to extend it for a few more days.

Any other inputs?

Regards,
Jordi
 
 

El 17/4/19 15:38, "v6ops en nombre de JORDI PALET MARTINEZ" <[e-mail] en nombre de jordi.palet=[e-mail]> escribió:

    Hi Mikael,
    
    Thanks for the review ... responding in-line.
    
    El 17/4/19 14:57, "v6ops en nombre de Mikael Abrahamsson" <[e-mail] en nombre de [e-mail]> escribió:
    
        On Mon, 8 Apr 2019, Ron Bonica wrote:
        
        > Folks,
        >
        > This email initiates a Working Group Last call on draft-ietf-v6ops-nat64-deployment-04. WGLC will end at COB, April 22, 2019.
        
        I have been asked to be document shepherd of this document. The below text 
        is not written with document shepherd hat on, but from me as a regular WG 
        participant.
        
        -------------------
        
        While reading through the document, I encountered some nits:
        
        In parts of the document it's called "a NAT64" and in other parts it's 
        called "NAT64 function". I'd like to see this done the same throughout. So 
        for instance in 3.1.1 there is:
        
        "... he DNS64 function, and the NAT64 function is provided ..."
        
        "... service provider offers the NAT64 only, and the DNS64 function ..."
        
        So in the last paragraph, say "... the NAT64 function only ..." ? Or 
        remove the "function" from several places? I would just like to see this 
        used the same way throughout.
    
    I think it will be more clear to use "function" all the way thru (expect if there is a specific reason for not doing so - now just thinking loud), but I'm going to review all the document and make sure about one or the other way and make it uniform for the v05.
        
        
        3.3 a.
        
        Replace with: "DNSSEC: Are there hosts validating DNSSEC?"
    
    Done!
        
        
        "   As a general conclusion, we should note that if the network must
            support applications using literals, non-IPv6-compliant APIs, or
            IPv4-only hosts or applications, only the scenarios with 464XLAT, or
            equivalent built-in local address synthesis features, will provide a
            solution. "
        
        Please make this a bullet list or something, that sentence is hard to 
        read. Also, perhaps add that it's "IPv4 literals" (if that's the case)?
    
    Done!
        
        4.
        
        This entire section has sentences that are hard to read because they're 
        long and contain a lot of commas.
        
        "So, such clients, if DNS64 is enabled,
            will never get A records, even for IPv4-only servers, and they may be
            in the path before the NAT64 and accessible by IPv4."
        
        "   When clients, in a service provider network, use DNS servers from
            other networks, for example manually configured by users, they may
            support or not DNS64, so the considerations in Section 4.3 will apply
            as well."
        
        This is not wrong per se, but it makes the sentences quite hard to read.
    
    Will work on this tonight.
        
        4.1.1
        
        For DHCPv6 options, shouldn't RFC 7051 be mentioned here?
    
    Will re-read and do.
        
        4.6.
        
        "   As already indicated in precedent sections, the successful use of the
            DNS64 is not guaranteed when networks or hosts can use "split-DNS"
            (also called Split Horizon), private DNS.  Section 4. of [RFC6950],
            analyses this case.  This a very common situation when using VPNs."
        
        I don't understand the sentence that ends with ", private DNS". Are there 
        some missing words here? Should it be ", also called private DNS" or 
        something?
    
    
    This has been already reworded (see the previous email). I will clarify anyway, if is still not sufficient.
    
        
        ""  a.  The WKP MUST NOT be used to represent non-global IPv4 addresses.
                If this is required, because the network to be translated use
                non-global addresses then an NSP is required."
        
        "the network to be translated", can we have some other phrase here? This 
        sentence is hard for me to parse. Perhaps:
        
        ""  a.  The WKP MUST NOT be used to represent non-global IPv4 addresses.
                If this is required because the addresses to be translated use
                non-global addresses, then an NSP is required."
        
        "   b.  The WKP MAY appear in inter-domain routing tables, if the
                operator provides NAT64 to peers, however special considerations
                related to BGP filtering are then required and IPv4-embedded IPv6
                prefixes longer than the WKP MUST NOT be advertised in BGP.  An
                NSP may be a more appropriate option in those cases."
        
        replace with:
        
        "   b.  The WKP MAY appear in inter-domain routing tables. If the
                operator provides NAT64 to peers, special considerations
                related to BGP filtering are then required and IPv4-embedded IPv6
                prefixes longer than the WKP MUST NOT be advertised (or accepted)
                in BGP.  An NSP may be a more appropriate option in those cases."
    
    Yeah both rewordings look fine.
        
        4.8.
        
        "   Those alternatives will solve the problem for and end-hosts, however,
            if that end-hosts is providing "tethering" or an equivalent service
            to others hosts, that need to be considered as well.  In other words,
            in a case of a cellular network, it resolves the issue for the UE
            itself, but may be not the case for hosts behind it."
        
        what are "those alternatives"?
    
    Will reword.
        
        "problem for and end-hosts" ? Can you please take a look at this entire 
        paragraph because I can't parse it.
    
    Will reword.
        
        4.10.
        
        typo: " an instead a single"
    
    Done!
        
        "So, in this
            case, the UEs typically have a build-in CLAT client, which is doing a
            stateful NAT44 before the stateless NAT46."
        
        replace:
        
        "So, in this
            case, the UEs typically have a build-in CLAT client which is performing
            a stateful NAT44 translation before the stateless NAT46."
    
    
    Done!
        
        5.
        
        "   It can be argued that none of the possible transition mechanisms is
            perfect, and somehow, we may consider that actually this is a good
            thing as a way to push for the IPv6 deployment, or otherwise, it may
            be further delayed, with clear undesirable effects for the global
            Internet."
        
        Can you please check this section some more?
    
    Will do!
        
        "  In an ideal world will, we could safely use DNS64, if the approach
            proposed in [I-D.bp-v6ops-ipv6-ready-dns-dnssec] is followed,
            avoiding the cases where DNSSEC may be broken."
        
        Typo?
    
    Done!
        
        10.1.
        
        As a summary, I think this document needs a serious once-over in the 
        aspect that the sentences are long and contains lots of commas (the above 
        examples are only a few examples).
    
    I will review all the doc again to try to avoid all the long sentences. I tend to do that, and I know "how to read them" but I understand is not easy to read for everyone from scratch.
        
        Also, Jordi, I know you like this deployment strategy but it shines 
        through in the document, especially in section 5 which isn't really a 
        summary but almost a marketing piece (especially in the beginning). Can 
        you look over the document (especially section 5) and keep to the facts 
        and do a bit less of "selling" of this specific deployment scenario?
    
    I was tempted several times to change the title of this section. I will review it and check how to better approach this change. Maybe we don't need a summary, or clearly state "if you decide to use NAT64 or 464XLAT, this is the decision flow chart" (or something in this line).
    
    
    Thanks a lot!
    
    Regards,
    Jordi
        
        -- 
        Mikael Abrahamsson    email: [e-mail]
        
        _______________________________________________
        v6ops mailing list
        [e-mail]
        https://www.ietf.org/mailman/listinfo/v6ops
        
    
    
    
    **********************************************
    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
    



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