Most of you know FOSDEM already, for those who don’t, it’s the largest Free and Open Source Software focused conference in Europe (if not the world.) If you haven’t been to it I definitely suggest it, particularly because it’s a free admission conference and it always has something interesting to discuss.
Even though there is no ticket and no badge, the conference does have free WiFi Internet access, which is how the number of attendees is usually estimated. In the past few years, their network has also been pushing the envelope on IPv6 support, first providing a dualstack network when IPv6 was fairly rare, and in the recent (three?) years providing an IPv6-only network as the default.
I can see the reason to do this, in the sense that a lot of Free Software developers are physically at the conference, which means they can see their tools suffer in an IPv6 environment and fix them. But at the same time, this has generated lots of complaints about Android not working in this setup. While part of that noise was useful, I got the impression this year that the complaints are repeated only for the sake of complaining.
Full disclosure, of course: I do happen to work for the company behind Android. On the other hand, I don’t work on anything related at all. So this post is as usual my own personal opinion.
The complaints about Android started off quite healthy: devices couldn’t actually connect to an IPv6 dual-stack network, and then they couldn’t connect to a IPv6-only network. Both are valid complaints to begin with, though there is a bit more to it. This year in particular the complaints were not so healthy because current versions of Android (6.0) actually do support IPv6-only networks, though most of the Android devices out there are not running this version, either because they have too old hardware or because the manufacturer has not released a new build yet.
What does tick me though has really nothing to do with Android, but rather with the idea that people have that the current IPv6-only setup used by FOSDEM is a realistic approach to IPv6 networking — it really is not. It is a nice setup to test things out and stress the need for proper support for IPv6 in tools, but it’s very unlikely to be used in production by anybody as is.
The technique used (at least this year) by FOSDEM is NAT64. To oversimplify how this works, it is designed to modify the DNS replies when resolving hostnames so that they always provide an IPv6 address, even though they would only have A records (IPv4 addresses). The IPv6 addresses used would then map back to IPv4, and the edge router would then “translate” between the two connections.
Unlike classic NAT, this technique requires user-space components, as the kernel uses separate stacks for IPv4 and IPv6 which do not allow direct message passing between the two. This makes it complicated and significantly slower (you have to copy the data from kernel to userspace and back all the time), unless you use one of the hardware router that are designed to deal with this (I know both Juniper and Cisco have those.)
NAT64 is a very useful testbed, if your target is figuring out what in your stack is not ready for IPv6. It is not, though, a realistic approach for consumer networks. If your client application does not have IPv6 support, it’ll just fail to connect. If for whatever reason you rely on IPv4 literals, they won’t work. Even worse, if the code allows a connection to be established over IPv6, but relies on IPv4 semantics for things like logging, or (worse) access control, then you now have bugs, crashes or worse, vulnerabilities.
And while fuzzing and stress-testing are great for development environments, they are not good for final users. In the same way -Werror is a great tool to fix your code, but uselessly disrupts your users.
In a similar fashion, while IPv6-only datacenters are not that uncommon – Facebook (the company) talked about them two years ago already – they serve a definite different purpose from a customer network. You don’t want, after all, your database cluster to connect to random external services that you don’t control — and if you do control the services, you just need to make sure they are all available over IPv6. In such a system, having a single stack to worry about simplifies, rather than complicate, things. I do something similar for the server I divide into containers: some of them, that are only backends, get no IPv4 at all, not even in NAT. If they ever have to go fetch something to build on the Internet at large, they go through a proxy instead.
I’m not saying that FOSDEM setting up such a network is not useful. It actually hugely is, as it clearly highlights the problems of applications not supporting IPv6 properly. And for Free Software developers setting up a network like this might indeed be too expensive in time or money, so it is a chance to try things out and iron out bugs. But at the same time it does not reflect a realistic environment. Which is why adding more and more rant on the tracking Android bug (which I’m not even going to link here) is not going to be useful — the limitation was known for a while and has been addressed on newer versions, but it would be useless to try backporting it.
For what it’s worth, what is more likely to happen as IPv6 adoption needs to happen, is that providers will move towards solutions like DS-Lite (nothing to do with Nintendo), which couples native IPv6 with carrier-grade NAT. While this has limitations, depending on the size of the ISP pools, it is still easier to set up than NAT64, and is essentially transparent for customers if their systems don’t support IPv6 at all. My ISP here in Ireland (Virgin Media) already has such a setup.
IPv6-only networks are real(istic). Some US-providers use it already via LTE.But you talking about wifi. Yes android has solved one of two IPv6-problems. It can use RDDNSS via ND but it still ignores completely dhcpv6.You compare NAT64 and DS-lite, of course DS-lite has a higher compatibility to old devices, but the effort for the ISP is higher. NAT64 is closer to the future: single stack!with the increasing number of IPv6-Hosts – NAT64 disappears by itself.
There are a few LTE providers using IPv6 — lots are using dual-stack though. With DS-Lite and similar. The problem here is not only compatibility with older devices, it’s also compatibility with older software.There is *no way* that in the next 20 years we’ll have a majority of IPv6-only network outside of controlled environments (datacenters, mobile networks, …) as it would mean throwing away lots of consumer and industrial devices.Which is part of the problem with IPv6: insisting that dual-stack is “legacy only” is a terrible idea. DS-Lite (which, by the way, does not require that much more work on the provider side, but it does have the negative side-effect for consumers of losing any semblance of public IPv4 — no torrent for you!) is a solution that can be deployed *now* and makes IPv6 a reality, but too many techs who should know better insist that “it’s not enough.” Balls.
Thank you for your answer.Losing connectivity to the IPv4-internet (only oneway ) is a fact. It doesn’t matter what the name is: cgnat, nat, NAT64, DS-lite with cgnat, proxy, application layer gateway or whatever.Maybe I am a “tech”. But I have made a good experience with NAT64. And of course I can use torrent with IPv6. There are enough ipv6-peers.Within the next 20 years people will have changed their mobile devices 10 times. Software – incompatible to IPv6/NAT64- is rare. One of them is just skype.Industrial devices should never connect directly to the “public” internet independent of the access technology and the version of the IP.IPv4 will not survive further 20 years.
Are you aware that we always offered dual-stack in parallel? At first as FOSDEM-dualstack, then FOSDEM-legacy, now FOSDEM-ancient. As this dual-stack network has an IPv4 temp PI /17, we don’t even need DS-Lite; we simply give everyone a globally routable address.NAT64 does not require userspace components on the end user clients. And in the network, we run an ASR1006 which does all this in hardware. There’s a bit more information in our yearly infrastructure review talk.
I am aware. But if you are not aware of the false impression you give people by calling a network *ancient* you are clearly out of touch with reality and users, and are exactly the kind of person that should not be allowed to take decision on products and network, because you suffer from geek supremacy.
I was asking because you didn’t mention this fact in your blog post.If you’re retreating to argumentum ad hominem, it might be more fruitful to simply end this discussion at this point.If you want to discuss on a technical level, we tell people about this setup via several channels, amongst others the booklet and the opening talk.
I have:> first providing a dualstack network when IPv6 was fairly rare, and in the recent (three?) years providing an IPv6-only network as the *default*.The fact that you have a dual-stack network as the non-default is irrelevant to the blog post, that an IPv6-only network is unrealistic for customer networks and as such a futile exercise to support.But go on, tell me this is an user problem again, it just makes my point.
Ah yes, I missed that; apologies.For completeness’ sake, I am still unsure what you meant with your comment about userspace vs kernel space.Anyway, our experience interfacing with hundreds if not thousands of attendees is different, but each to their own. I would appreciate if you didn’t put words in my mouth: The fact that we get extremely few complaints and a lot of praise paired with the fact that we go out of our way to inform people about what’s happening during a developer’s conference should point towards this not being considered “a user problem”.As it takes two to pick a fight, I will now leave you to your blogging and tweeting 🙂
To solve the problem of Legacy client applications while avoiding tunneling (cellular providers don’t like tunneling because it increases overhead and makes traffic classification harder) T-Mobile USA designed 464XLAT and pushed support into Andriod. This uses a stateless NAT46 to translate IPv4 traffic from clients and send it to the NAT64 . Like DS-LITE 464XLAT can be implemented either on the final end device or an an intermediate gateway router. Apple with IOS has been taking a different approach by simply demanding that developers make their applications work in a NAT64 environment if they want to get them on the appstore.