- lir-wg - mailman.ripe.net

New Document available: RIPE-242
by RIPE NCC Document Announcement Service 04 Jun '02

04 Jun '02

New RIPE Document Announcement -------------------------------------- A New document is available from the RIPE document store. Ref: ripe-242 Title: Smallest RIPE NCC Allocation / Assignment Sizes Author: Joao Luis Silva Damas, Leo Vegoda Date: 4 June 2002 Format: PS=22198 TXT=2179 Obsoletes: ripe-222 Obsoleted by: Updates: Updated by: Short content description ------------------------- This document contains the size of the minimum and default allocations made by the RIPE NCC to Local Internet Registries (LIRs) and End Users from IPv4 and IPv6 CIDR blocks allocated to the RIPE NCC by the Internet Assigned Numbers Authority (IANA). Accessing the RIPE document store --------------------------------- The RIPE document store is available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-242.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-242.txt plain text version You can also access the RIPE documents in HTML format via WWW. RIPE-242 is not available from the WWW at this moment, but will be soon, at the following URL: http://www.ripe.net/ripe/docs/smallest-alloc-sizes.html Kind Regards, RIPE NCC Webmaster

1 0

Re: IPv6 policy and Supernational-LIRs
by Wilfried Woeber, UniVie/ACOnet 03 Jun '02

03 Jun '02

>On Thu, May 30, 2002 at 10:05:09AM +0200, Kurt Erik Lindqvist KPNQwest wrote: >[..] >> > Not all of the /32s might even necessarily be visible globally, upstream >> > could go through the /28. >> >> Well, in our case they would. Problem is that we do not have a /28. My >> point was to some extent that we should define this better. It's is a >> single LIR, but the question is what the allocation should be for routing >> purposes. I seem to be missing something here, because right now I cannot see a direct relationship between the fact that a LIR is a "regular" LIR or an aggregate LIR (multinational), or the size of the initial allocation (/35 vs /32 or /28) when we talk *routing table size*. I think the "load" comes from the *complexity*, all the rest is indeed a matter of a few bits... Wilfried. PS: and by the way, the current state of some "major" provider(s) here in Europe seem to suggest that most of those discussions tend to become mute pretty often these days ;-)

1 0

IPv6 policy and Supernational-LIRs
by Kurt Erik Lindqvist KPNQwest 31 May '02

31 May '02

Now that we have the new IPv6 policy in place, and we have try and start using it, I have a small problem. We have been allocated a IPv6 block for the Supernational-LIR. However, the actual LIR consits of several ASes, each present at it's own IX and with it's own routing policy. To me, a Supernational-LIR consists of several sub-LIRs. My problem is that RIPE will only allocate on /35 block to us, saying that is the allocation for our LIR. This means that we will end up having to break that block into smaller announcements, one per each sub-LIR. Could someone elaborate on the thinking behind this policy. To me it would routingwise make more sense to allocate a block per sub-LIR. Best regards, - kurtis -

8 14

Re: IPv6 policy and Supernational-LIRs
by James Aldridge 30 May '02

30 May '02

Kurt Erik Lindqvist KPNQwest wrote: > Now that we have the new IPv6 policy in place, and we have try and start > using it, I have a small problem. We have been allocated a IPv6 block for > the Supernational-LIR. However, the actual LIR consits of several ASes, > each present at it's own IX and with it's own routing policy. > > To me, a Supernational-LIR consists of several sub-LIRs. My problem is > that RIPE will only allocate on /35 block to us, saying that is the > allocation for our LIR. This means that we will end up having to break > that block into smaller announcements, one per each sub-LIR. There is a definite change between the IPv4 and IPv6 allocation policies for supernational LIRs as far as the RIPE NCC is concerned. For IPv4, supernational registries (contributing as, for example, as KPNQwest does for the eu.eunet registry, the equivalent of 6 large LIRs) would receive up to 1.5 times the number of allocations from the NCC that a single large registry would get. For IPv6, on the other hand, a supernational registry can only get a single allocation, irrespective of its size and contributions to the NCC. I don't recall this policy change being discussed in the RIPE policy making forum (the LIR WG) being being put in place by the NCC for the then interim IPv6 policy. I am aware that there are few supernational registries and that they are a pain for the RIPE NCC but this policyy change seems to work against the aggregation principles we need to follow if we're not going to have the routing table growth rate we've seen with IPv4. James

3 2

RE: New Document available: RIPE-233
by Michel Py 30 May '02

30 May '02

Havard, > Havard Eidnes wrote: > 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. The very purpose of placing them at different points is to have redundancy; so yes, for the same reason they must have different blocks. > 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. There is an advantage to scattered numbers, IMHO. Since they are scattered, nobody will try to aggregate them and suppress the specific announcements. Martian configs do happen; not often but they do. > 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. There are (at least) two ways to achieve this: 1. Two-space systems (the servers would have a unique identifier and multiple changeable locators). 2. "special assignement" otherwise called PI. I think the RIRs have acted responsibly so far in not showing the bad example of allocating themselves a PI block. A short-term fix to this would be a two-space system where the locator initially assigned could be transformed into the identifier later. Michel.

1 0

New Document available: RIPE-233
by RIPE NCC Document Announcement Service 30 May '02

30 May '02

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

9 12

Re: IPv6 policy and Supernational-LIRs
by James Aldridge 29 May '02

29 May '02

Gert Doering wrote: > Hi, > > On Wed, May 29, 2002 at 09:29:33AM +0000, James Aldridge wrote: > > For IPv6, on the other hand, a supernational registry can only get a single > > allocation, irrespective of its size and contributions to the NCC. I don't > > recall this policy change being discussed in the RIPE policy making forum (the > > LIR WG) being being put in place by the NCC for the then interim IPv6 policy. > > > > I am aware that there are few supernational registries and that they are a > > pain for the RIPE NCC but this policyy change seems to work against the > > aggregation principles we need to follow if we're not going to have the > > routing table growth rate we've seen with IPv4. > > I don't understand why "not giving out multiple IPv6 blocks" is > "against the aggregation principles". > > Could you elaborate on this? The old IPv6 policy gave a single /35 to a supernational registry. This meant that each "sub-LIR" would have to put up with, say, a /40 (enough for a mere 256 /48 assignments) and once this was used it would be unlikely that the next /40 available from the LIR's allocation would form an aggregatable block with the earlier "sub-allocation". With different "sub-LIRs" having different (national) routing policies, these multiple non-aggregatable blocks would have to be announced to peers. This doesn't sound like following aggregation principles to me ;-) However, that was the old IPv6 policy... > Being a bit more relaxed in judging whether a multinational LIR really > needs a "/22" (to be a bit extreme) would mimic the "IPv4 approach" > (give out more space than usual) fairly well. ... yes, I'm sure this would help. The supernational LIR adds a few extra levels of hierarchy here: - RIR - Supernational LIR - "sub-LIR" - sub-LIR's ISP customers (who are either not LIRs or LIRs who don't meet current IPv6 criteria) - end-user assignments If a hierarchy such as this could be used to justify a larger-than-/32 allocation then I don't think that big supernational registries would have any particular problems. James

2 1

Re: New Document available: RIPE-233
by Pekka Savola 25 May '02

25 May '02

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

1 0

RE: New Document available: RIPE-233
by matthew.ford＠bt.com 24 May '02

24 May '02

" It is not associated with the organisation(s) that operate the root server at a particular point in time and these organisations should not use the address space to provide any services not related to the root server." s/should/must/ Mat. > -----Original Message----- > From: RIPE NCC Document Announcement Service [mailto:ncc@ripe.net] > Sent: 24 May 2002 16:01 > To: ipv6-wg(a)ripe.net > Cc: lir-wg(a)ripe.net > Subject: New Document available: RIPE-233 >

1 0

Implementation of Global IPv6 Policy
by Mirjam Kuehne 24 May '02

24 May '02

Dear Colleagues, We are pleased to announce that the RIPE NCC will implement the new Global IPv6 Policy on 1 July 2002. This policy has been agreed by the communities of all the Regional Internet Registries (RIRs). Before 1 July 2002 we will publish and announce the following as RIPE Documents: - Global IPv6 Policy Document - Initial IPv6 Allocation Request Form in the RIPE NCC Service Region - IPv6 End User Site Assignment Request Form in the RIPE NCC Service Region (for prefixes shorter than a /48) Regards, -- Mirjam Kuehne RIPE NCC

7 6