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

[Fernando Gont <[e-mail]>]

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.

Other cases might be if an interface has a stale ULA address one one
interface, and a fresh one on another. You might end up using the stale
ULA becase the rules about scope and "use addresses from the outgoing
interface" take precedence over the rule about freshness.

I do agree that these might be considered corner cases which might be
unimportant for scenarios where we only deal with GUAs, or at least only
GUAs become stale.


Note (that I forgot to mention in a previous email): Many
implementations limit the number of prefixes they may use for address
configuration. I seem to recall that some implementations limit them to
16. If you don't do "garbage collection" for the stale addresses (remove
stale addresses when there's some sort of indication that they are
stale), then you might end up in a scenario where stale addresses take
all the available "slots" for address configuration, and you don't have
room for configuring addresses for the fresh prefixes. With the default
Valid Lifetimes of 1 month, this is certainly a concern: if the prefix
changes 16 times in a month, without explicit signaling to remove the
stale addresses, you might be unable to configure addresses for the
fresh prefixes.

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