Antonio Querubin wrote:

On Mon, 4 Jun 2007, Jeroen Massar wrote:

...

Please at least honor: ip6.de.easynet.net/ipv6-minimum-peering.txt

A typical trans-Pacific path is significantly longer than a typical trans-Atlantic path. The < 40 ms policy recommendation in the above is unrealistically small for those of us out here in the Pacific Ocean where it takes roughly 50 ms just to reach only halfway across the ocean. It also favors a system of short IPv6 paths through multiple tunnels that add significant latency which is somewhat self-defeating. Ideally you want an IPv6 path between point A and point B to be reasonably close in latency to the IPv4 path.

That is indeed the intention of that document, therefor that "<40ms policy" can be mostly ignored for that type of links.

In the absence of ubiquitous, diverse, native IPv6 peering between Tier 1 providers, which I suspect will still take a while to develop, currently the only realistic way of keeping the latency delta minimized between an IPv4 path and an IPv6 path is to have your own diverse set of tunnels, even if it means tunnels that go halfway around the world.

I don't see a real reason why one needs to tunnel around the world. Unless you are indeed in a very remote location where no transit provider is providing IPv6 yet. If that is still the case though I definitely would suggest that you start kicking your current IPv4 transits *VERY* hard in several naughty places to get them going and start providing it. At the very least they can do a tunnel over their own infrastructure and terminate you at their ends.

The alternative is IPv6 connectivity that really stinks because packets have to bounce through multiple tunnels unnecessarilly.

Try to avoid that at all cost of course. But if that is the only way, then for the time being that is then the only solution. Of course document it properly and kick upstreams to fix it. Greets, Jeroen