Re: IPv6 support for com/net zones on October 19, 2004
Date: Wed, 27 Oct 2004 16:01:45 -0400 From: Joe Abley [EMAIL PROTECTED] 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=currentformat=htmla=2001:503:a83e::/48b=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
Re: IPv6 support for com/net zones on October 19, 2004
On Wed, Oct 27, 2004 at 04:01:45PM -0400, Joe Abley [EMAIL PROTECTED] 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.
Re: IPv6 support for com/net zones on October 19, 2004
* [EMAIL PROTECTED] (Stephane Bortzmeyer) [Thu 28 Oct 2004, 09:48 CEST]: On Wed, Oct 27, 2004 at 04:01:45PM -0400, Joe Abley [EMAIL PROTECTED] 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.
Re: IPv6 support for com/net zones on October 19, 2004
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!
Re: IPv6 support for com/net zones on October 19, 2004
* [EMAIL PROTECTED] (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. -- Today's subliminal thought is:
Re: IPv6 support for com/net zones on October 19, 2004
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: [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- PGP: 0xA85C8AA0
Re: IPv6 support for com/net zones on October 19, 2004
On Thu, 28 Oct 2004, Niels Bakker wrote: * [EMAIL PROTECTED] (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'. 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!
Re: IPv6 support for com/net zones on October 19, 2004
On Fri, Sep 24, 2004 at 02:10:58PM -0400, Matt Larson [EMAIL PROTECTED] 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?
Re: IPv6 support for com/net zones on October 19, 2004
On 27 Oct 2004, at 12:35, Stephane Bortzmeyer wrote: On Fri, Sep 24, 2004 at 02:10:58PM -0400, Matt Larson [EMAIL PROTECTED] 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. [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] show route 2001:503:a83e::2:30 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Joe
Re: IPv6 support for com/net zones on October 19, 2004
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, ATT, Verisign) but a traceroute is going straight from 6830 to ATT 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 -- CLUE-RIPE -- Jabber: [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- PGP: 0xA85C8AA0
Re: IPv6 support for com/net zones on October 19, 2004
On 27 Oct 2004, at 15:43, 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, ATT, Verisign) but a traceroute is going straight from 6830 to ATT 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. 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
RE: IPv6 support for com/net zones on October 19, 2004
Thanks Joe, great post re the /48's, I was just about to. We're working on this. -M -- Martin Hannigan (c) 617-388-2663 VeriSign, Inc. (w) 703-948-7018 Network Engineer IV Operations Infrastructure [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Joe Abley Sent: Wednesday, October 27, 2004 4:02 PM To: Daniel Roesen Cc: [EMAIL PROTECTED] Subject: Re: IPv6 support for com/net zones on October 19, 2004 On 27 Oct 2004, at 15:43, 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, ATT, Verisign) but a traceroute is going straight from 6830 to ATT 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. 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
IPv6 support for com/net zones on October 19, 2004
VeriSign will add support for accessing the com/net zones using IPv6 transport on October 19, 2004. On that day, 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 [EMAIL PROTECTED] VeriSign Naming and Directory Services
Re: IPv6 support for com/net zones on October 19, 2004
In article [EMAIL PROTECTED] you write: VeriSign will add support for accessing the com/net zones using IPv6 transport on October 19, 2004. On that day, 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 [EMAIL PROTECTED] 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
