Providers that carry IPv6

[Jeroen Massar]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 311 bytes
Desc: OpenPGP digital signature
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20070604/a9c287d8/attachment.sig>