[AusNOG] IPv6: Where's my tunnel?

[Geoff Huston]

On 08/03/2013, at 8:17 AM, Richard Archer <rha at juggernaut.com.au> wrote:

> On 8/03/13 7:16 AM, Don Gould wrote:
>> 
>> When my customer asks me why Google or what ever else has got slower recently I'm just going to tell the truth - "Sir it's because we're using $Provider as your ISP" and leave it at that.
> 
> You would be better off in the first instance to find a local provider who can offer native IPv6. Which:
> 
> 1. Eliminates the need for laggy tunnels
> 
> 2. Supports the providers who are doing the right thing
> 
> 3. Helps hasten the demise of providers who don't care for customer needs.
> 
> You might choose to deploy via tunnels, but when customer complains you have the native option to migrate them over to.

IPv6-over-IPv4 Tunnels are perhaps worse than not doing it at all. 

The problem is that the end systems are not necessarily aware of the presence of the tunnel and the packet has to be fragmented. Now in IPv4 that is not all that bad - as long as the DF bit in the IPv4 header is clear then the packet will fragment. But the problem we see more often is that the other end (the native IOv6 end) sends a full sized IPv6 packet and when it encounters the tunnel ingress the packet is too big. At this point the tunnel ingress has to send an ICMP6 packet back to the IPv6 source and get it to try again. For various historical reasons ICMP filtering at edge sites in incredibly widespread and often the ICMP filters block both ICMP4 and ICMP6 packets. ooops. Because this happens on large packets this problem manifests itself in the most horrible of ways - after the V6 session is established and after there is any [possibility of an automated fallback to IPv4 in the session establishment code path. This situation of a lost IPv6 ICMP6 packet leaves the end user waiting for a TCP timeout... but there is NO TCP timeout. Which means the user is left waiting for an application level timeout. Messy.

You are far better off avoiding tunnels. 

Really.

  Geoff