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

[David Farmer <[e-mail]>]

How about something like the following;

Since ULAs are defined to have a /48 site prefix, an implementation SHOULD
automatically add rows for all covering ULA site prefixes received in
Router Advertisements (RAs) [RFC4861] within Prefix Information Options
(PIOs) or Route Information Options (RIOs) [RFC4191]. These known-local ULA
/48s SHOULD have a precedence of 45.

All Nodes SHOULD provide a mechanism to configure the policy table. Any
Node that does not provide a mechanism for policy table configuration MUST
implement the automated increased precedence for known-local /48s of ULA.

Nodes implementing the automated increased precedence for known-local /48s
of ULA MAY set the default precedence for the ULA label (fc00::/7) to 10.
Otherwise, the default precedence for the ULA label (fc00::/7) MUST be 30.

All Nodes SHOULD implement HEv2 [RFC8305].


More comments below;

On Mon, Nov 13, 2023 at 9:10 AM Nick Buraglio <[e-mail]>
wrote:

> 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?
>

Yes, probably.

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.
>

This doesn't belong in RFC 4193 or even the 6man of v6ops working groups,
in probably needs to be a DNSOps working item.


> 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.
>

How about something like the above?


> 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
>> --------------------------------------------------------------------
>>
>

-- 
===============================================
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
===============================================