[ipv6-wg] [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address?

My vote: Devices with ULA only should be regarded as having no IPv6 at all
unless an active test can demonstrate connectivity (as in, through an NPTv6
device)

RIPE Atlas acts as a connectivity observatory.  A ULA is the equivalent of
an unconnected node.  It is not broken; it is, by design, limited to local
connectivity, and should always be that way.

If a device has no global IPv6 address, it should be regarded as IPv6
incapable, not IPv6 broken.

The situation where my probes have ULA:  An upstream Linksys router
supports IPv6 and provides a ULA.  Since it has no connectivity from the
MSO, it does not provide a global address.  It may provide site-local IPv6
routing, but never IPv6 Internet routing.  Therefore, it should be regarded
as not IPv6 capable.

There may be an NPTv6 gateway that will provide IPv6 connectivity for ULA
devices, but I will argue that this is less common that the home router
providing unrouteable ULA.  However, that case NPTv6 should be readily
detectable.

RE: Are CPEs doing the right thing - the HOMENET IETF group is very
concerned about that question, and actively wrestling with it.
https://datatracker.ietf.org/wg/homenet/documents/

On Wed, Mar 25, 2015 at 9:31 AM, Philip Homburg <philip.homburg at ripe.net>
wrote:

> 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-believe-they-have-ipv6-but-are-wrong
> )
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/ipv6-wg/attachments/20150325/94fec8ff/attachment.html>