nanog mailing list archives

Re: Providers that carry IPv6


From: Jeroen Massar <jeroen () unfix org>
Date: Mon, 04 Jun 2007 12:21:41 +0100

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

Attachment: signature.asc
Description: OpenPGP digital signature


Current thread: