Re: [v6ops] ULA precedence [Thoughts about wider operational input]

[Mark Smith <[e-mail]>]

Hi Ted,

On Tue, 26 Apr 2022 at 11:02, Ted Lemon <[e-mail]> wrote:
>
> I hate to contradict, but no it doesn’t. It means that such networks require explicit configuration.

I don't think they should, and requiring that makes ULAs far less
useful if GUAs are preferred over ULAs as either the DAs or the
matching SA for a selected ULA DA.

The main theme of DA selection in RFC3484 is to prefer the likely most
reliable DA by minimising external dependencies. Loopback is the best
DA because it has the minimum external dependencies - it is within the
host itself. GUAs are the least likely reliable of a set of DAs
because they are likely to have the most external dependencies, such
as links, routers, networks, network operators, and RIRs and ISPs
supplying the GUA space, for the majority of GUA DAs - Internet GUA
DAs.

RFC6724 doesn't follow that minimise external dependencies theme
because it is preferring GUAs with more external dependencies over
ULAs that have less external dependencies.

The main cause of the problems with site-locals was their lack of any
uniqueness and the complications of the work arounds to that, such as
site-IDs (see RFC3879). ULAs solved that by embedding a likely
globally unique 40 number in the local network address space.
(Link-locals have this lack of uniqueness problem too, which is why
there are zone IDs to fix it. Unique Link-Local Addressing anybody?)

So ULAs are likely more reliable than GUAs for all of the same reasons
Site-Locals were likely more reliable than GUAs - less external
dependencies. ULAs should be preferred over GUAs by default for DA and
then SA selection similar to how Site-Locals were preferred over GUAs
by default.

I assumed that was all the update to RFC6724 was going to be for ULAs
- replacing Site-Locals with ULAs with the same SA and DA preferences.

Regards,
Mark.





> If we don’t think that’s going to work, maybe we should do something about it. That said , Ole mentioned that this is intended to fix a broken network anyway, and it’s probably better to fix that in a different way (draft coming at some point).
>
> On Mon, Apr 25, 2022 at 18:43 Mark Smith <[e-mail]> wrote:
>>
>>
>>
>> On Mon, 25 Apr 2022, 21:45 Ted Lemon, <[e-mail]> wrote:
>>>
>>> On Apr 25, 2022, at 06:03, Erik Auerswald <[e-mail]> wrote:
>>>
>>> And all that would probably not preclude constructing a different
>>> scenario where choosing GUA over ULA as source address would break
>>> connectivity.
>>>
>>>
>>> The question is not what possible scenarios are there, but what scenarios do we want to address with default behavior versus what scenarios can we only address with managed behavior. So e.g. not using longest-match for ULAs with different global identifiers sounds like a good default behavior, but obviously will break in some scenarios; in these scenarios, clearly we need support for configuring source address selection (which we already know how to do). Preferring GUA source address over ULA makes sense by default, I think, even though it is not always going to be the right thing to do.
>>
>>
>>
>> Defeats a significant purpose of ULAs.
>>
>> RFC4193:
>>
>> 4.2.  Renumbering and Site Merging
>>
>>    The use of Local IPv6 addresses in a site results in making
>>    communication that uses these addresses independent of renumbering a
>>    site's provider-based global addresses.
>>
>>
>>>
>>> Thus I would rather suggest to consider if making tracking which
>>> gateways advertised which prefixes mandatory would be a better
>>> approach.
>>>
>>>
>>> That's nice, and again would probably produce better default behavior. But I suspect it doesn't solve as many problems as you're hoping it will. E.g. what happens if the link you're connected to is one hop away from the link to which both of your upstream providers are connected? Now you have one router advertising everything, so this doesn't help.
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [e-mail]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------