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

[Brian E Carpenter <[e-mail]>]

On 2019-02-21 15:01, Erik Kline 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...)

That's also why we made rule 5.5 a SHOULD in RFC 8028.

   Brian