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

[Erik Auerswald <[e-mail]>]

Hi Ted,

On Mon, Apr 25, 2022 at 07:40:13AM -0400, Ted Lemon 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.

I see a useful scenario with ULA use local reachability inside an
organization.  Some hosts are not allowed to directly communicate
with the global Internet.  They can use ULA.  Their first hop
gateways could blackhole 2000/3.  Bastion hosts with both GUA and
ULA addresses could be used to connect to ULA only hosts.  The RFC
6724 default source address selection policy supports this use
case, as does the example extension from section 10.6 of that RFC.
Without RFC 6724 section 10.6, always preferring GUA over ULA source
addresses would break this use case.

The more complex changes that conceptually introduce one policy table
entry for every possible ULA /48 prefix and then disregard prefix
match length results less than 48 would not break the common use
case of one /48 ULA per site.  It would require managed behavior
with VPN connectivity between different sites using different ULA
/48 prefixes.

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

I hope to solve the single problem presented with minimum
breakage. ;-)  That is, I am not convinced that the presented problem
warrants broad changes to the address selection algorithm.

Ideas like RFC 8028 require tracking which gateway advertised wich
prefix.  It seems to me as if this RFC is intended for general use
with the hope for support in common host operating systems.

RFC 8028 allows to take the idea of intra-organization only ULA one
step further by using a set of routers that only know about ULA (and
link-local addresses), and having a different set of routers that
only know about GUA (and link-local addresses).  Unconditionally
preferring GUA over ULA in source address selection would break
such a construct.

Kind regards,
Erik
-- 
Dipl.-Inform. Erik Auerswald
Gesellschaft für Fundamental Generic Networking mbH
Geschäftsführung: Volker Bauer, Jörg Mayer
Gerichtsstand: Amtsgericht Kaiserslautern - HRB: 3630