[74460] in North American Network Operators' Group
Re: IPv6 support for com/net zones on October 19, 2004
daemon@ATHENA.MIT.EDU (Jeroen Massar)
Mon Sep 27 04:30:05 2004
From: Jeroen Massar <jeroen@unfix.org>
To: Matt Larson <mlarson@verisign.com>
Cc: nanog@merit.edu
In-Reply-To: <20040924181058.GT9858@chinook.corpit.vrsn.com>
Date: Mon, 27 Sep 2004 10:29:12 +0200
Errors-To: owner-nanog-outgoing@merit.edu
--=-282+yt/G0fnQP8ai95Ho
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
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.
> >=20
> > 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.
>=20
> A few people have asked me privately to publish the IPv6 addresses
> ahead of time for reachability testing purposes, so here they are:
>=20
> 2001:503:a83e::2:30 (a.gtld-servers.net)
> 2001:503:231d::2:30 (b.gtld-servers.net)
>=20
> We would welcome opportunities for IPv6 tunnels to further improve our
> connectivity. Please contact ipv6-peering@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.=20
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@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=20
15.917 ms
2 sixxs-gw.ipv6.network.bit.nl (2001:7b8:3:4f:290:6900:4fc6:d81f)=20
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=20
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=20
174.535 ms 174.33 ms
7 sl-s1v6-nyc-t-1000.sprintv6.net (2001:440:1239:1001::2) 178.734 ms=20
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
--=-282+yt/G0fnQP8ai95Ho
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Jeroen Massar / http://unfix.org/~jeroen/
iD8DBQBBV89XKaooUjM+fCMRAkS3AKCGHY+/c9DgYyMgclF2Lb+9xi8cCwCff3C/
FGHG4ZGSC/uX8WR5Kk5QD+E=
=siMX
-----END PGP SIGNATURE-----
--=-282+yt/G0fnQP8ai95Ho--
