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

[Erik Auerswald <[e-mail]>]

Hi Mark,

On Thu, Apr 28, 2022 at 07:51:05AM +1000, Mark Smith wrote:
> 
> 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.

I'd say that _remote_ ULAs are less reliable than GUAs.  Selecting ULA
source to reach GUA destination risks that the return traffic would be
sent to a _remote_ ULA (if the initial packet even reaches the
destination; it could be filtered because of using a "wrong" source
address).

The RFC 6724 default errs on the side of caution by assuming that ULA
are non-local, unless either auto-detected or configured as local.

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

RFC 6724 attempts to distinguish between remote and local ULA.  Local
ULA is either manually added to the address selection policy table, or
automatically added based on active local ULA IPv6 addresses (section
10.6).  Other ULA are not known to be local, thus they might be remote.

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

There are at least two problems with always preferring ULA over GUA:

1. Using a ULA source address to reach a remote GUA destination is
   likely to result in connection problems (ULA source filtered
   at the edge, return traffic from GUA to ULA cannot reach the
   ULA destination).  To prevent this, GUA and ULA use different
   labels in the policy table.

2. Preferring a ULA destination of unknown locality over a GUA
   destination risks using an unreachable destination address.
   To prevent this, ULA that are not known to be local use a lower
   precedence than GUA.

To quote RFC 6724 section 10.6:

  "Sections 2.1.4, 2.2.2, and 2.2.3 of RFC 5220 [RFC5220] describe
   address selection problems related to Unique Local Addresses (ULAs)
   [RFC4193].  By default, global IPv6 destinations are preferred over
   ULA destinations, since an arbitrary ULA is not necessarily
   reachable"

The referenced sections describe specific problems with ULA use without
differentiating between GUA and ULA (i.e., RFC 3484 address selection)
in different scenarios:

* Section 2.1.4.  Combined Use of Global and ULA
* Section 2.2.2.  ULA and IPv4 Dual-Stack Environment
* Section 2.2.3.  ULA or Global Prioritization

Reverting to RFC 3484 would regress to that state.

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

Are you suggesting the following change?

OLD:

     Prefix        Precedence Label
     ------------------------------
     ::/0                  40     1
     fc00::/7               3    13
     fec0::/10              1    11

NEW:

     Prefix        Precedence Label
     ------------------------------
     ::/0                  40     1
     fc00::/7               1    11
     fec0::/10              1    11

That would not change comparison results between GUA and ULA addresses.

Put differently, your suggestion is already implemented in RFC 6724.

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