Improved support for IPv6 SLAAC renumbering events
In scenarios where network configuration information related to IPv6 prefixes becomes invalid without any explicit signaling of that condition (such as when a Customer Edge Router crashes and reboots without knowledge of the previously-employed prefixes), hosts on the local network will continue using stale prefixes for an unacceptably long period of time, thus resulting in connectivity problems. These issues are discussed in IETF I-D draft-ietf-v6ops-slaac-renum.
We have submitted a proposal to improve the reaction of SLAAC to renumbering events in IETF I-D draft-gont-6man-slaac-renum.
The proposal include multiple (mostly-orthogonal) improvements:
-
Reduce the default Valid Lifetime and Preferred Lifetime of PIOs (Section 4.1.1): This helps limit the amount of time a host will employ stale information, and also limits the amount of time a router needs to try to obsolete stale information.
-
Cap the received Valid Lifetime and Preferred Lifetime of PIOs (Section 4.1.2): This helps limit the amount of time a host will employ stale information, even in the presence of legacy ([RFC4861]) routers.
-
Honor PIOs with small Valid Lifetimes (Section 4.2): This allows routers to invalidate stale prefixes, since otherwise [RFC4861] prevents hosts from honoring PIOs with a Valid Lifetime smaller than two hours.
-
Recommend routers to retransmit configuration information upon interface initialization/reinitialization (Section 4.3): This helps spread the new information in a timelier manner, and also deprecate stale information via host-side heuristics (see Section 4.5).
-
Recommend routers to always send all options (i.e. the complete configuration information) in RA messages, and in the smallest possible number of packets (Section 4.4): This helps propagate the same information to all hosts, and also allows hosts to better infer that information missing in RA messages has become stale (see Section 4.5).
-
Infer stale network configuration information from received RAs (Section 4.5): This allows hosts to deprecate stale network configuration information, even in the absence of explicit signaling.
I'm not familiar with the NetworkManager code. But if you find the proposed improvements/mitigations sensible, I may commit some time to implement at least some of them for Network Manager.