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/ripe-atlas@ripe.net/
[atlas] IPv6-renew
- Previous message (by thread): [atlas] IPv6-renew
- Next message (by thread): [atlas] IPv6-renew
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
ot at cisco.com
ot at cisco.com
Mon Jun 21 12:25:12 CEST 2021
>> Is this a flaw, or is it by design? > > this is a known protocol issue with slaac. There's some discussion about it in rfc8978 and draft-ietf-6man-slaac-renum. To be correct; it's an operational issue. SLAAC works as designed with IPv6 renumbering. Imagine if the mobile operator swapped your mobile phone number midstream. Support for ephemeral addressing (aka flash renumbering) is quite involved. The mobile phone stacks have largely managed to do that, but for all else it involves transitioning away from TCP, updating all apps etc... Not surprising that the probe takes a few minutes to detect and adjust. Best regards, Ole -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: </ripe/mail/archives/ripe-atlas/attachments/20210621/250d0897/attachment.sig>
- Previous message (by thread): [atlas] IPv6-renew
- Next message (by thread): [atlas] IPv6-renew
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]