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

[Nick Buraglio <[e-mail]>]

On Mon, Nov 13, 2023 at 8:56 AM David Farmer <farmer=
[e-mail]> wrote:

> So if it is ok to mitigate DNS misconfigurations with border ACLs and
> Routing information in the routers delivering ICMP Destination Unreachable
> messages to hosts, using Happy Eyeballs racing different options, and
> advising people not to put ULAs in the public DNS, then why is it NOT OK to
> use some of that same information to make a first cut at which ULA /48s are
> local or not on the host?
>
> To be honest, this is a big enough problem that we should be using all the
> tools in the toolbox to solve it.
>
> Preferring known local /48s in the host's policy table doesn't eliminate
> the need for other mitigations, but as Lorenzo points out, those other
> mitigations have a cost, too. Why incur those costs %99.9999 of the time
> when there is no hope for reachability in the first place? And, Mark, I
> hear you. ULAs must be preferred above GUAs, but why prefer the %99.99999
> of ULAs that will never work anyway?
>
> We need;
>
> I agree with all of these.


> 1. ICMP Destination Unreachable messages from ACLs and routes in the
> routers, RFC 4193 Sections 4.1 and 4.3
>
> 2. Happy Eyeballs, RFC 8305, and maybe it needs some tweaks
>

This could be an opportunity for HE3 draft that is now in v6ops, perhaps?

>
> 3. Advice to not put ULAs in Public DNS, RFC 4193 Section 4.4 But we need
> to include options to instantiate local DNS properly. Just saying "DON'T DO
> THAT" isn't good enough.
>
We could add some verbiage into this update to say the same, but updating
4193 is  another task altogether.

>
> 4. Prefer only known local ULA /48s in host policy tables, beefing up
> Section 10.6 of RFC6724.
>
We could add some more text to reflect that, too.

>
> I think it’s not one or the other; we need to do all four of these.
>

Right, and we have to take a first step to start that trip, which is what
this draft is proposing. We also can't expect to address every possible
corner case, that is a sure-fire recipe for decision paralysis.
A great deal of what we've been discussing is fairly edge case and/or
subjective (e.g. dns implementation specifics). We very much should not
make the perfect the enemy of the good, especially when we have a fairly
large task.

Most of what I am reading both literally and between the lines is that this
is a recognized impediment to moving to a more v6-first world, and that's
good because that's what we're proposing and I think that's the goal of
this group. We will see if we can get some test results out this
week, hopefully that will alleviate some concerns.

>
> Thanks
>
>
> On Mon, Nov 13, 2023 at 05:13 Kyle Rose <[e-mail]> wrote:
>
>> On Sun, Nov 12, 2023 at 8:02 PM Lorenzo Colitti <lorenzo=
>> [e-mail]> wrote:
>>
>>> If we don't do this, RFC 6724 will make the wrong decision most of the
>>> time in the IPv4+ULA case. IPv4 addresses have global reachability and
>>> hosts can safely assume that they will work. ULA does not have global
>>> reachability, but this proposed change sort of assumes it does. "Don't put
>>> non-local ULAs in DNS" isn't a great answer, because DNS is not the only
>>> way that hosts get addresses.
>>>
>>
>> Maybe not, but it's overwhelmingly the most common mechanism for service
>> discovery between hosts with no pre-existing relationship, and putting ULA
>> into a DNS horizon (public or otherwise) from which the addresses are
>> unreachable is a misconfiguration. (Notably, getaddrinfo is also the most
>> common place the address selection algorithms described in 6724 and
>> predecessors are implemented, and getaddrinfo is tightly coupled with DNS,
>> so it makes sense that we're mostly focused on DNS in this discussion.)
>>
>> But also: does the mechanism of leakage matter? I frankly don't
>> understand why any exposure of unreachable ULA to a host should be
>> considered anything other than a misconfiguration. Even time-bounded
>> inconsistency like a local caching resolver handing out now-unreachable ULA
>> after a device moves networks seems like a bug: the OS should flush the
>> resolver cache, or at least those entries learned from the changed
>> interface, when this happens.
>>
>> I would like some examples of ULA leakage that you don't consider to be
>> misconfigurations. Until then, my conclusions remain as before:
>>
>>  - You should have a route to any ULA you are attempting to use, and if
>> you don't, that's a misconfiguration.
>>  - Attempting to mitigate every such misconfiguration via mere passive
>> address selection is futile.
>>
>> I'll note that mitigations are the whole purpose of Happy Eyeballs.
>>
>> "Rely on happy eyeballs" isn't a good answer either - HE always has a
>>> latency cost, and also, many applications and OSes don't implement it
>>> (example: java applications; most Android apps).
>>>
>>
>> Seems like something the OS or protocol stack could provide as a service
>> in most cases, rather than relying on applications to implement it.
>> Regardless, IMO it's perfectly reasonable for applications to misbehave
>> when the network is misconfigured: operators should fix their networks.
>>
>> Also: *this failure mode doesn't exist in RFC 6724 today*. Generally, if
>>> you follow the rules in RFC 6724 you'll get something that works
>>>
>>
>> 6724 and the proposed changes work or not under the same  circumstances:
>> whether the selected destination address is routable or not. You could just
>> as easily leak an unroutable 1918 address as you could leak an unroutable
>> ULA. Both are misconfigurations.
>>
>> Kyle
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>