What to do with RIPE Atlas probes that have only a ULA as IPv6 address?
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-beli...) 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
On Wed, 25 Mar 2015 17:31:02 +0100 Philip Homburg <philip.homburg@ripe.net> wrote:
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.
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. E.g. using ULA addressing can be a comfortable way to start deploying IPv6 in a set of geographically diverse offices of a company, in case some of them don't have IPv6 from ISPs locally, and if the company is not large enough to afford/warrant the expense and bureaucracy of getting their own globally-routable IPv6 space assignment, at least initially. 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.
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.
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.
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.
No globally reachable IPv6, that's correct.
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?
Yes I believe they do. Link-local address aren't supposed to be used directly, e.g. you can't expect to be able to load a website served from an LL IPv6 in a browser. 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. Also routers these days come with something like "Open http://192.168.0.1/ in the web browser to configure" -- this causes a problem if the user's local network already uses the 192.168.0.0/24 as their network prefix, and moreover, the 192.168.0.1 IP is already taken for some production server (which seemed like a pretty logical thing to do addressing-wise at the time). Maybe in the future they could come with some random "http://[fd12:3456::1]/" ULA default IP instead, with the router also automatically RA'ing that ULA network on first power-up. The actual prefix could be random per router model or per manufacturer, ensuring little to no collisions.
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.
ULA (and not LL) are the perfect equivalent of RFC-1918 space. Even though no one should [even think to] set up NAT from/to them to GUA, there are still uses for a private prefix, for example due to it being totally ISP-independent and unchanging, allowing to set up static ACLs and DNS records. -- With respect, Roman
-----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-----
Hi, On Thu, Mar 26, 2015 at 02:26:14PM +0100, Philip Homburg wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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.
this would assume that a) the probes are supposed to follow RFC 6724. are they? b) they actually _do_ this (follow RFC 6724) in practice. can this be confirmed? [keeping the wide variety of potential IPv6 node behavior in mind] that said I concur with the approach laid out in an earlier mail by Philip: "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." best Enno -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator =======================================================
On 2015/03/26 15:42 , Enno Rey wrote:
On Thu, Mar 26, 2015 at 02:26:14PM +0100, Philip Homburg wrote:
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.
this would assume that
a) the probes are supposed to follow RFC 6724. are they? b) they actually _do_ this (follow RFC 6724) in practice. can this be confirmed? [keeping the wide variety of potential IPv6 node behavior in mind]
My statement was meant to reflect on whether announcing ULAs when there is only IPv4 internet connectivity would harm a 'normal' internet user. It was not meant to make a statement about the probes. Probes are complicated in this aspect. For some parts of the probe functionality the stub resolver in the c library is used. This is uClibc except on anchors where it is glibc. Then there are measurements where the probe has to resolve a name as part of the measurement. In that case, the stub resolver in libevent is used. Finally, for most of the measurements the probe receives IP addresses and not DNS names, so there is no issue with destination selection. For all measurements it is up to the Linux kernel to select a suitable source address. Note that all measurements are explicitly directed to measure either IPv4 or IPv6, so there can be no confusion there. Philip
Hi,
On 26 Mar 2015, at 14:42, Enno Rey <erey@ernw.de> wrote:
On Thu, Mar 26, 2015 at 02:26:14PM +0100, Philip Homburg wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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.
this would assume that
a) the probes are supposed to follow RFC 6724. are they? b) they actually _do_ this (follow RFC 6724) in practice. can this be confirmed? [keeping the wide variety of potential IPv6 node behavior in mind]
If RFC 6434 (IPv6 Node Requirements) is being followed then RFC 6724 (as RFC 3484-bis) MUST be followed. But older implementations may only support RFC 3484. Further, some implementations appear to do other things (as I believe OS X does, with its preferences for IPv4 vs IPv6). Tim
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 26 Mar 2015 14:26:14 +0100 Philip Homburg <philip.homburg@ripe.net> wrote:
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?
Sure, why not. Nobody is surprised when a CPE with no Internet uplinks configured or operating still provides DHCPv4 server to the LAN, giving out RFC-1918 IPs.
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.
They really don't. Barely any (if any at all) client software supports explicitly specifying the interface identifier along with the IP or hostname, or does so in a consistent manner. LL IPs are not usable in any form by the user, aside from pinging from the command line (and even then, it's bothersome to not forget to specify the interface all the time). Even if there's some mDNS in operation, the proverbial dentist still can't be expected to be typing "http://printer.local%eth0/" into their web browser (assuming that would have been supported in the first place...) - -- With respect, Roman -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlUUOW0ACgkQTLKSvz+PZwjsGgCcCLYysHqeJwNK+LrcTiFXwtFf BmQAn2d3QetdCRGw8mRh7Aq0FW8gww6Q =G6jE -----END PGP SIGNATURE-----
Hi,
On 26 Mar 2015, at 16:53, Roman Mamedov <rm@romanrm.net> wrote:
Signed PGP part On Thu, 26 Mar 2015 14:26:14 +0100 Philip Homburg <philip.homburg@ripe.net> wrote:
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?
Sure, why not. Nobody is surprised when a CPE with no Internet uplinks configured or operating still provides DHCPv4 server to the LAN, giving out RFC-1918 IPs.
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.
They really don't. Barely any (if any at all) client software supports explicitly specifying the interface identifier along with the IP or hostname, or does so in a consistent manner. LL IPs are not usable in any form by the user, aside from pinging from the command line (and even then, it's bothersome to not forget to specify the interface all the time).
Indeed.
Even if there's some mDNS in operation, the proverbial dentist still can't be expected to be typing "http://printer.local%eth0/" into their web browser (assuming that would have been supported in the first place…)
With the work in the IETF dnssd WG, such service discovery may happen over a wider scope (multi-link), see https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-00 <https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-00>. But the address advertised would then be greater scope too. Tim
On Wed, Mar 25, 2015 at 5:31 PM, Philip Homburg <philip.homburg@ripe.net> 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
Hi folks, Jen Linkova <furry13@gmail.com> writes:
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.
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. However, I personally *do* run my stuff through a firewall setup including application level gateways. So it might be argued that my ULA-only devices still have (some rather limited sort of) Internet access anyway. Cheers, Benedikt -- Benedikt Stockebrand, Stepladder IT Training+Consulting Dipl.-Inform. http://www.stepladder-it.com/ Business Grade IPv6 --- Consulting, Training, Projects BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Hi,
On 26 Mar 2015, at 08:26, Benedikt Stockebrand <bs@stepladder-it.com> wrote:
Hi folks,
Jen Linkova <furry13@gmail.com> writes:
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.
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.
However, I personally *do* run my stuff through a firewall setup including application level gateways. So it might be argued that my ULA-only devices still have (some rather limited sort of) Internet access anyway.
It would seem this is a good platform from which to see what types of connectivity devices with ULAs have, e.g. to get a guesstimate of NPTv6 deployment. Tim
If those probes with ULA, aren¹t able to connect to v6 Internet, for example using NPT, then should be considered as non-IPv6 enabled. IPv6 is not broken, is just meant for LAN connectivity. If ³broken² for you mean no-Internet connectivity, then is broken ;-) And yes, the CPE is doing the right thing, it has been configured to use an ULA to allow LAN IPv6 connectivity. Regards, Jordi -----Mensaje original----- De: Philip Homburg <philip.homburg@ripe.net> Responder a: <philip.homburg@ripe.net> Fecha: miércoles, 25 de marzo de 2015, 11:31 Para: "ripe-atlas@ripe.net" <ripe-atlas@ripe.net>, <ipv6-wg@ripe.net> Asunto: [ipv6-wg] What to do with RIPE Atlas probes that have only a ULA as IPv6 address?
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-b elieve-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
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
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@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-beli... )
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
Hi, On 2015-03-25 17:31, Philip Homburg 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.
[...]
Currently they are regarded as having broken IPv6 connectivity. However, an alternative is to consider those probes as having no IPv6 at all.
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). Different tags may offer a finer granularity on the probes selection process, for example it would allow to run tests on probes with ULA behind an IPv6 NAT box. It also allows to have statistics on ULA usage. At the same time it would be still possible to run measurements on "global-only" probes by selecting ipv6-global-internet-reachability and explicitly filtering out ipv6-ula-only. Regards, -- Pier Carlo Chiodi http://pierky.com
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. -Peter
On Thu, 26 Mar 2015 13:12:52 +0100 Peter Koch <pk@DENIC.DE> 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.
This is still within the scope of determining "are we on the Internet". If the probe only has an ULA, but gets a default (or a 2000::/3, etc) route, and a connection request to a GUA IP succeeds, then yes we are, nonwithstanding through which perverse NAT66 means the host has chosen to provide the connectivity. -- With respect, Roman
Peter Koch <pk@DENIC.DE> writes:
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 think it might be interesting to see what breaks (and what not) when ULA and some form of address translation is used. Jens -- ---------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@jabber.quux.de | --------------- | ----------------------------------------------------------------------------
On 3/25/15 5:31 PM, Philip Homburg wrote:
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?
hi, as atlas measures internet connectivity and reachability, as ula addresses should not be routable in internet, probes with (just) ula addresses should be ignored (and not considered as broken) -- antonio
On Thu, 26 Mar 2015 13:53:49 +0100 Antonio Prado <aprado@topnet.it> wrote:
On 3/25/15 5:31 PM, Philip Homburg wrote:
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?
hi,
as atlas measures internet connectivity and reachability, as ula addresses should not be routable in internet,
RFC-1918 addresses too.
probes with (just) ula addresses should be ignored
By that logic probes with just RFC-1918 IPs should not attempt any IPv4 measurements either. NAT66 is not (and should not be) common, however there is no harm in doing an inobtrusive check to see if it's deployed, or to collect stats on the scale of such deployments. -- With respect, Roman
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/26/15 2:31 PM, Roman Mamedov wrote:
By that logic probes with just RFC-1918 IPs should not attempt any IPv4 measurements either.
roman, I don't compare v6 to v4. atlas should deal with ipv4 (nat44) in a different manner than ipv6 (nat66) - -- antonio -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlUUFzIACgkQuwElOCdao3/ttgCfVEIH6hIJX/lCR0+cIbQpncSA 8VYAnjaMsr47z+/qEMp/WW9d20SLWo0K =St9D -----END PGP SIGNATURE-----
On Thu, Mar 26, 2015 at 9:31 PM, Roman Mamedov <rm@romanrm.net> wrote:
NAT66 is not (and should not be) common, however there is no harm in doing an inobtrusive check to see if it's deployed, or to collect stats on the scale of such deployments.
I am part of a team deploying IPv6 in S E Asia, for enterprises in their offices. As we do not have clarity on who the ISP will be, and this will change frequently till v6 availability stabilises, use of ULA is common. A NAT66 device is used much a normal IPv4 NAT gateway; the NAT66 means that if the upstream IPv6 prefix address changes, all the PCs do ot end up with new addresses. -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane
Hi, On 26.03.2015 15:37, Sanjeev Gupta wrote:
I am part of a team deploying IPv6 in S E Asia, for enterprises in their offices. As we do not have clarity on who the ISP will be, and this will change frequently till v6 availability stabilises, use of ULA is common. A NAT66 device is used much a normal IPv4 NAT gateway; the NAT66 means that if the upstream IPv6 prefix address changes, all the PCs do ot end up with new addresses.
Why would you bother with NAT66 in this case? I mean using ULA for local traffic (like printing, filesharing, building control etc.) seems fine to me. For global connectivity you could just use SLAAC or DHCPv6 as an additional address? Does it really matter, if these additional addresses change from time to time? Regards André
On Thu, Mar 26, 2015 at 10:49 PM, Andre Keller <ak@list.ak.cx> wrote:
On 26.03.2015 15:37, Sanjeev Gupta wrote:
I am part of a team deploying IPv6 in S E Asia, for enterprises in their offices. As we do not have clarity on who the ISP will be, and this will change frequently till v6 availability stabilises, use of ULA is common. A NAT66 device is used much a normal IPv4 NAT gateway; the NAT66 means that if the upstream IPv6 prefix address changes, all the PCs do ot end up with new addresses.
Why would you bother with NAT66 in this case? I mean using ULA for local traffic (like printing, filesharing, building control etc.) seems fine to me. For global connectivity you could just use SLAAC or DHCPv6 as an additional address? Does it really matter, if these additional addresses change from time to time?
The idea is to stay in known territory, and replicate what the client 's team knows first. With ULA and a NAT66 device, their network policies can be implemented "the way we have always done this"'; ie all outgoing allowed (mapped onto a unique global address, with the lower 64 bits the same), and all incoming blocked except where authorised. With IPv4, they use NAT and PAT. With IPv6, they no longer need to do PAT. At sometime in future, once they have experience with v6, hopefully a better-thought-out firewall policy can be implemented. -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane
Andre Keller <ak@list.ak.cx> writes:
Why would you bother with NAT66 in this case? I mean using ULA for local traffic (like printing, filesharing, building control etc.) seems fine to me. For global connectivity you could just use SLAAC or DHCPv6 as an additional address?
Using both ULA and global addresses may / will confuse some operating systems and applications. I haven't seen it for my self but while researching this topic for a customer all I found was "DO NOT DO THIS IT WILL BREAK THINGS!" Jens -- ---------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@jabber.quux.de | --------------- | ----------------------------------------------------------------------------
On Thu, 26 Mar 2015 16:43:31 +0100 Jens Link <lists@quux.de> wrote:
Using both ULA and global addresses may / will confuse some operating systems and applications. I haven't seen it for my self but while researching this topic for a customer all I found was "DO NOT DO THIS IT WILL BREAK THINGS!"
Nope it will absolutely not. Whatever you have been reading, was written either by a somewhat misinformed person (putting it mildly), or you maye have misread/misunderstood something. Feel free to provide any links to where this is claimed. -- With respect, Roman
On Thu, Mar 26, 2015 at 5:51 PM, Roman Mamedov <rm@romanrm.net> wrote:
On Thu, 26 Mar 2015 16:43:31 +0100 Jens Link <lists@quux.de> wrote:
Using both ULA and global addresses may / will confuse some operating systems and applications. I haven't seen it for my self but while researching this topic for a customer all I found was "DO NOT DO THIS IT WILL BREAK THINGS!"
Nope it will absolutely not.
This is a very strong statement ;)
Whatever you have been reading, was written either by a somewhat misinformed person (putting it mildly), or you maye have misread/misunderstood something.
Or those people have to deal with hosts which did not implemented RFC6724 and used default address selection algorithm as it is defined in RFC3483. -- SY, Jen Linkova aka Furry
On Thu, 26 Mar 2015 18:10:59 +0100 Jen Linkova <furry13@gmail.com> wrote:
researching this topic for a customer all I found was "DO NOT DO THIS IT WILL BREAK THINGS!"
Nope it will absolutely not.
This is a very strong statement ;)
Because it is true; and verified personally by usage of ULA+GUA for years on diverse server and client devices and operating systems. Not "something I read on the Internet".
Whatever you have been reading, was written either by a somewhat misinformed person (putting it mildly), or you maye have misread/misunderstood something.
Or those people have to deal with hosts which did not implemented RFC6724 and used default address selection algorithm as it is defined in RFC3483.
Perhaps you meant https://tools.ietf.org/html/rfc3484; and even by that RFC, the "longest-matching prefix" rule 8 would prevent ULA from being selected over GUA as the outgoing address for connection to a GUA IP in case when the node has both (as in the situation we're discussing now), since fc00::/7 has zero matching leading bits with 2000::/3. -- With respect, Roman
Hi,
On 26 Mar 2015, at 14:37, Sanjeev Gupta <ghane0@gmail.com> wrote:
On Thu, Mar 26, 2015 at 9:31 PM, Roman Mamedov <rm@romanrm.net <mailto:rm@romanrm.net>> wrote:
NAT66 is not (and should not be) common, however there is no harm in doing an inobtrusive check to see if it's deployed, or to collect stats on the scale of such deployments.
I am part of a team deploying IPv6 in S E Asia, for enterprises in their offices. As we do not have clarity on who the ISP will be, and this will change frequently till v6 availability stabilises, use of ULA is common. A NAT66 device is used much a normal IPv4 NAT gateway; the NAT66 means that if the upstream IPv6 prefix address changes, all the PCs do ot end up with new addresses.
Technically, I think you mean NPTv6, as per RFC 6296. It’s disappointing but not unexpected that sites are doing this. The homenet approach is that hosts are multi-addressed with ULA and globals. They use ULAs internally, which provides a decent level of renumbering protection, and globals externally. Having a single IP address is IPv4 thinking. Tim
On Fri, Mar 27, 2015 at 9:46 PM, Tim Chown <tjc@ecs.soton.ac.uk> wrote:
Technically, I think you mean NPTv6, as per RFC 6296. It’s disappointing but not unexpected that sites are doing this. The homenet approach is that hosts are multi-addressed with ULA and globals. They use ULAs internally, which provides a decent level of renumbering protection, and globals externally. Having a single IP address is IPv4 thinking.
Tim, thank you for the reference, we are using something close-to-but-not RFC6296. The reason we are not saying "RFC 6296" is that in the design that is being implemented, we do not want to claim compliance at all with a standard, but ask the client if he understands and approves of the design. We had an issue in an earlier implementation when the Windows server team was worried that nodes with two IPv6 addresses might pollute and confuce dynamic updates in the AD DNS. No one wanted to test this, rather than delay the IPv6 rollout, we dropped global IPs in the internal network. I am a vice-chair of the IPv6 Forum Singapore Chapter, and my focus is to roll out more and more IPv6. Numbers, Sir, not Quality! -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane
On 27 Mar 2015 9:13 am, "Sanjeev Gupta" <ghane0@gmail.com> wrote:
Technically, I think you mean NPTv6, as per RFC 6296. It’s disappointing but not unexpected that sites are doing this. The homenet approach is that hosts are multi-addressed with ULA and globals. They use ULAs internally, which provides a decent level of renumbering protection, and globals externally. Having a single IP address is IPv4 thinking.
Tim, thank you for the reference, we are using something close-to-but-not RFC6296.
That's not a recommended deployment strategy. A much better strategy is the one recommended by RFC 7368. Bear in mind that RFC 6296 is classified as experimental, and to my knowledge is not used by any other ISP in this way. IIRC it was originally rushed through the prices due to a very unique situation in Japan, and even there it is used to convert between two different global prefixes, not ULA. Using NPTv6 will break applications, such as video chat clients, which are built on the assumption that IPv6 does not use NAT and thus in IPv6 implement only firewall traversal but not NAT traversal. That assumption is true in the vast majority of IPv6 deployments, so those apps may never support this more of operation. Also - if you're using ULAs, be aware that ULAs are specified to be globally unique, i.e. all the ULA prefixes used in your network should be different from all the ULA prefixes used elsewhere in the world. ULA achieves this by requiring that ULA prefixes be generated randomly to avoid collisions. If you're not doing this, you may encounter other forms of breakage. "It works like this in IPv4" doesn't means it will work in IPv6. In IPv4, virtually everybody uses NAT. In IPv6, virtually nobody does. Why can't you provide global IPv6 addresses? Most IPv6 deployments have to deal with IPv6 prefix changes, and none that I'm aware of have chosen to use ULA as a result.
Philip Homburg <philip.homburg@ripe.net> writes:
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.
BTW: Are there any probes with site-local IPv6 addresses (fec0::/10). Yes I know site local is deprecated for many years (RFC3879 is from 2004) but some people still haven't noticed[1]. I also found some while checking the Alexa list for odd AAAA records[2]. Jens [1] Last year I bought this book http://www.ciscopress.com/store/cisco-asa-all-in-one-next-generation-firewal... and most of the IPv6 chapter explains site-local addressing. The book was published in 2014. [2] http://blog.quux.de/?p=1829 - I'll try update and improve this list next week -- ---------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@jabber.quux.de | --------------- | ----------------------------------------------------------------------------
On 2015/03/26 14:23 , Jens Link wrote:
BTW: Are there any probes with site-local IPv6 addresses (fec0::/10). Yes I know site local is deprecated for many years (RFC3879 is from 2004) but some people still haven't noticed[1]. I also found some while checking the Alexa list for odd AAAA records[2].
It looks like there are 11 probes that (also) have a site local address. It looks like some 6to4 device is causing it. Philip
participants (15)
-
Andre Keller -
Antonio Prado -
Benedikt Stockebrand -
Enno Rey -
Jen Linkova -
Jens Link -
JORDI PALET MARTINEZ -
Lorenzo Colitti -
Peter Koch -
Philip Homburg -
Phillip Remaker -
Pier Carlo Chiodi -
Roman Mamedov -
Sanjeev Gupta -
Tim Chown