New Document available: RIPE-233
New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-233 Title: IPv6 Addresses for Internet Root Servers in the RIPE Region Author: Joao Luis Silva Damas Date: 24 May 2002 Format: PS=9362 TXT=2362 Obsoletes: Obsoleted by: Updates: Updated by: Short content description ------------------------- The "IPv6 Addresses for Internet Root Servers in the RIPE Region" document describes the special case assignment policy for Internet DNS root servers in the RIPE region. Accessing the RIPE document store --------------------------------- The RIPE document store is available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The document will be available shortly on the FTP-server at: ftp://ftp.ripe.net/ripe/docs/ripe-233.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-233.txt plain text version You can already access the RIPE document in HTML format via WWW at: http://www.ripe.net/docs/ipv6-rootservers.html Kind Regards, Jeroen Bet RIPE NCC Webmaster
Question: Why would you make a root-server renumber if it changes areas? The document starts by talking about why the servers are special and it is difficult to change the addresses etc. It ends by saying that if they change region they will have to renumber. Is there an explanation for this. At present we are talking about 13 servers I can't think of any large issues that would be caused by having the addresses routed from elsewhere outside the RIPE region. Maybe I'm missing something crucial? JC
John the idea is to treat this block of addresses as any other issued by the RIPE NCC. If the root server changes region, I will change administration (sort of having an LIR closing down). The new operator would request addresses somewhere else, or put forward a case to the LIR-WG to ask the RIPE NCC to re-issue the allocation to the root server at the new place. Things are better without exceptions, that's all Cheers, Joao
Having to "force" a root server to renumber if it goes out of RIPE's region seems like a bad idea. ARIN's micro allocation policy does not specifically require a renumber for critical (root-server) infrastructure, should that infrastructure move outside of ARIN's region. So, maybe the root-servers should goto IANA and be allocated IP space directly from IANA and thus be a "special RIR" ?? John Brown Chagres Technologies, Inc critical infrastructure != LIR winding up
-----Original Message----- From: owner-lir-wg@ripe.net [mailto:owner-lir-wg@ripe.net]On Behalf Of Joao Luis Silva Damas Sent: Tuesday, May 28, 2002 2:44 AM To: John L Crain; webmaster@ripe.net Cc: ipv6-wg@ripe.net; lir-wg@ripe.net Subject: Re: New Document available: RIPE-233
John
the idea is to treat this block of addresses as any other issued by the RIPE NCC. If the root server changes region, I will change administration (sort of having an LIR closing down). The new operator would request addresses somewhere else, or put forward a case to the LIR-WG to ask the RIPE NCC to re-issue the allocation to the root server at the new place.
Things are better without exceptions, that's all
Cheers, Joao
H Joao Isn't the whole policy in itself is a single, and to be a very clearly defined, exception? So if we have to make this one exception because of the issues stated, i.e. difficulty in renumbering etc. Why not make the exception in such a manner that the address block is allocated to the specific root-server and stays with that root server, no matter where it goes? The idea of having them possibly need to renumber, when they move, be treated just like any other network (or LIR) to my mind defeats a large part of the point of the exception. JC At 10:43 AM 5/28/2002 +0200, Joao Luis Silva Damas wrote:
John
the idea is to treat this block of addresses as any other issued by the RIPE NCC. If the root server changes region, I will change administration (sort of having an LIR closing down). The new operator would request addresses somewhere else, or put forward a case to the LIR-WG to ask the RIPE NCC to re-issue the allocation to the root server at the new place.
Things are better without exceptions, that's all
Cheers, Joao
John, Joao, On Tue, May 28, 2002 at 07:19:31AM -0700, John L Crain wrote:
Isn't the whole policy in itself is a single, and to be a very clearly defined, exception?
So if we have to make this one exception because of the issues stated, i.e. difficulty in renumbering etc. Why not make the exception in such a manner that the address block is allocated to the specific root-server and stays with that root server, no matter where it goes?
The idea of having them possibly need to renumber, when they move, be treated just like any other network (or LIR) to my mind defeats a large part of the point of the exception.
I agree. In addition, just like we asked the registries to use a single block of addresses worldwide for exchange points, it seems to make sense to do the same thing (but a different block!) for rootname servers. Would it not be possible to coordinate such a block with the other RIRs ?!? David K. ---
At 13:29 -0700 28/5/02, David Kessens wrote:
I agree. In addition, just like we asked the registries to use a single block of addresses worldwide for exchange points, it seems to make sense to do the same thing (but a different block!) for rootname servers. Would it not be possible to coordinate such a block with the other RIRs ?!?
Actually I think it makes much more operational sense to *not* put all the root name servers in one block. Joao
I would agree that having them in on single block could make for certain types of capture problems. Thus having the RIR assign a "random" block to a root server would be a good thing. As long as it doesn't mandate a renumber of the server should it re-locate. john brown
-----Original Message----- From: owner-lir-wg@ripe.net [mailto:owner-lir-wg@ripe.net]On Behalf Of Joao Luis Silva Damas Sent: Wednesday, May 29, 2002 2:00 AM To: David Kessens Cc: ipv6-wg@ripe.net; lir-wg@ripe.net Subject: Re: New Document available: RIPE-233
At 13:29 -0700 28/5/02, David Kessens wrote:
I agree. In addition, just like we asked the registries to use a single block of addresses worldwide for exchange points,
it seems to
make sense to do the same thing (but a different block!) for rootname servers. Would it not be possible to coordinate such a block with the other RIRs ?!?
Actually I think it makes much more operational sense to *not* put all the root name servers in one block.
Joao
I would agree that having them in on single block could make for certain types of capture problems.
I have to ask a rhetorical question here, what is a "block" in this context? Is it a single routing announcement? Surely, it cannot be, because the different root name servers are placed at different points in the topology. I'll claim that the actual numeric sequence (or non-sequence) of the IPv6 address blocks allocated to the root name servers do not matter; the identity of the blocks will be well-known anyway, so there is no robustness gain to be had from picking "obscure" or "scattered" numbers. I do however agree with those which have said that a root name server should not have its address changed when it moves between RIR regions; the whole point of this "special" assignment to the root name servers is to avoid *any* renumbering because the DNS bootstrap data is (currently) distributed in a static configuration file. Regards, - H�vard
Havard Eidnes said:
I'll claim that the actual numeric sequence (or non-sequence) of the IPv6 address blocks allocated to the root name servers do not matter; the identity of the blocks will be well-known anyway, so there is no robustness gain to be had from picking "obscure" or "scattered" numbers.
Actually, I can think of one reason to scatter them: it means that an erroneous route table entry (whether due to someone's error or a router bug) is less likely to take them all out. Whereas if they're all in the same (say) /28, ... -- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8371 1138 Internet Expert | Home: <clive@davros.org> | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | NOTE: fax number change
On Wed, 29 May 2002, Joao Luis Silva Damas wrote:
At 13:29 -0700 28/5/02, David Kessens wrote:
I agree. In addition, just like we asked the registries to use a single block of addresses worldwide for exchange points, it seems to make sense to do the same thing (but a different block!) for rootname servers. Would it not be possible to coordinate such a block with the other RIRs ?!?
Actually I think it makes much more operational sense to *not* put all the root name servers in one block.
Definitely not one _/32_, that's for sure. But 10 different /32's, from one /27 (for example)? Seems just fine to me. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
Actually I think it makes much more operational sense to *not* put all the root name servers in one block.
agreed^2 if one believes this scenario, than each having its own normal sized (i.e. globally routable) block is the only method i can see. [ unless we want to discuss the anycast path ] randy
Randy, Joao, On Wed, May 29, 2002 at 02:52:40AM -0700, Randy Bush wrote:
Joao wrote:
Actually I think it makes much more operational sense to *not* put all the root name servers in one block.
agreed^2
if one believes this scenario, than each having its own normal sized (i.e. globally routable) block is the only method i can see. [ unless we want to discuss the anycast path ]
I should have been more precise in my wording, I assumed that nobody would even think of not having a globally routed block for each server (except for the anycast model). My suggestion should have been read as that I would prefer that these routable blocks of address space come out of a larger address range set aside for rootnameserver numbering purposes. One of the reasons that people want their own address space for rootnameservers is that it becomes easier to apply policy for the rootnameserver operator but also for the users of the servers. Using one address range for all the different routable blocks of rootnameserver address space makes it easier to recognize that one deals with 'special' address space when one sees such an address and it makes it easier to apply policies on all these special addresses at once (if one desires so) instead of dealing with a list of randomly choosen prefixes. David K. ---
On Fri, May 24, 2002 at 05:01:15PM +0200, RIPE NCC Document Announcement Service wrote:
Ref: ripe-233 Title: IPv6 Addresses for Internet Root Servers in the RIPE Region
I heard someone suggest that all allocations should be done from the same superblock. Although it's not in the document, I think it makes sense. We all hate our martian filters, so putting the "exception to the rule" in the same superblock will make your name go over in history. PS: Removed webmaster from recipient list. -- Robert Martin-Legene
On Fri, 24 May 2002, Robert Martin-Leg�ne wrote:
On Fri, May 24, 2002 at 05:01:15PM +0200, RIPE NCC Document Announcement Service wrote:
Ref: ripe-233 Title: IPv6 Addresses for Internet Root Servers in the RIPE Region
I heard someone suggest that all allocations should be done from the same superblock. Although it's not in the document, I think it makes sense. We all hate our martian filters, so putting the "exception to the rule" in the same superblock will make your name go over in history.
This is assigning /32's to root servers. There are no need for "exceptions to the rule", unless you're thinking of e.g. special rules for BGP flap dampening for root servers or such. Btw, I agree with Matthew Ford that 'should' was too mild a word. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords
participants (10)
-
Clive D.W. Feather -
David Kessens -
Havard Eidnes -
Joao Luis Silva Damas -
John L Crain -
John M. Brown -
Pekka Savola -
Randy Bush -
RIPE NCC Document Announcement Service -
Robert Martin-Legène