IPv6 at NANOG 39
jeroen at unfix.org
Sat Feb 3 20:18:57 CET 2007
[not a directed rant... but yeah well it will read like it, make it a
nice topic at NANOG and discuss it]
Joe Abley wrote:
> Hi all,
> [If you're not coming to the NANOG meeting in Toronto, hit delete now.]
> The meeting side of the tunnel between Merit and the NANOG 39 router is
That address space seems to be encumbered by route deaggregation:
/40's, /44's and /48's all over the place.
Which part of "announce as a single aggregate" is missing in the ARIN
policy actually? Seems that quite a number are going over AS10886
anyway. This might be a good BoF thing: to deaggregate or not etc.
The other problem with that address space is of course the NREN factor
and especially the one where this NREN involved doesn't
want/can't/whatever peer with commercial providers.
> If there are people here planning to attend the meeting in Toronto who
> care about v6 performance to their home network, please feel free to
> test performance to that address and let me know if there are problems.
> We can always peer over tunnels if necessary to get things working
*ahem* *cough cough cough* Peer over TUNNELS!????!?!?!
As NANOG is for _Network Operators_ should it not be quite simple for
Network Operators to make sure that they can arrange a decent transit
Why not make it a challenge and demonstrate to the community that it is
possible, or impossible to arrange for good quality IPv6 connectivity
without having to resort to ugly things like tunnels?
The transits where you are receiving transit from should be contacted
instead to do their jobs properly and arrange that they can reach the
rest of the Internet properly; that is what you pay them for anyway.
If they can't do this, then you have a very nice BOF at NANOG to talk
about what the status is now, what is desired, and what steps to take to
From a US viewpoint doing traces it seems that latency is about 40ms,
which is about right, but could be that tracing from OCCAID, who are
connected to GIGAPoP might be beneficial there.
But it seems that, at least from .nl point of view, Gblx is doing
something really strange there. A ~160ms hop increase from Amsterdam to
the US. Normally such a hop is 80ms. Now either
jeroen at purgatory:~$ traceroute6 2001:468:1420:FF01::2
traceroute to 2001:468:1420:FF01::2 (2001:468:1420:ff01::2) from
2001:7b8:20d:0:290:27ff:fe24:c19f, 30 hops max, 24 byte packets
1 2001:7b8:5:10:74::1 (2001:7b8:5:10:74::1) 15.009 ms 9.693 ms
(2001:7b8:3:31:290:6900:31c6:d81f) 9.806 ms 13.497 ms 9.891 ms
3 jun1.sara.ipv6.network.bit.nl (2001:7b8::205:8500:120:7c1f) 11.92
ms 11.784 ms 13.878 ms
4 v6-transit.glbx.net (2001:7b8:40:7::1) 14.875 ms 11.875 ms 13.856 ms
(2001:450:2001:1000:0:670:1708:219) 166.934 ms 167.103 ms 166.982 ms
6 2001:468:ff:17c5::1 (2001:468:ff:17c5::1) 167.957 ms 167.235 ms
7 dnvrng-snvang.abilene.ucaid.edu (2001:468:ff:1017::1) 192.952 ms
191.842 ms 209.043 ms
8 kscyng-dnvrng.abilene.ucaid.edu (2001:468:ff:1013::2) 202.91 ms
202.997 ms 201.971 ms
9 iplsng-kscyng.abilene.ucaid.edu (2001:468:ff:1213::1) 210.961 ms
211.795 ms 211.962 ms
200ms, over quite high speeds links to reach a destination in the US is
a bit shameful. This number should be in the low low 100ms.
100ms extra and you could reach KAME in Japan:
14 orange.kame.net (2001:200:0:8002:203:47ff:fea5:3085) 286.958 ms
286.771 ms 287.967 ms
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 311 bytes
Desc: OpenPGP digital signature
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20070203/d3e0b651/signature.bin
More information about the ipv6-ops