[AusNOG] IPv6: Where's my tunnel?

[Karl Auer]

On Fri, 2013-03-08 at 08:17 +1100, Richard Archer 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:

Not "in the first instance". What's important is to get into IPv6, any
way you can and as soon as you can. Yes, go for native access if
possible - but don't get hung up on it; don't delay moving just because
that one duck is not lined up yet. One of the beauties of tunnels is
that they are very easy to st up and do not need any support from your
ISP.

> 1. Eliminates the need for laggy tunnels

Tunnels are not always laggy. It depends on where the tunnel terminates,
and where the traffic over the tunnel is going. If you have a tunnel
through Hurricane Electric and are sending traffic from (say) Sydney to
Melbourne, it's crossing the big water twice, so no wonder it's laggy!
If you are sending traffic from (say) Melbourne to Los Angeles, the
difference between the tunnel and native IPv4 is likely to be a great
deal less.

It is true that a tunnel by definition is slower than native, all other
things being equal. There is the encapsulation overhead (processor time
to encapsulate plus the extra bytes on the wire), and the possible
effects of a lower MTU. It may also be processed in software rather than
hardware. The question is how much slower? Slower is not the same as
slow. My own experience on a link with a typical IPv4 RTT of around 40ms
(I know; poor, poor pitiful me) was that tunnelled traffic had a RTT
about 1 or 2ms longer, if I was sending traffic to a destination near
the tunnel endpoint. That's a 5% "cost", and I don't know how much of
that cost was the fact that my tunnel client was running on an ancient
IBM T30 laptop :-) 

Right now the free prefixed tunnel options are HE, with a massive
inter-continental latency flagfall for us Antipodeans, and the overseas
also-rans like SixXs with similar latency flagfalls. Locally there is
the AARnet broker, which is fine when it works but is essentially
unsupported. It was never intended for more than experimentation. There
is Internode's broker, but that's only available to Internode customers
as far as I know, and if you are with Internode you can get native IPv6
anyway. And there is IPv6Now, which uses the same technology as
Internode and AARnet, but costs money if you want a prefix - on the
other hand it is a commercial service.[1]

> You might choose to deploy via tunnels, but when customer complains you 
> have the native option to migrate them over to.

Absolutely: Get started with tunnels, then you can get everything
happening and when the provider catches up you are ready to go. With PI
space, the change is very simple. With PA space (space provided by a
tunnel provider is PA space) using tunnels arguably has the *advantage*
that you will have planned to renumber.

Don't misunderstand me: I'm NOT touting tunnels as the cure for all
ills. If native IPv6 is available, use native. But if native is not
available, or not yet, a tunnel presets a useful, cheap and above all
immediately deployable alternative. 

Regards, K.

[1] I'm associated with IPv6Now.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)
http://www.biplane.com.au/kauer
http://www.biplane.com.au/blog

GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A
Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017