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

[Tim Chown <[e-mail]>]

On 21 Feb 2019, at 02:01, Erik Kline <[e-mail]<mailto:[e-mail]>> wrote:

On Wed, 20 Feb 2019 at 17:49, Fernando Gont <[e-mail]<mailto:[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]>
> <mailto:[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...)

Yeah.... we did add an explicit pointer to this in the Nodes Requirements -bis, fwiw (noting RFC 8028).

Tim