Re: [IPv6] Second Working Group Last Call for <draft-ietf-6man-rfc6724-update>

[Brian E Carpenter <[e-mail]>]

On 12-Apr-24 06:27, David Farmer wrote:
> 
> On Thu, Apr 11, 2024 at 8:29 AM Ted Lemon <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     On Thu, Apr 11, 2024 at 8:51 AM Kyle Rose <[e-mail] <mailto:[e-mail]>> wrote:
> 
>         On Thu, Apr 11, 2024 at 8:41 AM Ted Lemon <[e-mail] <mailto:[e-mail]>> wrote:
> 
>             But this is counterfactual. Rght now if you publish a ULA in the global DNS, it will not cause a delay because no host with IPv6 connectivity will try to connect to it. We only run into a problem if we decide to prefer all ULAs over all IPv4 addresses. That /will/ in fact cause delays.
> 
> 
>         Because something is misconfigured. Right now, that misconfiguration is hidden, and becomes visible only when IPv4 connectivity is broken for whatever reason. Fix the glitch, which is the ULA in global DNS.
> 
> 
>     Kyle, I don't know if you can see this from where you're sitting, but you are making a religious argument here. It is not a misconfiguration to put a ULA in the DNS right now in the sense that it causes a problem. It's a misconfiguration because it doesn't match your mental model of How Things Should Be.
> 
>     I don't entirely disagree with you about this—I don't think that we ought to put ULAs in the global DNS. But I don't actually have a solid argument against Lorenzo's position—I just don't happen to agree with it.
> 
> 
> I disagree with both of you. The distinction between local and global DNS only exists in the human mind. It doesn't exist in the DNS protocol or on the wire, except for the relatively recent availability of the .local zone.  And even with .local, there is no way to distinguish between different instances of .local.

With mDNS, resolving printer.local comes back with a zone as well as an IPV6 address. It's different from normal DNS resolution, where all you get back is the AAAA. I do know that not all code on Linux deals with this correctly (https://github.com/becarpenter/misc/tree/main/zelect#linux-a-tale-of-woe). I don't know what happens if you try to have two instances of printer.local on two different interfaces.

BTW, .internal is now defined (by ICANN, since the IETF didn't have the guts, apparently). That isn't a perfect solution, but it is an opportunity to do a better job of split horizon DNS. The challenge here is that not everybody agrees that split horizon DNS is a good idea, and not everybody agrees that ULAs in DNS are a bad idea, so we have weak language in RFC4193 and no well-defined approach to split horizon.

What I suggested yesterday still seems like the best way out for the current draft:

>>> All implementations MUST support inserting known-local prefixes.
>>> This feature MUST be configurable on or off.
>>> This feature SHOULD be configured on by default.

    Brian


> You don't know if a .local query is for or if the response is from your instance or my instance of .local. Except for the .local zone, there is no way to know if a query is intended to be global or local or if a response is global or local. The protocol on the wire is identical, and any distinction is a fiction of the human mind.
> 
> Furthermore, ULAs are global in scope, and if implemented correctly, they are effectively unique globally. The only real question is whether they are reachable or not, and preferring known-local ULAs and not other ULAs speaks directly to the reachability question. Whether or not the ULAs belong in the DNS or not, and how the DNS is configured, is irrelevant. The real question is only if they are reachable or not, and again, known-local ULAs resolve this question.
> 
> Thanks
> 
> 
> 
> -- 
> ===============================================
> David Farmer Email:[e-mail] <mailto:[e-mail]>
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: [phone]
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------