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

[Fernando Gont <[e-mail]>]

On 31/1/19 08:47, Mikael Abrahamsson wrote:
> On Thu, 31 Jan 2019, Fernando Gont wrote:
> 
>> Any comments will be welcome.
> 
> "   o  A CPE MUST record, on stable storage, the list of prefixes being
>       advertised on each LAN segment."
> 
> This is not always doable as some devices have very small flash with no
> write-leveling, so doing this generally might ruin the flash cells on
> some devices. This above requirement will drive cost, especially in the
> low end market of HGWs.

I agree 100% percent, for exact reason you point out. In fact, we
discussed whether making this a SHOULD, MUST, or not having any
normative language about this one at all. Our reasoning was that CPEs
not implementing this would simply not claim compliance with this spec.

Me, I agree with you that CPEs wouldn't do this in practice, and also
that the place to solve this is on the host side -- for robustness reasons.

Any proposal on how to address your comment? -- Include the reasoning
above? s/MUST/SHOULD/? Remove any normative language for this one?



> 
>       *  Any prefixes that were previously advertised via SLAAC, but
>          that are not currently intended for address configuration, MUST
>          be advertised with a PIO option with the "A" bit set to 1 and
>          the "Valid Lifetime" and a "Preferred Lifetime" set to 0.
> 
> 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.


> Another comment, typically the lifetime of the LAN PIO is capped at the
> DHCPv6-PD WAN lease time. I couldn't find this requirement in RFC7084,
> but I only searched for "lifetime". Anyhow, Openwrt does this and might
> be good to mention.

Very good point. Will do in the next rev.



> 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...

FWIW, this problem came to my radar as a result of an ISP asking for
help on how to address this.


> 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.

While one might get away with an Informational document that specifies
this -- v6ops has done this for RA-related stuff, I think the best and
proper way to do it is with a std track document.

But, of course, the point of posting the I-D is to see what other folks
think....

Thanks!

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