This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[ipv6-wg] Mitigating the effects of SLAAC renumbering events (draft-ietf-6man-slaac-renum)
- Previous message (by thread): [ipv6-wg] RFC 9288 on Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers
- Next message (by thread): [ipv6-wg] Mitigating the effects of SLAAC renumbering events (draft-ietf-6man-slaac-renum)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Fernando Gont
fgont at si6networks.com
Wed Aug 31 12:34:32 CEST 2022
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-the-robustness-of-stateless-address-autoconfiguration-slaac-to-flash-renumbering-events-00) 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 at si6networks.com PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
- Previous message (by thread): [ipv6-wg] RFC 9288 on Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers
- Next message (by thread): [ipv6-wg] Mitigating the effects of SLAAC renumbering events (draft-ietf-6man-slaac-renum)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]