2015-04-19
A potential path to IPv6 (again), but probably not a realistic one today
In practice, adding IPv6 to existing networks is a lot of work and is clearly going quite slowly in many places, or even not going at all. Given the economic incentives involved, this is no surprise; currently IPv6 primarily benefits people who are not on the Internet, not people who are. So what will drive adoption of IPv6, so that it becomes available in more areas? In particular, what would push http://www.cs.toronto.edu/ towards adding IPv6 to our networks?
My current answer is that the only thing that would really make this important is a noticeable amount of IPv6 only websites and other Internet resources that people here wanted to reach. If this happens and especially if it's increasing, that would create an actual win for our users for us deploying IPv6 instead of the current situation of it just being kind of nice. But where are these IPv6 only resources going to come from?
My best guess is that the most likely place to develop them are areas with large IPv6 penetration today. If you're building a business that is primarily or entirely targeting an IPv6 enabled audience (if, for example, you're targeting mobile users in a geographic area where they all get IPv6), only going with IPv6 for your servers and so on may make your life simpler.
Unfortunately there are a lot of holes in this idea. Even if you're dealing with an area where IPv6 is better than IPv4, running a dual stack environment is probably easy enough that it's cheap insurance against needing to expand into an IPv4 audience (and it means that all sorts of IPv4 only people can at least check you out). Going dual stack does increase IPv6 usage on the whole, but it doesn't turn you into an engine driving IPv6 adoption elsewhere. Beyond that, the Wikipedia page on IPv6 deployment and APNIC's numbers suggests that I've significantly overestimated how many areas of the world are strongly IPv6 enabled at the moment. If there's no real pool of IPv6 users (especially in areas that are not already saturated with IPv4 address space), well, so much for that.
All of this does make me wonder if and when large hosting and datacenter providers will start effectively charging extra for IPv4 addresses (either explicitly or by just giving you a discount if you only want IPv6 ones). That would be both a driver and a marker of a shift to IPv6.
(I wrote about a potential path to IPv6 a while back. This is kind of a new version of that idea from a different perspective, although I had forgotten my old entry when I first had this idea.)
2015-04-18
A core problem of IPv6 adoption is the lack of user benefits
I've written before about some of the economic incentives involved with IPv6 adoption, focusing on who benefits from IPv6. Today I want to touch on this economic issue from another angle. Put simply, one of the big problems is this:
In many places, adding IPv6 to your network won't improve anything for your users.
Sure, from a geeky technical side it's nice to support IPv6 on your network and see ipv6.google.com and so on. Having your network and organization be IPv6 ready and enabled is clearly the right thing, a good thing for the future, and all that. But it's not essential. In fact it's usually not even beneficial, not even a little bit. If you add IPv6 to your network today, generally almost no one will notice anything different.
(Let's pretend that there are no bugs and systems that are unprepared to deal with IPv6 addresses and so on.)
At one level this is great; it's good that you can quietly drop in another network protocol and no one notices. At another level it's catastrophic to IPv6 adoption. IPv6 adoption is a lot of work in most networks; you've got a great deal to learn, a great deal to set up, a great deal to test, and so on. Unless you have a lot of free time it's hard to justify spending a lot of effort on something that doesn't actually deliver real improvements to your users, it's just the right thing to do.
(People like working on right things, but they inevitably get a low priority and thus not very much time. They're sleepy Friday and slack day and 20% time projects, not prime time work.)
Purely from a speed of adoption perspective, it would be much better if adding IPv6 was less transparent because it suddenly let people do things that they couldn't do before. Then you'd have a much easier time of building a case for spending significant effort on it.
(In fact it's my impression that many of the IPv6 adoption stories I've heard about are exactly from situations where adopting IPv6 did deliver real, tangible benefits to the organization involved. See eg Facebook's slides about their internal IPv6 usage, where IPv6 helped them deal with real issues and made their lives better.)
2015-04-15
Illusory security is terrible and is worse than no security
One of the possible responses to my entry on how your entire download infrastructure should be using HTTPS is to say more or less 'well, at least the current insecure approach is trying, surely that's better than ignoring the whole issue'. My answer is simple: no, it's not. The current situation covered in my entry is actually worse than not having any PGP signatures (and perhaps SHA1 hashes) at all.
In general, illusory security is worse than no security because in practice, illusory security fools people and so lulls them into a false sense of security. I'm pretty sure that almost everyone who does anything at all is going to read the Joyent page, faithfully follow the directions, and conclude that they're secure. As we know, all of their checking actually means almost nothing. In fact I'm pretty sure that the Joyent people who set up that page felt that it creates security.
What makes no security better than illusory security is that it's honest. If Joyent just said 'download this tarball from this HTTP URL', everyone would have the same effective security but anyone who was worried about it would know immediately that they have a problem. No one would be getting a false sense of security; instead they would have an honest sense of a lack of security.
It follows that if you're setting up security, it's very important to get it right. If you're not confident that you've got it right, the best thing you can do is shut up about it and not say anything. Do as much as you can to not lead people into a false sense of security, because almost all of them will follow you if you do.
(Of course this is easier said than done. Most people set out to create good security instead of illusory security, so there's a natural tendency to belive that you've succeeded.)
PS: Let me beat the really security-aware people to the punch by noting that an attacker can always insert false claims of security even if you leave them out yourself; since you don't have security, your lack of claims of it is delivered insecurely and so is subject to alteration. It's my view that such alterations are likely to be more dangerous for the attacker over the long term for various reasons. (If all they need is a short-term win, well, you're up the creek. Welcome to security, land of justified paranoia.)