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

[Ted Lemon <[e-mail]>]

I hate to contradict, but no it doesn’t. It means that such networks
require explicit configuration. 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 <https://datatracker.ietf.org/doc/html/rfc4193#section-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
>> --------------------------------------------------------------------
>>
>