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

[David Farmer <[e-mail]>]

One more thought.

On Mon, Nov 13, 2023 at 10:28 AM David Farmer <[e-mail]> wrote:

> 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
>
>
These known-local ULA /48s SHOULD have a precedence of 45 and a common
label identifier.


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


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