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

[Erik Auerswald <[e-mail]>]

Hi Ole,

On Mon, Apr 25, 2022 at 12:16:02PM +0200, [e-mail] wrote:
> [...]
> 
> > Thus I would rather suggest to consider if making tracking which
> > gateways advertised which prefixes mandatory would be a better
> > approach.
> 
> The SAS/DAS algorithm must work in arbitrary topologies.

Let me add important detail from previous emails:

There was a specific failure scenario presented.  In that scenario,
following rule 5.5 of RFC 6724 would have prevented the problem.
To use this rule, prefix advertisement tracking per next hop is
required.

https://datatracker.ietf.org/meeting/113/materials/slides-113-6man-source-address-selection-for-foreign-ulas-00

> A host cannot assume that that it is directly connected to a
> border router.

Direct connectivity to a border router that did not know about some
of the internal topology created the problem.

To state this differently: the network provided only partial
connectivity.  One host could use two source addresses when sending
a packet to another host.  The routers in between the hosts could
only route back to one of the source addresses, but not the other.

With no protocol between hosts and routers, the hosts cannot always
choose the correct source address for such a network, because they
cannot know which connectivity is broken.

Choosing local (ULA) source addresses for connectivity to a local
(ULA) destination seems a sensible choice.

I concur with Ted Lemon that "automatic behavior should not break
things."

It may well be (I do not know that) that some combination of
automatic behavior and manual configuration resulted in the observed
problem.  It may be possible to improve automatic behavior or device
defaults to prevent some problems.  This should not break currently
functioning use cases, though.

In the presented scenario, if either "Router" or "CE Router" had
learned the new ULA prefix via RAs from "ULA Router", connectivity
would most likely not have been disrupted (either "CE Router" would
have known how to deliver the packet, or "Router" should have sent
the packet directly to "Host 1".)

The scenario is called a "[t]wo subnet home network," thus it
seems possible that Linux based home routers are used.  The Linux
IPv6 implementation by default does not accept RAs on interfaces
that forward IPv6 packets.  Combining routers that do not learn
reachability information from each other can easily result in only
partial connectivity.

[The slides contain the oddity that "Router" does not forward
packets to one of its directly connected links directly to the host,
but to "CE Router."  But the ULA problems occur both if "Router"
does deliver directly to the host for the common subnet and if it
forwards to "CE Router", because the ULA prefix from "ULA Router"
is not known by either "CE Router" nor "Router", as far as we know.]

While I do concur with Ted Lemon that "[n]obody is doing anything
“wrong” here", I think that some necessary steps have been
omitted, i.e., guaranteeing full connectivity between all prefixes
of all the routers.  This may have been caused by those routers
not learning reachability information from the other routers.

I do not think that any default automatic behavior can correct any
possible incomplete network configuration.

> It cannot assume addresses of equal scope/zone have the same
> reachability.

It cannot assume that addresses of different scope/zone have the
same reachability either.

It seems more likely that addresses af equal scope/zone allow
communication than those of different scope/zone.

The final tie-breaker of matching prefix length (which is not
guaranteed to succeed anyway) seems to be an attempt to often find
a deterministic solution instead of choosing randomly.

[ Example for tie after rule 8:

  D  = 2001:db8:ffff::1
  SA = 2001:db8:0001::2
  SB = 2001:db8:0002::3

  CommonPrefixLen(SA, D) == CommonPrefixLen(SB, D) == 32 ]

It seems to be based on the idea of topological addressing, i.e.,
longer common prefixes suggest smaller topological distance.  This
idea does not really seem to hold for different /48 ULA prefixes.
Thus making an exception for ULA to not consider CommonPrefixLen,
and then adding another rule (this would be number 9) to prefer
GUA over ULA combined with modifying rule 6 to consider different
/48 ULA to have different labels, seems plausible.

But it would break existing IPv6 only networks where only the
default RFC 6724 policy table is in use and some local hosts
have only ULA connectivity, but cannot reach any GUA addresses,
even those of hosts in the same site.  Having hosts that cannot
directly communicate with GUA addresses, but only ULA addresses,
seems to be a valid use case.  RFC 6724 supports this currently.

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