Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-srv-00.txt

[Martin Hunek <[e-mail]>]

Dne pondělí 11. března 2019 18:50:53 CET, Lee Howard napsal(a):
> 
> On 3/11/19 1:20 PM, Martin Hunek wrote:
> >
> > Dne pondělí 11. března 2019 16:37:44 CET, Lee Howard napsal(a):
> >
> > Yes, it is the general idea. Think is that not every end user uses DNS servers of its ISP (quad8, quad9, and so on). But doing so, they would lost DNS64 functionality so they would not have NAT64 available as well. Until now, it was negligible, however with DNS over HTTPS, it might get more pressing (as DoH operator is generally third party). In this case, the RFC7050 trick would not work.
> Yes, people who use DoH have decided that they don't need to reach the 
> tens of millions of people using DNS64.
It really depends, who would actually choose to use it. When web browser vendor chooses to prefer DoH, the end user would be the one without working NAT64/DNS64.
> >
> > DNS64 SRV record would be used if the end node won't be able to actually do DNS64 itself. If it can, then it might just point to NAT64 prefix from corresponding SRV record. If it cannot, than it should use server from DNS64 SRV record when it receives NODATA on AAAA query via usual channel.
> >
> > With DNS64 SRV record I am actually strugling if it should be mandatory or optional. If I would only like to cover detection of NAT64 prefix for case of DNSSEC validation, then it is not needed. But on the other hand, if I would like it to cover cases in which you would have only stub resolver without ability of DNS64, then the DNS64 SRV would be quite handy.
> I don't know how you can make it mandatory. Who's going to enforce the rule?
I mean MUST vs. SHOULD. No one would actually force it.
> >> I think it would work, but I'm not generally in favor of giving more
> >> support to people who won't provide forward compatibility. I'd need to
> >> think about it more.
> > Can you elaborate on "people who won't provide forward compatibility"? I'm not sure what do you mean by that.
> 
> I mean that people on IPv4-only are not compatible with IPv6, which 
> everyone knows is the protocol going forward.
This is somehow philosophical issue. If I deploy NAT64/DNS64 it is because I want my IPv6 users to be able to access IPv4 internet. This is something which actually allows me to shutdown IPv4 in internal network sooner. But I understand that it might be even used other way around and allow this way access to internal IPv4 network. This is than slowing IPv6 deployment in particular network, but at least it somehow ease access to such network from IPv6 hosts. So it won't hurt overall. 
> 
> I will also say that people who deploy DoH are knowingly losing 
> connectivity. I refer to the first paragraph of Section 10 "Operational 
> Considerations" of the DoH RFC, rfc8484:
> 
>     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.

Thanks for clarification.

Martin
> 
> Lee
> 
> >
> > Martin
> >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
>