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

[Vasilenko Eduard <[e-mail]>]

Hi Erik,
> [EV] Why?
> I do not understand the advantage to populate more prefixes into the 
> host If the site would have many ULA prefixes.

This is required to prefer locally used ULA over IPv4 and possibly
IPv6 GUA, but prefer IPv6 GUA and IPv4 over non-local ULA.
Non-local ULA prefixes are generally not reachable.

[EV] We are talking about complicated things here - I need to think more.
But looks like the statement above is not right.
Because there is no danger that Non-local ULA would be chosen as the source - it was not announced in any PIO on the local link.
Hence, I do not understand what problem you are solving by separate /48 prefixes.
The current FC/7 should be just prioritized - it is enough.
Of course in conjunction with Label=13 check
and the assumption that all routers announce the same PIOs.

Eduard
-----Original Message-----
From: Erik Auerswald [mailto:[e-mail]]
Sent: Monday, April 25, 2022 12:05 PM
To: Vasilenko Eduard <[e-mail]>
Cc: Nick Buraglio <[e-mail]>; v6ops list <[e-mail]>; 6man list <[e-mail]>
Subject: Re: [v6ops] ULA precedence [Thoughts about wider operational input]

Hi Eduard,

On Mon, Apr 25, 2022 at 07:57:05AM +0000, Vasilenko Eduard wrote:
> Hi Erik,
> See below
> Eduard

I have added the quoting level you omitted to help differentiate who wrote what, and trimmed the message below.

> -----Original Message-----
> From: Erik Auerswald [mailto:[e-mail]]
> Sent: Monday, April 25, 2022 10:48 AM
> > On Sun, Apr 24, 2022 at 08:12:29PM +0000, Vasilenko Eduard wrote:
> > > [...]
> > > 2. Attach a special Label (redundant action because FC/7 already 
> > > has unique Label=13)
> >
> > The different label to differentiate between locally used ULA
> > prefix(es) and the remaining ULA space is intentional.
> 
> [EV] Why?
> I do not understand the advantage to populate more prefixes into the 
> host If the site would have many ULA prefixes.

This is required to prefer locally used ULA over IPv4 and possibly
IPv6 GUA, but prefer IPv6 GUA and IPv4 over non-local ULA.
Non-local ULA prefixes are generally not reachable.

In a special situation, where ULA is used as a replacement of GUA, say a large private network, or a NAT66 setup, ULA should be treated just as GUA, as was done before RFC 6724.  This can be achieved with RFC 6724 compliant systems by changing the fc00::/7 policy table entry to use identical preference and label as the ::/0 entry.
This expresses the local policy to treat ULA identical to GUA, just as private IPv4 space is treated identical to public IPv6 space for address selection.

> > > Imagine the situation where only one router on the link announces 
> > > ULA PIO, but the other one - GUA PIO.  (Routers are not in sync 
> > > for announcements).

It seems that RFC 8028 as mentioned by Brian would provide a solution for this.

> > Using different first hop gateways for GUA and ULA is another 
> > problem.  It would be nice if hosts would (optionally) not consider 
> > a gateway announcing a ULA prefix as default gateway, but only for 
> > ULA reachability.
> 
> [EV] Nope. It is better to revert the logic: decide about the
>      source address first (needed anyway for MHMP) only then to
>      decide about the next-hop.

If a router announcing only a ULA prefix would not be considered as a default router, the host could detect that GUA is not reachable, and fall back to IPv4.  I think this is a different use case from what you have in mind.

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