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.
Matt
In article <20040920205849.GA6162@tornado.kahlerlarson.org> you write:
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.Matt
--
Matt Larson <mlarson@verisign.com>
VeriSign Naming and Directory Services
So does this mean A and B will now support EDNS?
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-node-requirements-11.txt
Section 5?
I know it's only a day's work to add support if
you havn't already done it.
Mark
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.
Thanks,
Matt
> 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
Please do NOT do any long-haul tunneling! See the MIPP document for
elaboration on reasoning. I can understand tactic short-haul tunnels
to actually provide any connectivity, but please no long-haul tunnels
which really distort global v6 routing decisions. Seek native transits
in US and be done with it.
Thanks for your consideration.
Best regards,
Daniel
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?
Stephane Bortzmeyer wrote:
(!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?
This is from 3ffe:401d:2022:b::2 (a /48 served by a tunnel from occaid.org)
suresh@frodo 22:02:17 [~]$ traceroute6 a.gtld-servers.net
traceroute6 to a.gtld-servers.net (2001:503:a83e::2:30) from 3ffe:401d:2022:b::2, 30 hops max, 12 byte packets
1 18.gr-0-1-0.cr1.sfo2.us.occaid.org 13.767 ms 13.622 ms 14.371 ms
2 sl-bb1v6-sj-t-23.sprintv6.net 16.526 ms 16.801 ms 16.611 ms
3 sl-bb1v6-rly-t-1002.sprintv6.net 97.204 ms 96.842 ms 96.615 ms
4 3ffe:2900:1c::2 99.798 ms !P 99.984 ms !P 100.182 ms !P
srs
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 wrote:
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.
!S Destination Unreachable - Not a Neighbour.
Pete
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
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.
That you have no route for A is most probably a filtering issue
somewhere... I'm seeing it being propagated by Sprint.
Best regards,
Daniel
erm sorry, going Sprint (6175) => AT&T (7018). So skipping Cisco
(109).
Regards,
Daniel
Since I mailed that, 3557 started receiving a covering /48 for A. Maybe there's some operational/maintenance-induced stability issues for those paths.
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.
For the record, ARIN assign critical-infrastructure /48s which it is important to accept:
http://www.arin.net/registration/ipv6/micro_alloc.html
Gert D�ring maintains an excellent summary of current good practice for v6 filtering (including cisco and JUNOS configuration examples, and filters of various degrees of strictness) here:
http://www.space.net/~gert/RIPE/ipv6-filters.html
Operators who are currently blocking any prefix covered by 2001::/16 which is longer than 32 bits are encouraged to review that page, and fix their routers.
Joe
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.
* bortzmeyer@nic.fr (Stephane Bortzmeyer) [Thu 28 Oct 2004, 09:48 CEST]:
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
Better than the other way around...
b is still unreachable. We get a route but not everybody does.
Both now work for me. But I've always seen both routes.
-- Niels.
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!"
* cfriacas@fccn.pt (Carlos Friacas) [Thu 28 Oct 2004, 13:38 CEST]:
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
Query times using IPv6 seem significantly higher than those for IPv4 to
both a and b.gtld-servers.net, but as far as you can trust traceroute it
doesn't seem as if the IPv4 and IPv6 addresses for each host end up in
wildly different places...
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'.
-- Niels.
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
* cfriacas@fccn.pt (Carlos Friacas) [Thu 28 Oct 2004, 13:38 CEST]:
> 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: 504Query times using IPv6 seem significantly higher than those for IPv4 to
both a and b.gtld-servers.net, but as far as you can trust traceroute it
doesn't seem as if the IPv4 and IPv6 addresses for each host end up in
wildly different places...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'.
Yes. Definitely there are tunnels in the path...
For now, i dont care about query times, i only wish to guarantee
reachability. The next phase will only happen when *more* tier-1s start to
sell ipv6 transit on the same basis they sell ipv4 transit for years.
-- Niels.
--
Today's subliminal thought is:
./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!"
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