Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 12 Jun 2018 00:38:38 +0000

I've been rather quiet on this, trying to figure out how to politely say (with explanation) that I don't think this doc is in a state that would make it acceptable as a WG draft. But in re-reading Andrew's response from a few weeks ago, I think he's managed to put into words what some of my reservations are. I'm top-posting on Andrew's email, with my summary of some of the points he made, and my conclusions.
A BCP that provides accurate and usable criteria for evaluating "which NAT64 architecture is right for me" might be a good thing to produce. But this draft isn't it. This draft lacks WG consensus that it has the correct assessment of the various architectural options. It is also not written in a way that makes it easy to compare the pros and cons of the various options against the needs of a network operator. The draft has potential, but isn't there (yet?).
I don't have enough interest in this to spend the time needed to overcome these objections. So raising these objections should not be seen as an obligation to actively provide the corrections needed to overcome these objections.
Barbara

> -----Original Message-----
> From: v6ops <[email-masked]> On Behalf Of Andrew Sullivan
> Sent: Tuesday, May 29, 2018 3:38 PM
> To: [email-masked]
> Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion
> 
> Hi,
> 
> On Tue, May 29, 2018 at 08:27:29PM +0200, JORDI PALET MARTINEZ wrote:
> 
> > I understand your point that NAT64 was meant to be "imperfect", but this
> is something that is not valid for operators. Operators need to support
> existing customers with existing devices and apps, that only have IPv4
> support, and this is only possible with NAT64 + CLAT.
> >
> 
> Obviously, operators have customers and need to support whatever they
> need to support.  It appears that there are people who are using 464XLAT
> with DNS64 where that works for them.  I certainly have no trouble with
> something that wants to outline (for instance) how one would make a
> determination about whether anyone downstream is doing their own
> validation.  What I think is wrong here is a generic claim that one or another
> approach is the only right answer, because the CLAT in many cases requires
> more translation (which means more overhead and more work that the
> operator has to do).
> 
> > Also, most of the actual usages of 464XLAT are still using DNS64 (except a
> few like Orange in Poland if I recall correctly), so the point is to explain that
> you can also solve the DNSSEC issue, when using CLAT (not using DNS64), etc.
> >
> 
> Well, you can indeed.  I think there is nothing wrong with making this point,
> but the document as it is appears to be suggesting that the trade-off is not
> clear in DNS64.  I think RFC 6147 is crystal clear about it, so I don't get why this
> document (which has a much less comprehensive treatment of what fails
> and why) is an improvement.
> 
> > So, the goal of the document is to find what is the "best" possible
> > way to deploy NAT64, which in my opinion, in the real world is by
> > using it combined with CLAT.
> 
> I don't observe that the document is called "Jordi's opinion on best
> NAT64 deployment scenarios".  If the WG is supposed to work on this, then I
> think it would be better to outline the various trade-offs and allow people to
> make their own choices, fully informed.
> 
> > Of course, Section 3.1 (now 4.1 in v1) is not a credible case, but I
> > wanted to do the exercise of looking into all possible cases, just to
> > make sure that somebody using the document see what is possible and
> > what is not, instead of making the exercise by themselves.
> 
> I see.  Such a section could be massively improved, then, by calling out the
> scenarios that are known not to work, that are broken on purpose, and so
> on.  At the moment, it reads as though these alternatives are all live
> possibilities, but some of them simply aren't, were never intended to be, and
> are not a real problem anyone should have.
> 
> > What I disagree with you is in your comment that anyone who is willing to
> deploy (let's concentrate in) 464XLAT, will do DNS64 too. This is actually not
> needed in that case.
> >
> 
> I think what I said is that they're going to _be able_ to, not that they would.  I
> do not claim that DNS64 ought to be deployed by anyone.
> It's just a mechanism that is available if it happens to fit a need, and each
> network operator needs to evaluate that.  I claim that the I-D as written
> doesn't actually help people do such an evaluation, and that in fact it leaves
> out some of the necessary analysis.
> 
> > Maybe if you see the point that an operator will not be able to provide
> services without the CLAT, you have a better understanding on the
> document now.
> >
> 
> It's simply false that an operator will not be able to provide service without
> the CLAT, but it is true that _some_ operators will find such a service
> inadequate.  I believe that's why 464XLAT was invented, in fact.
> 
> > Would you agree that if an operator deploying IPv6-only access want to
> make sure that the customers using some IPv4-only devices work fine, the
> only way is using NAT64+CLAT, and that using NAT64+DNS64 will not work?
> >
> 
> No.  But I believe that there are operators for whom that will be true.  I also
> believe there are operators for whom 464XLAT with DNS64 is a viable and
> useful option in some scenarios, particularly having to do with the costs of
> double translation.  I'm not opposed to a document that attempts to lay out
> the trade-offs.  I am very much opposed to a document that attempts to say
> there's only one way that works, because it isn't true.  Indeed, for some
> values of "works", _none_ of this qualifies, and the only real answer is native
> ipv6.
> 
> Best regards,
> 
> A
> 
> --
> Andrew Sullivan
> [email-masked]
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwICAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8Tq4vrfog&m=RSkkIe4IvPSsZ3MQjB0zrke22MCFWChjY3TS_hlIyu8&s=
> vSMt4g-fkpgeb1fo2zsjL5D0DcFGs_nZzDf1agm1obo&e=

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 12 Jun 2018 08:43:44 +0200

Thanks Barbara.

Already working in a new version to accommodate to that, so I think it will make sense for anyone willing to contribute, to wait until I've submitted that version, unless is adding something substantially different to what Andrew provided. 

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de "STARK, BARBARA H" <[email-masked]>
Fecha: martes, 12 de junio de 2018, 2:39
Para: 'Andrew Sullivan' <[email-masked]>, "[email-masked]" <[email-masked]>
Asunto: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion

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

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
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.