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

From: Fred Baker <[email-masked]>
Date: Sun, 13 May 2018 19:07:18 -0700

Considering https://tools.ietf.org/html/draft-palet-v6ops-nat64-deployment-00, discussed at IETF 101 using the slides at https://datatracker.ietf.org/meeting/101/materials/slides-101-v6ops-nat64-deployment-guidelines-in-operator-and-enterprise-networks-00. I'd like to invite discussion on the list. What thoughts do folks have on this draft?

---

From: Lencse Gábor <[email-masked]>
Date: Wed, 23 May 2018 22:03:45 +0200

Dear Fred and Jordi,

I have read the draft and I think it is useful.

If I my put my two cents in, I would like to point out that we have come 
to a very similar conclusion in Section 4.9 (titled "DNS and DNSSEC") of 
our paper below to the one presented in Section 2 of the draft.

G. Lencse and Y. Kadobayashi, "Methodology for the identification of 
potential security issues of different IPv6 transition technologies: 
Threat analysis of DNS64 and stateful NAT64", /Computers & Security/ 
(Elsevier), vol. 77, no. 1, pp. 397-411, September 1, 2018, DOI: 
10.1016/j.cose.2018.04.012
Free access link valid until June 30: 
https://authors.elsevier.com/a/1X1K5c43ukegl
Revised version is available freely (as green open access) from my list 
of publications: http://www.hit.bme.hu/~lencse/publications/

Perhaps ISPs can use our benchmarking results when selecting DNS64 or 
NAT64 implementations.

As for DNS64, we have up to date performance information, which may be 
somewhat surprising concerning the performance problems of BIND. If you 
are interested, please check our results concerning the DNS64 
performance of BIND, PowerDNS and Unbound:

G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: 
Theory and Practice", /Computer Communications/ (Elsevier), to be published

Revised version is available freely (as green open access) from my list 
of publications: http://www.hit.bme.hu/~lencse/publications/

As for stateful NAT64, we have only very old measurement results showing 
that OpenBSD PF outperformed TAYGA+iptables, which was not surprising at 
all, but those measurements were not RFC 8219 compliant, as RFC 8219 did 
not exist yet.

Best regards,

Gábor

On 5/14/2018 4:07 AM, Fred Baker wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 27 May 2018 20:04:39 +0200

Hi Lencse,

Thanks a lot for your inputs.

I’ve read all your papers. Nice job.

Do you feel I’m missing anything in the document?

I’m planning a revised version of this document in 2-3 days, so it will be nice if the WG can provide any additional inputs.

Regards,

Jordi

De: v6ops <[email-masked]> en nombre de Lencse Gábor <[email-masked]>
Fecha: miércoles, 23 de mayo de 2018, 22:04
Para: <[email-masked]>
Asunto: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion

Dear Fred and Jordi,

If I my put my two cents in, I would like to point out that we have come to a very similar conclusion in Section 4.9 (titled "DNS and DNSSEC") of our paper below to the one presented in Section 2 of the draft. 

G. Lencse and Y. Kadobayashi, "Methodology for the identification of potential security issues of different IPv6 transition technologies: Threat analysis of DNS64 and stateful NAT64", Computers & Security (Elsevier), vol. 77, no. 1, pp. 397-411, September 1, 2018, DOI: 10.1016/j.cose.2018.04.012
Free access link valid until June 30: https://authors.elsevier.com/a/1X1K5c43ukegl
Revised version is available freely (as green open access) from my list of publications: http://www.hit.bme.hu/~lencse/publications/

Perhaps ISPs can use our benchmarking results when selecting DNS64 or NAT64 implementations.

As for DNS64, we have up to date performance information, which may be somewhat surprising concerning the performance problems of BIND. If you are interested, please check our results concerning the DNS64 performance of BIND, PowerDNS and Unbound:

G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Theory and Practice", Computer Communications (Elsevier), to be published

Revised version is available freely (as green open access) from my list of publications: http://www.hit.bme.hu/~lencse/publications/

As for stateful NAT64, we have only very old measurement results showing that OpenBSD PF outperformed TAYGA+iptables, which was not surprising at all, but those measurements were not RFC 8219 compliant, as RFC 8219 did not exist yet.

Best regards,

Gábor

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

---

From: Lencse Gábor <[email-masked]>
Date: Mon, 28 May 2018 21:14:16 +0200

Dear Jordi,

I would not say that anything is missing, but perhaps including some of 
our results about DNS64 would strengthen your draft. More specifically, 
I would suggest the following ones.

You wrote in Section 2:

    [...] So, the recursive name server actually
    lie to the client device, however in most of the cases, the client
    will not notice it, because generally they don't perform validation
    themselves as instead rely on their recursive name servers.

    If the client device performs DNSSEC validation on the AAAA record,
    it will fail as it is a synthesized record.

Here you may want to add something like:

The best possible scenario from DNSSEC point of view is when the client 
requests the DNS64 server to perform the DNSSEC validation (by setting 
the DO bit to 1 and the CD bit to 0). In this case, the DNS64 server 
validates the data thus tampering may only happen inside the DNS64 
server (which is considered as a trusted part, thus its likelihood is 
low) or between the DNS64 server and the client; all other parts of the 
system (including transmission and caching) are protected by DNSSEC. [1]

And just one nit. You wrote in at the end of Section 2:

    [...] Previous data seems to indicate, that
    the figures of DNSSEC broken by using DNS64 will be around 1.7%
    (information 2 years old).

It would be worth mentioning the source of this information. I think it 
is [2]. (We have taken the same information from there.)

IMHO, the 100%-1.7%=98.3% of the domains with no DNSSEC also deserve 
some discussion. We have performed the threat analysis of a system, 
which uses DNS64 [1]. From the many identified threats, cache poisoning 
is perhaps the most important one. It was a hot issue about 10 years ago 
[3]. Fortunately, the major DNS servers implemented the countermeasures 
against cache poisoning recommended by RFC 5452. We have also confirmed 
it regarding BIND, PowerDNS and Unbound [1].

I think the readers of the future RFC would benefit from benchmarking 
results of different NAT64 implementations. We are planning to compare 
the performances of the following ones:
- OpenBSD PF
- TAYGA+iptables
- Jool
- Ecdysis
We are going to start their stateless tests according to the dual DUT 
setup of RFC 8219 using an RFC 2544 compliant tester in June.
We are also planning to benchmark them  according to the single DUT 
setup of RFC 8219, but we need to wait for implementation of the Tester. 
(Unfortunately, I have no guarantee, when it will be ready, as it is 
done by one of my PhD students.)

What is the planned time frame of your draft?

I hope that our DNS64 server benchmarking results of BIND, PowerDNS and 
Unbound published in [4] may also be useful. (Perhaps the main 
performance numbers, the different scale up behaviors and the 
performance problem of BIND would be worth mentioning.)

And the references are:

[1] G. Lencse and Y. Kadobayashi, "Methodology for the identification of 

[2] J. Linkova, "Let’s talk about IPv6 DNS64 & DNSSEC", APNIC Blog 
(2016). https://blog.apnic.net/2016/06/09/lets-talk-ipv6-dns64-dnssec/

[3] CERT, “Multiple DNS implementations vulnerable to cache poisoning”, 
Vulnerability Note VU#800113 [Online].
Available: http://www.kb.cert.org/vuls/id/800113

[4] G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: 
Theory and Practice", /Computer Communications/ (Elsevier), in press, 
DOI: 10.1016/j.comcom.2018.05.005

So, what do you think of them?

And I would be happy to receive some feedback from various operators, 
whether they can use our results. Or perhaps what else should we 
measure, examine, analyze concerning the IPv6 transition technologies?

Best regards,

Gábor

5/27/2018 8:04 PM keltezéssel, JORDI PALET MARTINEZ írta:
> I’m planning a revised version of this document in 2-3 days, so it 
> will be nice if the WG can provide any additional inputs.
>
>
> Regards,
>
> Jordi
>
> *De: *v6ops <[email-masked]> en nombre de Lencse Gábor 
> <[email-masked]>
> *Fecha: *miércoles, 23 de mayo de 2018, 22:04
> *Para: *<[email-masked]>
> *Asunto: *Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion
>
> Dear Fred and Jordi,
>
> If I my put my two cents in, I would like to point out that we have 
> come to a very similar conclusion in Section 4.9 (titled "DNS and 
> DNSSEC") of our paper below to the one presented in Section 2 of the 
> draft.
>
> Revised version is available freely (as green open access) from my 
> list of publications: http://www.hit.bme.hu/~lencse/publications/ 
> <http://www.hit.bme.hu/%7Elencse/publications/>
>
> somewhat surprising concerning the performance problems of BIND. If 
> you are interested, please check our results concerning the DNS64 
> Revised version is available freely (as green open access) from my 
> list of publications: http://www.hit.bme.hu/~lencse/publications/ 
> <http://www.hit.bme.hu/%7Elencse/publications/>
>
> As for stateful NAT64, we have only very old measurement results 
> showing that OpenBSD PF outperformed TAYGA+iptables, which was not 
> surprising at all, but those measurements were not RFC 8219 compliant, 
> as RFC 8219 did not exist yet.
>
> Best regards,
>
> Gábor
>
>     Consideringhttps://tools.ietf.org/html/draft-palet-v6ops-nat64-deployment-00
>     <https://tools.ietf..org/html/draft-palet-v6ops-nat64-deployment-00>, discussed at IETF 101 using the slides athttps://datatracker.ietf.org/meeting/101/materials/slides-101-v6ops-nat64-deployment-guidelines-in-operator-and-enterprise-networks-00. I'd like to invite discussion on the list. What thoughts do folks have on this draft?
>
>
>
>
>     [email-masked] <mailto:[email-masked]>
>
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
>
> 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: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 29 May 2018 18:37:36 +0200

Hi Gabor,

I’ve included your suggested text for section 2 and the references 1 & 2. Thanks!

I’m trying to finish today a new version as I’m also taking care of some ID-Nits that will announce to the list.

See below, in line some more responses.

Saludos,

Jordi

De: v6ops <[email-masked]> en nombre de Lencse Gábor <[email-masked]>
Fecha: lunes, 28 de mayo de 2018, 21:15
Para: <[email-masked]>
Asunto: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion

Dear Jordi,

I would not say that anything is missing, but perhaps including some of our results about DNS64 would strengthen your draft. More specifically, I would suggest the following ones.

You wrote in Section 2:

The best possible scenario from DNSSEC point of view is when the client requests the DNS64 server to perform the DNSSEC validation (by setting the DO bit to 1 and the CD bit to 0). In this case, the DNS64 server validates the data thus tampering may only happen inside the DNS64 server (which is considered as a trusted part, thus its likelihood is low) or between the DNS64 server and the client; all other parts of the system (including transmission and caching)  are protected by DNSSEC. [1]

It would be worth mentioning the source of this information. I think it is [2]. (We have taken the same information from there.)

IMHO, the 100%-1.7%=98.3% of the domains with no DNSSEC also deserve some discussion. We have performed the threat analysis of a system, which uses DNS64 [1]. From the many identified threats, cache poisoning is perhaps the most important one. It was a hot issue about 10 years ago [3]. Fortunately, the major DNS servers implemented the countermeasures against cache poisoning recommended by RFC 5452. We have also confirmed it regarding BIND, PowerDNS and Unbound [1].

[Jordi] I think it will make sense to have one specific RFC based in your “Threat analysis of DNS64 and stateful NAT64”. Probably also one more with the benchmarking. It has been done in IETF many times, but not for NAT64 and DNS64.

I think the readers of the future RFC would benefit from benchmarking results of different NAT64 implementations. We are planning to compare the performances of the following ones:
- OpenBSD PF
- TAYGA+iptables
- Jool
- Ecdysis
We are going to start their stateless tests according to the dual DUT setup of RFC 8219 using an RFC 2544 compliant tester in June. 
We are also planning to benchmark them  according to the single DUT setup of RFC 8219, but we need to wait for implementation of the Tester. (Unfortunately, I have no guarantee, when it will be ready, as it is done by one of my PhD students.)

[Jordi] Agree, it will be good to have the benchmarking. I’m using mainly Jool with either Ubuntu or OpenWRT, and very happy. Regarding the ID timing, is really difficult to say. As you know, only you actually said publicly that this is something useful, and this means is difficult to get it adopted as WG item, which will be the first step … If you have results that we can include in the document I will be happy to consider it, but do not worry too much because you can always work in a new specific ID.

I hope that our DNS64 server benchmarking results of BIND, PowerDNS and Unbound published in [4] may also be useful. (Perhaps the main performance numbers, the different scale up behaviors and the performance problem of BIND would be worth mentioning.)

And the references are:
  
[1] G. Lencse and Y. Kadobayashi, "Methodology for the identification of potential security issues of different IPv6 transition technologies: Threat analysis of DNS64 and stateful NAT64", Computers & Security (Elsevier), vol. 77, no. 1, pp. 397-411, September 1, 2018, DOI: 10.1016/j.cose.2018.04.012

[2] J. Linkova, "Let’s talk about IPv6 DNS64 & DNSSEC", APNIC Blog (2016). https://blog.apnic.net/2016/06/09/lets-talk-ipv6-dns64-dnssec/

[3] CERT, “Multiple DNS implementations vulnerable to cache poisoning”, Vulnerability Note VU#800113 [Online]. 
Available: http://www.kb.cert.org/vuls/id/800113 

[4] G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Theory and Practice", Computer Communications (Elsevier), in press, DOI: 10.1016/j.comcom.2018.05.005

[Jordi] I’ve read all your documents, a quick read at the moment, and definitively I will invest more time during the weekend to read them.

And I would be happy to receive some feedback from various operators, whether they can use our results. Or perhaps what else should we measure, examine, analyze concerning the IPv6 transition technologies?

[Jordi] I will suggest that you open a new thread in v6ops to encourage people to read your documents (When you ask them to contribute at the end of an email about my ID, probably the end of your email is not being read …), I think they are really useful, and may be look for people interested in contributing to that work as well, or even possible co-authors for IDs (I will be happy to contribute depending on my workload …). We need to check if this is in the scope of v6ops or if there are other more appropriate WGs.

Best regards,

Gábor

Hi Lencse,

Regards,

Jordi

Dear Fred and Jordi,

Best regards,

Gábor

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 29 May 2018 13:57:09 -0400

Hi,

> Considering https://tools.ietf.org/html/draft-palet-v6ops-nat64-deployment-00, discussed at IETF 101 using the slides at https://datatracker.ietf.org/meeting/101/materials/slides-101-v6ops-nat64-de…

Thanks for asking.

I have read the draft.

In section 2, I find this claim bizarre:

   If a device connected to an IPv6-only WAN queries for a domain name
   in a signed zone, by means of a recursive name server that supports
   DNS64, and the result is a synthesized AAAA record, and the recursive
   name server is configured to perform DNSSEC validation and has a
   valid chain of trust to the zone in question, it will
   cryptographically validate the negative response from the
   authoritative name server.  So, the recursive name server actually
   lie to the client device,

Of course they are "lying" to the client: that's literally the
feature.  What the DNS64 mechanism does is give you answers for a AAAA
record when you otherwise wouldn't get one.  And indeed, a validating
DNS64 resolver can give you that synthetic AAAA with greater
confidence, having validated that the AAAA really for sure doesn't
exist.

Similarly,

This is only true if the "client device" is NAT64-oblivious.  That
point is made at some length in RFC 6147, in sections 3, 5.5, and 6.2.
It isn't like we didn't think about this.  Essentially all of section
2 is covered at length in RFC 6147; and the "obvious solution"
contained in this section is rather non-obvious to me, given that such
a requirement is both beyond the means of the person who has the
problem and also, in fact, the very problem NAT64/DNS64 is trying to
mitigate.  Indeed, if the solution were just, "Everyone should deploy
IPv6," we wouldn't need NAT64/DNS64 at all.

When we wrote DNS64, we made the assumption (which I think we made
clear in RFC 6147) that it was sufficiently early in the
validator-deployment curve that it would be ok to break certain DNSSEC
assumptions for people who were really stuck in a NAT64/DNS64-needing
world.  Validators could come to know about NAT64, could perform the
necessary discovery, and could do their own synthesis.  This is why we
overloaded the CD bit.  (I am aware that Mark Andrews hated that
decision, but it was the only one on offer unless we wanted to do
multiple round trips for every one of these cases -- something I still
think would have been a bad idea.  And it was the WG consensus; Mark
was in the rough.)

In section 3, there are some arguments for deployment scenarios that
are explicitly ruled out by NAT64/DNS64.  In particular, if 3.a. is
true then the validating resolvers need to be DNS64-aware too (as RFC
6147 pointed out); if not, then they can't validate.  3.b. was always
a known issue with NAT64/DNS64, and my position then (and now) was
that we weren't trying to make this perfect, we were trying to
mitigate pain.  I have been pleasantly surprised by the success of RFC
6877, which seems to me to be a partial answer to the limitations of
NAT64/DNS64.  But I did not believe then, and I do not believe now,
that we should make the transition services perfect.  We need to make
them just good enough that most things mostly work, and rely on
commercial pressure (particularly from lousy performance) to ensure
that people who are IPv4 only get the message.

Section 3.1 describes a case that simply doesn't work: the whole point
of publishing NAT64 and DNS64 together was to make complementary
things that worked together.  I am struggling to imagine what
conceivable value this would be (or in what world random authoritative
servers on the Internet are going to configure synthetic records for
everyone else).

In general, I find the use cases to be improbable.  Anyone who is
willing to go to the effort of deploying NAT64 or 464XLAT is going to
be able to deploy DNS64 too.  Virtually nobody is doing DNSSEC
validation in endpoints even today, and virtually everyone who is has
the capacity to do synthesis themselves as well.

So, I don't really understand what the document is trying to do.  I
think it would be useful to tell people, "If you're going to deploy
NAT64, you need DNS64, and here are some limitations."  This document
seems instead to pretend that there are some sorts of mitigations for
most of these issues, some of which appear to involve getting other
people on the Internet to do things.  I don't see how it helps any
transition, and I don't see how it helps people trying to deploy
NAT64+DNS64 to cloud the water with a bunch of scenarios that won't
work and were never expected to work.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 29 May 2018 20:27:29 +0200

Hi Andrew,

Thanks for reading and contributing.

Let me provide some background of this document.

It started as "464XLAT Deployment Guidelines in Operator Networks" (draft-palet-v6ops-464xlat-deployment-00), because we have many deployments, as you mention of 464XLAT, but not clear guidelines, and even we had a discussion in the IETF general area about offering only NAT64 in our network by default, etc., while I was suggesting 464XLAT. Also, unfortunately, I realized that being the transition mechanism that has been more successful is only informational.

When I presented it in the WG (I think it was in Singapore), the WG told me that what we need is a similar document for NAT64 scenarios ... and here we are.

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.

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.

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.

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 recall having seen other IETF documents doing the same (looking into all the possible cases and then discarding some). Same for your comments about section 3, etc.

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've no problem to add text, to more explicitly say "If you're going to deploy NAT64, you need DNS64, and here are some limitations".

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.

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?

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Andrew Sullivan <[email-masked]>
Fecha: martes, 29 de mayo de 2018, 19:58
Para: <[email-masked]>
Asunto: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion

    Hi,

    Thanks for asking.
    
    I have read the draft.

    
    
    Similarly,

    

    

    Best regards,
    
    A
    
    -- 
    Andrew Sullivan
    [email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 29 May 2018 15:37:36 -0400

Hi,

> 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, t…

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, whe…

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+DN…

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]

---

From: Lee Howard <[email-masked]>
Date: Tue, 29 May 2018 16:03:30 -0400

> 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, t…

This statement is too broad in several ways.
"Operators" may use 2G, 3G, LTE, fixed wireless, DSL, FTTH, DOCSIS, PON, 
Wi-Fi, or local Ethernet.
They may serve different kinds of customers, including their enterprise 
users, homes, businesses, mobile handsets, mobile tablets, hospitality, 
retail Wi-Fi. Some of those cases may not require IPv4 at the host, or 
even the app. Even in a heterogeneous network, an operator may prefer to 
offer NAT64 only to some customers, and native dual-stack to others, 
rather than requiring a CLAT of all of them.
To say that existing customers have IPv4-only requirements is true for a 
specific subset of the kinds of networks and the endpoints served. 
IPv6-only may work, or NAT64 may work.

Further, as far as I can tell, MAP solves as many use cases, with as 
much scale, as 464xlat. DS-Lite also solves the use cases, but maybe not 
at the same scale. And so on.

For the sake of this document, I agree that NAT64 is the focus, and CLAT 
provides a useful reference, but it is not the only way to deploy NAT64.

> I've no problem to add text, to more explicitly say "If you're going to deploy NAT64, you need DNS64, and here are some limitations".

That would be better. Experience suggests that anyone deploying NAT64 
and/or 464xlat will deploy DNS64 too, so explicit exceptions would be nice.

> 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+DN…

I don't agree with that, as I said above.
> Jordi
Lee

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 29 May 2018 22:26:48 +0200

Thanks again for your detailed responses. I will work in the next few days in a very in-depth review, this has been very helpful.

See below, in-line.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Andrew Sullivan <[email-masked]>
Fecha: martes, 29 de mayo de 2018, 21:38
Para: <[email-masked]>
Asunto: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion

    Hi,

    

I see your point. The question is the operators want to avoid, at all means, user complains, so if you want to make it "perfect", you may prefer more translations, but not breaking DNSSEC. Anyway, I will try to find a way to suggest that you need to determine in your own case if DNSSEC is going to be a problem for your customers and possible alternatives such ACL for specific customers, etc.

    

Your review is the first "complete" one. A couple of people provided inputs in specific sections ...

Definitively I'm going to work in a new version carefully observing all your inputs. Thanks again. I wish having so many inputs in every document that we have in v6ops, but unfortunately is not happening.

Right, I will clasify them in different "sub-sections" to make it very clear. Probably will use some tables to make a summary.

    

    

I didn't write correctly the best example for you to answer this question. Basically, what I wanted to ask is NAT64+DNS64 vs NAT64+DNS64+CLAT.
    
    Best regards,
    
    A
    
    -- 
    Andrew Sullivan
    [email-masked]

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 29 May 2018 22:44:09 +0200

Hi Lee,

Responses below in-line.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Lee Howard <[email-masked]>
Fecha: martes, 29 de mayo de 2018, 22:06
Para: <[email-masked]>
Asunto: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion

    

If the CE supports CLAT, but is getting dual stack in the WAN, then CLAT should not be used, so the operator will make sure that those customers have a different information by means of the provisioning or whatever. Nevertheless, I think this is out of the scope of this document (draft-ietf-v6ops-transition-ipv4aas is probably the most appropriate for that).

  
Agree, but my comment was in the scope of "if you want to use NAT64, you better do 464XLAT". But still yes, this need to be better qualified, as that sentence only makes sense if you still need to provide "dual-stack" inside the customer CE.  

Today I believe is difficult to find cases that differ from "if you want to use NAT64, you better do 464XLAT ": almost every residential and business customer of every ISP in the world still has the need to have support for IPv4-only devices and apps. This will change in the next years? Yes, for sure.

    
    
    Lee

---

From: Fred Baker <[email-masked]>
Date: Wed, 30 May 2018 03:10:29 +0200

Lee, Andrew, others...

Question for you. Jordi is working to make this a useful document. Your comments tell me that while at one level you disagree with statements he is making, at another level it is important to get the statements right and *say*them* as a body. Which is to say, treat this as a working group document.

Are you, specifically, in favor of adopting this as a working group document (e.g., working on it to get it right and publishing it)? More generally, is that our view as a working group? 

> On May 29, 2018, at 10:26 PM, JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:
> 
> Thanks again for your detailed responses.