[ipv6-wg] [atlas] What to do with RIPE Atlas probes that have only a ULA as IPv6 address?
Roman Mamedov rm at romanrm.net
Wed Mar 25 19:04:49 CET 2015
On Wed, 25 Mar 2015 17:31:02 +0100 Philip Homburg <philip.homburg at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: <https://lists.ripe.net/ripe/mail/archives/ipv6-wg/attachments/20150325/1f04fa36/attachment.sig>
[ ipv6-wg Archives ]