13.25 years ago, in January 2004, the University Of Hawaii hosted the Techs In Paradise conference in Honolulu. During that conference we provided IPv6 connectivity to Japan, via our STM-1 to APAN Tokyo, and NICT operated a demonstration involving radio controlled model cars with tiny cameras aboard, where drivers at JGN Tokyo could operate cars in Honolulu, and vice versa. It was the beginning of operational IPv6 networking in Hawaii. Sure, for several years after, an IPv6 outage didn’t cause any users to call the help desk, but the operational core was there.
In late 2008, we obtained our own IPv6 addresses from ARIN (previously, we had an allocation from Internet2), and began to operate our dual-stack university network in earnest. At the time, IPv6 clients were somewhat sparse, but were present in increasing numbers. Windows Vista had IPv6 features built in and turned on the previous year, and was actually more popular than anybody admitted, and even Windows XP had limited, but usable IPv6 support. Mac OS X Leopard also supported IPv6, as did Linux. Cisco, Juniper, Foundry, and other vendors were including IPv6 features in routers. (Of course the 2017 perspective might lead you to ask about smart phones, but smart phones and PDAs were only then beginning to affect the way people accessed the Internet. iPhone 1, out that year did not originally support IPv6. )
In mid 2009, we turned on IPv6 peerings with TW Telecom, giving us IPv6 connectivity on all sides, no longer exclusively with Internet2. In the 8 years since, we have operated an operational dual-stack IPv6/IPv4 network, and the team mantra became “IPv6 is not an experiment – there is no IPv6 guy, we are all IPv6 guys.” IPv6 operations have gone smoothly. New staff receive no IPv6 training beyond OJT. And like staff at other organizations who have deployed IPv6, the common impression is that it’s pretty much like operating an IPv4 network, with longer addresses. There are a couple of new concepts to assimilate, with addressing plans, address assignment and tracking, but the operation of a dual-stack network does not require your staff to learn anything that they’re not already required to learn about advancing technology on a weekly basis.
As of right now, Google, YouTube, Netflix, FaceBook, Akamai, and other big content providers all provide our users with content over IPv6. Within our State-wide network, IPv6 deployment is still elective for departments and institutes that operate their own LANs, but ITS administered networks include IPv6. Most of our institutional content is not yet offered over IPv6, part of a national condition, where IPv6 connectivity is deployed in 111 different Internet2 Member university’s networks, but not in most of their data centers.
Dissent
In the process of meeting various people at gatherings around the country, and reading various articles and posts on the Internet, I’ve come to appreciate that there is a lot of loose, non-sequitur rationalization afoot, and little is being done to counter it, or address it. To fill that void, I want to address a series of prevalent rationalizations people offer as to why they’re not doing IPv6.
Rationalization #1: “IPv6 isn’t ready yet. We’re waiting for it to mature”
I’ve been doing it for 13 years, and I have to say that this excuse doesn’t stand up to scrutiny. IPv6 works as well as IPv4, and it’s no more or less secure or private. Plus, it’s out there, on your network, whether you like it or not, since all modern operating systems include it, and it’s turned on. If you’re pouring energy into turning off and suppressing IPv6 on your network, you’re wasting more time and energy than you would just including it in your plans.
Rationalization #2: “Our users aren’t requesting it.”
It’s a mystery to me how anyone could offer this as a reason, and not immediately realize how silly it sounds, but somehow people manage to. Of course your users aren’t requesting it, why would they? Furthermore, you could use it as a selling point, in the tradition of printing the words “Field Effect Transistor Technology” on a stereo receiver, or offering Internet connections with “Fiber”. Users don’t care what layer 3 protocol they’re getting, they don’t care if their fast connection arrives over fiber or coax or WiMax, until you tell them it’s a premium feature. Bottom line is: deploying IPv6 is positioning your network to provide better experience to your users, a better experience for which your users will call you to account when you don’t provide it, or more likely, they’ll vote with their feet. Early, pervasive IPv6 deployment is competitive. Compete or perish.
Rationalization #3: “IPv6 is unfamiliar and we can’t afford to prioritize training for it.”
As I said, at the University Of Hawaii, these last 8 years:
- All of our staff are IPv6 capable
- Our only IPv6 training is on-the-job
It’s really not unfamiliar in practice, those who have deployed it usually say that it’s like managing IPv4, with longer addresses. The difference between organizations that deploy IPv6 and those who don’t is simply rationale.
Rationalization #4: “IPv6 addressing reduces user privacy”
Stop reading old articles. With the inclusion of RFC 4941 privacy addressing in modern OSes, as well as RFC 3972 cryptographically generated addresses, IPv6 offers more privacy and security than IPv4 does. (ISOC post on this)
Rationalization #5: “The IETF messed up. They got it wrong.”
If you’ve ever been to an IETF meeting, you know that the IETF does not lack for:
- people as insightful and sophisticated as you
- people willing to belabor a point
The IETF is not a software vendor. You are part of the process by which IPv6 will fill your future needs. If there are things about IPv6 operations that you want to effect change in, become part of the process.
Furthermore, the IETF got a great deal right, after MUCH rumination and discussion. They envisioned a future for the Internet, they considered whether it was better to make IPv6 backward compatible or not, they came up with what we have now. The next step is to deploy it, and discover the details in practice.
Who’s Accountable?
In most layer-3-protocol-change-denial rationalizations, there is a tacit insinuation that someone, somewhere is negligent, and that deployment can only reasonably occur when that someone-who-is-ultimately-responsible for IPv6 gets their act together. What the world needs now is for enough networks to deploy so that the global Internet reaches the tipping point, where those who face problems from IPv4 address exhaustion can begin to use IPv6 as a solution. In order for that tipping point to be realized, a majority of networks must deploy IPv6, both by providing user connectivity and by providing services and content over IPv6.
If “critical mass” is the needed milestone, then anybody who’s in a position to deploy IPv6, but doesn’t is the obstacle to it becoming useful.
Who’s accountable? You are. If you’re tempted to pick nits and offer anti-deployment counterpoints, consider that it’s up to you. You’d be arguing with yourself. I don’t offer to account for your talking points, but I do offer to engender a discussion about v4/v6 parity, about developing best practices, and about documenting solutions that will enable you to use IPv6 today to deploy systems that will be ready to engage the future-ready Internet.
Minimal Internet citizenship involves taking the steps to deploy a dual-stack network, with NATed v4 and native v6 if necessary. Call your ISP and complain, pound on the table when your vendors say “probably first quarter next year”. The global community of Internet operators will ultimately determine the Internet’s form, and the best form available is an IPv6 Internet.