it was discussed already, that it depends not on RIR, but on ICANN. When these guys will finish tests&checks, we will get that game to our painful collection. AKK * Iljitsch van Beijnum <iljitsch@muada.com> [2004-08-02 21:24]:

On 2-aug-04, at 19:42, Andrei Robachevsky wrote:

...

K-root server has now IPv6 transport enabled.

That's nice, but the first thing any DNS server does on startup is:

...

host -t ns -v . 2001:7fd::1 Using domain server 2001:7fd::1:

rcode = 0 (Success), ancount=13 The following answer is not verified as authentic by the server: . 518400 IN NS a.root-servers.net . 518400 IN NS h.root-servers.net . 518400 IN NS c.root-servers.net . 518400 IN NS g.root-servers.net . 518400 IN NS f.root-servers.net . 518400 IN NS b.root-servers.net . 518400 IN NS j.root-servers.net . 518400 IN NS k.root-servers.net . 518400 IN NS l.root-servers.net . 518400 IN NS m.root-servers.net . 518400 IN NS i.root-servers.net . 518400 IN NS e.root-servers.net . 518400 IN NS d.root-servers.net Additional information: a.root-servers.net 3600000 IN A 198.41.0.4 h.root-servers.net 3600000 IN A 128.63.2.53 c.root-servers.net 3600000 IN A 192.33.4.12 g.root-servers.net 3600000 IN A 192.112.36.4 f.root-servers.net 3600000 IN A 192.5.5.241 b.root-servers.net 3600000 IN A 192.228.79.201 j.root-servers.net 3600000 IN A 192.58.128.30 k.root-servers.net 3600000 IN A 193.0.14.129 l.root-servers.net 3600000 IN A 198.32.64.12 m.root-servers.net 3600000 IN A 202.12.27.33 i.root-servers.net 3600000 IN A 192.36.148.17 e.root-servers.net 3600000 IN A 192.203.230.10 d.root-servers.net 3600000 IN A 128.8.10.90

...and then we're back in v4 land again.

On 2-aug-04, at 21:50, Jon Lawrence wrote:

...

it was discussed already, that it depends not on RIR, but on ICANN. When these guys will finish tests&checks, we will get that game to our painful collection.

and I suppose the question is when are ICANN actually going to get around to it. They seem to have waited long enough to add some ccTLD AAAA records, but to me that seems kind of pointless without the root containing AAAA's.

I'm not so much concerned about how long this step took for exactly the reason you mention: there is little advantage in having TLD AAAA glue records (you say ccTLDs, what about the gTLDs then??) without the same for the root itself. What I _am_ worried about is the way they presented this fairly small step as a huge deal. As I wrote on my website: "One small step for mankind... but a huge step for ICANN." (With the announcement pretty much on the 35th anniversary of the moon landing and all.) -- Iljitsch van Beijnum - http://www.bgpexpert.com/ (updated: Jul 22, 1:28:10)

Hi Robert, Robert Martin-Legène wrote: [...]

And.. do you consider to get this into the root-servers.net zone itself? I suppose it would then actually get picked up as a glue and upset conservative parties? (but it might make the root v6-reachable - except at bootstrap).

Definitely. And not only in the root-servers.net but also in the hints file and in the root zone itself. And not only for K, but for all other root servers that have IPv6 transport enabled. But as we know it's more complex than just updating relevant files. This requires careful consideration of possible technical issues, so that RSSAC can provide clear recommendations to IANA. As far as I know this work in underway.

And finally, why is it that k.root-servers.net and k.root-servers.org has different IPv4-addresses?

The first one is the server itself, the second is the website containing information about K.

-- Robert Martin-Legene DK Hostmaster

Regards, Andrei -- Andrei Robachevsky RIPE NCC

On 3-aug-04, at 9:00, Pim van Pelt wrote:

| Just out of curiousity.. what is at 2001:7fd::0 ?

It's most probably a router anycast, which is the lowest possible IPv6 address in a given segment. I've forgotten the document that specifies this,

RFC 3513 section 2.6.1.

but afaik most operating systems today use it when forwarding is turned on.

But Real Routers (tm) don't. :-)

iljitsch@muada.com (Iljitsch van Beijnum) wrote:

...

This information is also available from www.root-servers.org webiste.

Since the ARIN micro allocation policy creates some problems, I was curious what kind of address space RIPE uses for k-root. A /32 "macro allocation", it turns out:

inet6num: 2001:07FD::/32 netname: K-rootserver-net-20030829 descr: This assignment given to k-root.server.net

I believe this ASSIGNment is in violation of existing IPv6 ALLOCATION policies. I would be very interested in learning any information to the contrary.

So do I, since I have a ccTLD service to provision with IPv6. Elmar. (And yes, ARIN sent me to RIPE, and they sent me home...) -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---

On Thu, Feb 24, 2005 at 07:28:43PM +0100, Iljitsch van Beijnum wrote:

Since the ARIN micro allocation policy creates some problems, I was curious what kind of address space RIPE uses for k-root. A /32 "macro allocation", it turns out:

inet6num: 2001:07FD::/32 netname: K-rootserver-net-20030829 descr: This assignment given to k-root.server.net

I believe this ASSIGNment is in violation of existing IPv6 ALLOCATION policies. I would be very interested in learning any information to the contrary.

http://www.ripe.net/ripe/docs/ipv6-rootservers.html "Under this policy, each (current or future) Internet DNS root server (as listed in the root-servers.net zone) in the RIPE region will be assigned a block of IPv6 address space for purposes of root server operations. The size of the block shall be the same as the size of the minimum allocation to Local Internet Registries (LIRs) valid at the time of the root server assignment." An ALLOCATION makes no sense as no assignments would be done. The root server operator IS the end user of the address space. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

On Thu, Feb 24, 2005 at 08:55:10PM +0100, Iljitsch van Beijnum wrote:

And it's extremely wasteful to use 2^96 addresses when only 1 is needed.

That's because of people's lazy and stupid habit of derriving policy from prefix length (exceeding the valid conclusions from the IPv6 architecture documents). I would have preferred the ARIN way of using /48s (end site size). Unfortunately still many people think (or just copied some random filter recommendation) that filtering ANY /48 is a good thing, and don't update filters. Regards, Dan'overly aggressive filtering considered harmful'iel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

Hi, On Thu, Feb 24, 2005 at 08:55:10PM +0100, Iljitsch van Beijnum wrote:

So who authorized this?

The normal RIPE policy process. People discussed it, and decided it's a useful idea to have a way to get well-known IPv6 addresses to root servers. The resulting document is ripe-233: --------------------- snip --------------------- IPv6 Addresses for Internet Root Servers in the RIPE Region Joao Luis Silva Damas Document ID: ripe-233 Date: 24 May 2002 Abstract This document describes the special case assignment policy for Internet DNS root servers in the RIPE region. --------------------- snip --------------------- The progress that led to this policy is documented in the archives.

It looks a lot like the RIPE NCC doesn't have to stick to its own rules when it doesn't feel like it.

Please try to get your facts straigth *before* making such statements. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234

Hi, On Thu, Feb 24, 2005 at 09:27:01PM +0000, Jon Lawrence wrote:

...

An ALLOCATION makes no sense as no assignments would be done. The root server operator IS the end user of the address space.

Yep, that makes sense. A root server operator would be an end user - can't imagine why they'd need more than a /48 though.

They need a /128. But experience has shown that BGP participants *do* filter, and as such, it was decided to go for a /32 in RIPE land. ARIN does /48s.

It would make sense to me if root servers were assigned directly from RIPE (possibly from a special allocation set as side for the root servers' use).

This is the way it is done.

It seems completely pointless to allocate/assign a /32 to a root server. If the root server operator gets an assignment (directly from RIPE) why does it need to be the same size as a normal minimum allocation.

BGP filters. But hey, so what. There are roughly 4 billion /32s - what do you gain by saving 10 /32s? The number of routing table entries (which are a larger problem than "exhaustion of the available /32s") doesn't change.

Regardless of min allocation size - which ISP isn't going to allow an known root server IP through. If people want to filter then let them, if they don't know what they're doing then that's their look out.

Root servers should be allocated/assigned (whatever) from a known block - that way everyone knows not to filter that block.

At the time the policy was written, people thought that this way would be better. On the subject of root servers, people tend to be conservative. OTOH, no policy that can't be changed if people think otherwise today. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234

sorry for replying to this to all of the mailinglist. On Thu, 24 Feb 2005, Iljitsch van Beijnum wrote: <znip:

inet6num: 2001:07FD::/32 netname: K-rootserver-net-20030829 descr: This assignment given to k-root.server.net

I believe this ASSIGNment is in violation of existing IPv6 ALLOCATION policies. I would be very interested in learning any information to the contrary.

This is pointless discussion, only point of it would maybe be to making it clear that the VERY few DNS _root-servers_ there are out there, are the ONLY thing important enough to get it's own /32. -- ------------------------------ Roger Jorgensen | rogerj@stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no -------------------------------------------------------