On Wed, 25 Mar 2015 17:31:02 +0100 Philip Homburg <[email protected]> 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
signature.asc
Description: PGP signature
