Subject: [v6ops] Éric Vyncke's No Objection on draft-ietf-v6ops-nat64-deployment-06: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Sun, 07 Jul 2019 05:58:13 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-v6ops-nat64-deployment-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hello Jordi,

Thank you  for the work put into this clear and well-written document.

I only wonder whether section 3 and section 4 should be swapped for a more
logical flow: explain the issues, then describe working solutions. Probably too
late in the publication to change though.

The underlying message of "464XLAT solves everything" is annoying but I must
admit that this is true ;-)

Please find below many COMMENTs in the hope of improving the readability and
factual data points in the document.

-éric

== COMMENTS ==

Is there a description of the use of DNS64 in the host as it fixes the DNSSEC
issues ? (except in section 3.2.2.)

-- Section 3.1 --

"known to work": can you add references or data backing this statement ?

-- Section 3.1.1 --

When discussing scenarii, please refer to the figure ID in the text for clarity.

-- Section 3.1.2 --

It is unclear to me whether "The support of this scenario" refers to the
UE-only or the CPE deployment.

Same demand as above: please refer to the figure ID in the text for clarity.

-- Sectio 3.2.1 --

I really wonder whether it is useful to describe this scenario as 'working
under special conditions'... those 'special conditions' will probably never met
in real life.

More generally, I am unsure about the value of the whole section 3.2 (it is
more like an academic thing).

-- Section 4.1.1. --

Can you add reference and/or data for "monitored by some governmental bodies
and other institutions".

Please add a reference for the use of "ipv4only.arpa". AFAIK
draft-cheshire-sudn-ipv4only-dot-arpa appears to be dormant/dead.

-- Section 4.1.2 --

The leading paragraph is a little confusing as it assumed that CLAT exists
(stated in the text but not in the section title).

-- Section 4.1.5 --

The section title is rather misleading "ACL of clients" and I wonder why a
dual-stack client would use a DNS64 server as its recursive DNS server. Isn't
it an obvious configuration mistake?

-- Section 4.4.1 --

Some explanations of the consequences of a foreign DNS would be welcome.

-- Section 4.4.2 --

Rather than using "DNS privacy" please use "DNS request confidentiality" as the
DNS64 will learn/glean about the client activities.

-- Section 4.6 --

Please explain why older API is a problem (or rather rephrase it into
applications using IPv4-only API).

-- Section 4.10 --

draft-ietf-tram-turnbis is also able to support IPv6-only client. It is
currently in the same IESG status as this document.

-- Section 5 --

Please add data/references for "with hundreds of millions of users"

-- Section 7 --

Not so much about security but about privacy. I would appreciate to have some
text around the lack of privacy when using an external DNS64 as this server
will learn about all clients activities.

== NITS ==

Generally, please refrain from using "HEv2" in place of "Happy Eyeball version
2".

-- Section 3.1.1. --

Figure 1 shows a box containing both NAT64 and DNS64 while those functions
could reside in different devices.

s/One more equivalent scenario/One additional equivalent scenario/ ?

-- Section 4.1 --

s/to an IPv6-only WAN/to an IPv6-only access network/

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 07 Jul 2019 23:24:21 +0200

Hi Eric,

Thanks a lot for your review!

Comments in-line below. Most of them I will reword some text or correct nits, but there are a couple of questions for you to clarify.

Regards,
Jordi
@jordipalet

El 7/7/19 14:59, "v6ops en nombre de Éric Vyncke via Datatracker" <[email-masked] en nombre de [email-masked]> escribió:

    
    
    Hello Jordi,

I think that will be a major change, because I've a lot of references to the "possible" deployment scenarios to explain the different issues. My "flow" was thinking in how you can deploy it, and then what are the issues that you need to consider.

This document started as 464XLAT deployment guidelines, and the WG asked me to turn it also to "NAT64". I think that explains it, but in any case, as you well say, it is true ... and there is explicit text to indicate that if you're sure that everything inside the network is supporting IPv6, no literals, etc., then it may be fine with just NAT64. However we all know that this is a non-realistic scenario.

    -éric
    
    == COMMENTS ==

Not sure to completely understand what you mean here, just trying ... This is not something that the service provider can solve, as it is up to the OS (for all the devices in that network). That's why I think is not something for this document. However, I just realized that this is described in section 7.2 of RFC6147. I can add a reference to that in section 3.2.2.
    
    -- Section 3.1 --

Well, those are the models being used today in cellular and broadband networks. So I can just say that?
    
    -- Section 3.1.1 --

Done (I'm already editing a new version while writing this, pending on some that you can provide to my comments).
    
    -- Section 3.1.2 --

It is referring to the "service provider network support". Will clarify it.

Done!
    
    -- Sectio 3.2.1 --

I think some of those scenarios are possible in some networks, may be not connecting to Internet, or for example, you may want to configure explicit mappings, which can be done with EAM. I just realized that I've not cited that. I will do.
    
    -- Section 4.1.1. --

I believe that was pointed out by somebody in the WG, but it is true that some regulators do that. I recall having seen something about that in France, but I'm not 100% sure right now.

Right, this is defined by RFC7050, done!

This is one of the issues that I've commented with Warren, responding to IANA. I understand he is sponsoring that document. 

    -- Section 4.1.2 --

Will clarify it.
    
    -- Section 4.1.5 --

No, I think that text is correct, but I will try to reword it to make it clearer. You may have a situation with IPv4-only servers, which are located, in the path between the dual-stack hosts and the NAT64. So, if the DNS64 is not configured to exclude those servers, it will synthetize the AAAA records and they will become unreachable. So that's why bind and other DNS64 servers provide this ACL function.
    
    -- Section 4.4.1 --

Done!
    
    -- Section 4.4.2 --

I used this terminology as it was suggested as the common one for the different protocols in this category. I will try to confirm if is the right one just in case. May be rewording the title as "DNS Privacy/Encryption Mechanisms" ?

    -- Section 4.6 --

Done!
    
    -- Section 4.10 --

Definitively, will add a reference to it!
    
    -- Section 5 --

I can cite several cellular networks, but I will do in a generic way, I don't think we should mention explicit providers, right?. 
    
    -- Section 7 --

Good point, thanks. Will do!
    
    == NITS ==

Done!
    
    -- Section 3.1.1. --

Will clarify it.

Done!
    
    -- Section 4.1 --

Done!    

    _______________________________________________
    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: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 8 Jul 2019 06:11:56 +0000

Hola Jordi,

A couple of my comments were about lacking of references for "known to work" or "monitored by some governmental bodies and other institutions" or ""with hundreds of millions of users" which are strong statements without any factual data behind them. I make me feel uncomfortable... the document would be much stronger if there were references (external papers are fine).

Your explanations for "ACL of clients" are clear now. I suggest that you rewrite the section to add the example given in your reply. And, use a different name to the section ;-)

Thank you for all the fixes and for authoring the document

-éric

On 07/07/2019, 23:39, "JORDI PALET MARTINEZ" <[email-masked]> wrote:

        -- Section 3.1 --

        
        -- Section 3.1.1 --

        
        -- Section 3.1.2 --

        
    
    Done!
        
        -- Sectio 3.2.1 --

    
        
        -- Section 4.1.1. --

        

    

        -- Section 4.1.2 --

    Will clarify it.
        
        -- Section 4.1.5 --

        
        -- Section 4.4.1 --

    Done!
        
        -- Section 4.4.2 --

        
        -- Section 4.6 --

    Done!
        
        -- Section 4.10 --

        
        -- Section 5 --

        
        -- Section 7 --

        
        == NITS ==

    Done!
        
        -- Section 3.1.1. --

    Will clarify it.

    Done!
        
        -- Section 4.1 --

    Done!

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 08 Jul 2019 15:11:38 +0200

Hi Eric,

I just posted a new version (https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/).

I believe it addresses all the issues and nits that you have raised (plus other nits that I've found as well).

Again, thanks a lot for the very detailed review!

Regards,
Jordi
@jordipalet

El 8/7/19 8:45, "Eric Vyncke (evyncke)" <[email-masked]> escribió:

    Hola Jordi,

    
    
    -éric

            -- Section 3.1 --

            
            -- Section 3.1.1 --

            
            -- Section 3.1.2 --

            
        
        Done!
            
            -- Sectio 3.2.1 --

        
            
            -- Section 4.1.1. --

            

        

            -- Section 4.1.2 --

        Will clarify it.
            
            -- Section 4.1.5 --

            
            -- Section 4.4.1 --

        Done!
            
            -- Section 4.4.2 --

            
            -- Section 4.6 --

        Done!
            
            -- Section 4.10 --

            
            -- Section 5 --

            
            -- Section 7 --

            
            == NITS ==

        Done!
            
            -- Section 3.1.1. --

        Will clarify it.

        Done!
            
            -- Section 4.1 --

        Done!

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Mon, 8 Jul 2019 17:05:21 +0000

Section 3.3:

"if the network must
   support applications using any of the following:

   o  IPv4-only hosts or applications

   Then, only the scenarios with 464XLAT, a CLAT function, or equivalent
   built-in local address synthesis features, will provide a valid
   solution."

Which document explains how 464XLAT and a CLAT function provide connectivity from IPv4only-host to IPv6only-host?

Thanks,
Dusan.

> -----Original Message-----
> From: v6ops <[email-masked]> On Behalf Of JORDI PALET
> MARTINEZ
> Sent: Sunday, July 7, 2019 5:24 PM
> To: Éric Vyncke <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; v6ops-
> [email-masked]
> Subject: Re: [v6ops] Éric Vyncke's No Objection on draft-ietf-v6ops-nat64-
> deployment-06: (with COMMENT)
> 
> Hi Eric,
> 
> Comments in-line below. Most of them I will reword some text or correct
> nits, but there are a couple of questions for you to clarify.
> 
> Regards,
> Jordi
> @jordipalet
> 
> 
> 
> El 7/7/19 14:59, "v6ops en nombre de Éric Vyncke via Datatracker" <v6ops-
> [email-masked] en nombre de [email-masked]> escribió:
> 
>     Please refer to https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_iesg_statement_discuss-
> 2Dcriteria.html&d=DwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJ
> xhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=_E9ZufQAIc5wlVLDWKPA2DvW0t
> rvZwSDh5SnT8LOzdg&s=LwRXKT1d-8SS5QiUbHNrp33o3TBAeLqgs9RN-
> UwC0Yg&e=
>     https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dv6ops-2Dnat64-
> 2Ddeployment_&d=DwIGaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLe
> aJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=_E9ZufQAIc5wlVLDWKPA2DvW
> 0trvZwSDh5SnT8LOzdg&s=PHW-
> a847Dg670Srlft54euH86mfhpwcaNiqzcBPS8v4&e=
> 
> 
> 
> I think that will be a major change, because I've a lot of references to the
> "possible" deployment scenarios to explain the different issues. My "flow"
> was thinking in how you can deploy it, and then what are the issues that you
> need to consider.
> 
> This document started as 464XLAT deployment guidelines, and the WG asked
> me to turn it also to "NAT64". I think that explains it, but in any case, as you
> well say, it is true ... and there is explicit text to indicate that if you're sure
> that everything inside the network is supporting IPv6, no literals, etc., then it
> may be fine with just NAT64. However we all know that this is a non-realistic
> scenario.
> 
> Not sure to completely understand what you mean here, just trying ... This is
> not something that the service provider can solve, as it is up to the OS (for all
> the devices in that network). That's why I think is not something for this
> document. However, I just realized that this is described in section 7.2 of
> RFC6147. I can add a reference to that in section 3.2.2.
> 
>     -- Section 3.1 --
> 
> I think some of those scenarios are possible in some networks, may be not
> connecting to Internet, or for example, you may want to configure explicit
> mappings, which can be done with EAM. I just realized that I've not cited
> that. I will do.
> 
>     -- Section 4.1.1. --
> 
> I believe that was pointed out by somebody in the WG, but it is true that
> some regulators do that. I recall having seen something about that in France,
> but I'm not 100% sure right now.
> 
> This is one of the issues that I've commented with Warren, responding to
> IANA. I understand he is sponsoring that document.
> 
> 
>     -- Section 4.1.2 --
> 
> No, I think that text is correct, but I will try to reword it to make it clearer. You
> may have a situation with IPv4-only servers, which are located, in the path
> between the dual-stack hosts and the NAT64. So, if the DNS64 is not
> configured to exclude those servers, it will synthetize the AAAA records and
> they will become unreachable. So that's why bind and other DNS64 servers
> provide this ACL function.
> 
>     -- Section 4.4.1 --
> 
> I used this terminology as it was suggested as the common one for the
> different protocols in this category. I will try to confirm if is the right one just
> in case. May be rewording the title as "DNS Privacy/Encryption Mechanisms"
> ?
> 
> 
> 
>     -- Section 4.6 --
> 
> I can cite several cellular networks, but I will do in a generic way, I don't think
> we should mention explicit providers, right?.
> 
>     -- Section 7 --
> 
>     https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIGaQ&c=BFpWQw8bsuKp
> l1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=_E9
> ZufQAIc5wlVLDWKPA2DvW0trvZwSDh5SnT8LOzdg&s=wOPWzlIjnoqYXR0OM
> bl5dJswrnnMmmTX2ymOmmJ0Rfo&e=
> 
> 
> 
> 
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.theipv6company.com&d=DwIGaQ&c=BFpWQw8bsuKpl1SgiZH64
> Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=_E9ZufQAIc5
> wlVLDWKPA2DvW0trvZwSDh5SnT8LOzdg&s=DJpxsc514-
> zcfBAFS4ksUO1Az_LzLKo1Da80uIg60JA&e=
> 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.
> 
> 
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIGaQ&c=BFpWQw8bsuKp
> l1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=_E9
> ZufQAIc5wlVLDWKPA2DvW0trvZwSDh5SnT8LOzdg&s=wOPWzlIjnoqYXR0OM
> bl5dJswrnnMmmTX2ymOmmJ0Rfo&e=

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 08 Jul 2019 19:24:00 +0200

Hi Dusan,

I think you're reading it wrong.

This document is about guidelines for deployment of an existing transition mechanism: NAT64 (and a derivate of it, 464XLAT).

NAT64 was designed as a solution for IPv6-only hosts, connected to an IPv6-only access network, to access IPv4-only services (as well as dual-stack ones).

464XLAT also provides a solution for IPv4-only hosts, connected to an IPv6-only access network, to access IPv4-only services (as well as dual-stack ones).

So, the *actual* implementation of 464XLAT/NAT64 doesn't allow IPv4-only hosts to connect to IPv6-only hosts.

*However*, you may be interested in reading this optimization that may solve the problem:
https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches/?include_text=1

Note that this is work-in-progress, and if you wait to the end of the day, you will get a *much better* version of this document. This will solve the problem that you mention if 464XLAT is used.

I will send a notification in the list when I submit the next version, it is taking many more hours than I expected ...

Regards,
Jordi
@jordipalet

El 8/7/19 19:08, "v6ops en nombre de Mudric, Dusan (Dusan)" <[email-masked] en nombre de [email-masked]> escribió:

    Section 3.3:
    
    "if the network must

    
    
    Thanks,
    Dusan.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 08 Jul 2019 19:32:09 +0200

By the way, when you read this:

   As a general conclusion, we should note that, if the network must
   support applications using any of the following:
   o  IPv4 literals
   o  non-IPv6-compliant APIs
   o  IPv4-only hosts or applications

You can't take it out of the context of the document. I think this is where you are getting confused. "if the network", because the context of the complete document, is referring to the user LANs in and operator or enterprise IPv6-only access network, supporting 464XLAT (NAT64 doesn't solve all those problems), but again, in the context of destinations which are IPv4-only or dual-stack, but not "IPv6-only".

We will come to that when we reactivate sunset4 WG, and we decide to recommend that IPv4 is historic, and must be disabled in all the networks ... but that's another history! Meanwhile, if you want a "service" to be reachable by everyone, you need to support some form of dual-stack (for example a DC may be IPv6-only but use SIIT-DC to appear as dual-stack in the public facing interfaces).

Regards,
Jordi
@jordipalet

El 8/7/19 19:24, "JORDI PALET MARTINEZ" <[email-masked]> escribió:

    Hi Dusan,

    

    

    
    Regards,
    Jordi
    @jordipalet

    
        Section 3.3:
        
        "if the network must

        
        
        Thanks,
        Dusan.