Re: [IPv6] RFC 6724 shouldn't prefer partial reachability over reachability

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

On 27-Nov-23 04:59, Kyle Rose wrote:
> On Sun, Nov 26, 2023 at 10:20 AM Michael Richardson <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     But, you as an operator, would be deleting those announcements based upon
>     your well configured BCP38.  So, it's really is entirely under your control,
>     which I agree with you: is a better.
> 
> 
> I am not referring to leaking routes, but to leaking rendezvous information, i.e., DNS. In a world in which operators run recursive resolvers that clients can be assumed to use when on your network, you maybe can configure yours to drop all external address records referring to ULA or 1918 space, but we're now in a world in which privacy (via DoH/DoQ) and end-to-end integrity (via DNSSEC) have been prioritized over operability, so you have to assume you won't have full control over what DNS entries a client sees. 

All the more reason for doing everything we can to avoid trying a ULA destination address that is definitely unreachable. That at least is theoretically possible by requiring a /48 match with a locally used ULA prefix. But I think that is logically disjoint from RFC6724.

> This has implications for the set of trade-offs involved in misconfigurations, especially when the naive user blames you for something not working even when it's mostly not under your control. With border routers sending ICMP unreachable rejections, working Happy Eyeballs would hopefully make failover transparent, but "hopefully" is doing a lot of heavy lifting in that expectation.

Yes. But our chances are no worse with ULAs in DNS than with RFC1918 in DNS, and that's a thing too.

Non-authoritative answer:
Name:    campus.eckerd.edu
Addresses:  fde1:53ba:e9a0:de11:cd63:b055:9846:cb20
           198.187.214.99
           10.1.96.92
           198.187.214.100
           10.1.99.45
           172.17.4.74

   Brian

> 
> Anyway, I consider this an acceptable set of trade-offs, but there is a discussion to be had about the implications that would benefit from the experience of big-time operators who have run into a much broader set of issues than I have.
> 
> Kyle
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------