Re: A common problem with SLAAC in "renumbering" scenarios

[Jan Zorz - Go6 <[e-mail]>]

Hi,

On 31/01/2019 13:11, Fernando Gont wrote:
>> Doesn't RFC7084 already say this? L-13.
> 
> Yes, and we missed this (thanks!). -- that said, we added this bullet
> for completeness sake. The case we care about in this doc is the reboot
> scenario.

However, RFC7084 is Informational and not Standard. I think this should 
make it into Standard. I've seen many CPE vendors saying "we found 
relevant standard documents and implemented whatever was a MUST and 
shipped the product."

A bit irresponsible in my view, but still a "valid" behaviour.

That being said - we need to be cautious that most probably just a MUST 
requirements will make it into CPEs at the end of the day.

>> When the new prefix is received it'll most likely have a higher
>> preferred and valid lifetime, so hosts should use the new prefix just by
>> means of them preferring the higher preferred lifetime of that PIO. So
>> the problem is a bit less than you write in the draft.
> 
> Nothing in the spec says preference is related to the "Preferred
> Lifetime" timer. i.e., an address is preferred, or it is not...

Exactly. We've observed all possible sort of behaviour in different 
stack implementations and lifetime is rarely taken into account.

If lifetime is > 0 then the address is valid, if lifetime == 0 then it's 
invalid and removed.

Not very useful in our case ;)

>> So while I am generally sympathetic to this draft and what it tries to
>> achieve (especially the part where it ties the router announcing
>> something to what it's later announcing, and lack of something means
>> it's implicitly zero preferred time for that), we need to figure out a
>> few more things first. RFC7084 was informational which made it fairly
>> easy to get through, now you're proposing a standards track document so
>> we need to make sure everything works. Changing all hosts is a big thing.
> 
> FWIW, I personally think the way to go is the host-side fix. You do want
> hosts to get smarter about this, and obviously cannot rely on the CPE to
> solve this for you.

Both places needs to be fixed. At the end of the day - CPE is in most 
cases your only device that is forwarding/routing packets towards the 
world and you need to rely that even old and ancient devices behind it 
can still function properly.

Cheers, Jan