On Wed, Mar 25, 2015 at 5:31 PM, Philip Homburg <[email protected]> wrote: > 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.
> 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. One of the possible reasons might be that a home network does not have IPv6-enabled uplink but ULAs are used for internal connectivity. I actually did it at my place at some point, when I wanted to have Ipv6-enalbed LAN but my ISP did not provide me with v6 connectivity. 114 out of 350 does look like a lot (on the other hand a lot of probes are hosted by network people who love to play with their home networks; ) I do hope that this situation is not caused by ISPs using ULAs.... > 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. What difference does it make? > 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. If ULA is configured in a CPE, then it should be announced in RAs. As long as it does not break v6 for users (and it should not as there is not default route), it's fine. > 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? But wait, if a probe has RFC1918 addresses only you do not mark it as 'no v4 connectivity', right? If a probe has a address of a global scope (v4 or v6) but could not reach the outside world it means the connectivity is broken. So IMHO it makes slightly more sense to mark ULA-only probes as having broken connectivity. But, again, could you please clarify what is the difference between two tags from practical perspective? -- SY, Jen Linkova aka Furry
