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

From: Ron Bonica <[email-masked]>
Date: Mon, 8 Apr 2019 14:20:05 +0000

Folks,

This email initiates a Working Group Last call on draft-ietf-v6ops-nat64-deployment-04. WGLC will end at COB, April 22, 2019.

Authors,

Please respond to this message indicating whether you are aware of any IPR regarding this draft.

                                                                      Ron

Juniper Internal

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 17 Apr 2019 14:57:13 +0200 (CEST)

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

3.3 a.

Replace with: "DNSSEC: Are there hosts validating DNSSEC?"

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

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.

4.1.1

For DHCPv6 options, shouldn't RFC 7051 be mentioned here?

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?

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

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

"problem for and end-hosts" ? Can you please take a look at this entire 
paragraph because I can't parse it.

4.10.

typo: " an instead a single"

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

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?

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

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

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?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 17 Apr 2019 15:37:59 +0200

Hi Mikael,

Thanks for the review ... responding in-line.

El 17/4/19 14:57, "v6ops en nombre de Mikael Abrahamsson" <[email-masked] en nombre de [email-masked]> escribió:

    
    
    -------------------

    

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.

Done!

Done!
    
    4.

    

Will work on this tonight.
    
    4.1.1

Will re-read and do.
    
    4.6.

This has been already reworded (see the previous email). I will clarify anyway, if is still not sufficient.

    

    replace with:

Yeah both rewordings look fine.
    
    4.8.

Will reword.

Will reword.
    
    4.10.

Done!
    
    "So, in this
    
    replace:
    
    "So, in this

Done!
    
    5.

Will do!

    Typo?

Done!
    
    10.1.

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.

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

    _______________________________________________
    v6ops mailing list
    [email-masked]
    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.

---

From: Fred Baker <[email-masked]>
Date: Wed, 17 Apr 2019 10:41:32 -0700

I'd suggest you post -05 for people to comment on, and -06 over the weekend.

> On Apr 17, 2019, at 6:37 AM, JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:
> 
> Hi Mikael,
> 

--------------------------------------------------------------------------------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu

---

From: <[email-masked]>
Date: Thu, 18 Apr 2019 09:42:41 +0000

Hi Jordi, all,

FWIW, you may find some comments to this version at: 

* pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-v6ops-nat64-deployment-04-rev%20Med.pdf 
* doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-v6ops-nat64-deployment-04-rev%20Med.doc

Cheers,
Med

> -----Message d'origine-----
> De : v6ops [mailto:[email-masked]] De la part de Ron Bonica
> Envoyé : lundi 8 avril 2019 16:20
> À : [email-masked]; [email-masked]
> Objet : [v6ops] WGLC: draft-ietf-v6ops-nat64-deployment-04
> 
> Folks,
> 
> This email initiates a Working Group Last call on draft-ietf-v6ops-nat64-
> deployment-04. WGLC will end at COB, April 22, 2019.
> 
> Authors,
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 20 Apr 2019 00:21:30 +0200

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" <[email-masked] en nombre de jordi.palet=[email-masked]> escribió:

    Hi Mikael,

    

        
        -------------------

        

    

        3.3 a.

    Done!

    
    Done!
        
        4.

        

        
        4.1.1

    Will re-read and do.
        
        4.6.

        

        
        replace with:

        
        4.8.

    
    Will reword.

    Will reword.
        
        4.10.

    Done!
        
        "So, in this
        
        replace:
        
        "So, in this

    Done!
        
        5.

    
    Will do!

        Typo?
    
    Done!
        
        10.1.

        

    Thanks a lot!
    
    Regards,
    Jordi

---

From: Ron Bonica <[email-masked]>
Date: Mon, 22 Apr 2019 19:54:06 +0000

Folks,

This ends WG Last Call on draft-ietf-v6ops-nat64-deployment-04.

Mikael,

Would you provide the shepherd's write-up.

                                                                                     Ron

Juniper Internal

> -----Original Message-----
> From: Ron Bonica
> Sent: Monday, April 8, 2019 10:20 AM
> To: [email-masked]; [email-masked]
> Subject: WGLC: draft-ietf-v6ops-nat64-deployment-04
> 
> Folks,
>