Mitigating the effects of SLAAC renumbering events (draft-ietf-6man-slaac-renum)
Folks, 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 stale/invalid addresses. 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: https://www.ietf.org/archive/id/draft-ietf-6man-slaac-renum-04.txt 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 it. I presented this algorithm at the last IETF meeting (https://youtu.be/eKEizC8xhhM?t=1308). (You may find the slides here: https://datatracker.ietf.org/meeting/114/materials/slides-114-6man-improving...) Finally, I've sent draft text for the specification of the algorithm here: https://mailarchive.ietf.org/arch/msg/ipv6/KD_Vpqg0NmkVXOQntVTOMlWHWwA/ We would be super thankful if you could take a look at the draft text (i.e., https://mailarchive.ietf.org/arch/msg/ipv6/KD_Vpqg0NmkVXOQntVTOMlWHWwA/) 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! Regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
Hi all, The router could split information between RAs (and send it at different intervals). It may be difficult to guess what is stale and what is just "not in this RA". Fernando proposing (not documented yet in draft-ietf-6man-slaac-renum-04) re-asking the router by RS and using timers (size of timers is not proposed yet) To guess that router has probably supplied the full set of information And we could start concluding what is stale. There is an alternative proposal to signal by ND flag that "this RA has the complete set of information" https://datatracker.ietf.org/doc/html/draft-vv-6man-nd-prefix-robustness-02 ... then you could immediately make your reliable conclusion on what is stale. IMHO: Clear signaling that "information is complete in this RA" is better than guessing by timers. It is the more robust solution. We need to sync the state between the host and just rebooted the router. If you have an opinion on this matter, Please send a message to ipv6@ietf.org Thanks. Eduard -----Original Message----- From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei.com@nanog.org] On Behalf Of Fernando Gont Sent: Wednesday, August 31, 2022 1:35 PM To: nanog@nanog.org Subject: Mitigating the effects of SLAAC renumbering events (draft-ietf-6man-slaac-renum) Folks, 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 stale/invalid addresses. 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: https://www.ietf.org/archive/id/draft-ietf-6man-slaac-renum-04.txt 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 it. I presented this algorithm at the last IETF meeting (https://youtu.be/eKEizC8xhhM?t=1308). (You may find the slides here: https://datatracker.ietf.org/meeting/114/materials/slides-114-6man-improving...) Finally, I've sent draft text for the specification of the algorithm here: https://mailarchive.ietf.org/arch/msg/ipv6/KD_Vpqg0NmkVXOQntVTOMlWHWwA/ We would be super thankful if you could take a look at the draft text (i.e., https://mailarchive.ietf.org/arch/msg/ipv6/KD_Vpqg0NmkVXOQntVTOMlWHWwA/) 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! Regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
Hi, On 31/8/22 09:43, Vasilenko Eduard wrote:
Hi all,
The router could split information between RAs (and send it at different intervals). It may be difficult to guess what is stale and what is just "not in this RA".
You ask the router, and the router responds. If you want to consider the case where the router intentionally splits the options into multiple packets (which does not exist in practice), AND the link is super lossy, you just increase the number of retransmissions. There's no guessing. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
Such router behavior is completely legal by ND RFC. It does not matter that real routers implementations do not do this. We should think that they do because the standard permits it. And the RA in the chain may be lost. It is better to attach information about completeness to the information itself. Eduard -----Original Message----- From: Fernando Gont [mailto:fgont@si6networks.com] Sent: Wednesday, August 31, 2022 4:12 PM To: Vasilenko Eduard <vasilenko.eduard@huawei.com>; nanog@nanog.org Subject: Re: Mitigating the effects of SLAAC renumbering events (draft-ietf-6man-slaac-renum) Hi, On 31/8/22 09:43, Vasilenko Eduard wrote:
Hi all,
The router could split information between RAs (and send it at different intervals). It may be difficult to guess what is stale and what is just "not in this RA".
You ask the router, and the router responds. If you want to consider the case where the router intentionally splits the options into multiple packets (which does not exist in practice), AND the link is super lossy, you just increase the number of retransmissions. There's no guessing. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
participants (2)
-
Fernando Gont -
Vasilenko Eduard