It’s Time For IPv6, Isn’t It?


 

I made a joke tweet the other day:

It did get lots of great interaction, but I feel like part of the joke was lost. Every one of the things on that list has been X in “This is the Year of X” for the last couple of years. Which is sad because I would really like IPv6 to be a big part of the year.

Ars Technica came out with a very good IPv6-focused article on January 3rd talking about the rise in adoption to 10% and how there is starting to be a shift in the way that people think about IPv6.

Old and Busted

One of the takeaways from the article that I found most interesting was a quote from Brian Carpenter of The University of Aukland about address structure. Most of the time when people complain about IPv6, they say that it’s stupid that IPv6 isn’t backwards compatible with IPv4. Carpenter has a slightly different take on it:

The fact that people don’t understand: the design flaw is in IPv4, which isn’t forwards compatible. IPv4 makes no allowance for anything that isn’t a 32 bit address. That means that, whatever the design of IPng, an IPv4-only node cannot communicate directly with an IPng-only node.

That’s a very interesting take on the problem that hadn’t occurred to me before. We’ve spent a lot of time trying to make IPv6 work with IPv4 in a way that doesn’t destroy things when the problem has nothing to do with IPv6 at all!

The real issue is that our aging IPv4 protocol just can’t be fixed to work with anything that isn’t IPv4. When you frame the argument in those terms you can start to realize why IPv4’s time is coming to an end. I’ve been told by people that moving to 128-bit addressing is overkill and that we need to just put another octet on the end of IPv4 and make them compatible so we can use things as they are for a bit longer.

Folks, the 5th octet plan would work exactly like IPv6 as far as IPv4 is concerned. The issue boils down to this: IPv4 is hard-coded to reject any address that isn’t exactly 32-bits in length. It doesn’t matter if your proposal is 33 bits or 256 bits, the result is the same: IPv4 won’t be able to directly talk to it. The only way to make IPv4 talk to any other protocol version would be extend it. And the massive amount of effort that it would take to do that is why we have things like dual stack and translation gateways for IPv6. Every plan to make IPv4 work a little longer ends in the same way: scrap it for something new.

New Hotness

Fresh from our take on how IPv4 is a busted protocol for the purposes of future proofing, lets take a look at what’s driving IPv6 right now. I got an email from my friend Eric Hileman, who runs a rather large network, asking me when he should consider his plans to transition to IPv6. My response was “wait for mobile users to force you there”.

Mobility is going to be the driving force behind IPv6 adoption. Don’t believe me? Grab the closest computing device to your body right now. I’d bet more than half of you reached for a phone or a tablet if you didn’t already have a smartwatch on your wrist. We are a society that is embracing mobile devices at an increasingly rapid rate.

Mobility is the new consumer compute. That means connectivity. Connectivity everywhere. My children don’t like not being able to consume media away from wireless access points. They would love to have a cellular device to allow them access to TV shows, movies, or even games. That generation is going to grow up to be the primary tech consumer in the next ten years.

In those intervening years, our tech infrastructure is going to balloon like never before. Smart devices will be everywhere. We are going to have terabytes of data from multiple sources flooding collectors to produce analysis that must be digested by some form of intelligence, whether organic or artificial. How do you think all that data is going to be transmitted? On a forty-year-old protocol with no concept of the future?

IPv6 has to become the network protocol to support future infrastructure. Mobility is going to drive adoption, but the tools and software we build around mobility is going to push new infrastructure adoption as well. IPv6 is going to be a huge part of that. Devices that don’t support IPv6 are going to be just like the IPv4 protocol they do support – forever stuck in the past with no concept of how the world is different now.


Tom’s Take

It’s no secret I’m an IPv6 champion. Even my distaste for NAT has more to do with its misuse with regard to IPv6 than any dislike for it as a protocol. IPv6 is something that should have been recognized ten years ago as the future of network addressing. When you look at how fast other things around us transform, like mobile computing or music/video consumption, you can see that technology doesn’t wait for stalwarts to figure things out. If you don’t want to be using IPv4 along with your VCR it’s time to start planning for how you’re going to use it.

 

 

Advertisements

6 thoughts on “It’s Time For IPv6, Isn’t It?

  1. As an engineer at an ISP in middle america, we have fully deployed dual stack to our customers and still run into issues, the biggest being the Android refusal to work with DHCPv6. We have workarounds in place, and still are only seeing around 10% of our total traffic being IPv6. Unfortunately, like many articles say, with IPv6 it only takes a single point in the path to not be running IPv6 to make it fall back to IPv4. Our CDN content is higher than 10%, but still not at the halfway mark yet. Unfortunately, tunneling and translation, while useful, will simply prolong the problem since they mask it. Once CGN becomes a necessity and people see how much it breaks, then IPv6 will see a higher deployment. I hope I’m wrong and we see higher penetration, but I’m sure we’ll always have IPv4 in existence.

  2. Interesting point of view, but I don’t understand his argument, or IPv6 has some major features I don’t know…
    How is IPv6 forward compatible?
    If I compare IPv4 and IPv6 it is obvious that v4 can’t be forward compatible, as there aren’t enough addresses.
    But in which ways is IPv6 forward compatible for example with a future IPv8 with 1024bit addresses?
    And how would v6 work with anything which has longer than 128bit addresses? Also I didn’t know that there are IPv6 addresses that aren’t 128bit long…

    • Using the argument that “What comes after IPv6” is pointless at this juncture. We need to move to it. Here’s one of the best “how many IPv6 addresses are there” statements I’ve seen, and hopefully you’ll realize that IPv6 isn’t going to be replaced in the next few decades…or generations:

      3.156×10^31 -Unique IPv6 addresses that would be assigned after 1 trillion years if a new IPv6 address was assigned at every picosecond.

      • The analogy breaks, though, because we are assigning IPv6 addresses at a far higher rate than one every picosecond. If you only connect one household per day, and only give that household a single /64, that’s nearly 10 quintillion IP addresses (10^19). That is about 100 IPv6 addresses per picosecond – for a single household per day that only receives a single /64.

        With more realistic assumptions, we are probably handing out a couple million IPv6 addresses every picosecond.

  3. No, it’s not time for IPv6. It’s time for CGNAT. I would much prefer IPv6, but the IPv6 promoters are their own biggest enemies by insisting on ideological purity. CGNAT may cause problems, but the self-inflicted problems with IPv6 are just as severe. As long as the IPv6 promoters are stuck in their ivory tower, I expect that IPv6 will stall as soon as the growth in mobile abates.

    To be clear: I’m not saying that IPv6 is bad – just that it is nowhere near as mature as some people hope it is. In time, it will get there – sometimes kicking and screaming.

    So what are the problems with IPv6? The NAT horse has been beaten to death, but there is another aspect of IPv6 that is theoretically great – until it meet the real world of business decisions: the restriction on subnetting to nothing smaller than a /64 without breaking tons of stuff. This restriction essentially throws us right back to the rigidity of classful addressing by another name.

    There are quite a few other things that need to be ironed out (and some already are): the inability of SLAAC to assign DNS addresses is being worked on. Address readability is another one, albeit comparatively minor – advocates like to point to DNS as the solution, but that assumes that you have a rock-solid infrastructure for keeping DNS updated. In reality, those solutions are far from mature, and hard to administer. Thankfully, IPSec was already dropped from IPv6 a while ago.

    Advocates like to claim that IPv6 allows 340 undecillion addresses. That’s nonsense. Because of the /64 subnet restriction, you have to use 10 quintillion addresses even if you only need to hook up one or two devices.

    Because of that limitation and a few other constraints, IPv6 effectively adds only about 16 bits to IPv4 addresses. It’s an improvement, but not by all that much. When we have to hand out IPv6 addresses to some organizations as /29s, we are bound to run out of IPv6 addresses in a few years, too.

    There is a more immediate problem, though: you are at your ISP’s mercy for your internal subnet design. Theoretically, you are always supposed to get at least a /56 from your ISP – but we already see ISPs that don’t adhere to that rule; I have seen some give you a single /64, or, even worse, run the /64 on their end; you only get individual IP addresses.

    If you want to unleash IPv6, drop the /64 restriction, allow NAT and straighten out a few other things.

    Then see IPv6 spread like wildfire.

    • Ever tried setting up CGN on an ASR9k? To say it’s a nightmare to deploy is an understatement. IPv6 is tested and proven, CGN is a pipe dream that unless you have millions of dollars to throw at is much more unrealistic than IPv6.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s