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

[Fernando Gont <[e-mail]>]

On 21/2/19 07:41, Tim Chown wrote:
>> 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).

Probably an irrelevant question to ask now :-), but, anyway: any clues
why RFC8028 is a "SHOULD" rather than "MUST"? -- It would seem to me you
cannot really do multi-prefix without RFC8028...

-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492