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

[David Farmer <[e-mail]>]

I’ll agree local scope naming or addressing doesn’t need to be visible from
the global scope, and most people don’t intend it to be such. Nevertheless,
it is a daily fact that local scope naming and addressing leaks into the
global scope, regardless of and in spite of all intentions to the contrary.
This is again because there is no real concept of local vs. global scope as
part of the DNS protocol or on the wire, therefore the protocol provides no
help preventing this leakage.

We all know which road is paved with good intentions. Therefore, It is my
belief regardless of the intent for local naming and addressing to be local
and not visible globally, we need a design that is robust to this leakage.

I believe that requiring a preference for known-local ULAs, with GUA and
IPv4 preferred over other ULAs, is the robust solution to the leakage of
local naming and addressing into the global scope that we need.

Even this heuristic isn’t perfect, there is no way to know if a particular
known-local ULA is actually reachable until we try communicating with it,
but this is true for all address types. However, the contrary is almost
certain, a non-local or remote ULA is almost certainly unreachable and GUA
or IPv4 addresses are more likely to be reachable than a non-local or
remote ULA.

As for your VPN example, if the VPN uses ULA, then you would expect the
host will have an address from the VPN and would be a known-local ULA, and
this heuristic will work as intended.

On Thu, Apr 11, 2024 at 15:33 Ted Lemon <[e-mail]> wrote:

> Hm. In general I suspect that most of the time the stuff that's going to
> get both a ULA and a GUA in the DNS doesn't need to be visible from outside
> of a firewall. Like, the name isn't needed. I think it's very unlikely that
> any resource that's ever going to go through a CDN would make sense to
> advertise with a ULA. So I am not particularly attached to using ULAs in
> names that are globally reachable.
>
> But as you say, this is not a distinction that exists in the protocol
> specification. So I agree with Kyle that it doesn't make sense to advertise
> internal stuff globally with ULAs, and I agree with you that there are
> plenty of domain names that are going to have AAAA records on them
> containing ULAs as well as GUAs. I don't think this is quite contradictory.
> Like, it's hard for me to imagine a situation where it would make sense for
> the name www.google.com, even if it had AAAA records on it, to have AAAA
> records containing ULAs.
>
> On the other hand, names under internal.example.com might well have ULAs
> on them. If these are discoverable from the Internet, that doesn't really
> matter, because they are only intended for internal users. But generally
> speaking internal resources are only accessible through a VPN anyway, so
> it's a moot point—you're probably never going to see that delegation
> answered on the Internet, and even if you did, there would be no real point
> to putting GUAs in the delegation because anybody who needs to reach one of
> those hosts has the VPN up, and if they don't we don't want those hosts to
> be reachable.
>
> On Thu, Apr 11, 2024 at 2:27 PM David Farmer <[e-mail]> wrote:
>
>>
>> On Thu, Apr 11, 2024 at 8:29 AM Ted Lemon <[e-mail]> wrote:
>>
>>> On Thu, Apr 11, 2024 at 8:51 AM Kyle Rose <[e-mail]> wrote:
>>>
>>>> On Thu, Apr 11, 2024 at 8:41 AM Ted Lemon <[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. 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]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================