Hi, Whenever my network get's a different IPv6-prefix from my provider (which happens every now and then), the probe is flagged down in the dashboard. The reason seems to be that RIPE Atlas probes are unable to renew their (SLAAC?) IPv6-addresses when needed. Only solution is a powercycle. Is this a flaw, or is it by design? -- Marco
On Mon, 21 Jun 2021 at 08:20, Marco Davids (IETF) via ripe-atlas <ripe-atlas@ripe.net> wrote:
Whenever my network get's a different IPv6-prefix from my provider (which happens every now and then), the probe is flagged down in the dashboard.
Does the delegated v6 prefix only change when your router power-cycles the wan facing (upstream) interface? Or is the pfx change scheduler based (i.e. timer/scheduler based)? -- Chriztoffer
Op 21-06-21 om 09:38 schreef Chriztoffer Hansen:
Whenever my network get's a different IPv6-prefix from my provider (which happens every now and then), the probe is flagged down in the dashboard.
Does the delegated v6 prefix only change when your router power-cycles the wan facing (upstream) interface? Or is the pfx change scheduler based (i.e. timer/scheduler based)?
I believe it only happens after a reboot due to firmware upgrades or otherwise. Not sure why, but recently this seems to occur more than before. Previously my prefix seemed to have a bigger change of surviving such a reboot. Router is an Arris ConnectBox TG2492LG-ZG from Dutch ISP Ziggo. -- Marco
Am 21.06.21 um 08:20 schrieb Marco Davids (IETF) via ripe-atlas:
Hi,
Whenever my network get's a different IPv6-prefix from my provider (which happens every now and then), the probe is flagged down in the dashboard.
The reason seems to be that RIPE Atlas probes are unable to renew their (SLAAC?) IPv6-addresses when needed. Only solution is a powercycle.
Is this a flaw, or is it by design?
I have had similar problems - even if I change a probe quickly between different LANs/ISPs. I assume you talk about a hardware probe (the behavior on software probes is out of control of ripe). Recognizing the new network takes a while. But in the end, I think it is a flaw of your router. It should withdraw the old prefix by using reasonable life times/ zero life times. Here is an example with a hw probe and ~daily reconnects. The measured disconnected time is between 2 and 5 minutes usually. I think that's ok. https://atlas.ripe.net/probes/53236/#tab-network Regards, Thomas
Marco Davids (IETF) via ripe-atlas wrote on 21/06/2021 07:20:
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. Nick
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
participants (6)
-
Chriztoffer Hansen -
Marco Davids -
Marco Davids (IETF)
-
Nick Hilliard (INEX) -
ot＠cisco.com -
Thomas Schäfer