Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios

[Erik Kline <[e-mail]>]

On Wed, 20 Feb 2019 at 18:28, Fernando Gont <[e-mail]> wrote:

> On 20/2/19 23:01, Erik Kline wrote:
> [....]
> >     >
> >     >
> >     > Not receiving multicast RAs is not a condition you can really take
> any
> >     > action on.
> >
> >     Agreed.
> >
> >     The main issue I see with incorporating an explicit rule in RFC6724
> >     about "freshness" is that in multi-prefix scenarios, it's guaranteed
> >     that the default SA will oscillate among the different prefixes, and
> >     that if you only implement this workaround, you wouldn't be able to
> >     communicate with hosts actively employing your stale prefix.
> >
> >
> > that's where rule 5.5 would help (wherever it is actually implemented;
> > alas...)
>
> Not sure what you mean. How would rule 5.5. prevent SA oscillation or
> allow communication with the new "owner" of the stale prefix?
>

I don't know about "stale", but looking at it again now I think 5.5 doesn't
appear complete. I think an implementation would need to go further than
just select a srcaddr based on the next hop advertiser, but it would need
to remember to keep using that next hop for traffic originated with that
srcaddr until a router failure could be detected (NUD failure, is_router
flag flip, lifetime expiration, ...).  Non-trivial, actually.