[ note: aggregated mails ;) ] On Wed, 2004-07-21 at 14:57, Joe Abley wrote:
On 21 Jul 2004, at 14:47, Stephane Bortzmeyer wrote:
Wrong, several root name servers (of course, not ICANN's one) are reachable over IPv6: read http://www.root-servers.org/ and edit your db.root.
With BIND, the hints file is used to bootstrap a nameserver such that it can find answers to the question "dig . NS", with attendant glue. Once such an answer has been received, the hints file is not used any more.
Remove the hints and 'load' your roots as a master, that is the trick I employ when I want to use alternate roots. Bind will complain but won't dig ;) Dirty trick and indeed as you mentioned the AAAA's should be in the root (.) otherwise everybody will have to do this dirtywork. <SNIP>
It would be interesting to know what a recursive nameserver with AAAA records added to its hints file and no IPv4 transit would do, after it got an answer with no IPv6 glue from a root nameserver, though. I haven't tried it.
It throws away your hints information thus basically it is left dead on the street... On Wed, 2004-07-21 at 15:02, Joe Abley wrote:
On 21 Jul 2004, at 15:33, Jeroen Massar wrote:
F.root-servers.org:
traceroute to 2001:500::1035 (2001:500::1035) from 2001:838:1:1:210:dcff:fe20:7c7c, 30 hops max, 16 byte packets 1 ge-1-3-0.breda.ipv6.concepts-ict.net (2001:838:1:1::1) 0.385 ms 0.35 ms 0.341 ms
[etc]
We are trying hard to make F available from our anycast nodes on its IPv6 address. Finding exchange points which (a) will give you v6 addresses and (b) have peers which will peer with you over IPv6 is not trivial, however.
Then I should advise you to come to the AMS-IX, there is no F there and it should not be hard to get IPv6 from the IX nor transit nor peers. Just give them a shout and I am sure people are willing to help out.
H.root-servers.org:
traceroute to 2001:500:1::803f:235 (2001:500:1::803f:235) from 2001:838:1:1:210:dcff:fe20:7c7c, 30 hops max, 16 byte packets 1 ge-1-3-0.breda.ipv6.concepts-ict.net (2001:838:1:1::1) 0.386 ms !H 0.347 ms !H 0.349 ms !H
Which gets announced as a /48 thus doesn't come through the filters...
If that doesn't make it through your filters, then your filters are broken. 2001:500:1::/48 is an ARIN micro-allocation, and it is perfectly legitimate to advertise it with no covering /32 supernet.
Incidentally, F is also announced as a /48, and is also an ARIN micro allocation (the first one they made, in fact). 2001:500::/48 seems to get through your filters ok.
This is indeed something odd, as can be seen in GRH* most ISP's get it and indeed the 2001:500:1::/48 doesn't get trough, I've taken it up with AS12871 who provide the connectivity for that machine and they control the filters not me ;) * = http://www.sixxs.net/tools/grh/lg/?find=2001:500::/32 Greets, Jeroen