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

[Fernando Gont <[e-mail]>]

On 21/2/19 09:33, Philip Homburg wrote:
>> 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.
> 
> Assuming that only the preferred lifetime is changed quickly in response
> to receiving an RA, what problems do you expect with the oscillating 
> source addresses?

I don't expect *problems*. I do think that when problems arise,
undeterministic behaviour makes trouble-shooting way more painful.



> As far as I know, there exist NATs for IPv4 that distribute traffic over
> multiple public IPv4 addresses. That seems to work.
> 
> I don't know if there are IPv6 stacks that distribute traffic over multiple
> addresses that all have preferred lifetime > 0, but as far as I know, that
> is allowed.

It is certainly allowed. However, troubleshooting becomes way more painful.

Depending on the timing of RAs, it could mean that a specific source
address next-hop is employed for a very short window of time. When such
next-hop fails, network problems become intermitent.

I'd expect that if load is to be shred among RAs, it happens in some
sort of deterministic fashion (i.e., it is quite clear and explicit that
default routers are selected in round-robin fashion, or that one
next-hop is employed only if another fails).

Another draw-back of this approach is that since "longest-match" becomes
the last rule (after freshness), then it is quite likely that you might
not end up using the best bath to the destination -- since you
prioritize freshness over longest match.

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