From philip.homburg at ripe.net Wed Mar 25 17:31:02 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 25 Mar 2015 17:31:02 +0100 Subject: [ipv6-wg] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? Message-ID: <5512E2C6.7030205@ripe.net> 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 From furry13 at gmail.com Wed Mar 25 19:05:31 2015 From: furry13 at gmail.com (Jen Linkova) Date: Wed, 25 Mar 2015 19:05:31 +0100 Subject: [ipv6-wg] [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <5512E2C6.7030205@ripe.net> References: <5512E2C6.7030205@ripe.net> Message-ID: On Wed, Mar 25, 2015 at 5:31 PM, 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. > 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 From rm at romanrm.net Wed Mar 25 19:04:49 2015 From: rm at romanrm.net (Roman Mamedov) Date: Wed, 25 Mar 2015 23:04:49 +0500 Subject: [ipv6-wg] [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <5512E2C6.7030205@ripe.net> References: <5512E2C6.7030205@ripe.net> Message-ID: <20150325230449.058eb5fb@natsu> On Wed, 25 Mar 2015 17:31:02 +0100 Philip Homburg 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From jordi.palet at consulintel.es Wed Mar 25 19:19:30 2015 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 25 Mar 2015 13:19:30 -0500 Subject: [ipv6-wg] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <5512E2C6.7030205@ripe.net> References: <5512E2C6.7030205@ripe.net> Message-ID: 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 Responder a: Fecha: mi?rcoles, 25 de marzo de 2015, 11:31 Para: "ripe-atlas at 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. From remaker at gmail.com Thu Mar 26 06:40:51 2015 From: remaker at gmail.com (Phillip Remaker) Date: Wed, 25 Mar 2015 22:40:51 -0700 Subject: [ipv6-wg] [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <5512E2C6.7030205@ripe.net> References: <5512E2C6.7030205@ripe.net> Message-ID: 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 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: From bs at stepladder-it.com Thu Mar 26 09:26:40 2015 From: bs at stepladder-it.com (Benedikt Stockebrand) Date: Thu, 26 Mar 2015 08:26:40 +0000 Subject: [ipv6-wg] [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: (Jen Linkova's message of "Wed, 25 Mar 2015 19:05:31 +0100") References: <5512E2C6.7030205@ripe.net> Message-ID: <87twx8uptr.fsf@stepladder-it.com> Hi folks, Jen Linkova 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/ From pierky at pierky.com Thu Mar 26 10:24:54 2015 From: pierky at pierky.com (Pier Carlo Chiodi) Date: Thu, 26 Mar 2015 10:24:54 +0100 Subject: [ipv6-wg] =?utf-8?q?=5Batlas=5D_What_to_do_with_RIPE_Atlas_probes?= =?utf-8?q?_that_have_only_a_ULA_as_IPv6_address=3F?= In-Reply-To: <5512E2C6.7030205@ripe.net> References: <5512E2C6.7030205@ripe.net> Message-ID: 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 From tjc at ecs.soton.ac.uk Thu Mar 26 10:23:23 2015 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Thu, 26 Mar 2015 09:23:23 +0000 Subject: [ipv6-wg] [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <87twx8uptr.fsf@stepladder-it.com> References: <5512E2C6.7030205@ripe.net> <87twx8uptr.fsf@stepladder-it.com> <3BD718AB-F4EA-4E13-A589-652C793F8E43@ecs.soton.ac.uk> Message-ID: Hi, > On 26 Mar 2015, at 08:26, Benedikt Stockebrand wrote: > > Hi folks, > > Jen Linkova 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 From pk at DENIC.DE Thu Mar 26 13:12:52 2015 From: pk at DENIC.DE (Peter Koch) Date: Thu, 26 Mar 2015 13:12:52 +0100 Subject: [ipv6-wg] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: References: <5512E2C6.7030205@ripe.net> Message-ID: <20150326121252.GR12291@x28.adm.denic.de> 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 From aprado at topnet.it Thu Mar 26 13:53:49 2015 From: aprado at topnet.it (Antonio Prado) Date: Thu, 26 Mar 2015 13:53:49 +0100 Subject: [ipv6-wg] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <5512E2C6.7030205@ripe.net> References: <5512E2C6.7030205@ripe.net> Message-ID: <5514015D.8080403@topnet.it> 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 From rm at romanrm.net Thu Mar 26 13:45:15 2015 From: rm at romanrm.net (Roman Mamedov) Date: Thu, 26 Mar 2015 17:45:15 +0500 Subject: [ipv6-wg] [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <20150326121252.GR12291@x28.adm.denic.de> References: <5512E2C6.7030205@ripe.net> <20150326121252.GR12291@x28.adm.denic.de> Message-ID: <20150326174515.06a51dfa@natsu> On Thu, 26 Mar 2015 13:12:52 +0100 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. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From lists at quux.de Thu Mar 26 14:09:03 2015 From: lists at quux.de (Jens Link) Date: Thu, 26 Mar 2015 14:09:03 +0100 Subject: [ipv6-wg] [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <20150326121252.GR12291@x28.adm.denic.de> (Peter Koch's message of "Thu, 26 Mar 2015 13:12:52 +0100") References: <5512E2C6.7030205@ripe.net> <20150326121252.GR12291@x28.adm.denic.de> Message-ID: <87zj6zhpn4.fsf@pc8.berlin.quux.de> Peter Koch 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 at jabber.quux.de | --------------- | ---------------------------------------------------------------------------- From lists at quux.de Thu Mar 26 14:23:34 2015 From: lists at quux.de (Jens Link) Date: Thu, 26 Mar 2015 14:23:34 +0100 Subject: [ipv6-wg] [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <5512E2C6.7030205@ripe.net> (Philip Homburg's message of "Wed, 25 Mar 2015 17:31:02 +0100") References: <5512E2C6.7030205@ripe.net> Message-ID: <87vbhnhoyx.fsf@pc8.berlin.quux.de> Philip Homburg 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-firewall-ips-and-9781587143076 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 at jabber.quux.de | --------------- | ---------------------------------------------------------------------------- From philip.homburg at ripe.net Thu Mar 26 14:26:14 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 26 Mar 2015 14:26:14 +0100 Subject: [ipv6-wg] [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <20150325230449.058eb5fb@natsu> References: <5512E2C6.7030205@ripe.net> <20150325230449.058eb5fb@natsu> Message-ID: <551408F6.5030809@ripe.net> -----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----- From philip.homburg at ripe.net Thu Mar 26 14:53:23 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 26 Mar 2015 14:53:23 +0100 Subject: [ipv6-wg] [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <87vbhnhoyx.fsf@pc8.berlin.quux.de> References: <5512E2C6.7030205@ripe.net> <87vbhnhoyx.fsf@pc8.berlin.quux.de> Message-ID: <55140F53.2040604@ripe.net> 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 From rm at romanrm.net Thu Mar 26 14:31:00 2015 From: rm at romanrm.net (Roman Mamedov) Date: Thu, 26 Mar 2015 18:31:00 +0500 Subject: [ipv6-wg] [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <5514015D.8080403@topnet.it> References: <5512E2C6.7030205@ripe.net> <5514015D.8080403@topnet.it> Message-ID: <20150326183100.52b8ce28@natsu> On Thu, 26 Mar 2015 13:53:49 +0100 Antonio Prado 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From aprado at topnet.it Thu Mar 26 15:26:58 2015 From: aprado at topnet.it (Antonio Prado) Date: Thu, 26 Mar 2015 15:26:58 +0100 Subject: [ipv6-wg] [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <20150326183100.52b8ce28@natsu> References: <5512E2C6.7030205@ripe.net> <5514015D.8080403@topnet.it> <20150326183100.52b8ce28@natsu> Message-ID: <55141732.6010707@topnet.it> -----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----- From erey at ernw.de Thu Mar 26 15:42:39 2015 From: erey at ernw.de (Enno Rey) Date: Thu, 26 Mar 2015 15:42:39 +0100 Subject: [ipv6-wg] [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <551408F6.5030809@ripe.net> References: <5512E2C6.7030205@ripe.net> <20150325230449.058eb5fb@natsu> <551408F6.5030809@ripe.net> Message-ID: <20150326144239.GM61405@ernw.de> 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 ======================================================= From ghane0 at gmail.com Thu Mar 26 15:37:35 2015 From: ghane0 at gmail.com (Sanjeev Gupta) Date: Thu, 26 Mar 2015 22:37:35 +0800 Subject: [ipv6-wg] [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <20150326183100.52b8ce28@natsu> References: <5512E2C6.7030205@ripe.net> <5514015D.8080403@topnet.it> <20150326183100.52b8ce28@natsu> Message-ID: On Thu, Mar 26, 2015 at 9:31 PM, Roman Mamedov 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Thu Mar 26 16:30:33 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 26 Mar 2015 16:30:33 +0100 Subject: [ipv6-wg] [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <20150326144239.GM61405@ernw.de> References: <5512E2C6.7030205@ripe.net> <20150325230449.058eb5fb@natsu> <551408F6.5030809@ripe.net> <20150326144239.GM61405@ernw.de> Message-ID: <55142619.6020107@ripe.net> 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 From GeertJan.deGroot at xs4all.nl Thu Mar 26 22:44:10 2015 From: GeertJan.deGroot at xs4all.nl (Geert Jan de Groot) Date: Thu, 26 Mar 2015 22:44:10 +0100 Subject: [ipv6-wg] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: Your message of "Thu, 26 Mar 2015 09:10:32 +0100." Message-ID: As to the ATLAS-ULA discussion, here is a datapoint that may be interesting to some. After some network changes / upgrades, my probe was not happy with IPv6. For the built-in measurements, IPv4 was fine but all the IPv6 measurements were showing on-off behaviour with a cycle time of 2 hours. Initially I had no clue what was happening. Set up various IPv6 ping tests to the probe, and they were clean, and the measurements still showed the same outages. Also, measurements to other SLAAC clients were also spotless. While I was investigating something else however, I noticed these packets on the VDSL PPPoE-link to the ISP: 15:25:39.366673 IP6 fd0c:8f98:a1d2:80:6666:b3ff:fec5:dee.54536 > 2001:500:2d::d .53: 61413 TXT CHAOS? hostname.bind. (31) 15:25:41.911297 IP6 fd0c:8f98:a1d2:80:6666:b3ff:fec5:dee.46086 > 2001:500:2::c. 53: 64278 TXT CHAOS? hostname.bind. (31) Note the source address of these packets. Indeed, looking at the ATLAS portal, both the public IPv6 IP and ULA IP was listed on the info page of my probe, and the ULA IP didn't have connectivity. I diked out the ULA config on the OpenWRT router (not sure how it got there, probably PEBCAK but I didn't explicitely configure it), and things are a lot better now. Thanks to Philip for spotting the problem, Geert Jan From rm at romanrm.net Thu Mar 26 17:53:01 2015 From: rm at romanrm.net (Roman Mamedov) Date: Thu, 26 Mar 2015 21:53:01 +0500 Subject: [ipv6-wg] [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <551408F6.5030809@ripe.net> References: <5512E2C6.7030205@ripe.net> <20150325230449.058eb5fb@natsu> <551408F6.5030809@ripe.net> Message-ID: <20150326215301.336620ef@natsu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 26 Mar 2015 14:26:14 +0100 Philip Homburg 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----- From olivia at ripe.net Fri Mar 27 12:54:41 2015 From: olivia at ripe.net (Olivia Mijnals-Ruimwijk) Date: Fri, 27 Mar 2015 12:54:41 +0100 Subject: [ipv6-wg] [training] RIPE NCC Webinars - new dates Message-ID: <55154501.7090300@ripe.net> Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. We focus on the topics and issues most important for LIRs. Register now at https://lirportal.ripe.net/training/courses Participation is limited to 20 people, so don't hesitate if you want to take part! If you have questions, please email . We look forward to seeing you online. Kind regards, RIPE NCC Training Services From dave.wilson at heanet.ie Fri Mar 27 14:28:55 2015 From: dave.wilson at heanet.ie (Dave Wilson) Date: Fri, 27 Mar 2015 13:28:55 +0000 Subject: [ipv6-wg] [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <87twx8uptr.fsf@stepladder-it.com> References: <5512E2C6.7030205@ripe.net> <87twx8uptr.fsf@stepladder-it.com> Message-ID: <55155B17.2070705@heanet.ie> On 26/03/2015 08:26, Benedikt Stockebrand wrote: > Jen Linkova writes: >> 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. It's quite valid for a device to have a global address but not be connected to the internet; a network might need to be globally unique even if it's not globally reachable. It's rare in v4, and pretty rude in a time of scarcity, but it's technically valid. The question of whether a device is configured to be connected to the internet isn't answered by the scope of the address, but by the presence or absence of a default route. If a probe has ULA but no default route, that sounds to me like an entirely correct configuration. The behaviour Philip observes, where the system call fails immediately, is the desirable behaviour (and would cause a higher level application to fail over to IPv4.) So I think that the proposal is right to consider such a device "not connected to the IPv6 internet" as opposed to "improperly configured." (But I want to hedge on one thing: I'd like to still see the reason for the "not connected" decision recorded - i.e. no address vs. ULA but no default - so that we can see trends over time.) All the best, Dave -- Dave Wilson, Project Manager web: www.heanet.ie HEAnet Ltd, 5 George's Dock, IFSC, Dublin 1 tel: +353-1-660-9040 Registered in Ireland, no 275301 fax: +353-1-660-3666 From tjc at ecs.soton.ac.uk Fri Mar 27 14:44:24 2015 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Fri, 27 Mar 2015 13:44:24 +0000 Subject: [ipv6-wg] [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <20150326144239.GM61405@ernw.de> References: <5512E2C6.7030205@ripe.net> <20150325230449.058eb5fb@natsu> <551408F6.5030809@ripe.net> <20150326144239.GM61405@ernw.de> Message-ID: Hi, > On 26 Mar 2015, at 14:42, Enno Rey 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 From tjc at ecs.soton.ac.uk Fri Mar 27 14:46:56 2015 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Fri, 27 Mar 2015 13:46:56 +0000 Subject: [ipv6-wg] [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: References: <5512E2C6.7030205@ripe.net> <5514015D.8080403@topnet.it> <20150326183100.52b8ce28@natsu> <80D271B5-F723-442B-B2A5-90BF539B8544@ecs.soton.ac.uk> Message-ID: Hi, > On 26 Mar 2015, at 14:37, Sanjeev Gupta wrote: > > On Thu, Mar 26, 2015 at 9:31 PM, Roman Mamedov > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjc at ecs.soton.ac.uk Fri Mar 27 14:49:36 2015 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Fri, 27 Mar 2015 13:49:36 +0000 Subject: [ipv6-wg] [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: <20150326215301.336620ef@natsu> References: <5512E2C6.7030205@ripe.net> <20150325230449.058eb5fb@natsu> <551408F6.5030809@ripe.net> <20150326215301.336620ef@natsu> <202B3D0B-6B29-4506-A322-4A0FAC147BE8@ecs.soton.ac.uk> Message-ID: Hi, > On 26 Mar 2015, at 16:53, Roman Mamedov wrote: > > Signed PGP part > On Thu, 26 Mar 2015 14:26:14 +0100 > Philip Homburg 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 . But the address advertised would then be greater scope too. Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ghane0 at gmail.com Fri Mar 27 17:12:41 2015 From: ghane0 at gmail.com (Sanjeev Gupta) Date: Sat, 28 Mar 2015 00:12:41 +0800 Subject: [ipv6-wg] [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: References: <5512E2C6.7030205@ripe.net> <5514015D.8080403@topnet.it> <20150326183100.52b8ce28@natsu> <80D271B5-F723-442B-B2A5-90BF539B8544@ecs.soton.ac.uk> Message-ID: On Fri, Mar 27, 2015 at 9:46 PM, Tim Chown 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lorenzo at google.com Fri Mar 27 18:56:13 2015 From: lorenzo at google.com (Lorenzo Colitti) Date: Fri, 27 Mar 2015 12:56:13 -0500 Subject: [ipv6-wg] [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address? In-Reply-To: References: <5512E2C6.7030205@ripe.net> <5514015D.8080403@topnet.it> <20150326183100.52b8ce28@natsu> <80D271B5-F723-442B-B2A5-90BF539B8544@ecs.soton.ac.uk> Message-ID: On 27 Mar 2015 9:13 am, "Sanjeev Gupta" 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: