Re: [v6ops] Scope of Unique Local IPv6 Unicast Addresses (Fwd: New Version Notification for draft-gont-6man-ipv6-ula-scope-00.txt)

[Ted Lemon <[e-mail]>]

On Jan 7, 2021, at 10:18 PM, Mark Andrews <[e-mail]> wrote:
> When you change topology the node will see new RAs and getaddrinfo() will filter out all the old addresses.  The node has a set of link identifiers for links it is attached to.  Remember machines don’t care about these names.  They are just ways to filter out the currently useful addresses.  Each node
> will maintain its own mapping from applicable names to sin6_scope_id which will be filled in by getaddrinfo() generated by the RAs it sees.

I think link identifiers as you describe might be useful for some applications, but putting them in a database has a lot of issues. If every router on a link multicasts a link identifier to a link, then it’s not a link identifier—it’s a router interface identifier. That’s fine, but now my node has to track what router interface identifiers are present on the link, and publish its information on each identifier. Now suppose a router is unplugged from one link and plugged into another. It starts advertising its router interface identifier on the new link. Now you have stale information in the DNS, but the host doesn’t know, because there’s no positive indication that that router has gone.

You could track the router's reachability in the neighbor table, but now you have a different problem: it’s only going to be in the neighbor table if you’re using it, or if an RA has been received recently. So now you have a router link identifier that’s fluctuating. Do you update the database on every fluctuation?

Furthermore, DNS has TTLs. What’s the TTL on the data? How quickly does it fall out of your cache? Remember, you wanted to do this because Caching Is Good, so if you use a short TTL, your Good Caching isn’t happening.

What if you’re on an IPv4-only link? How do you publish your IPv6 LLA with a router link identifier? Your router isn’t giving you one. You can’t use the RFC1918 subnet prefix you got from DHCP as a link identifier, because they are non-unique.

This is what I mean when I say this isn’t practicable. Sure, it’s theoretically possible to imagine an environment where it would work. But it’s a tremendous amount of work that fails in ways that will create delay in many corner cases. And all it gets you is a hint from DNS as to which interface to use to communicate with a named host using its LLA. This isn’t much of a benefit.

If I just wanted hints, I could just do ND on every multicast-capable interface and get much more reliable hints: in most cases I’ll only get an answer on one interface, and then I can just send the packet on that interface and be much more assured of correctness than I could be based on stale data in the DNS.

Look at this from the other direction. A DNS full service resolver on your network can in many cases know where the query is coming from. BIND 9 already does this—I can define a set of prefixes that are “local” and allow queries from those prefixes, but refuse queries from other prefixes.

This generalizes well: I can do the same thing for ULAs. I could very easily mark some set of ULA prefixes as “reachable for hosts with addresses in prefixes on this list.” And then when I get an AAAA record query that has both ULA and GUA addresses, I can return just the GUA address for queries from prefixes that aren’t on the list, and I can return the ULA only for queries from prefixes that are in the list. Or ULA+GUA.

This works well because minor changes in topology aren’t relevant. We know who owns the ULA prefix. We don’t need to know the details of where sub-prefixes of that ULA prefix are being advertised. We know what GUAs we have. If our upstream renumbers us, we need to update the prefix list, but this is a very lightweight change. And particularly if we _only_ return ULAs when the ULA is valid, this prefix change doesn’t affect any host that has the answer cached: our upstream GUA prefix change doesn’t affect our internal ULAs.

So from an operational perspective, this is a really useful feature—it’s one that I’d dearly love to see in BIND.