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 tunnel somewhere.
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 sense.
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, 192.88.99.1, then your tunnel endpoint is probably outside NZ -- but unpredictably further away than a fixed tunnel broker, since 192.88.99.0/24 is anycast and you can never be completely sure which relay router you're going to reach at any particular time.
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, 192.88.99.1 is in Poland, so your encapsulated packets are crossing two oceans. From a router attached to TCL's network, 192.88.99.1 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 great :)