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

[Brian E Carpenter <[e-mail]>]

On 26-Apr-22 13:02, Ted Lemon wrote:
> I hate to contradict, but no it doesn’t. It means that such networks require explicit configuration. 

I'm not sure exactly how to parse that, but if you're implying that networks that might sometime change to a new ISP and are not big enough to pay 
for their own PI prefix need explicit configuration, then Mark is correct. SME or SOHO networks by the millions should be the main beneficiaries 
of invariant internal addressing, and that means the factory default should prefer ULA->ULA even if GUA->GUA is available.

    Brian

> 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] <mailto:[e-mail]>> wrote:
> 
> 
> 
>     On Mon, 25 Apr 2022, 21:45 Ted Lemon, <[e-mail] <mailto:[e-mail]>> wrote:
> 
>         On Apr 25, 2022, at 06:03, Erik Auerswald <[e-mail] <mailto:[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] <mailto:[e-mail]>
>         Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>         --------------------------------------------------------------------
> 
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>