The stage was set. The work had been done, and now it was decision time. The fate of how the Internet would transition to IPv6 was to be decided, in Hong Kong, on February 23, 2006, at a special IETF Softwires meeting.
There was a lot riding on this for my company, then known as Hexago, now gogo6 . We were a small company, and investing in two full-time people, not to mention a fat travel budget, to attend Internet Engineering Task Force (IETF) meetings around the world, was a big deal or, should I say, a big bet. A calculated bet. One typically made only by the largest networking players determined to play standards into a competitive advantage.
At stake was the IPv6 tunneling mechanism to become the gold standard by which all broadband networks and networking vendors would abide. Our transition mechanism, Tunnel Setup Protocol (TSP), was one of two candidates in the running, and without a win, the viability of our company was uncertain.
As we were to learn, however, the road to IPv6 migration would not be as direct as expected, nor would the standards deployment process work out as planned.
Transition mechanisms are the technology and procedures used to migrate to IPv6. In those early days, we saw three paths to migration: dual stack, tunneling, and translation. Among experts at that time, the thinking was: “Dual stack where you can, tunnel where you must, and use translation as a last resort.” Sage advice… in the perfect world.
Here's a look at how the three approaches were viewed:
As Tony Hain, CEO of Hain Consulting and the first chair of the IETF Working Group on IPv6 Transition Technologies (precursor to Softwires), explains: “To some degree, you can call dual stack a procedure. Where the other transition mechanisms are distinct technology instances, dual stack is more of an approach.”
Dual stack yields a dual network where every node and service runs both IPv4 and IPv6, effectively creating two parallel and separate networks. This is the simplest mechanism and most preferred, however implementing dual stack end-to-end can require significant capital and resources.
The next mechanism involves connecting network “islands” separated by different Internet protocols. Packets are encapsulated at one end of the tunnel, routed through the “tunnel” and decapsulated on the other end, after which they continue on their journey. This allows network engineers to fill the gaps in their networks as their transition evolves.
Tunneling comes in many flavors, tailored to specific network types.
- Configured (manual) tunnels: 6in4. Configured by hand. Secure but labor intensive. Generally used to connect sites.
- Automatic tunnels: ISATAP, Teredo. Automatically configured but generally not as secure. Used in enterprise to connect users.
- Brokered tunnels: A tunnel broker automates configured tunnel creation, deletion, and address management. Used in enterprise and by small ISPs to connect users and sites.
- Softwire tunnels: L2TP, TSP, 6rd, DS-Lite, DSTM, LW4o6, MAP. Built to be deployed in scale by broadband providers. Used to connect users.
"The transition mechanisms being used today are 6rd and DS-Lite for tunneling, and NAT64/DNS64 for translation is also in demand," says John Gudmundson, Senior Manager of Product Marketing for A10 Networks Inc. . "But in practice our customers are also extending their IPv4 address inventory with CGN [carrier-grade network address translation, or NAT]. Many just don’t have a choice."
And lastly, there is translation, the bad boy of the group. While simple in principle -- IP packets of one type are transformed into packets of the other type -- this approach has a lot of limitations. Translation, such as NAT64, doesn’t work on most security protocols, such as IPSec, and will “break” protocols that include IP addresses in the packet payload (DNS, FTP, SIP…) and apps and services such as Skype, Xbox Live, and Spotify for the same reason.
In 2007, the IETF tried to banish translation by deprecating it to history… but it didn’t work. Nor did we prevail in trying to get our tunneling standard adopted by the IETF.
Hexago was undergoing its own transition. Not long after I joined the company as CEO and raised a $6 million round of VC financing, we lost our founder and his two closest lieutenants, who happened to be our IETF A-team. While I was able to keep the team together for one last fight, it didn't survive against a crack team of 12 IETF specialists, flown in just for this important mission. In the end we would have settled to have two standards, but the IETF Area Chairs were determined to produce a single standard to reference.
We lost. Though we were devastated at the time, in the end it really didn’t matter because no one could have predicted what would happen next.
The rise of the de facto standard
Now, there are standards and there are de facto standards. The first de facto standard to circumvent the IETF was 6rd. Rémi Deprés, 6rd’s inventor and a consultant for the French ISP Free , believed he had a better solution. Never taken seriously at any of the Softwire meetings, 6rd wasn’t even in the running in Hong Kong against TSP and L2TP.
But this didn’t matter, Deprés convinced his management to deploy it anyway. And after connecting 1.5 million subscribers to IPv6 in a five-week span without a hitch, the past was forgotten and the IETF fast-tracked 6rd’s independently submitted RFC to be the second Softwires tunneling standard. Adding to the inventor’s satisfaction were his initials, immortally stamped into his standard.
Due to the delay in implementing IPv6, dual stack and tunneling, the only two sanctioned transition mechanisms, were becoming less and less relevant as each day passed, due to their dependence on the ever-dwindling supply of IPv4 addresses.
This unavailability of IPv4 and a viable transition mechanism created a vacuum. Carrier Grade NAT is not a transition mechanism, but it did fill a need and started to take hold along with a new class of hybrid transition mechanisms that combined tunneling and translation. (See The Dark Side of IPv6.)
Not long after Deprés crashed the party with 6rd, a third Softwires tunneling standard was added to the mix. Alain Durand, from Comcast Corp. (Nasdaq: CMCSA, CMCSK) and then Juniper Networks Inc. (NYSE: JNPR), had developed a hybrid tunneling mechanism called DS-Lite that combined v4 over v6 tunneling with one layer of NAT.
Hybrid transition mechanisms such as DS-Lite and, more recently, MAP and LW4o6 (optimized DS-Lite) indirectly help migration by encouraging native IPv6-only networks as the start point and using reverse tunneling and address sharing (or translation) to connect to IPv4. Eventually the tunneled traffic and translation disappears, leaving the operator with a next-generation IPv6 network.
Next page: Expect the unexpected