Interested in input on tunnels as an IPv6 transition technology

Hullo all.

I'm working on a talk, and would be interested to know what people think
is good about tunnels as an IPv6 transition technology, and what people
think is bad about tunnels.

It would probably be best to let me know off-list :slight_smile: but I'm happy to
summarise back to the list. Any references you have to useful papers,
articles, discussions etc would also be appreciated.

I'm looking for both general problems and advantages, but also
advantages and disadvantages specific to particular tunnel types. It
would also be helpful to know from what perspective particular things
are good or bad, in so far as it isn't obvious. A carrier has a
different perspective than, say, a home user, who will have a different
perspective again to an enterprise user.

Many thanks in advance for your input.

Regards, K.

PS: Note the all-important words "as an IPv6 transition technology"...

Without tunnels we'd have no IPv6 today. Even today many people, especially home users, depend on them. But it would have been impossible to get IPv6 started by running it native-only.

Tunnels can work very well and if they're direct they can be almost as good as native connectivity. However, in the past we saw Europeans get tunneled IPv6 connectivity from Japan. That kind of thing is very bad because it inflates RTTs and thus slows everything down.

Enabling automatic tunneling by default is also a mistake because then you think you have IPv6 even if the automatic tunnel doesn't work because relays are unreachable or stuff is firewalled.

A downside of tunneling is the reduced MTU, but hopefully the fact that tunnels are common makes people fix PMTUD problems rather than blindly send 1500-byte packets and let the chips fall where they may that way too many people do with IPv4.

So... tunnels can be good or can be bad, but native is still better than a good tunnel.

Fundamentally tunneling allows you to introduce the new technology while you work through budgeting / amortization-of-legacy / resistance-to-change issues. The Internet as we know it was built as a tunnel overlay to the voice system, and the underlying operators of that time said the overlay couldn't work or was sub-optimal, just like we hear today as a new generation of overlay is deployed.

There is a serious stalemate between the transit/access system which won't/can't invest in something new without a rapid ROI as demonstrated by a wildly popular application, and the application/content world that won't/can't invest in new applications without a delivery mechanism in place. Tunnels help break that stalemate.

That said, at scale configuring and debugging an array of tunnels is an operational pain which will quickly outstrip the cost for just deploying the new technology natively. In the tunnel-over-voice model, hubs were set up and the end user was expected to configure their end of the tunnel to find the closest hub. Works well enough, and tunnel brokers are doing the same for IPv6 over IPv4 today. The issue is that we left the dial model behind and people just expect their magic CPE thing to take care of it automatically to stay connected at all times. Enter the automated tunnels...

People on this list will complain all day about how bad an idea automated tunnels are, but at the end of the day the point of automated tunnels is to get technology deployed to places where those who are complaining have not done so yet, and then doing that at scale without changing end user expectations of magic in the CPE. To put it a different way, the IPv4 operators have become the lethargic core that they complained about so vehemently 15 years ago, so now the $50 CPE has to find a way past them to stay always-connected no matter what rate their ISP rolls the IPv4 DHCP pool, or how many layers of nat get put in the way.

For the specific complaint about MSFT putting tunneling in the host, you can complain to me because I drove that model (I have not worked there for over 10 years, but I was the PM for IPv6 in XP). The entire point was to break the stalemate and get apps deployed. People on this list generally are network operators and frequently get myopic about what problems need to be solved. For the specific problem of app development, there has to be a trust that it is worthwhile starting the development, so the API has to work no matter what impediments there are in the network. Given that you have to have an app deployed to demonstrate the need for the network operators to make the investment to improve its performance, making the API work means the host has to originate the tunnel, at least initially. That said, the original XP implementation deferred to any native service and that is the way all implementations of automated tunneling should work (I make the point because the rewrite of the stack for Vista/W7 broke this deferral for the isatap tunnel type, and as of the last time I checked it has not been fixed yet). Making the API work also means that multiple approaches to tunneling are required to deal with the various network topologies that the end system will find itself in. From the app developer perspective, none of that should matter as the OS stack should take care of masking whatever contortions it has to do for bit delivery. That almost works except for RTT and MTU issues which cause performance degradation relative to the underlying legacy protocol.

I can already hear the responses about how people are demonstrating the failure modes of automated tunnels. My response is that those who protest are taking the religious position of 'my content is available via the RIR allocated address and you will come to me', which forces traffic through a 3rd party transit intermediary when they could just as easily add an address for direct support of the automated tunneling world and all of the 3rd party issues they complain about as failures would vaporize. There would still be firewall induced failures, but the entire point of firewalls is to cause a failure for services the firewall operator is not prepared to deal with. There is a simple enough work around for that by daisy chaining automated tunnel technologies with an intermediate firewall, so it doesn't have to be the crisis it is being made out to be.

While IPv4 creates a nice global NBMA network (to pass what from an IPv6 perspective are logically layer-2 frames around), tunnels create a challenge for diagnostics because there may be a divergence between the tunnel and the underlying path. This is amplified when the underlying path it asymmetric, and even further when 3rd parties are introduced in one or both directions. This issue also exposes the disparity between what the applications are trying to do vs. what the native network is capable of. When your job is the underlying network, exposing this difference is going to cause grief, and in turn complaints about the thing that is shining light on the situation.

As to specific technologies:
Tunnel brokers
The modern equivalent of modem-pools. Requires explicit action by the end user, and some degree of technical skill to get configured correctly (more so than a dial modem which used the widely understood paradigm of placing a phone call). Also requires some degree of adaptability by the hub operator to deal with dynamics in the underlying network addressing over time. Primary application issue is reduced MTU.

designed as an intra-enterprise tool for hosts to reach across an infrastructure that is still being amortized. Use of an IPv4 DNS A record allows network managers to explicitly distribute clients across a set of tunnel termination routers, while the alternative use of an IPv4 anycast allows clients to reach the topologically nearest router. Can be used in conjunction with native external access, or 6to4/6rd by reencapsulating the packet. The triplet of a 6to4/6rd router, native IPv6 firewall, and isatap router allows IPv6 application support between the enterprise end system and the public Internet with the same firewall policies as IPv4, and without the need for deep packet inspection to parse the tunnel packets.

designed as a border router to tunnel to other 6to4 routers over public infrastructure that was not ready for native support. Relays to transit between the 6to4 addressed environment and the native environment were an add-on that merged the two. The IPv4 anycast address to further simplify deployment was another add-on which reduces configuration on the client side router. The problematic issue of 6to4 is the misguided one-liner in RFC 3056 5.2 bullet 3 that restricts advertisements into the IPv6 BGP mesh to be the entire 2002::/16. This leads to unwanted traffic patterns, so the relays are not deployed as widely as they could/should be to mitigate latency and asymmetry issues. If the cpe is capable of dealing with the encapsulation, end hosts are unable to distinguish this prefix from any native service that might have been offered to the cpe. When no adjacent router is offering native IPv6 service, an end system with a public IPv4 address might attempt to use this technology, and if encapsulated packets are blocked by a firewall it will fail, but without the firewall the applications will see what appears to be an IPv6 network.

designed as a derivative of 6to4 to explicitly remove the /16 restriction in IPv6 BGP advertisements because changing that one line would have taken longer to get agreement on than an entirely new design, implementation, and deployment sequence (note that this will result in just as many IPv6 prefix announcements into BGP as fragmenting 2002:: would have, so the arguments about modifying 3056 are moot). Requires that each provider have a large enough allocation to embed the uniquely identifying parts of their IPv4 space into each 6rd address block, which is a challenge with existing IPv6 allocation policies. It does align the tunnel endpoints with the access infrastructure that is being overlaid, at least at the organizational level. Does require CPE capable of sorting out which set of IPv4 address bits should be concatenated with the IPv6 pop prefix to create the ultimate IPv6 prefix for that CPE.

designed to deal with the reality that most end systems find themselves behind a nat and without an adjacent router offering IPv6 so the above approaches won't work. Has additional overhead compared with the above, further reducing the MTU, and requiring a lengthy call-setup sequence. Works well enough for bulk bit delivery when responsiveness expectations are low and nat traversal is the primary goal.


All I can say is that if it wasn't for HE tunnels I would be SOL. No provider here in east central Florida can even speak IPv6. Brighthouse is clueless. ATT told me maybe 2012 or 2013! So I tunnel to HE's POP in Miami. With this I can test and become dual stack operational. Yes, it is not as good as a native connection but in my position its the only game in town.


6rd doesn't have to add any extra routes to the global routing

As for adding more specific routes to 2002::/16, a operator would
need a route for each IPv4 cidr netblock they offer 6to4 on to avoid
the use of 3rd party relays. That being said ther routes should
only be there between the time the operator brings up the 6to4
relays as a initial transition service and the time they deploy
IPv6 natively. After that they would most probably still run reverse
path relay covering all of 2002::/16.