March 2015 - ipv6-wg - mailman.ripe.net

What to do with RIPE Atlas probes that have only a ULA as IPv6 address?
by Philip Homburg 27 Mar '15

27 Mar '15

Dear community members, The RIPE Atlas team has a question what to do with probes that have only a Unique Local IPv6 Unicast Address (ULA) [RFC4193] as their IPv6 address. The question is whether to treat those probes as IPv6 capable or not. It is known that about 10% of the RIPE Atlas probes that have IPv6 addresses do not actually have IPv6 connectivity. This was documented by Stéphane Bortzmeyer in his RIPE Labs article "How Many RIPE Atlas Probes Believe They Have IPv6 (But Are Wrong)?" (https://labs.ripe.net/Members/stephane_bortzmeyer/how-many-atlas-probes-bel…) As a way of dealing with this problem, the RIPE Atlas system now tags probes that have broken IPv6. Any probe that has an IPv6 address (other than link local) but cannot reach the global internet is tagged as "IPv6 Doesn't Work" (see https://atlas.ripe.net/docs/probe-tags/) At the moment, around 2800 probes are connected and have an IPv6 address. Of those probes, around 350 (12.5%) are tagged that IPv6 doesn't work. Of those 350 probes, 114 have the surprising condition that the connect system call fails immediately with the error 'Network is unreachable.' Those 114 probes have two things in common, they have only a ULA address and the do not have a default route. It is the lack of default route that causes the connect system call to fail immediately. This feature (ULA and no default route) is specified in RFC-7084 (IPv6 CE Router Requirements) requirement ULA-5 ("An IPv6 CE router MUST NOT advertise itself as a default router with a Router Lifetime greater than zero whenever all of its configured and delegated prefixes are ULA prefixes.") The surprising thing is that for some probes this condition persists for many months. For the Atlas project, the question is how we should treat these probes. Currently they are regarded as having broken IPv6 connectivity. However, an alternative is to consider those probes as having no IPv6 at all. Broader questions are: are CPEs doing the right thing here. Should a CPE announce a ULA on the local LAN even if there hasn't been any IPv6 internet connectivity for a very long time? It is already complex enough for normal users to understand that there is always a link local IPv6 address even if there is no IPv6 connectivity. Now we have to add ULA to that group as well. So the question to the community, should RIPE Atlas treat ULAs in the same way as RFC-1918, addresses that should be ignored unless a valid global address can be found elsewhere. Or should we keep the current approach where ULAs are treated just like other global IPv6 addresses and consider the probe host's network setup to be broken? Philip

15 26

[training] RIPE NCC Webinars - new dates
by Olivia Mijnals-Ruimwijk 27 Mar '15

27 Mar '15

Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. We focus on the topics and issues most important for LIRs. Register now at https://lirportal.ripe.net/training/courses Participation is limited to 20 people, so don't hesitate if you want to take part! If you have questions, please email <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 0

Re: [ipv6-wg] What to do with RIPE Atlas probes that have only a ULA as IPv6 address?
by Geert Jan de Groot 26 Mar '15

26 Mar '15

As to the ATLAS-ULA discussion, here is a datapoint that may be interesting to some. After some network changes / upgrades, my probe was not happy with IPv6. For the built-in measurements, IPv4 was fine but all the IPv6 measurements were showing on-off behaviour with a cycle time of 2 hours. Initially I had no clue what was happening. Set up various IPv6 ping tests to the probe, and they were clean, and the measurements still showed the same outages. Also, measurements to other SLAAC clients were also spotless. While I was investigating something else however, I noticed these packets on the VDSL PPPoE-link to the ISP: 15:25:39.366673 IP6 fd0c:8f98:a1d2:80:6666:b3ff:fec5:dee.54536 > 2001:500:2d::d .53: 61413 TXT CHAOS? hostname.bind. (31) 15:25:41.911297 IP6 fd0c:8f98:a1d2:80:6666:b3ff:fec5:dee.46086 > 2001:500:2::c. 53: 64278 TXT CHAOS? hostname.bind. (31) Note the source address of these packets. Indeed, looking at the ATLAS portal, both the public IPv6 IP and ULA IP was listed on the info page of my probe, and the ULA IP didn't have connectivity. I diked out the ULA config on the OpenWRT router (not sure how it got there, probably PEBCAK but I didn't explicitely configure it), and things are a lot better now. Thanks to Philip for spotting the problem, Geert Jan

1 0