Joe Abley wrote:
On 26 Feb 2005, at 05:50, Perry Lorier wrote:
On 25 Feb
2005, at 20:39, Philip D'Ath wrote:
> I'm talking about using NAT-PT to allow a native ipv6 network to
> talk to
> an ipv4 network. Without some kind of protocol translation (aka PT)
> ipv6 can't talk to ipv4. The reason this has to be done is because you
> can't buy an ipv6 connection to an ISP in NZ yet.
In the absense of local carriers with dual-stack
edge routers (i.e.
in the case of most of the planet) the way you do this is terminate a
I humbly disagree. My experience with public end user tunnel brokers
is that none of them are "close" enough to NZ. No matter who you
broker with you end up paying in huge (>3000ms in some cases!) RTT's,
this is especially true of the large US tunnel brokers such as
hurricane electric and freenet. A much more reliable way (IMHO) to
play with IPv6 in New Zealand is to use 6to4.
There's a slight contradiction in your sentiments above -- 6to4 is a
mechanism for tunnelling without manually specifying tunnel endpoints,
not some kind of address translation mechanism, and so "6to4 is more
reliable than tunnelling" doesn't seem to make a tremendous amount of
It's the public end user tunnel brokers that I have a problem with.
Tunneling itself is fine (well, native v6 is better still). 6to4 does
have the problem that you need to find the nearest anycast server, and
often they can be all over the place, and they don't seem to be long
term stable (they change from month to month). However if two people
speak 6to4 then they can do so with the same routes as IPv4, and not
introduce an extra detour out of the country and through some overloaded
tunnel broker. If you are speaking to someone using "real" v6 addresses
then you're probably going to have to leave the country one way or
another if it's going to be via 6to4 anycast or a public end user tunnel
broker. From my personal experience 6to4 is much more reliable than
tunnel brokers which have a tendency to disappear for a few days at a
time every now and again, with anycast it just hops on over to the next
anycast server. Originally I tried to run 6to4 and a tunnel broker to
try and get the best of both worlds, but ran into the problem I
mentioned with Linux's source address selection policies.
If you're using the rfc3068 6to4 relay router,
188.8.131.52, then your
tunnel endpoint is probably outside NZ -- but unpredictably further away
than a fixed tunnel broker, since 184.108.40.206/24 is anycast and you can
never be completely sure which relay router you're going to reach at any
Indeed. This is why I hope that ISP's in NZ will spend a little time
and setup their own 6to4 relay routers, as (I believe, I don't work for
an ISP) it should be fairly low impact on their current infrastructure
and fairly trivial to setup. This service doesn't even have to be a
critical service, since if the service fails, as long as the anycast
route is removed, users will just be provided degraded service.
From a router attached to ICONZ's network,
220.127.116.11 is in Poland, so
your encapsulated packets are crossing two oceans. From a router
attached to TCL's network, 18.104.22.168 is in Boston. Neither of these
are obviously better choices than the usual suspects on the west coast
of the US, or AARNet in Australia.
[Having said that, I have heard that some of the prominent tunnel
brokers have had scaling issues with their services, and it's possible
some of the large RTTs you've seen have been due to lab 7200s running at
100% CPU, or under-sized circuits to tunnel routers running at capacity.]
This is my hypothesis as to what's going on too. While I have never
directly spoken to someone who runs a tunnel broker, the wildly varying
RTT's somewhere in the last couple of hops suggests that it's the tunnel
broker, not the routes that is introducing the latency, however tunnel
brokers being overseas doesn't help the situation any either.
Everything is a trade off. Native v6 provides the best user experience,
with mostly stable latency and routes, and all the extra magical
features of IPv6 however native v6 requires finding equipment that
supports native v6, it requires finding people to talk to that will also
speak native v6 etc. End user tunnel brokers have stable latency and
routes, but require some level of configuration by the end user, they
are all outside the country, they have a history of high latency and/or
jitter as well as not being the most reliable service in the world.
6to4 has the advantage of being more reliable, has lower latency and
jitter to other 6to4 hosts, and is usually fairly trivial to configure,
but when talking to v6 native hosts you have to go via an anycast end
point which isn't necessarily stable, or topologically close. I presume
*BSD, and Windows users can probably combine fixed tunnels and 6to4 to
ameliorate their weaknesses.
My experience with end user tunnel brokers is that they do not provide a
good end user experience for people playing with IPv6 and lead to people
deciding that IPv6 is far less usable than IPv4.
Running a 6to4 relay router in your network is a nice
service to provide
to your customers, incidentally, if you're an ISP; it'd be a nice way
for the international carriers to atone for some of their de-peering
antics, for example (hint hint) :-)
Having ISP's in New Zealand provide a 6to4 relay router in NZ would be