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@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@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

On Fri, Sep 24, 2004 at 02:10:58PM -0400, Matt Larson <mlarson@verisign.com> wrote a message of 27 lines which said:

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)

Now that the IPv6 glues are published, I can not reach these nameservers from Renater: ~ % traceroute6 a.gtld-servers.net traceroute to a.gtld-servers.net (2001:503:a83e::2:30) from 2001:660:3003:8::4:68, 30 hops max, 16 byte packets 1 gw.nic.fr (2001:660:3003:8::1) 0.7 ms 0.729 ms 0.687 ms 2 afnic-g0-3-10.cssi.renater.fr (2001:660:300c:1001:0:131:0:2200) 1.432 ms 1.112 ms 1.195 ms 3 nri-a-g13-0-30.cssi.renater.fr (2001:660:3000:3c:86:10::) 1.979 ms 1.8 ms 1.632 ms 4 lyon-pos6-0.cssi.renater.fr (2001:660:3000:41:10:12::) 7.036 ms 6.962 ms 6.968 ms 5 P3-0.BAGCR1.Bagnolet.ipv6.opentransit.net (2001:688:0:3:4::) 12.875 ms 12.142 ms 12.189 ms 6 P6-0-0.BAG6AR1.Bagnolet.ipv6.opentransit.net (2001:688:0:2:4::3) 12.586 ms 12.422 ms 12.214 ms 7 P1-0.LON6AR1.London.ipv6.opentransit.net (2001:688:0:2:1::1) 21.898 ms 21.922 ms 21.672 ms 8 uk6x.ipv6.btexact.com (2001:7f8:2:1::1) 22.226 ms 21.841 ms 22.043 ms 9 v6-tunnel-grnet.ipv6.btexact.com (2001:7f8:2:8018::3) 90.603 ms 90.134 ms 90.413 ms 10 3ffe:2900:1c::2 (3ffe:2900:1c::2) 243.383 ms !S 243.933 ms !S 243.319 ms !S (!S : source route failed, which is quite surprising) Filtering of the micro-allocation of the /48? Something else? Other people with connectivity problems to gtld-servers.net?

On Wed, Oct 27, 2004 at 06:35:45PM +0200, Stephane Bortzmeyer wrote:

On Fri, Sep 24, 2004 at 02:10:58PM -0400, Matt Larson <mlarson@verisign.com> wrote a message of 27 lines which said:

...

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)

Filtering of the micro-allocation of the /48? Something else? Other people with connectivity problems to gtld-servers.net?

coming from 2001:418:3f4:0:20e:a6ff:febf:a5ca i'm unable to get a response from either as well: punk:~> dig @2001:503:a83e::2:30 ; <<>> DiG 8.3 <<>> @2001:503:a83e::2:30 ; (1 server found) ;; res options: init recurs defnam dnsrch ;; res_nsend to server 2001:503:a83e::2:30 2001:503:a83e::2:30: Connection timed out punk:~> dig @2001:503:231d::2:30 ; <<>> DiG 8.3 <<>> @2001:503:231d::2:30 ; (1 server found) ;; res options: init recurs defnam dnsrch ;; res_nsend to server 2001:503:231d::2:30 2001:503:231d::2:30: Connection timed out both go the same path: traceroute to 2001:503:231d::2:30 (2001:503:231d::2:30) from 2001:418:3f4:0:20e:a6ff:febf:a5ca, 30 hops max, 16 byte packets 1 nnn-7202-fe-1-0.nether.net (2001:418:3f4::1) 2.049 ms 1.473 ms 1.27 ms 2 d1-0-3-0-21.a00.anarmi01.us.ra.verio.net (2001:418:3000:5000::1) 5.059 ms 4.96 ms 4.924 ms 3 d3-1-3-0.r02.chcgil01.us.bb.verio.net (2001:418:0:6000::5) 13.355 ms 13.278 ms 13.208 ms 4 p16-3-0-0.r00.chcgil06.us.bb.verio.net (2001:418:0:2000::2a5) 13.401 ms 28.997 ms 13.391 ms 5 p16-0-3-0.r21.asbnva01.us.bb.verio.net (2001:418:0:2000::296) 38.976 ms 53.9 ms 39.5 ms 6 p16-4-0-0.r02.asbnva01.us.bb.verio.net (2001:418:0:2000::9e) 52.512 ms 45.23 ms 49.914 ms 7 fa-0-1-1.r00.asbnva01.us.b6.verio.net (2001:418:0:700b::b600) 39.007 ms 39.572 ms 38.958 ms 8 verio-gw.mdtnj.ipv6.att.net (2001:1890:61:8801::1) 50.276 ms 50.313 ms 50.428 ms 9 * * * 10 2001:1890:61:9102::2 (2001:1890:61:9102::2) 112.216 ms !S 111.795 ms !S 112.517 ms !S I'm not sure that !S is source route in this case, (sometimes things are slightly different in the programs from v4 to v6..) but either way it means a reachability issue of some sort. - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.

On 27 Oct 2004, at 12:35, Stephane Bortzmeyer wrote:

On Fri, Sep 24, 2004 at 02:10:58PM -0400, Matt Larson <mlarson@verisign.com> wrote a message of 27 lines which said:

...

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)

Now that the IPv6 glues are published, I can not reach these nameservers from Renater:

In case more data points are required, neither of those servers are reachable from ISC. We appear to have no route for a.gtld-servers.net at all, and only a single path for b, which suggests some route propagation issues (we're well multi-homed in 3557; I'd expect to see lots of paths). Maybe Verisign needs more (reliable) v6 transit. [jabley@tag]% traceroute6 2001:503:a83e::2:30 traceroute6 to 2001:503:a83e::2:30 (2001:503:a83e::2:30) from 2001:4f8:4:d::236, 64 hops max, 12 byte packets 1 2001:4f8:4:d:290:6900:d32:a81f 0.669 ms !A 0.557 ms !A 0.441 ms !A [jabley@tag]% traceroute6 2001:503:231d::2:30 traceroute6 to 2001:503:231d::2:30 (2001:503:231d::2:30) from 2001:4f8:4:d::236, 64 hops max, 12 byte packets 1 2001:4f8:4:d:290:6900:d32:a81f 0.624 ms 0.573 ms 0.449 ms 2 fa-5-2.a01.snfcca05.us.ra.verio.net 0.550 ms 0.463 ms 0.417 ms 3 xe-1-2-0-4.r20.plalca01.us.bb.verio.net 1.728 ms 1.757 ms 1.688 ms 4 p16-0-1-3.r21.asbnva01.us.bb.verio.net 62.086 ms 62.145 ms 62.046 ms 5 p16-4-0-0.r02.asbnva01.us.bb.verio.net 62.191 ms 62.166 ms 62.228 ms 6 fa-0-1-1.r00.asbnva01.us.b6.verio.net 62.316 ms 62.289 ms 62.218 ms 7 verio-gw.mdtnj.ipv6.att.net 73.927 ms 73.587 ms 74.037 ms 8 * *^C [jabley@tag]% dig @2001:503:a83e::2:30 com soa ; <<>> DiG 8.3 <<>> @2001:503:a83e::2:30 com soa ; (1 server found) ;; res options: init recurs defnam dnsrch ;; res_nsend: Connection refused [jabley@tag]% dig @2001:503:231d::2:30 com soa ; <<>> DiG 8.3 <<>> @2001:503:231d::2:30 com soa ; (1 server found) ;; res options: init recurs defnam dnsrch ;; res_nsend: Operation timed out [jabley@tag]%

Filtering of the micro-allocation of the /48? Something else?

That's not our problem; we see the route to 2001:503:231d::/48 just fine, for example: jabley@r2.sfo2> show route 2001:503:a83e::2:30 jabley@r2.sfo2> show route 2001:503:231d::2:30 inet6.0: 761 destinations, 1748 routes (759 active, 0 holddown, 21 hidden) + = Active Route, - = Last Active, * = Both 2001:503:231d::/48 *[BGP/170] 00:49:51, MED 0, localpref 100 AS path: 2914 7018 26415 I > to 2001:418:1c00:5000::1 via ge-0/1/0.63 [BGP/170] 00:49:51, MED 0, localpref 100, from 2001:4f8:4::3 AS path: 2914 7018 26415 I to fe80::2a0:a5ff:fe12:caf via so-0/0/0.0 > to fe80::2a0:a5ff:fe12:caf via so-1/0/0.0 jabley@r2.sfo2> Joe

On Wed, Oct 27, 2004 at 09:43:08PM +0200, Daniel Roesen wrote:

On Wed, Oct 27, 2004 at 03:21:44PM -0400, Joe Abley wrote:

...

Maybe Verisign needs more (reliable) v6 transit.

Something is broken in several colors here. I'm seeing AS_PATHs like 6830 6175 109 7018 26415 (Sprint, Cisco, AT&T, Verisign) but a traceroute is going straight from 6830 to AT&T and dying there with !P.

erm sorry, going Sprint (6175) => AT&T (7018). So skipping Cisco (109). Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

On Wed, Oct 27, 2004 at 04:01:45PM -0400, Joe Abley <jabley@isc.org> wrote a message of 42 lines which said:

Since I mailed that, 3557 started receiving a covering /48 for A.

a.gtld-servers.net works now for us. Verisign does not reply but may listen :-) b is still unreachable. We get a route but not everybody does.

From AS1930 (Portugal, Europe): [it works...]

;; Query time: 544 msec ;; SERVER: 2001:503:231d::2:30#53(2001:503:231d::2:30) ;; WHEN: Thu Oct 28 12:11:40 2004 ;; MSG SIZE rcvd: 504 ;; Query time: 547 msec ;; SERVER: 2001:503:a83e::2:30#53(2001:503:a83e::2:30) ;; WHEN: Thu Oct 28 12:43:23 2004 ;; MSG SIZE rcvd: 504 ./Carlos -------------- http://www.ip6.fccn.pt/nativeRCTS2.html Wide Area Network (WAN) Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (140068/465), naming (millions) and... people!"

On Thu, Oct 28, 2004 at 01:45:28PM +0200, Niels Bakker wrote:

Anyone else care to comment? The hop count is suspiciously lower for IPv6 than for IPv4, and has twice the latency (coming from Europe too). But again, this is traceroute `wisdom'.

One problem with IPv6 traceroute is, that Cisco got two things severly wrong in some versions: - TTL might not decremented when switching packets into GRE tunnels - ICMP TTL exceeded must be sourced from ingress interface. IOS violated that in some versions and used the EGRESS interface IP as source for the ICMP packets. Both bugs do severely hurt traceroutes and interpretation of them as you cannot be sure wether you are actually experiencing them or not. Unfortunately those IOS versions are still seen in the wild, and because the v6 world still uses (far too many senseless) tunnels. So interpreting traceroutes in v6 can sometimes really be considered guesswork, even more than in v4. :-Z Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

Date: Wed, 27 Oct 2004 16:01:45 -0400 From: Joe Abley <jabley@isc.org> Subject: Re: IPv6 support for com/net zones on October 19, 2004

[ ... ] We've had reports before of F's covering /48 (2001:500::/48) being filtered by some people, based on the conviction that /48s were always bad and should never be accepted by anybody. It's possible that this is biting Verisign, too.

A nice and handy tool to see if something is being propagated and/or filtered is the SixXS.net GRH Tool which allows prefix comparison(s): http://www.sixxs.net/tools/grh/compare/?when=current&format=html&a=2001:503:a83e::/48&b=2001:500::/48 (not much sense, since the AS's differ ;D) SixXS.net actively welcomes Ghost Route Hunter peers: http://www.sixxs.net/tools/grh/peering/ Regards, JP Velders