Mitigating the effects of SLAAC renumbering events (draft-ietf-6man-slaac-renum)
fgont at si6networks.com
Wed Aug 31 10:35:17 UTC 2022
We have been discussing the potential problems associated with SLAAC
renumbering events for a while now -- one of the most common cases being
ISPs rotating home prefixes, and your devices ending up with
We have done quite a bit of work already:
* Problem statement: https://datatracker.ietf.org/doc/html/rfc8978
* CPE recommendations: https://datatracker.ietf.org/doc/html/rfc9096
But there's still some work to do to address this issue: The last
remaining it is to improve SLAAC such that hosts can more gracefully
deal with this renumbering events.
In that light, IETF's 6man has been working on this document:
And we have proposed a simple algorithm for SLAAC (an extension, if you
wish) that can easily help, as follows:
If you (host) receive an RA that contains options, but not all
of the previously-received options/information, simply send a
unicast RS to the local-router, to verify/refresh that such missing
information is still valid. If the information is stale, get rid of
I presented this algorithm at the last IETF meeting
(You may find the slides here:
Finally, I've sent draft text for the specification of the algorithm
We would be super thankful if you could take a look at the draft text
and provide feedback/comments.
If you can post/comment on the 6man wg mailing list
(https://www.ietf.org/mailman/listinfo/ipv6), that´d be fabulous.
But we'll appreciate your feedback off-line, on this list, etc. (that'd
still be great ;-) )
Thanks in advance!
e-mail: fgont at si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
More information about the NANOG