Thanks for such a comprehensive and thoughtful answer. The differences between 6rd and 6to4 and Teredo are well-known within the IPv6 community but not so much beyond that and this is a good clarification.
Between Free Telecom, AT&T, and others, 6rd is responsible for enalbing more homes with IPv6 than any other technology in deployment today. Not all ISPs will choose a migration path that includes 6rd, but for those that do it has proven very successful.
A well-designed and operated 6rd deployment and a well-designed and operated native IPv6 deployment are effectively indistinguishable from one another from the perspective of an end-user. 6rd is very different from 6to4, Teredo, and other tunneling protocols in that it is managed by the ISP that is providing the service to the user rather than depending upon the use of relays setup by those willing to donate processing power, bandwidth and rackspace to just anyone. The technology behind 6rd is also very different from stateful tunneling protocols like L2TP (I also wrote RFC 2661, so have some experience here as well), which carry per-subscriber state and tend to terminate in centralized locations. 6rd adds no additional per-user state within the ISP network, can follow the shortest routing path within the ISP network, and ultimately is night-and-day more scalable than any tunneling protocol that requires per-user configuration or signalling.
60 vs. 40: 6rd does require an additional encapsulation vs. Native IPv6. So, for a few hops as your packet enters and leaves your ISP network, there are 60 bytes of IP header vs. 40 bytes of IP header. Given all the other encapsulations - PPP, PPPoE, Ethernet (native, or in MPLS as part of a VPLS or Pseudowire), various MAC-in-MAC Ethernet tunneling mechanisms, a GRE tunnel here and there, maybe even Mobile IP, LISP, or SSL... this temporary extra 20 bytes in the life of a packet is truly negligible in the grand scheme of things.
Certainly, our ultimate goal is to move all operators using 6rd to Native IPv6. I've even written an IETF draft on it (draft-townsley-v6ops-6rd-sunsetting-00). The reason, however, is not because 6rd gives worse perforance to end users vs. Native IPv6. The reason is so that one day we can turn off IPv4. Before that can happen though, we have to see a substantial amount of end-to-end, production-quality, ISP-supported, IPv6 traffic. 6rd has shown its ability to do this. Without it, there would be a whole lot less IPv6 traffic out there to be celebrating the Launch of right now.
1. Tunnel encapsulation adds latency and overhead to the transmission process.
2. Tunnel encapsulation reduces MTU
3. 6rd deployment reduces IPv6 addresses available to the end user or consumes excessive amounts of IPv6 addresses to provide reasonable sized prefixes to the user.
As a result, 6rd is quicker to deploy if your equipment in your network is IPv6-deficient, but, more expensive to maintain than native dual-stack. As such, I think you will see most providers going native dual stack as quickly and to whatever extent they can.
While entry-level SOHO routers may not have it now, there are some mid to upper grade SOHO routers already support 6rd (i.e. D-Link), and the IETF's 6204-bis says that routers should support 6rd (http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-09#section-4.4.1)
Interestingly, Brooks Fitzsimmons, assistant VP-IPv6 transition, admitted on today's call that AT&T is using 6rd as a way to get IPv6 out to as many of its customers as possible as quickly as possible but will deploy dual-stack in the future, because - as Comcast and Time Warner folks have been saying - that is the long-term strategy.
Free, the French ISP, is the other major service provider to deploy 6rd, and they did it very early.
What the cable companies are now pushing is for consumer electronics gear to come loaded with native IPv6, so that consumers don't have to do any configuration to get it to work.
Looks like IPv6rd requires certain equipment at the customer premises, which might seem like a disadvantage. But based on what we're hearing from Comcast, it seems like that limitation exists for them too. (Even though dual stack theoretically doesn't require any special CPE, the reality is that a lot of people have CPE that just doesn't support IPv6 in any form.)
The blogs and comments are the opinions only of the writers and do not reflect the views of Light Reading. They are no substitute for your own research and should not be relied upon for trading or any other purpose.
To save this item to your list of favorite Light Reading content so you can find it later in your Profile page, click the "Save It" button next to the item.
