IPv6 support for com/net zones on October 19, 2004

Mon Sep 27 08:29:12 UTC 2004

On Fri, 2004-09-24 at 20:10, Matt Larson wrote:
> On Mon, 20 Sep 2004, Matt Larson wrote:
> > VeriSign will add support for accessing the com/net zones using IPv6
> > transport on October 19, 2004.  On that day, AAAA records for
> > a.gtld-servers.net and b.gtld-servers.net will be added to the root
> > and gtld-servers.net zones.
> > 
> > We do not anticipate any problems resulting from this change, but
> > because these zones are widely used and closely watched, we want to
> > let the Internet community know about the changes in advance.
> 
> A few people have asked me privately to publish the IPv6 addresses
> ahead of time for reachability testing purposes, so here they are:
> 
> 2001:503:a83e::2:30 (a.gtld-servers.net)
> 2001:503:231d::2:30 (b.gtld-servers.net)
> 
> We would welcome opportunities for IPv6 tunnels to further improve our
> connectivity.  Please contact ipv6-peering at verisign.com if you're
> interested.

Tunneling does *NOT* improve connectivity.

Please read: http://ip6.de.easynet.net/ipv6-minimum-peering.txt

Also note that these /48's are not visible at some ISP's:

grh.sixxs.net> show bgp 2001:503:a83e::2:30
BGP routing table entry for 2001:503:a83e::/48
Paths: (38 available, best #35, table Default-IP-Routing-Table)

grh.sixxs.net> show bgp 2001:503:231d::2:30
BGP routing table entry for 2001:503:231d::/48
Paths: (38 available, best #31, table Default-IP-Routing-Table)

Out of the current 47 active neighbours on GRH.
See http://www.sixxs.net/tools/grh/ for more information.

For the people not seeing these ARIN micro allocations, update your
filters (see: http://www.space.net/~gert/RIPE/ipv6-filters.html), or if
you have no intention of maintaining them, set them to filter anything
>/48 or just simply remove them as that is less of a pain and breaks
less things. 

See below for a traceroute from my home DSL line to B, as can be seen
the biggest latency is apparently between gblx and the US part of gblx,
I'll contact them to inquire what is going wrong there as ~150ms is
twice the atlantic, the rest of the path seems fine (20ms difference),
though there is an asynchronous route back in the path.

Greets,
 Jeroen

--

jeroen at purgatory:~$ traceroute6 2001:503:231d::2:30
traceroute to 2001:503:231d::2:30 (2001:503:231d::2:30) from
2001:7b8:300:0:290:27ff:fe24:c19f, 30 hops max, 16 byte packets
 1  gw-1.ede-01.nl.sixxs.net (2001:7b8:2ff::1)  13.093 ms  16.288 ms 
15.917 ms
 2  sixxs-gw.ipv6.network.bit.nl (2001:7b8:3:4f:290:6900:4fc6:d81f) 
16.01 ms  13.538 ms  12.962 ms
 3  jun1.sara.ipv6.network.bit.nl (2001:7b8::205:8500:120:7c1f)  15.399
ms  13.046 ms  15.323 ms
 4  eth10-0-0.xr1.ams1.gblx.net (2001:7f8:1::a500:3549:1)  14.57 ms 
19.869 ms  16.05 ms
 5  2001:450:1:1::22 (2001:450:1:1::22)  173.922 ms  173.351 ms  173.863
ms
 6  sl-bb1v6-rly-t-96.sprintv6.net (3ffe:2900:f:e::1)  174.849 ms 
174.535 ms  174.33 ms
 7  sl-s1v6-nyc-t-1000.sprintv6.net (2001:440:1239:1001::2)  178.734 ms 
177.391 ms  180.665 ms
 8  3ffe:2900:2001:3::2 (3ffe:2900:2001:3::2)  187.075 ms !S  192.268 ms
!S  225.92 ms !S

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 240 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20040927/e5433e8b/attachment.sig>