IPv6 at NANOG 39

[Jeroen Massar]

[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
> 2001:468:1420:FF01::2.

That address space seems to be encumbered by route deaggregation:
http://www.sixxs.net/tools/grh/lg/?find=2001:468::/32

/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
> acceptably.

*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
service!?

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
get there.


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
10.902 ms
 2  i49.ge-0-1-0.jun1.kelvin.ipv6.network.bit.nl
(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
 5  2001:450:2001:1000:0:670:1708:219
(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
166.953 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
<dead>

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

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/20070203/d3e0b651/attachment.sig>