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

[Erik Kline <[e-mail]>]

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

> Hi, Eric,
>
> On 20/2/19 22:12, Erik Kline wrote:
> >
> >
> > On Wed, 20 Feb 2019 at 17:07, Fernando Gont <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     On 20/2/19 06:36, Jen Linkova wrote:
> >     [...]
> >     >> Example:
> >     >>
> >     >> Say you have two network interfaces: If1 and If2.
> >     >> Say If1, is configured with 2001:db8:1::/64, and If2 with
> >     2001:db8:2::/64
> >     >>
> >     >> Say the first default router is that associated with If1.
> >     >>
> >     >> Say prefix 2001:db8:1::/64 stops being announced, or that you stop
> >     >> receiving RAs on If1, but RAs on If2 keep arriving fine.
> >     >>
> >     >> Based on the logic of your algorithm, one would expect that a new
> >     >> connection uses 2001:db8:2::/64/If2 (since that's the "more
> recently
> >     >> advertised information). However, Rule #5 would override that and
> >     make
> >     >> you employ 2001:db8:1::/64/If1, since Rule #5 prioritizes
> >     addresses on
> >     >> the outgoing interface.
> >     >
> >     > I'm even more confused now, sorry ;((
> >
> >     I was referring to the fact that some of the previous rules might
> >     prevent the evaluation of the rule about freshness. e.g.:
> >
> >     * You have two network interfaces eth0 and eth1 (say each connected
> to a
> >     different ISP)
> >     * eth0 has stopped receiving RAs
> >     * eth1 receives RAs as usual (hence all info associated with this
> >       interface is "fresher" than than corresponding to eth0)
> >     * The default router employed by eth0 has precedence (whether
> because it
> >       had a higher preference value, because it was the first one that
> was
> >       learned, or whatever)
> >     * When you evaluate the rules in RFC6724, rule 5 will say that the
> >       outgoing interface will be eth0, and thus you should pick an
> address
> >       associated with it --- however, as noted above, the addresses on
> eth1
> >       are fresher than those from eth1.
> >
> >
> > 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...)