[IPv6]Re: Using different router addresses (draft-link-6man-gulla) to solve the router fail-over scenario in (draft-gont-v6ops-multi-ipv6)

[David 'equinox' Lamparter <[e-mail]>]

Hi Fernando,

(reordering quotes a little bit to make a cohesive mail)

On Thu, Mar 20, 2025 at 10:10:43AM -0300, Fernando Gont wrote:
> On 20/3/25 08:06, Jen Linkova wrote:
> > On Wed, Mar 19, 2025 at 7:46 PM Fernando Gont <[e-mail]> wrote:

Let's start here:

> You don't get that without a requirement for RFC 8028. The only thing 
> that is actually "implicitly required" is that you track which router 
> advertised what, not that you are able to route based on that.

Yes, absolutely, this is a hole in RFC6724 rule 5.5 by itself.  You select a source address to go with a nexthop, but nothing makes you stay with that nexthop.

In practice, it seems to work in a lot but not all cases.  Ted has mentioned (hope I'm paraphrasing correctly -- no warranty!) that Apple OSes behave this way since 2 years ago, rule code 5.5 seems to have been added to fix Thread-related issues, and it largely works, but they're seeing some small number of remaining problems.

To do this correctly, you need to have the source address influence routing, which is the intent of RFC8028 (odd wording and errata'd abstract nonwithstanding.)

RFC8028 only asks this for default routes and puts it in specific context, but really you're doing SADR routing.  The very freshly uploaded -03 of the sourcedest draft in rtgwg now also mentions this, cf.
https://www.ietf.org/archive/id/draft-ietf-rtgwg-dst-src-routing-revive-03.html#name-improving-source-address-se

"Destination-source routing is explicitly applicable to hosts, and in the context of fully implementing [RFC6724] and [RFC8028], it is RECOMMENDED that end hosts in fact implement destination-source routing."

(That's basically the crossing-over point in terms of scope; the intent with the wording there is to acknowledge the routing side as close to the host as it gets, but no further.  I dont' want to, and don't believe it is appropriate to, go further than this in a rtgwg document.  RFC8028 was really straddling that boundary as well, from the other side.)


Now:

> > > * RFC6724 talks about "which next hop would be used if you were to
> > >     select a given source address". This means that you'd have some
> > >     NH() function that you can use to ask NH(src, Dst) to learn the next
> > >     hop for a given (src, dst) pair.

No, this isn't a valid expression/analog of rule 5.5.  It is not "which next hop would be used if you were to select a given source address."  (I hope I'm not rude here, it's only a reflection of my level of confidence in this claim, hope you can read it as such.)

The 5.5 paragraph is incredibly little wording for an incredible lot of meaning and effect.  But it is quite clear:

"Prefer addresses in a prefix advertised by the next-hop."

and

"[…] assigned by the selected next-hop that will be used to send to D […]"

Thus, rule 5.5 is to prefer if "src ∈ SRCS(NH(dst))".  (That's an "element-of" there, in case of b0rked Unicode.)

Even the destination isn't a direct input;  it's the next-hop (which of course is determined by the destination), and which must already have been selected (for this destination) at this point. (* this is also why the -03 destination-source routing draft has *two* fresh source address selection sections.  There needs to be a working route lookup before you have a source address, otherwise it's an infinite dependency loop.)

The "NH(src, dst)" you're describing is, well, destination-source routing, and it's partially (for default routes) brought in by RFC8028.  But it doesn't exist in 6724 in itself.  I've made the mistake of trying to implement rule 5.5 this way, in an earlier attempt for Linux.  It's not semantically equivalent to "flip the perspective" like this and it did not work as intended.

And this dovetails into:

> What Section 6.3.6 of RFC4861 says is: when selecting a next-hop, if you 
> have multiple options for the next-hop, and have one that is known to be 
> reachable, and one that isn't, then pick the one that is reachable.

Because you have to select the next-hop before evaluating source addresses in rule 5.5, selecting a non-working next-hop on the "NH(dst)" step is already disfavored.  It won't even get to "SRCS(NH(dst))" unless all next-hops are broken, or a more specific route for the destination applies.

(The "more specific route for the destination" case would stem from the broken router having sent a RIO before.  It's yet another tricky case to add to the pile, but I don't believe it's a showstopper.)

As a logical consequence of the above, I don't believe the rule 5.7 you're suggesting to add is needed.

Hope this helps,


equi
(David)