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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks for all the responses. In this mail, I'll try to respond to
multiple replies.

On 2015/03/25 19:04 , Roman Mamedov wrote:
> ULA-only is not a breakage that needs to be fixed. The network
> simply has no connectivity with the global IPv6 Internet. However
> it might very well have links to other such "islands" managed by
> the user, by the means of a VPN over IPv4 Internet or some other
> technology such as private leased L2 links.

Note that the probes I'm talking about combine two issues: they have
only ULA addresses and they don't have a default route.

Without a default route, no IPv6 traffic will leave the probe (except
for traffic targeting other node in the onlink /64).

> Browsers and other client software will not try the ULA IP as
> outgoing bind address to connect to dual-stacked websites and
> services on the global Internet, so it does not cause any
> user-visible breakage either.

I forgot that RFC-6724 (Default Address Selection for Internet
Protocol Version 6) now explicitly lists ULAs, so indeed they would
not do any harm in trying to reach a dual-stack target.

> Nothing really surprising about this. There is simply no IPv6
> offered by the ISP, and many ISPs still do not begin to deploy IPv6
> and only promise (if even that) for months and years.

But is that a good reason for a CPE to start announcing IPv6 prefixes?

> And imagine some future IPv6-only client device. With ULA it could
> access local services of the user's LAN (for example files shared
> from a NAS), if there is no need for it to access anything on the
> Internet.  Trying to use LLs for this and lugging around
> "%interface" everywhere is not an acceptable answer.

Link local was supposed to solve the 'dentist office' problem where
there is no router. So that scenario is now dead?

On 2015/03/25 18:25 , Dickinson, Ian wrote:
> The answer IMHO is to treat ULAs in the same way as RFC1918 - ULA
> is
not just another global address.
> The IPv6 is not broken, but is simultaneously not available - so
treat it as having no IPv6 at all unless it has a global address.

Yes. The most generic way of dealing of dealing with this problem is
to look for a global address, i.e. for a probe with just a ULA to see
if it can perform any kind of operation that requires the use of a
global address. If that is successful then declare the probe as IPv6
capable. That should be future proof in case somebody wants to deploy
NAT66.

On 2015/03/25 19:05 , Jen Linkova wrote:> On Wed, Mar 25, 2015 at 5:31
> 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; )

Good question. I sort of assumed it would be done automatically by the
router. Otherwise I would get a tunnel. I'll if I can find out more.

> I do hope that this situation is not caused by ISPs using ULAs....

I assume we can rule that out because there is no default route.

>> 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?

The difference is that these probes get a full load of IPv6
measurements which all fail (and cannot succeed while there is no
default route). It may inflate IPv6 brokenness numbers.

> 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.

I wonder if this will cause problems with server software in the
future. I.e. a server finds a ULA and announces it one way or another.
And a host on a different site that also has ULA tries to use the
address and fails. Next iteration, the server software explicitly
ignores ULAs.

>> 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?

At the moment, IPv4 and IPv6 are treated differently. For IPv4 the
assumption is that lots of probes are behind NAT so the system tracks
local and global addresses. For IPv6, the current assumption is that
all addresses are global and there is no NAT.

Note that in general, a probe that has a RFC-1918 address also has a
default route. I'm not really aware of any exceptions. Whereas in this
case there is no default route. So it is quite clear that there is no
IPv6 connectivity.

On 2015/03/26 6:40 , Phillip Remaker wrote:
> 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)

Sounds like a good way forward to me.

On 2015/03/26 9:26 , Benedikt Stockebrand wrote:> Hi folks,
> just wondering: If I use RFC1918 addresses with IPv4 I might still
> have Internet access through a NAT gateway.  If I have only ULA,
> then I may reasonably expect there's no NAT, so there's a
> fundamental difference here.

Maybe the best way is to create feature-parity with IPv4 and support
IPv6 NAT as well. That would make both protocols from a RIPE Atlas
point of view more symmetric.

On 2015/03/26 10:24 , Pier Carlo Chiodi wrote:
> do you think it is worth considering to use different tags in order
> to describe different aspects? For example an "ipv6-ula-only" tag
> and an "ipv6-global-internet-reachability" tag.
> 
> Assigning the "IPv6 Doesn't Work" tag just on the basis of the
> ULA-only criteria would exclude those (few?) probes having ULA but
> also global IPv6 reachability, perhaps through some kind of NAT
> (NPTv6).

My proposal would mark probes that have only ULA but also lack a
default route as not IPv6 capable.

Without a default route, the probe is never going to perform any IPv6
measurements even if there would be a NAT box.

For probes that have ULA and do have a default route, it might be
worth tagging them. Though at the moment it is just dynamically
determined that IPv6 doesn't work based on actual measurements.

On 2015/03/26 13:12 , Peter Koch wrote:
> On Thu, Mar 26, 2015 at 10:24:54AM +0100, Pier Carlo Chiodi wrote:
>> behind an IPv6 NAT box. It also allows to have statistics on ULA
usage.
> 
> Atlas should be used as an Internet measurement tool, not as a
reconnaissance
> mechanism for the hosts' networks. ULA only equals "no IPv6" in my
opinion.

I agree that RIPE Atlas should not try to measure the probe host's
local network. But do we want to rule out support for NAT66? Or rule
out support for NAT66 at the moment and then support when it is in
actual use?

Philip


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlUUCPYACgkQ23LKRM64egK31wCfX8Aq3Xh/+sPcVaYY5f4ew6Z2
xrIAn3Iwn0ri7gpkKkv9mEEmDeO2SW4l
=3CFu
-----END PGP SIGNATURE-----