Innovation isn’t Implementation

Earlier this month, the Internet had its first wake-up call in terms of technical implementation difficulties. For those who aren’t familiar with what IPv4 and IPv6 are, basically understand that every device that accesses the Internet gets an IP address – like which is the IP address for this site at present – but that there’s only a finite space for IP addresses in that form (IPv4, it’s called), and at the broadest, coarse level, it’s full. Which is a problem for a growing Internet.

Well, it’s a problem in that it’s a barrier to growing the Internet, especially with the explosion in the mobile arena – with users having more and more different ways of accessing the Internet, and each wanting an IP address to play with.

One might, slightly naively, wonder why it’s only now that we’re looking at this… but the IPv4 exhaustion problem is nothing new – I first remember reading about it in 1997. And here we are in 2011, 14 years later, actually hitting the barrier that we knew was coming.

Now, some smart cookies have already been working on the solution, it’s called IPv6 and it’s been refined over the last few years – but it’s already best part of two decades since the initial designs for IPv6 were founded… so why is it only now that it’s a problem?

Simple: the innovation that is IPv6 just hasn’t been implemented fully yet. Many devices and systems sport IPv6 support – it’s certainly nothing new to most networking equipment manufacturers, or systems engineers that work with networking code. But Internet Service Providers – ISPs – have been reluctant to roll it out. Partly it’s because migration from IPv4 to IPv6 isn’t quite as simple as flicking a switch, but no small part of it has been ‘putting it off till tomorrow’. Unfortunately, yesterday’s tomorrow has caught up with us.

What we will see in the short term are refinements and extensions of other innovations to stifle the bleeding of IP addresses (it’s exhausted at the most coarse level of granularity, the next level – the regional registrars – have maybe until the end of the year before allocation there is exhausted). I think we’ll see expansion of one technology in particular: NAT. It’s not a silver bullet, but the ability to put multiple devices behind a single outward facing address (imagine two computers in a house sharing an Internet connection – both machines inherit the IP address of the router connecting to the Internet) – but it does mean you can have multiple machines hidden away under that connector.

What we’ll also see is trading, those who got allocations much bigger than they needed, I think they’ll start to sell them off either in blocks or individually. Whatever happens, though, there’s going to be a scramble to innovate to keep the wheels of the Internet turning, while IPv6 gets more fully implemented.

Who knows? There may well be other innovations that come out in the meantime that staunch the bleed of IPv4 further without compromising functionality – but it just reminds us that when you’ve innovated and got the next generation of whatever you do ready… don’t just innovate, implement too.

This entry was posted in Uncategorized and tagged , , . Bookmark the permalink.

6 Responses to Innovation isn’t Implementation

  1. Adonis says:

    It’s Y2K all over again.

    That went by relatively painlessly – though I know of a few IT people that were ‘on site’ instead of ringing in the New Year partying.

    Cake and balloons for World IPv6 day! :D

  2. Arantor says:

    It is but it isn’t.

    Y2K was overrated, not an issue for the majority of systems out there – Y2K38 is going to be a much larger problem as the systems that could slide through Y2K will inevitably fail, and fail in all kinds of ways. At least with Y2K systems issues, there was a possible chance that people who knew the system would be around, the lead time being perhaps 20 years at the outside for most systems still in active service.

    (The truly huge systems would have had people already dealing with it anyway, I’m talking about those who were on fairly big iron systems but without the serious backing to fix application issues)

    But 2038, that’s a whole different ball game – by the time we hit that, there will be an entire generation, nearly two generations, of computer user who were born after Y2K and dismissed it as little more than a vague issue. You’ll have people who are in the midst of their professional lives, looking on at system code, struggling to make sense of it because it was laid down before they were even born, when such issues were not so important.

    Y2K was never that far away that you would ignore it, as it were, but I’m looking at Y2K38 and thinking that by then, I’ll be in my mid 50s, had a family, and they will be in the early days of their professional careers before this hits.

    IPv6 deployment isn’t quite like that, actually. It’s been in development since the early 1990s, when even then it was realised there would be a problem, and a lot of equipment can cope with it just fine – it’s mostly the ISPs and registrars that have no idea how they’re going to handle deployment. Whereas Y2K was a little more of a surprise and a gotcha, IPv6 seems almost stuck in analysis paralysis.

  3. Adonis says:

    I guess that’s what happens when you don’t have a solid deadline.

    If you keep expecting that *someone* is going to come up with a really great solution you just keep waiting, as it gets harder to implement and more pain from not doing anything.

  4. Arantor says:

    Well, the thing is with IPv6, the first deadline has come and gone: IPv4 exhaustion at the root. Next is the RIRs running out of blocks at their level, which is 3-6 months. Right now, everyone should be scrambling like fury to implement IPv6 support in applications – because so many applications just do not have the support for it.

    I know multiple forum software packages, multiple blog packages, not to mention several other ‘big name’ software packages that are in massive use across the web, none of which have adequate IPv6 support – though more than one of those packages is aware of the deficiency, and has been for some time.

    It doesn’t help that while the networking infrastructure supports it, the next real layer up for application purposes – data storage – doesn’t fully support it. I mentioned several web applications that have no IPv6 support, well, part of the problem is that MySQL, upon which all of those packages can rely, does not have native support for juggling IPv6, while it does for IPv4 – so any solutions currently will involve a none too small helping of ingenuity. I’ve implemented IPv6 in a web app, it’s not difficult once you put your mind to it, but neither is it a swift and easy job.

  5. Adonis says:

    No *calendar* deadline. Warning flags have gone up, but there’s a big difference between 3 months and 6 months – depending on how the bleeding is controlled.

    It looks like an IT nightmare, in which everyone relies on someone else further up the food chain or conversely, still has to try and support everyone else and most of the workarounds all at once.

    I think we should just take the Internet offline for a year or two and sort it all out that way. :b

  6. Arantor says:

    That’s the thing, a calendar deadline wouldn’t really help, all that would happen is we’d hear the noise when the deadline flew by.

    Yes, there’s a big difference between 3 and 6 months, and some of the others may last up to the end of the year, depending on how they allocate IP blocks. Where it will get fun, and likely demonstrate some innovation, is what happens when the RIRs run out too – I think we’ll see market economics come into play, as entities that got huge IP blocks will sell back some of their blocks, and some of the infrastructure will have to be fixed to support it.

    It doesn’t just resemble a nightmare, it’s going to become one unless ISPs (who are the major bottleneck) start deploying IPv6 – trouble is, everyone seems to be waiting for everyone else to see how they do it.

    It’s entirely possible to run an IPv4 and IPv6 environment at the same time, most decent networking gear can run both. And it’s not like there aren’t ways to deliver IPv4 over IPv6. The bottom end of the food chain is fixed, the top end is being fixed, but the middle of the chain’s in turmoil – and that’s where it has to be fixed.

Comments are closed.