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

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 08 Apr 2019 18:02:33 +0200

Hi Ron,

I'm not aware of any IPR on this document.

Regards,
Jordi

El 8/4/19 17:54, "v6ops en nombre de Ron Bonica" <[email-masked] en nombre de rbonica=[email-masked]> escribió:

    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
    
    _______________________________________________
    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: Tue, 9 Apr 2019 17:37:26 -0700

For the record, the question here is two-fold. First, is it correct and complete? Is there more, or less, that should be said? Second, are there operators -ISPs, IxPs, enterprise, or whatever, that consider this useful in their deployments?

> On Apr 8, 2019, at 9:02 AM, JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:
> 
> Hi Ron,
>

---

From: Alejandro D'Egidio <[email-masked]>
Date: Mon, 15 Apr 2019 20:31:23 -0300 (ART)

Hello,
>From my point of view, I think this document is really useful.
In my case, I consider 464XLAT as a very good solution and in fact I already have a cablemodem with a FW with CLAT and it works perfectly!

Regarding the content.

In "possible communication paths" for both cases with and without DNS64, we have this option:
"   c.  Local-IPv4 to Remote-IPv6: Not possible.  It is not expected that
       services are deployed in Internet using IPv6-only, unless there
       is certainty that peers will also be IPv6-capable.
"

If we consider EAMT (RFC7757) as we are suggesting in draft-palet-v6ops-464xlat-opt-cdn-caches-01 it could be possible.

Maybe you can add some note that It is possible if we CPE supports EAMT allowing to connect IPv4-only devices/apps to IPv6 services.

Regards,
Alejandro

---

From: Gábor Lencse <[email-masked]>
Date: Tue, 16 Apr 2019 22:37:06 +0900

Dear Jordi,

I think your draft contains valuable material, and I support its 
publication as an RFC. I try to do my best to read it, but I cannot 
finish it today.

While reading, I take notes below. The majority of them will be nits. 
The sign "-->" means a suggestion for correction.

1. Introduction:

   NAT64 ([RFC6146  <https://tools.ietf.org/html/rfc6146>]) describes a stateful IPv6 to IPv4 translation, -->*Stateful*  NAT64 ([RFC6146  <https://tools.ietf.org/html/rfc6146>]) describes a stateful IPv6 to IPv4 translation,

(Saying simply "NAT64" may include both stateful and stateless NAT64. If 
you do not want to write always "stateful NAT64", then perhaps you 
should explain in the beginning that you mean "stateful NAT64" under 
"NAT64".)

Page 8.:

    Furthermore, as indicated in [RFC6877  <https://tools.ietf.org/html/rfc6877>] (464XLAT),_can be used_  in
    broadband IPv6 network architectures, by implementing the CLAT
    functionality at the CE.

I do not understand WHAT can be used. Perhaps you meant:

    Furthermore, as indicated in [RFC6877  <https://tools.ietf.org/html/rfc6877>],*464XLAT can be used*  in
    broadband IPv6 network architectures, by implementing the CLAT
    functionality at the CE.

Page 9.

    c.  Local-IPv4 to Remote-IPv6: Not possible._It is not expected that services are deployed in Internet using 
IPv6-only, unless there is certainty that peers will also be IPv6-capable._

Perhaps a philosophical question: When will it be expected? (How long 
shell we need to always consider IPv4?)

Section 3.1.3.

However, doesn't
    look a sensible approach from an Operating System or application
    vendor perspective, to provide IPv6-only support unless, similarly to
    c.  above, there is certainty of peers supporting IPv6 as well.

I understand, but I am not happy with that. I am not arguing with you 
but with this approach...

Section 3.2.

_In addition to the different pros, cons and trade-offs_, which may be acceptable for some operators, they have
    implementation difficulties, as they are beyond the original
    expectations of the NAT64/DNS64 original intent.

You might want to refer to our I-D as an informative reference: 
https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-02

I have stopped reading at the beginning of Section 4 (because of my time 
zone), I hope to be able to continue tomorrow.

Best regards,

Gábor

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 16 Apr 2019 16:27:05 +0200

Hi Gabor,

Thanks a lot!

Responding below in-line.

Regards,

Jordi

El 16/4/19 15:38, "v6ops en nombre de Gábor Lencse" <[email-masked] en nombre de [email-masked]> escribió:

Dear Jordi,

I think your draft contains valuable material, and I support its publication as an RFC. I try to do my best to read it, but I cannot finish it today.

While reading, I take notes below. The majority of them will be nits. The sign "-->" means a suggestion for correction.

1. Introduction:
  NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 translation, -->   Stateful NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 translation,
(Saying simply "NAT64" may include both stateful and stateless NAT64. If you do not want to write always "stateful NAT64", then perhaps you should explain in the beginning that you mean "stateful NAT64" under "NAT64".)

I’ve now addressed this in v05, thanks!

Page 8.:

   Furthermore, as indicated in [RFC6877] (464XLAT), can be used in
   broadband IPv6 network architectures, by implementing the CLAT
   functionality at the CE.
I do not understand WHAT can be used. Perhaps you meant:

   Furthermore, as indicated in [RFC6877], 464XLAT can be used in
   broadband IPv6 network architectures, by implementing the CLAT
   functionality at the CE.

Done!

Page 9.

   c.  Local-IPv4 to Remote-IPv6: Not possible.  It is not expected that
       services are deployed in Internet using IPv6-only, unless there
       is certainty that peers will also be IPv6-capable.

Perhaps a philosophical question: When will it be expected? (How long shell we need to always consider IPv4?)

I don’t think this is something to be discussed in this document, however, this text has changed in v05, see my earlier response with new text to Alejandro. Anyway, I’m happy to amend it again, if the WG believes we should enter into philosophical discussions …

Section 3.1.3.
However, doesn't

I understand, but I am not happy with that. I am not arguing with you but with this approach... 

I’m not sure to understand your point here. Should I explicitly say that providing IPv6-only for an OS is a bad thing? That is contradictory with your previous philosophical discussion … Maybe you want to suggest some specific wording so I can get your point better?

Section 3.2.

In addition to the different pros, cons and
   trade-offs, which may be acceptable for some operators, they have
   implementation difficulties, as they are beyond the original
   expectations of the NAT64/DNS64 original intent.
You might want to refer to our I-D as an informative reference: https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-02

Yes, good point :-)

I have stopped reading at the beginning of Section 4 (because of my time zone), I hope to be able to continue tomorrow.

Thanks again!

Best regards,

Gábor

 
Hi Ron,

Regards,
Jordi

 
   Folks,

   Authors,

                                                                         Ron

   Juniper Internal

 

 
 
_______________________________________________ v6ops mailing list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 16 Apr 2019 16:57:10 +0200

I’m confused about one of your inputs, see below.

El 16/4/19 16:27, "JORDI PALET MARTINEZ" <[email-masked]> escribió:

Hi Gabor,

Thanks a lot!

Regards,

Jordi

Dear Jordi,

1. Introduction:

Page 8.:

This is the same text as what I’ve:

   functionality at the CE.

Page 9.

Section 3.1.3.
However, doesn't

 

Section 3.2.

Yes, good point :-)

After re-reading, I’ve decided that it makes more sense to have this reference at the end of the intro, to state that there are other choices than just NAT64/464XLAT.

Thanks again!

Best regards,

Gábor

 
Hi Ron,

Regards,
Jordi

 
   Folks,

   Authors,

                                                                         Ron

   Juniper Internal

---

From: Alfredo Sola <[email-masked]>
Date: Tue, 16 Apr 2019 19:09:31 +0200

Hello,

> For the record, the question here is two-fold. First, is it correct and complete? Is there more, or less, that should be said? Second, are there operators -ISPs, IxPs, enterprise, or whatever, that…

	From my perspective as a network operator, I think this document is useful and mature (both correct and complete). In my opinion, it should be published as soon as the author finishes addressing the current feedback round, which seems to revolve around clarifications and not challenging the ideas presented.

-- 
Alfredo Sola
https://www.tecnocratica.net

---

From: Gábor Lencse <[email-masked]>
Date: Thu, 18 Apr 2019 21:20:53 +0900

Hi, Jordi,

> I’m confused about one of your inputs, see below.
[...]

>    broadband IPv6 network architectures, by implementing the CLAT
Yes, you are completely right!

In fact, I accidentally started reading the "-00" version, and when I 
noticed that, I revised my notes and deleted some others, which were 
already corrected in the "-04" version, but I somehow did not notice 
this one.

Gábor

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 18 Apr 2019 14:22:16 +0200

Perfect, thanks a lot!

Regards,

Jordi

El 18/4/19 14:21, "Gábor Lencse" <[email-masked]> escribió:

Hi, Jordi,

[...]

Page 8.:

   functionality at the CE.

In fact, I accidentally started reading the "-00" version, and when I noticed that, I revised my notes and deleted some others, which were already corrected in the "-04" version, but I somehow did not notice this one.

Gábor