-----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.
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
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: 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....
For the Atlas project, the question is how we should treat these
I assume we can rule that out because there is no default route. 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-----