Subject: [v6ops] draft-byrne-v6ops-dnssecaaaa

From: Ron Bonica <[email-masked]>
Date: Wed, 5 Sep 2018 15:28:39 +0000

Folks,

Each week between now and IETF 103, we will review and discuss one draft with an eye towards progressing it.

This week, please review and comment on draft-byrne-v6ops-dnssecaaaa.

                                      Fred and Ron

---

From: Lencse Gábor <[email-masked]>
Date: Wed, 5 Sep 2018 19:52:35 +0200

Dear All,

I have read the draft and I agree both with its intention to reconcile 
DNS64 and DNSSEC and also with the recommended solution.

I have found one nit:

    DNS64 is a key part of widely deployed IPv6-only transition mechanism
    such as 464XLAT [RFC6877 <https://tools.ietf.org/html/rfc6877>] and Happy Eyeballs Version 2 [RFC8305 <https://tools.ietf.org/html/rfc8305>].

Maybe I misunderstand something, but I think DNS64 is _not a part of_ 
464XLAT. Of course they can be used together in a sense that:
- native IPv6 clients communicate with native IPv6 servers using native IPv6
- native IPv6 clients communicate with IPv4 only servers using DNS64 + 
stateful NAT64
- IPv4 only applications/clients in an "IPv6 only environment" (where 
only IPv6 is used in the ISP core network) communicate with IPv4 servers 
using 464XLAT
Thus the two solutions (DNS64 and 464XLAT) can complement each other 
well, but DNS64 is not a part of 464XLAT.

Best regards,

Gábor Lencse

9/5/2018 5:28 PM keltezéssel, Ron Bonica írta:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Ca By <[email-masked]>
Date: Wed, 5 Sep 2018 11:07:00 -0700

On Wed, Sep 5, 2018 at 10:53 AM Lencse Gábor <[email-masked]> wrote:

> Maybe I misunderstand something, but I think DNS64 is *not a part of*
> - IPv4 only applications/clients in an "IPv6 only environment" (where only
> IPv6 is used in the ISP core network) communicate with IPv4 servers using
> 464XLAT
> Thus the two solutions (DNS64 and 464XLAT) can complement each other well,
> but DNS64 is not a part of 464XLAT.
>
> Best regards,
>
> Gábor Lencse
>

The key word is *widely deployed*

The largest 464xlat deployments use dns64

> v6ops mailing [email-masked]://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: Ole Troan <[email-masked]>
Date: Wed, 5 Sep 2018 20:34:41 +0200

> On 5 Sep 2018, at 20:07, Ca By <[email-masked]> wrote:
> 

Why wouldn’t you more precisely refer to that as a nat64+dns64 deployment and a 464xlat deployment? Sharing the NAT64. 

Ole

---

From: Lee Howard <[email-masked]>
Date: Wed, 5 Sep 2018 16:34:20 -0400

I think this document should be BCP, not Informational.

Section 2

s/mechanism/mechanisms in the first instance in the first sentence.

How is HEv2 a transition mechanism?

I'd rephrase to say, "DNS64 is a key part of widely deployed IPv6-only 
transition mechanisms, including several large 464xlat [RFC6877] 
deployments, and all NAT64 deployments." I think that clarifies that 
we're talking about specific deployments here.

Since the discussion of DNSSEC in RFC6147 is so brief, I think it's 
worth discussing here, so the explanation of why it is an insufficient 
workaround is sufficient. I'd like to replace the last sentence of 
section 2 with a new paragraph:

RFC6147 ("DNSSEC") outlines how validation may occur in the presence of 
DNSSEC:

An existing DNSSEC validator (i.e., one that is unaware of DNS64)

    might reject all the data that comes from DNS64 as having been
    tampered with (even if it did not set CD when querying).  If it is
    necessary to have validation behind the DNS64, then the validator
    must know how to perform the DNS64 function itself.  Alternatively,
    the validating host may establish a trusted connection with a DNS64,
    and allow the DNS64 recursive resolver to do all validation on its
    behalf. [RFC6147 - DNS64]

However, the domain administrator has no control over the client doing 
the validating, and clients (or their validating resolvers) cannot be 
expected to know about the presence of DNS64 a priori. Clients who might 
trust an authoritative name server for some content may not be as 
trusting of their carrier's DNS64 server.

Section 3

s/to changes/to change
s/not recommend/not recommended
To soften the blow, I'd suggest adding a sentence, after "in tandem."  
"The IPv6 deployment may be as light weight as a translator, such as 
SIIT-DC [RFC7755]."

There's more I'd add to the document, and it's the "So what?"

For instance, in Security Considerations:
"If clients trust RRs that fail validation (because they were invented 
by an DNS64 server), there is increased risk that they will trust other 
RRs that fail validation. Further, a compromised or hostile 
man-in-the-middle DNS64 server will be undetected, despite DNSSEC signing."
In Section 2, I admit I don't know what a client actually sees, if 
anything. Do browsers or other applications warn that a name failed 
validation? I'm sure I can test it tomorrow. I don't know how to inform 
users or their content providers that "This record cannot be guaranteed 
to be accurate, since it failed DNS Security validation. It appears to 
be a synthetic record, since the name only has an IPv4 record."

Even though my comments are longer than the draft, I like this effort, 
and wish I had initiated it.

Lee

---

From: Ca By <[email-masked]>
Date: Wed, 5 Sep 2018 14:33:00 -0700

On Wed, Sep 5, 2018 at 11:34 AM Ole Troan <[email-masked]> wrote:

> Why wouldn’t you more precisely refer to that as a nat64+dns64 deployment
> and a 464xlat deployment? Sharing the NAT64.
>
> Ole

I believe the document is about dns64. There is a statement in the i-d that
there exist dns64 deployments that are  large that happen to be 464xlat ,
to provide context to the reader. The reader would properly assume a large
dns64/nat64-only deployment would be laughable.

---

From: Erik Nygren <[email-masked]>
Date: Wed, 5 Sep 2018 17:50:44 -0400

DNSSEC isn't the only threat here.  Clients implementing protocols such as
DoH also bypass the DNS64.
draft-ietf-doh-dns-over-https-14 does say:

   Local policy considerations and similar factors mean different DNS
   servers may provide different results to the same query, for instance
   in split DNS configurations [RFC6950].  It logically follows that the
   server that is queried can influence the end result.  Therefore a
   client's choice of DNS server may affect the responses it gets to its
   queries.  For example, in the case of DNS64 [RFC6147], the choice
   could affect whether IPv6/IPv4 translation will work at all.

I'm not sure what the best way to approach this is in this draft.  For
example:

* Acknowledge that DNS64 is a shortish-term hack that only works in
constrained environments.     If this is the case, that might argue that
this draft should be at most Informational and not BCP?

* Commit to DNS64 being a robust part of the architecture and cover topics
more broadly than just DNSSEC?   Is there a way to handle the DOH case
short of mandating that clients implementing DOH also do bump-in-the-API or
client-side DNS64 synthesis or 464xlat?  If this is the case, should there
be more firm wording in draft-ietf-doh-dns-over-https-14.  I suspect other
conflicts will also appear over time.

Is there really value in picking some middle ground between these?

Is there concrete data on how often DNSSEC and DNS64 cause interaction
issues and where?  They shouldn't on the recursive resolver itself.  How
often are clients redoing DNSSEC validation and running into issues here?

A separate pragmatic/cynic question is whether we think this will influence
behavior?  I don't have a positive feeling that those who control whether a
zone has DNSSEC enabled also have control over whether AAAA records are
present for dual-stacked content in the zone.  Those are often separate
actors.  Will a recommendation here have any substantive impact, and is
there an audience who will be able to take action on this?

       Erik

---

From: David Farmer <[email-masked]>
Date: Wed, 5 Sep 2018 16:55:33 -0500

I like this draft, I also agree with Lee's suggestions, I was going to make
one or two of them myself. I think changing it to BCP is a great idea and
making it a normative recommendation too boot. It probably wouldn't hurt to
pass it by the DNS guys too. It is really both an IPv6 and DNS (DNSSEC) BCP.

One comment below.

> I think this document should be BCP, not Informational.
...

> "If clients trust RRs that fail validation (because they were invented by
> an DNS64 server), there is increased risk that they will trust other RRs
> that fail validation. Further, a compromised or hostile man-in-the-middle
> DNS64 server will be undetected, despite DNSSEC signing."
> validation?

I use a browser plugin, it gives you a green icon if DNSSEC validates. It
is grey most of the time as most sites don't do DNSSEC signing. RED icon if
DNSSEC is invalid.  To be honest I don't pay as much attention to it as I
should since it is grey most of the time.

https://www.dnssec-validator.cz/

> I'm sure I can test it tomorrow. I don't know how to inform users or their
> content providers that "This record cannot be guaranteed to be accurate,
> since it failed DNS Security validation. It appears to be a synthetic
> record, since the name only has an IPv4 record."
>

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 06 Sep 2018 09:14:31 +1100

I’ve a similar document in sunset4.

Maybe we want to combine both of them, now that sunset4 is sleeping ...

https://tools.ietf.org/html/draft-palet-sunset4-ipv6-ready-dns-00

Regards,

Jordi

De: v6ops <[email-masked]> en nombre de Lee Howard <[email-masked]>
Fecha: jueves, 6 de septiembre de 2018, 7:35
Para: <[email-masked]>
Asunto: Re: [v6ops] draft-byrne-v6ops-dnssecaaaa

Section 2

I'd rephrase to say, "DNS64 is a key part of widely deployed IPv6-only transition mechanisms, including several large 464xlat [RFC6877] deployments, and all NAT64 deployments." I think that clarifies that we're talking about specific deployments here.

Since the discussion of DNSSEC in RFC6147 is so brief, I think it's worth discussing here, so the explanation of why it is an insufficient workaround is sufficient. I'd like to replace the last sentence of section 2 with a new paragraph:

RFC6147 ("DNSSEC") outlines how validation may occur in the presence of DNSSEC:

However, the domain administrator has no control over the client doing the validating, and clients (or their validating resolvers) cannot be expected to know about the presence of DNS64 a priori. Clients who might trust an authoritative name server for some content may not be as trusting of their carrier's DNS64 server.

Section 3

s/to changes/to change
s/not recommend/not recommended
To soften the blow, I'd suggest adding a sentence, after "in tandem."  "The IPv6 deployment may be as light weight as a translator, such as SIIT-DC [RFC7755]."

For instance, in Security Considerations:
"If clients trust RRs that fail validation (because they were invented by an DNS64 server), there is increased risk that they will trust other RRs that fail validation. Further, a compromised or hostile man-in-the-middle DNS64 server will be undetected, despite DNSSEC signing."
In Section 2, I admit I don't know what a client actually sees, if anything. Do browsers or other applications warn that a name failed validation? I'm sure I can test it tomorrow. I don't know how to inform users or their content providers that "This record cannot be guaranteed to be accurate, since it failed DNS Security validation. It appears to be a synthetic record, since the name only has an IPv4 record."

Even though my comments are longer than the draft, I like this effort, and wish I had initiated it.

Lee

 
 
                                      Fred and Ron

_______________________________________________ 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: Lee Howard <[email-masked]>
Date: Thu, 6 Sep 2018 12:20:05 -0400

On 09/05/2018 05:50 PM, Erik Nygren wrote:
> DNSSEC isn't the only threat here.  Clients implementing protocols 
> such as DoH also bypass the DNS64.
> I'm not sure what the best way to approach this is in this draft.

Yes, I remember reading that in DoH and rolling my eyes. The best 
response is to strengthen the statement in that draft to say, "Hundreds 
of millions of users behind DNS64 will be unable to use DoH, unless IPv6 
resource records are available, bypassing the DNS64 function." And maybe 
to point at this draft.

I note that no OpsDir review has been submitted 
https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/
This is an operational issue.

> For example:
> constrained environments.     If this is the case, that might argue 
> that this draft should be at most Informational and not BCP?

"Constrained environments" in this case meaning "the IPv4 Internet."
This draft is BCP for domains with DNSSEC. It makes no recommendation 
for DNS64 deployers.
>
> * Commit to DNS64 being a robust part of the architecture and cover 
> topics more broadly than just DNSSEC?   Is there a way to handle the 
> DOH case short of mandating that clients implementing DOH also do 
> bump-in-the-API or client-side DNS64 synthesis or 464xlat?  If this is 
> the case, should there be more firm wording in 
> draft-ietf-doh-dns-over-https-14.  I suspect other conflicts will also 
> appear over time.

I wouldn't call it "robust," but I'd call it "widespread." I support 
your suggestion that the BCP be applied more broadly, although it may 
start to become redundant with BCP177 (rfc6540, "IPv6 Support Required 
for All IPv6-Capable Nodes").

> issues and where?  They shouldn't on the recursive resolver itself.  
> How often are clients redoing DNSSEC validation and running into 
> issues here?
>
> A separate pragmatic/cynic question is whether we think this will 
> influence behavior?  I don't have a positive feeling that those who 
> control whether a zone has DNSSEC enabled also have control over 
> whether AAAA records are present for dual-stacked content in the 
> zone.  Those are often separate actors.  Will a recommendation here 
> have any substantive impact, and is there an audience who will be able 
> to take action on this?

I think this problem is largely unnoticed, and needs a recommendation to 
address it. It may be unnoticed because the 15% of domains that use 
DNSSEC [https://stats.labs.apnic.net/dnssec/XA?c=XA&x=1&g=1&r=1&w=7&g=0] 
are more likely to be among the 24% of domains that have IPv6 
[http://www.employees.org/~dwing/aaaa-stats/]  (or the other way around) 
because the operators are early adopters.

Lee

>
>        Erik
>
>   
>
> On Wed, Sep 5, 2018 at 11:29 AM Ron Bonica <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Folks,
>
>     Each week between now and IETF 103, we will review and discuss one
>     draft with an eye towards progressing it.
>
>     [email-masked] <mailto:[email-masked]>

---

From: Mark Andrews <[email-masked]>
Date: Fri, 7 Sep 2018 09:42:07 +1000

Can we please have some technological leadership in the IETF and
say that DNS64 is technically flawed for a number of reason and
SHOULD NOT be used.  It was a short term hack that really has
out lived its usefulness.  Just because cell phone account software
couldn’t unwrap a IPv4 in IPv6 packet to do accounting was NOT
a good reason to inflict DNS64 long term on the Internet.  Just
because 3GPP was too scared to deploy DS-Lite was NOT a a good
reason to inflict DNS64 long term on the Internet.

You can get all the benefits of DNS64 by putting the mapping in
getaddrinfo() after advising the node what the NAT64 mapping is.

There is NO NEED to do in the mapping in the name server.  DNS64
was presented as a SHORT TERM solution.

* DNS64 does not work with DNSSEC.  Even IANA can’t setup IPV4ONLY.ARPA
to make it work correctly with DNS64 as IANA has signed IPV4ONLY.ARPA
and won’t remove the signatures without a RFC and we all know how long
that process takes.

* DNS64 does not work with iterative resolvers on nodes.

* DNS64 does not work with external recursive servers.

It has always been a flawed technology that was deployed as a stop-gap.

Stop trying to get the rest of the internet to change because some
sites are continuing to deploy DNS64 which is what this draft does.
That is the tail wagging the dog.

Similarly IPV4ONLY.ARPA as a NAT64 prefix discovery mechanism is
technically flawed even after IANA fixes the DNSSEC issues.

* IPV4ONLY.ARPA does not work with iterative resolvers on nodes.

* IPV4ONLY.ARPA does not work with external recursive servers.

DS-Lite has a mechanism to distribute the mapping information to
every node.

MAP-T and MAP-E have mechanisms to distribute the mapping
information to every node.  The existing NAT64 boxes can be used
with MAP-T.

Mark

> On 7 Sep 2018, at 2:20 am, Lee Howard <[email-masked]> wrote:
> 
> 
> 
>> DNSSEC isn't the only threat here.  Clients implementing protocols such as DoH also bypass the DNS64.
> Yes, I remember reading that in DoH and rolling my eyes. The best response is to strengthen the statement in that draft to say, "Hundreds of millions of users behind DNS64 will be unable to use DoH, unless IPv6 resource records are available, bypassing the DNS64 function." And maybe to point at this draft.
> 
> I note that no OpsDir review has been submitted https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/
>> * Acknowledge that DNS64 is a shortish-term hack that only works in constrained environments.     If this is the case, that might argue that this draft should be at most Informational and not BCP? 
> 
> This draft is BCP for domains with DNSSEC. It makes no recommendation for DNS64 deployers.
>> 
>> * Commit to DNS64 being a robust part of the architecture and cover topics more broadly than just DNSSEC?   Is there a way to handle the DOH case short of mandating that clients implementing DOH also do bump-in-the-API or client-side DNS64 synthesis or 464xlat?  If this is the case, should there be more firm wording in draft-ietf-doh-dns-over-https-14.  I suspect other conflicts will also appear over time.
> 
> I wouldn't call it "robust," but I'd call it "widespread." I support your suggestion that the BCP be applied more broadly, although it may start to become redundant with BCP177 (rfc6540, "IPv6 Support Required for All IPv6-Capable Nodes").
> 
>> Is there concrete data on how often DNSSEC and DNS64 cause interaction issues and where?  They shouldn't on the recursive resolver itself.  How often are clients redoing DNSSEC validation and running into issues here?
>> 
>> A separate pragmatic/cynic question is whether we think this will influence behavior?  I don't have a positive feeling that those who control whether a zone has DNSSEC enabled also have control over whether AAAA records are present for dual-stacked content in the zone.  Those are often separate actors.  Will a recommendation here have any substantive impact, and is there an audience who will be able to take action on this?
> 
> I think this problem is largely unnoticed, and needs a recommendation to address it. It may be unnoticed because the 15% of domains that use DNSSEC [https://stats.labs.apnic.net/dnssec/XA?c=XA&x=1&g=1&r=1&w=7&g=0] are more likely to be among the 24% of domains that have IPv6 [http://www.employees.org/~dwing/aaaa-stats/]  (or the other way around) because the operators are early adopters. 
> 
> 
> Lee
> 
>> 
>>        Erik
>> 
>>  
>> 
>> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Fred Baker <[email-masked]>
Date: Thu, 6 Sep 2018 17:48:04 -0700

I think you're looking for https://tools.ietf.org/html/draft-pref64folks-6man-ra-pref64. Under discussion in 6man.

> On Sep 6, 2018, at 4:42 PM, Mark Andrews <[email-masked]> wrote:
> 

--------------------------------------------------------------------------------
The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...

---

From: Lee Howard <[email-masked]>
Date: Fri, 7 Sep 2018 09:53:27 -0400

On 09/06/2018 07:42 PM, Mark Andrews wrote:
> SHOULD NOT be used.

Technological leadership looks to you like telling operators they 
deployed their network wrong, and must change it.
To me, it looks like acknowledging advice from operators on how the 
Internet actually works, and identifying interoperability problems.

Technological leadership to me looks more like warning people about 
interoperability issues and how to avoid them. When that's as easy as 
following previous BCP advice (i.e., rfc6540: deploy IPv6), we are 
remaining entirely consistent.

If you want to deprecate DNS64, and therefore the other transition 
mechanisms that rely on it, that's a different draft. I would not 
support it at this time. If instead you want a draft that warns about 
interoperability problems when deploying DNS64, if it says something 
more than what is already in rfc6147 (DNS64) and this draft, I look 
forward to seeing it.

> It has always been a flawed technology that was deployed as a stop-gap.

That could be said for all transition technologies, and I eagerly await 
the day when they can be discarded.

> That is the tail wagging the dog.
I don't think this is "continuing to deploy DNS64" but "continuing to 
deploy DNSSEC when it won't work with existing DNS64."
Most operators I'm talking to are looking at more recent and stateless 
transition technologies. That doesn't get the hundreds of millions of 
folks off of the networks they're on.

In the case of DOH, that is an effort trying to get the Internet to 
change despite known interoperability problems.

Lee

---

From: Ole Troan <[email-masked]>
Date: Fri, 7 Sep 2018 16:12:13 +0200

Lee,

So not accepting Mark’s advice is just a trade-off between customer support calls and updating implementations to do local address synthesizing?
I would certainly make a few phone calls to my ISP if they forced my to use their DNS recursive resolvers.

Best regards,
Ole

> On 7 Sep 2018, at 15:53, Lee Howard <[email-masked]> wrote:
> 
> 
> 
> Technological leadership looks to you like telling operators they deployed their network wrong, and must change it.
> To me, it looks like acknowledging advice from operators on how the Internet actually works, and identifying interoperability problems.
> 
> Technological leadership to me looks more like warning people about interoperability issues and how to avoid them. When that's as easy as following previous BCP advice (i.e., rfc6540: deploy IPv6), we are remaining entirely consistent.
> 
> If you want to deprecate DNS64, and therefore the other transition mechanisms that rely on it, that's a different draft. I would not support it at this time. If instead you want a draft that warns about interoperability problems when deploying DNS64, if it says something more than what is already in rfc6147 (DNS64) and this draft, I look forward to seeing it.
> 
> That could be said for all transition technologies, and I eagerly await the day when they can be discarded.
> 
>> 
> I don't think this is "continuing to deploy DNS64" but "continuing to deploy DNSSEC when it won't work with existing DNS64."
> Most operators I'm talking to are looking at more recent and stateless transition technologies. That doesn't get the hundreds of millions of folks off of the networks they're on.
> 
> In the case of DOH, that is an effort trying to get the Internet to change despite known interoperability problems.
> 
> Lee
>

---

From: Ca By <[email-masked]>
Date: Fri, 7 Sep 2018 07:15:26 -0700

> folks off of the networks they're on.

There is no large scale (1M + subs)  stateless deployment, today, that i am
aware of.  Please correct me. It is 2018.

Meanwhile, ds-lite may be around 10M subs?

And things couched in stateful nat64 are 100s of Millions and growing.
Stateful nat44 10s of billions ?

There is nobody working today, or ever planned to be working, a 3gpp
stateless transition solution. That said, nobody in 3gpp worked a stateful
transition. V6ops simply threaded the needle given that 3gpp does not care
about ipv6.

So, now may be a good time to rebase your expectations and understanding of
the current state and trajectory of the ipv4 internet.

That said, please deploy ipv6, these problems are solved when ipv6 is e2e.

---

From: Lee Howard <[email-masked]>
Date: Fri, 7 Sep 2018 11:02:41 -0400

On 09/07/2018 10:15 AM, Ca By wrote:
>
>
> On Fri, Sep 7, 2018 at 6:54 AM Lee Howard <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>

> There is no large scale (1M + subs)  stateless deployment, today, that 
> i am aware of.  Please correct me. It is 2018.

https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO_7NK9vcVApc/edit#gid=0

Reliance Jio, a mobile carrier, has millions, maybe tens of millions 
behind MAP-T.
JPNE has a significant MAP-E, but I can't find a size estimate.
Charter is still in EFT with MAP-T, so not yet 1M.
CERNET told us about their MAP-T/MAP-E switch. 
https://tools.ietf.org/agenda/92/slides/slides-92-v6ops-3.pdf

So, while I agree that stateful transition technologies dwarf stateless, 
my anecdotal impression is that networks who are currently deciding 
between technologies are tending toward the stateless ones. That is not 
an indictment of decisions made by other operators.
> Meanwhile, ds-lite may be around 10M subs?
I'd guess a couple tens, not that it matters.

>
> And things couched in stateful nat64 are 100s of Millions and 
> growing.  Stateful nat44 10s of billions ?
>
> stateless transition solution. That said, nobody in 3gpp worked a 
> stateful transition. V6ops simply threaded the needle given that 3gpp 
> does not care about ipv6.
>
> So, now may be a good time to rebase your expectations and 
> understanding of the current state and trajectory of the ipv4 internet.
>

Are we not agreeing?

Lee

---

From: Lee Howard <[email-masked]>
Date: Fri, 7 Sep 2018 11:14:08 -0400

> I would certainly make a few phone calls to my ISP if they forced my to use their DNS recursive resolvers.

Network operators don't generally have the option of updating 
implementations to do local address synthesizing. That's an OS decision.

Fred pointed to the Pref64 draft, which provides part of Mark's 
suggestion. I don't know whether OS vendors will listen to it, and I 
don't know how many devices would get left behind even if they do 
provide updates.

Good luck with those calls. If my choice as an operator is to lose money 
providing IPv4 or lose money on support calls, I'm going with the method 
that loses the least money. If I can charge for IPv4 addresses (is that 
even possible in mobile networks?) maybe I'll offer that option instead.

We all agree that server operators should deploy IPv6, right? There's no 
doubt that it's Best Current Practice.
One of the reasons it's a Best Current Practice is that if they are 
using DNSSEC, there are interoperability problems with IPv4, 
specifically in some transition mechanisms.

Trying to develop alternative mechanisms and insisting network operators 
deploy those instead is wishful thinking and ignores the deployed 
Internet. The network operators have deployed IPv6: the content 
providers must, too, or risk problems. We can provide operational 
guidance about those potential problems.

Lee

---

From: Ca By <[email-masked]>
Date: Fri, 7 Sep 2018 09:31:58 -0700

>From the APNIC blog, Jio is a DOCSIS and Mobile provider. MAP-T is used in
the wireline side along with dual-stack.  But happy to learn specifics from
folks with first hand knowledge.

I would not say millions behind MAP-T without a citation. The blog you
linked to does not pin any particulars or scale or share for various
approaches.

> my anecdotal impression is that networks who are currently deciding between
> technologies are tending toward the stateless ones. That is not an
> indictment of decisions made by other operators.
>
>
> So, now may be a good time to rebase your expectations and understanding
> of the current state and trajectory of the ipv4 internet.
>

---

From: Ole Troan <[email-masked]>
Date: Fri, 7 Sep 2018 18:48:15 +0200

> On 7 Sep 2018, at 17:14, Lee Howard <[email-masked]> wrote:
> 
> We all agree that server operators should deploy IPv6, right? There's no doubt that it's Best Current Practice.

If you choose a mechanism that depends on a DNS64 in the network,  then deploying IPv6 doesn’t help. The enduser is still stuck with the ISPs recursive resolver. 

Ole

---

From: Lee Howard <[email-masked]>
Date: Fri, 7 Sep 2018 13:15:05 -0400

> If you choose a mechanism that depends on a DNS64 in the network,  then deploying IPv6 doesn’t help. The enduser is still stuck with the ISPs recursive resolver.

*chose*

Five or more years ago. The ship has sailed. The decision has been made, 
by multiple network operators, for hundreds of millions of users.

It is too late to un-make that decision.

The decision now is whether to advise other operators on potential 
interoperability issues. "If you deploy DNSSEC, we advise you to deploy 
IPv6 also, to avoid interoperability issues." We don't have an 
alternative that include time travel.

If, as you and Mark argue (I think), we decide not to issue such an 
advisory because we think we can improve DNS64/NAT64/464xlat, then we 
are accepting those interoperability issues until all vendors of network 
devices on those networks have implemented the new option, the operators 
have deployed it, and all vendors of OSes have implemented the new 
option, and have deployed it  (without leaving any devices behind).

IPv4-only DNSSEC deployments will suffer until all of that happens. I 
haven't seen numbers on how bad that is, i.e., how many devices in those 
IPv6+translation networks do their own validation.

DOH deployments will suffer until that happens. Per the DOH draft, "the 
choice [of DNS server] could affect whether IPv6/IPv4 translation will 
work at all." I think that means an IPv4-only server whose A record is 
provided over DOH will be unreachable by the hundreds of millions of 
devices relying on DNS64. That seems like a pretty important 
consideration for someone considering deploying DOH. If deploying IPv6 
means they have no problem, that's advice they might appreciate.

I'm sorry if you don't like using your ISP's resolver. For hundreds of 
millions, they choice is apparently between using their resolver or not 
being able to reach the IPv4 Internet. The way to minimize their pain is 
to reduce the IPv4-only Internet.

Lee

---

From: Ole Troan <[email-masked]>
Date: Fri, 7 Sep 2018 20:25:18 +0200

Lee,

> Five or more years ago. The ship has sailed. The decision has been made, by multiple network operators, for hundreds of millions of users.

Just to be clear:
 MAP-E, MAP-T, LW46, 464XLAT, DS-lite all offer dual stack service to the end-user and does not in any way depend on DNS64.

NAT64 and DNS64 is deployed, and sometimes in chort with 464XLAT.

Are you saying that there are hundreds of millions of users on IPv6 only networks with NAT64/DNS64 their only exit to the IPv4 Internet?
Where are these users? Cause I wasn’t aware of any general deployments of that to end-users.

Ole

> The decision now is whether to advise other operators on potential interoperability issues. "If you deploy DNSSEC, we advise you to deploy IPv6 also, to avoid interoperability issues." We don't have an alternative that include time travel.
> 
> If, as you and Mark argue (I think), we decide not to issue such an advisory because we think we can improve DNS64/NAT64/464xlat, then we are accepting those interoperability issues until all vendors of network devices on those networks have implemented the new option, the operators have deployed it, and all vendors of OSes have implemented the new option, and have deployed it  (without leaving any devices behind).
> 
> IPv4-only DNSSEC deployments will suffer until all of that happens. I haven't seen numbers on how bad that is, i.e., how many devices in those IPv6+translation networks do their own validation.
> 
> DOH deployments will suffer until that happens. Per the DOH draft, "the choice [of DNS server] could affect whether IPv6/IPv4 translation will work at all." I think that means an IPv4-only server whose A record is provided over DOH will be unreachable by the hundreds of millions of devices relying on DNS64. That seems like a pretty important consideration for someone considering deploying DOH. If deploying IPv6 means they have no problem, that's advice they might appreciate.
> 
> 
> I'm sorry if you don't like using your ISP's resolver. For hundreds of millions, they choice is apparently between using their resolver or not being able to reach the IPv4 Internet. The way to minimize their pain is to reduce the IPv4-only Internet.
> 
> Lee
> 
> 
> 
>> 
>> Ole
>

---

From: Gert Doering <[email-masked]>
Date: Fri, 7 Sep 2018 20:30:13 +0200

Hi,

On Fri, Sep 07, 2018 at 08:25:18PM +0200, Ole Troan wrote:
> Where are these users? Cause I wasn???t aware of any general deployments of that to end-users.

T-Mobile USA...?

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Lee Howard <[email-masked]>
Date: Fri, 7 Sep 2018 14:57:32 -0400

> Where are these users? Cause I wasn’t aware of any general deployments of that to end-users.

Am I saying it? I'm quoting the draft: "Currently, hundreds of millions 
of host rely on DNS64 for access to the internet. "

Since the draft author said, "I would not say millions behind MAP-T 
without a citation," 
[https://mailarchive.ietf.org/arch/msg/v6ops/ELX3IIOK136mRr6rWLS3plBRCqU], 
perhaps a citation for the "hundreds of millions" is needed in the 
draft. What do you think?

If, indeed, there are hundreds of millions of Internet users dependent 
on DNS64, would you agree that advice along the lines of this draft 
("expect problems if you dont' deploy IPv6") would be useful?

Lee

---

From: Kristian McColm <[email-masked]>
Date: Fri, 7 Sep 2018 19:01:06 +0000

Rogers Canada.. 
Orange Poland as well I believe..

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Gert Doering
Sent: September 7, 2018 14:30
To: Ole Troan <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] draft-byrne-v6ops-dnssecaaaa

Hi,

T-Mobile USA...?

Gert Doering
        -- NetMaster

---

From: Adam Roach <[email-masked]>
Date: Fri, 7 Sep 2018 14:24:00 -0500

Lee --

What you're describing is an issue that spans *all* Public DNS 
providers, regardless of whether they're DoT, DoH, or classic DNS. I 
believe that any operational advice that addresses the situation needs 
to be written in such a way that it speaks to all three cases, rather 
than being laser-focused on DoH. I don't want to speak for Warren or the 
DNSOPS chairs (copied), but this sounds to me like something that would 
best be resolved by a "Operational Considerations for Public DNS 
Servers" document.

/a

On 9/6/18 11:20 AM, Lee Howard wrote:
> response is to strengthen the statement in that draft to say, 
> "Hundreds of millions of users behind DNS64 will be unable to use DoH, 
> unless IPv6 resource records are available, bypassing the DNS64 
> function." And maybe to point at this draft.
>
>> bump-in-the-API or client-side DNS64 synthesis or 464xlat?  If this 
>> is the case, should there be more firm wording in 
>> draft-ietf-doh-dns-over-https-14.  I suspect other conflicts will 
>> also appear over time.
>
>> Is there concrete data on how often DNSSEC and DNS64 cause 
>> interaction issues and where?  They shouldn't on the recursive 
>> resolver itself.  How often are clients redoing DNSSEC validation and 
>> running into issues here?
>>
>> have any substantive impact, and is there an audience who will be 
>> able to take action on this?
>
> I think this problem is largely unnoticed, and needs a recommendation 
> to address it. It may be unnoticed because the 15% of domains that use 
> DNSSEC 
> [https://stats.labs.apnic.net/dnssec/XA?c=XA&x=1&g=1&r=1&w=7&g=0] are 
> more likely to be among the 24% of domains that have IPv6 
> [http://www.employees.org/~dwing/aaaa-stats/] (or the other way 
> around) because the operators are early adopters.
>
>
> Lee
>
>>
>>        Erik
>>
>>   
>>
>>     Each week between now and IETF 103, we will review and discuss
>>     one draft with an eye towards progressing it.
>>

---

From: Ole Troan <[email-masked]>
Date: Fri, 7 Sep 2018 21:25:57 +0200

> On 7 Sep 2018, at 21:01, Kristian McColm <[email-masked]> wrote:
> 
> Rogers Canada.. 

Do you have a detailed service description?
If I recall correctly T-Mobile offers dual stack when tethering, but possibly nat64 for local mobile applications. But note this device is tightly controlled and could of course do address synthesis. 

Ole

---

From: Kristian McColm <[email-masked]>
Date: Fri, 7 Sep 2018 19:46:28 +0000

Not sure how detailed you are looking for. Rogers is IPv6-only with DNS64/NAT64 for the main LTE APN and devices Android L and iPhone 6 and newer, but the tethering APN is still dual-stacked.

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] 
Sent: September 7, 2018 15:26
To: Kristian McColm <[email-masked]>
Cc: Gert Doering <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [v6ops] draft-byrne-v6ops-dnssecaaaa

Ole

---

From: Ole Troan <[email-masked]>
Date: Fri, 7 Sep 2018 22:35:28 +0200

> 
> Not sure how detailed you are looking for. Rogers is IPv6-only with DNS64/NAT64 for the main LTE APN and devices Android L and iPhone 6 and newer, but the tethering APN is still dual-stacked

Right, then we’re talking about a tightly controlled environment where SPs and handset manufacturers work closely together.
Not particularly difficult to argue that handsets should be able to synthesize addresses on the host in these cases. So why shouldn’t that be our recommendation?

Ole

---

From: Ca By <[email-masked]>
Date: Fri, 7 Sep 2018 14:09:38 -0700

On Fri, Sep 7, 2018 at 1:35 PM Ole Troan <[email-masked]> wrote:

>
> >
> > Not sure how detailed you are looking for. Rogers is IPv6-only with
> DNS64/NAT64 for the main LTE APN and devices Android L and iPhone 6 and
> newer, but the tethering APN is still dual-stacked
>
> Right, then we’re talking about a tightly controlled environment where SPs
> and handset manufacturers work closely together.
> Not particularly difficult to argue that handsets should be able to
> synthesize addresses on the host in these cases. So why shouldn’t that be
> our recommendation?
>

1. They discover the pref64 via rfc 7050 with dns64. There is no dhcp in
3gpp to the ue.  Dns64 must be present.

2.  Many 464xlat networks prefer the use of dns64 to avoid double
translation on the user plane.  This provides simplification and
performance benefits.

3. Nothing about 70+ million subscribers is tightly controlled, please do
not minimize the challenge

> > Cc: Gert Doering <[email-masked]>;
> [email-masked]; [email-masked]
> > If I recall correctly T-Mobile offers dual stack when tethering, but
> possibly nat64 for local mobile applications. But note this device is
> tightly controlled and could of course do address synthesis.
> >
> > Ole
> >
> >
> >>
> >>> Are you saying that there are hundreds of millions of users on IPv6
> only networks with NAT64/DNS64 their only exit to the IPv4 Internet?
> >> have you enabled IPv6 on
> <https://maps.google.com/?q=have+you+enabled+IPv6+on+&entry=gmail&source=g>something
> today...?
> >>

---

From: Mark Andrews <[email-masked]>
Date: Sat, 8 Sep 2018 16:22:52 +1000

> On 7 Sep 2018, at 11:53 pm, Lee Howard <[email-masked]> wrote:
> 
> 
> 

Yes, they got it WRONG. They just happed to GET AWAY WITH IT because they clients
where mainly very limited devices called CELL PHONES that don’t *generally* do DNSSEC,
nor do their own iterative DNS resolution, nor use DNS servers other than the ones
given to them over 3GPP (directly or indirectly).

Anyone that wants to do those things gets told “we don’t support that” from the
Telcos.

> Technological leadership to me looks more like warning people about interoperability issues and how to avoid them. When that's as easy as following previous BCP advice (i.e., rfc6540: deploy IPv6),…

You can’t avoid them with DNS64. The people deploying DNS64 are not the ones that
are running IPv4 only sites.

What advice do you give the site deploying DNS64 to make everything work?  Deploy
intercepting DNS proxies of which I’ve yet to see one that does even a semi-reasonable job.  No, you can’t just direct all the DNS queries at a recursive DNS server with DNS64 configured.  That doesn’t work for plain DNS let along DNS with DNS64 despite what
the snake oil vendors that off that sort of stuff claim.  I’ve had to turn off
full iterative servers too many times to work around the breakage of a ISP that
thinks intercepting DNS proxies are a good idea.

> That could be said for all transition technologies, and I eagerly await the day when they can be discarded.

It was deployed as a stop gap for other transition technologies. 3GPP said we want
something *NOW*!!!!  We have other transition technologies that have don’t have the
drawbacks of DNS64.  

> I don't think this is "continuing to deploy DNS64" but "continuing to deploy DNSSEC when it won't work with existing DNS64.”

It’s not just DNSSEC.  It’s you MUST use our name servers as we have deployed DNS64.

> In the case of DOH, that is an effort trying to get the Internet to change despite known interoperability problems.

DOH is just a example of what DNS64 breaks.  It is not the only thing.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 8 Sep 2018 16:36:04 +1000

> On 8 Sep 2018, at 1:14 am, Lee Howard <[email-masked]> wrote:
> 
> Network operators don't generally have the option of updating implementations to do local address synthesizing. That's an OS decision.

Operators can advertise DS-Lite, MAP-E, and MAP-T simultaneously while still doing DNS64.  Customers are not then stuck with DNS64.

> Fred pointed to the Pref64 draft, which provides part of Mark's suggestion. I don't know whether OS vendors will listen to it, and I don't know how many devices would get left behind even if they do provide updates.
> 
> Good luck with those calls. If my choice as an operator is to lose money providing IPv4 or lose money on support calls, I'm going with the method that loses the least money. If I can charge for IPv4 addresses (is that even possible in mobile networks?) maybe I'll offer that option instead.
> 
> One of the reasons it's a Best Current Practice is that if they are using DNSSEC, there are interoperability problems with IPv4, specifically in some transition mechanisms.
> 
> Trying to develop alternative mechanisms and insisting network operators deploy those instead is wishful thinking and ignores the deployed Internet. The network operators have deployed IPv6: the content providers must, too, or risk problems. We can provide operational guidance about those potential problems.

The best operational guidance we can give about DNS64 is make it HISTORIC.  It
is a protocol that should not see new deployments.

A lot of this is the IETF’s fault by not saying "Enough is enough" when it comes
to IPv4AAS mechanisms soon enough despite the incremental cost of each of them
being miniscule.

---

From: Fred Baker <[email-masked]>
Date: Mon, 10 Sep 2018 11:10:42 -0700

> On Sep 7, 2018, at 11:30 AM, Gert Doering <[email-masked]> wrote:
> 

Indeed. My telephone has only had an IPv6 address on its LTE interface for quite some time now.

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

---

From: Lencse Gábor <[email-masked]>
Date: Mon, 10 Sep 2018 21:06:15 +0200

Dear Fred,

I have just received an e-mail from my head of department with a list of 
topics for our students from a leading Hungarian ISP. One of them is: 
"IPv6-only mobile networks". :-)
As for IPv6 transition technologies to be considered, they mention only 
NAT64, DNS64 and 464XLAT (in this order).

Of course, I do not want to conclude from this single event that they 
would be better than any other IPv6 transition technologies, but I 
believe that it is still worth using them for new deployments.

BTW.: As for the advantages and disadvantages of the different IPv6 
transition technologies for providing IPv4aaS (namely: 464XLAT, DS-Lite, 
lw4o6, MAP-E, MAP-T) we have put together a table for crowd sourcing 
with Lee, Jordi and Richard. Unfortunately, it has not yet been 
finished, because I was too busy in this Summer, but I hope to send the 
link of the google spreadsheet to the v6ops mailing list within a few days.

However, I think that these IPv4aaS technologies may NOT substitute 
NAT64+DNS64 in a communication scenario when an IPv6 only client needs 
to communication with an IPv4 only server. Under an IPv6 only client, I 
mean a client, which does not have an IPv4 address or even IPv4 protocol 
stack. Why should we force anyone to use private IPv4 addresses, who 
does not want to do so?

I think, NAT64+DNS64 is the most appropriate solution for this 
communication scenario and draft-byrne-v6ops-dnssecaaaa is a good 
solution for the conflict of DNS64 and DNSSEC, therefore, I definitely 
support it.

Best regards,

Gábor

---

From: Mark Andrews <[email-masked]>
Date: Tue, 11 Sep 2018 06:56:26 +1000

Well 464XLAT has a IPv4 stack.

You can achieve the same effects as DNS64 in getaddrinfo if you publish the NAT64 prefix out side of the DNS.  The problem with DNS64 is that it modifies answers at the wrong place.  Recursive servers really aren’t the correct place no matter how attractive they seem. 

Getaddrinfo allows you to get mapped address back. DNS64 is just a different mapped address.

-- 
Mark Andrews

> On 11 Sep 2018, at 05:06, Lencse Gábor <[email-masked]> wrote:
> 
> Dear Fred,
> 
> I have just received an e-mail from my head of department with a list of topics for our students from a leading Hungarian ISP. One of them is: "IPv6-only mobile networks". :-)
> As for IPv6 transition technologies to be considered, they mention only NAT64, DNS64 and 464XLAT (in this order).
> 
> Of course, I do not want to conclude from this single event that they would be better than any other IPv6 transition technologies, but I believe that it is still worth using them for new deployments. 
> 
> BTW.: As for the advantages and disadvantages of the different IPv6 transition technologies for providing IPv4aaS (namely: 464XLAT, DS-Lite, lw4o6, MAP-E, MAP-T) we have put together a table for crowd sourcing with Lee, Jordi and Richard. Unfortunately, it has not yet been finished, because I was too busy in this Summer, but I hope to send the link of the google spreadsheet to the v6ops mailing list within a few days.
> 
> However, I think that these IPv4aaS technologies may NOT substitute NAT64+DNS64 in a communication scenario when an IPv6 only client needs to communication with an IPv4 only server. Under an IPv6 only client, I mean a client, which does not have an IPv4 address or even IPv4 protocol stack. Why should we force anyone to use private IPv4 addresses, who does not want to do so?
> 
> I think, NAT64+DNS64 is the most appropriate solution for this     communication scenario and draft-byrne-v6ops-dnssecaaaa is a good solution for the conflict of DNS64 and DNSSEC, therefore, I definitely support it.
> 
> Best regards,
> 
> Gábor
> 
> 
> 
>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 11 Sep 2018 07:59:58 +1000

Add in a RA and/or DHCP option with

<prefix-len> <prefix-bits> <aclname>

would do.  Where aclname points to a DNS name with a APL record (RFC 3123) that is
used to exclude AAAA and A records from the processing. If aclname is “.” then
you don’t lookup the APL RRset.  This move the DNS64 configuration from the
recursive server onto the network.  The DNS resolution path for aclname needs
to be completely resolvable from a IPv6-only client.

For reference this is the DNS64 configuration syntax for BIND.

        dns64 <netprefix> {
                break-dnssec <boolean>;
                clients { <address_match_element>; ... };
                exclude { <address_match_element>; ... };
                mapped { <address_match_element>; ... };
                recursive-only <boolean>;
                suffix <ipv6_address>;
        }; // may occur multiple times

clients is a no-op.  aclname covers exclude and mapped. recursive-only is a no-op.
break-dnssec is a no-op as all this happens after any DNSSEC processing.

Pick a different NAT64 prefix for this option so one can monitor client take up
of the use of this method.  Add the prefix advertised using DNS64 to the APL record
to prevent DNS64 modified AAAA records being used.

The only thing needed is a getaddrinfo flag to turn this on.  Add the flag to
the default set of flags.

Mark

> On 11 Sep 2018, at 6:56 am, Mark Andrews <[email-masked]> wrote:
>

---

From: Lee Howard <[email-masked]>
Date: Mon, 10 Sep 2018 19:15:54 -0400

I don't understand why you're working so hard to mark IPv4 work, when 
the clear answer is to deploy IPv6. It's not as if it's a surprise.

But fine, more questions inline. . .

> to be completely resolvable from a IPv6-only client.

rfc3123 was new to me. An experiment from 2001; I'd like to hear whether 
name servers other than BIND have implemented APL.

I'm really not following your proposal, so let me try to repeat it: The 
ISP Example provisions, using an as-yet-undescribed RA:
/24 192.0.2.0 example.net

The client then queries the example.net NS for an APL record, which 
provides the IPv6 prefix used for the NAT64 server. When it receives an 
A response, but no AAAA, to a query, it can then forward to the NAT64 
server.

How does an operator know whether to provision (whether RA or DHCPv6) 
the DNS64 nameserver or just a dual-stack resolver?
If a device has the above hack, you don't want it to use the DNS64 
because it'll never get an A record.
If it doesn't have it, it must have DNS64 to reach anything that's 
IPv4-only.

> break-dnssec is a no-op as all this happens after any DNSSEC processing.

I'm pretty lost. This is saying, "If the DNS query comes from 
<netprefix> then don't do DNS64" i.e., forward the A record and let the 
client sort it out.

> the default set of flags.

A getaddrinfo flag, an RA option, and a DHCPv6 option. This is 
fundamentally a new transition mechanism, using SIIT (as NAT64) again.

At what point do we stop trying to save IPv4-only operators from themselves?

Lee

---

From: Mark Andrews <[email-masked]>
Date: Tue, 11 Sep 2018 09:53:48 +1000

> On 11 Sep 2018, at 9:15 am, Lee Howard <[email-masked]> wrote:
> 
> I don't understand why you're working so hard to mark IPv4 work, when the clear answer is to deploy IPv6. It's not as if it's a surprise.
> 
> rfc3123 was new to me. An experiment from 2001; I'd like to hear whether name servers other than BIND have implemented APL.

Every single one as it is supported by UNKNOWN TYPES (RFC 3597) in nameservers that do not have type specific code for reading it from the master file.  STD13 recursive servers have ALWAYS supported it as they are supposed to treat unknown records as opaque blobs. People not understanding this in part lead to the myth that it was hard to deploy new types.

> I'm really not following your proposal, so let me try to repeat it: The ISP Example provisions, using an as-yet-undescribed RA:

Using the well known prefix as a example:

	96 64:ff9b:: nat64-rules.isp.com

> The client then queries the example.net NS for an APL record, which provides the IPv6 prefix used for the NAT64 server. When it receives an A response, but no AAAA, to a query, it can then forward to the NAT64 server.

It queries for AAAA target.example.com, A target.example.com and APL nat64-rules.isp.com.

It then uses those DNS responses along with prefix information from the RA/DHCPv6/… to construct struct addrinfo answers for getaddrinfo to return.

> How does an operator know whether to provision (whether RA or DHCPv6) the DNS64 nameserver or just a dual-stack resolver?

How did people decide when to only provision MX records rather than A and AAAA records to reach SMTP servers?  They made a judgement call.

I would use RFC 7050 with a ipv4only.arpa zone (not DNS64) and 464XLAT as the fallback mechanism for legacy devices and don’t deploy DNS64 at all.  That should work for the current crop of cell phones.  It should also work for CPE routers as 464XLAT support is effectively required for all ISPs deploying DNS64 in wireline scenarios today.

I would expect a CPE devices would be request this information on the upstream side and if it sees it, advertise it on the downstream side.  Similarly for cell phones when tethering.

> If a device has the above hack, you don't want it to use the DNS64 because it'll never get an A record.

DNS64 never stopped A records getting through.  All it does is modify some AAAA responses.

> If it doesn't have it, it must have DNS64 to reach anything that's IPv4-only.

Mark

> I'm pretty lost. This is saying, "If the DNS query comes from <netprefix> then don't do DNS64" i.e., forward the A record and let the client sort it out.
> 
>> 
> A getaddrinfo flag, an RA option, and a DHCPv6 option. This is fundamentally a new transition mechanism, using SIIT (as NAT64) again.
> 
> 
> 
> 
>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 11 Sep 2018 10:50:32 +1000

> I don't understand why you're working so hard to mark IPv4 work, when the clear answer is to deploy IPv6. It's not as if it's a surprise.

Because DNS64 hijacks all use of the DNS and prevents people people doing what they currently do with the DNS without a lot of specialised knowledge.

I’m trying to give DNS back to the customers.  If they want to be able to 1.1.1.1 or 8.8.8.8 as their recursive servers they should be able to.  If they want to run their own recursive nameservers they should be able to.  If they want to DNSSEC validate answers they get from their ISP they should be able to.  DNS64 breaks / makes doing this sort of thing extremely difficult.  I can manage it (even if I need to install a DNS server to achieve it) but most people can’t.

All the issues we are talking about with DNS64 today where known about and hand waved away when DNS64 was being published.  8 years later all that hand waving as people deploy beyond the trivial cell phone case is coming back to bite.

Mark

---

From: Ca By <[email-masked]>
Date: Mon, 10 Sep 2018 18:25:58 -0700

On Mon, Sep 10, 2018 at 5:51 PM Mark Andrews <[email-masked]> wrote:

> Because DNS64 hijacks all use of the DNS and prevents people people doing
> what they currently do with the DNS without a lot of specialised knowledge.
>
> I’m trying to give DNS back to the customers.  If they want to be able to
> 1.1.1.1 or 8.8.8.8 as their recursive servers they should be able to.  If
> they want to run their own recursive nameservers they should be able to.
> If they want to DNSSEC validate answers they get from their ISP they should
> be able to.  DNS64 breaks / makes doing this sort of thing extremely
> difficult.  I can manage it (even if I need to install a DNS server to
> achieve it) but most people can’t.
>
> All the issues we are talking about with DNS64 today where known about and
> hand waved away when DNS64 was being published.  8 years later all that
> hand waving as people deploy beyond the trivial cell phone case is coming
> back to bite.
>
> Mark

That’s your opinion and your values.

I deployed dns64 6 years ago. Very happy with results. I would deploy
again, 5 out of 5.

http://www.worldipv6launch.org/apps/ipv6week/measurement/images/graphs/T-MobileUSA.png

My view, and the i-d of referenced for this thread, all the dns64 ills go
away if you deploy ipv6, so please deploy ipv6.

And, dont expect ipv4 to work. IPv4 life support (nat, dns64, map, ...)
breaks ipv4 in various way.

CB

---

From: Mark Andrews <[email-masked]>
Date: Tue, 11 Sep 2018 11:40:03 +1000

> On 11 Sep 2018, at 11:25 am, Ca By <[email-masked]> wrote:
> 
> 
> 
> I deployed dns64 6 years ago. Very happy with results. I would deploy again, 5 out of 5. 
> 

You deployed to CELL PHONES which has a very RESTRICTED client base.  That it mostly “worked” with these very restricted clients is not news.  It also does not invalidate all the issues there are with DNS64.

> My view, and the i-d of referenced for this thread, all the dns64 ills go away if you deploy ipv6, so please deploy ipv6.

Your draft does NOTHING effective to address DNS64 issues.  It won’t speed up IPv6 deployment.  It won’t remove the issues clients of ISP’s that deploy DNS64 see especially wireline clients.

> And, dont expect ipv4 to work. IPv4 life support (nat, dns64, map, ...) breaks ipv4 in various way.

I never said it didn’t, but thank you for introducing red herring.

---

From: Ole Troan <[email-masked]>
Date: Tue, 11 Sep 2018 08:40:06 +0200

> On 11 Sep 2018, at 03:25, Ca By <[email-masked]> wrote:
> 

If everyone everywhere deployed IPv6, then yes. 
But until then, this creates problems for IPv6 hosts. 

Cheers 
Ole

---

From: Ca By <[email-masked]>
Date: Tue, 11 Sep 2018 05:20:19 -0700

On Mon, Sep 10, 2018 at 11:40 PM Ole Troan <[email-masked]> wrote:

> > My view, and the i-d of referenced for this thread, all the dns64 ills
> go away if you deploy ipv6, so please deploy ipv6.
>

The queation in this i-d is who carries the burden? This i-d assigns the
burden to the person trying to do dnssec, not the person doing ipv6-only
with dns64.  This i-d says the optional activity of deploying dnssec, to
work best, also includes the cost of having that resouce identified in the
resource record to have ipv6. The person deploying dnssec is clearly smart,
well healed, and is well positioned to do ipv6 on their described end points

cheers,
CB

---

From: Lee Howard <[email-masked]>
Date: Tue, 11 Sep 2018 09:31:42 -0400

> But until then, this creates problems for IPv6 hosts.

Or you could say, "This creates problems for DNSSEC hosts."
Or DOH hosts.

Is this more a DNS/server side problem or a DNS64/network side problem?
In my world view, which I admit is strongly biased in this case, 
everyone MUST eventually run IPv6, and everyone SHOULD run DNSSEC. IPv6 
and DNSSEC are perfectly interoperable, it's only the transition 
mechanism state where there's a problem.

Does anyone on v6ops disagree that best practice is for server operators 
to deploy IPv6? If not, is there anything wrong with the statement in 
this draft?

Publishing this draft does not prevent us from making other updates that 
would make it less of a problem. Even if we resolve the interoperability 
problem (in a few years), it will still be best practice to deploy IPv6.

Lee

---

From: Ca By <[email-masked]>
Date: Tue, 11 Sep 2018 06:50:48 -0700

> to deploy IPv6? If not, is there anything wrong with the statement in

One could say this i-d is simply a personal invitation to dnssec deployers
to the rfc6540 party, which already states ipv6 is not optional.

Here is an example use case of the i-d

Dnssec-Person: my stuff does not validate on your network, fix it by
burning down your infrastructure that has delivered material improvement to
the global ipv6 deployment and overall health , scale, and security of the
internet!

Dns64 operator: your resources do not have ipv6, please comply with rfc6540
and move us all forward. My host have v6, dns64 will not be used for your
v6 records.

DP- 6540 does not apply to me

DO- well, i-d-byrne is real specific about this issue.  Your CDN / cloud /
ISP / OS  likely will let you enable it for free. Let me google it for you
....

DP - Ok! I did it!  Now i need to write blog about how great i am at ipv6

Crisis averted. Internet goals achieved.

CB

---

From: Fred Baker <[email-masked]>
Date: Tue, 11 Sep 2018 14:51:21 -0700

> On Sep 11, 2018, at 6:50 AM, Ca By <[email-masked]> wrote:
> 
> One could say this i-d is simply a personal invitation to dnssec deployers to the rfc6540 party, which already states ipv6 is not optional.

Sort of. RFC 6540 says that the industry wants "ubiquitous [ipv6] hardware and software support" in the products that it deploys. What you're saying (which I'm quite OK with) is different: you want ubiquitous service support using that hardware and software. I wonder (this is a question) whether if RFC 6540 was something we needed, whether the service counterpart to it is needed as an RFC as well.

---

From: David Farmer <[email-masked]>
Date: Tue, 11 Sep 2018 16:58:24 -0500

On Tue, Sep 11, 2018 at 4:51 PM, Fred Baker <[email-masked]>
wrote:

> > One could say this i-d is simply a personal invitation to dnssec
> deployers to the rfc6540 party, which already states ipv6 is not optional.
>
> Sort of. RFC 6540 says that the industry wants "ubiquitous [ipv6] hardware
> and software support" in the products that it deploys. What you're saying
> (which I'm quite OK with) is different: you want ubiquitous service support
> using that hardware and software. I wonder (this is a question) whether if
> RFC 6540 was something we needed, whether the service counterpart to it is
> needed as an RFC as well.
>

I have been thinking maybe this should update RFC6540, making it one BCP.
I'm not sure they really need to be distinct entities.

---

From: Fred Baker <[email-masked]>
Date: Tue, 11 Sep 2018 15:40:43 -0700

> On Sep 11, 2018, at 2:58 PM, David Farmer <[email-masked]> wrote:
> 
> 
> On Tue, Sep 11, 2018 at 4:51 PM, Fred Baker <[email-masked]> wrote:
> 
> 
> I have been thinking maybe this should update RFC6540, making it one BCP. I'm not sure they really need to be distinct entities.

But by implication, you think there is value in saying this?

---

From: David Farmer <[email-masked]>
Date: Wed, 12 Sep 2018 13:18:12 -0500

On Tue, Sep 11, 2018 at 5:40 PM, Fred Baker <[email-masked]>
wrote:

> > Sort of. RFC 6540 says that the industry wants "ubiquitous [ipv6]
> hardware and software support" in the products that it deploys. What you're
> saying (which I'm quite OK with) is different: you want ubiquitous service
> support using that hardware and software. I wonder (this is a question)
> whether if RFC 6540 was something we needed, whether the service
> counterpart to it is needed as an RFC as well.
> >
> > I have been thinking maybe this should update RFC6540, making it one
> BCP. I'm not sure they really need to be distinct entities.
>

Yes, I said I supported the draft and the suggestions Lee made earlier,
that hasn't changed.

---

From: David Farmer <[email-masked]>
Date: Fri, 14 Sep 2018 11:10:44 -0500

On Mon, Sep 10, 2018 at 8:25 PM, Ca By <[email-masked]> wrote:

>> All the issues we are talking about with DNS64 today where known about
>> and hand waved away when DNS64 was being published.  8 years later all that

I would make a slightly stronger statement, deploying IPv6, especially on
the content side, makes the DNS64 irrelevant.

I support this draft. I also support the work on
draft-pref64folks-6man-ra-pref64. Further, once it is generally available
and supported in hosts, it wouldn't take too much to convince me to support
deprecating DNS64 and both RFCs 6147 and 7050.

DNS64 clearly has issues and I would prefer a solution like
draft-pref64folks-6man-ra-pref64. But that doesn't mean DNS64 hasn't served
a purpose. Like it or not, as a solution, it is at least partially
responsible for much of the IPv6 deployment we have today especially in the
mobile and cellular realm. Do I wish we would have done something like
draft-pref64folks-6man-ra-pref64 instead of DNS64? Yes, but that is water
under the bridge.

Thanks