Re: [atlas] IPv6-renew
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
Re: [atlas] IPv6-renew
Ole Troan wrote on 21/06/2021 11:11: To be correct; it's an operational issue. SLAAC works as designed with IPv6 renumbering. slaac - being stateless 'n all - was not designed with flash renumbering in mind because flash renumbering needs some degree of state synchronisation on all devices on the path between the provisioning system issuing the prefix and the end device. So in this sense it is a protocol issue, albeit an issue that was outside the design scope of the protocol. Imagine if the mobile operator swapped your mobile phone number midstream. mobile phone numbers are stateful. You don't need to change phone number every time you're handed off to a different cell. Nick
Re: [atlas] IPv6-renew
>> 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 signature.asc Description: Message signed with OpenPGP
Re: [atlas] IPv6-renew
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
Re: [atlas] Is there a definitive guide to firewall rules?
On 2021-06-20 17:22, Peter Garner (iPad) wrote: Noob question. I set up a software probe a couple of days ago on a Linux box that uses Universal FireWall (UFW). I've no problem with the required internal ports and the probe seems to be working as intended but would like to know if there's a definitive list of ports and protocols that I can apply to get the maximum benefit to the data? Hello, There's an entry in the FAQ (https://atlas.ripe.net/about/faq/): So which services do I need for my probe to work? The absolute minimum set is DHCP, DNS and outgoing TCP port 443 (HTTPS) in order to allow the probe to connect to the network. However, this in itself is not enough to do measurements, which is the entire focus of RIPE Atlas. The more kinds of outgoing traffic you allow, the more measurements will have a chance of succeeding. So please, at a minimum, also permit outgoing ICMP, UDP (DNS + traceroute + NTP) and TCP for traceroute and HTTP(S). Permitting outgoing DNS to any server is a must in order to be useful for non-local-resolver queries. For incoming traffic: the probes don't provide real accessible services, so incoming ICMP/ping and UDP/traceroute should be enough. I hope this helps, Robert
Re: [atlas] IPv6-renew
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
Re: [atlas] IPv6-renew
On Mon, 21 Jun 2021 at 08:20, Marco Davids (IETF) via ripe-atlas 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
