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

[[e-mail]]

Erik,

To summarise my view:

- Regardless of how we tweak the SAS/DAS algorithm, it is going to be trivial to show scenarios where it fails. Solving Ted's (misconfigured) example is likely a game of whack-a-mole.
- If a network is configured to not distribute reachability information between routers I would argue it is misconfigured.
- Host implementations will need to handle SAS/DAS more dynamically. Going as far as trying all combinations. Reachability is after all dynamic.

Cheers,
Ole



> On 25 Apr 2022, at 14:05, Erik Auerswald <[e-mail]> wrote:
> 
> 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