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. isatap 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. 6to4 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. 6rd 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. teredo/mirado 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. Tony > -----Original Message----- > From: Karl Auer [mailto:ka...@biplane.com.au] > Sent: Thursday, May 12, 2011 10:53 PM > To: NANOG List > Subject: 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 :-) 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"... > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) > http://www.biplane.com.au/kauer/ +61-428-957160 (mob) > > GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old > fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
