|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Is ripe allocating /24's?
I don't think RIPE has change their /19 allocations to registries. Hm... this from Ripe just last week: Forwarded message: > From [email protected] Wed Oct 14 06:28:45 1998 > Message-Id: <[email protected]> > To: Regional IR Boards <[email protected]> > Subject: Initial Allocation Policy > Cc: RIPE Local Internet Registries WG <[email protected]> > From: Daniel Karrenberg <[email protected]> > X-Organization: RIPE NCC > X-Phone: +31 20 535 4444 > Date: Wed, 14 Oct 1998 12:24:34 +0200 > Sender: [email protected] > > > > Background > ---------- > > The advisory council of ARIN asked ARIN to consider changing the current > allcation policy. The initial allocation to a new LIR/ISP should be > reduced from a /19 to a /20. The reason being that this would make it > easier for new ARIN customers to receive an allocation directly from > ARIN rather than from their up-stream provider. According to ARIN's > local allocation policy they would then need to justify the utilisation > of only a /21 instead of a /20 previously allocated to them by their > upstream provider. > > Another motivation is to improve conservation of address space by > reducing the amount of unused addresses in initial allocations. > The new policy would not increase the load on the global routing, > because the same amount of allocations would still be given out, just > one longer prefix. > > Before deciding on this proposal ARIN has asked the other regional > registries (APNIC and RIPE NCC) to also consider this change. > > > Considerations > -------------- > > Based on the RIPE NCC allocation data starting in 1992 we investigated > how much impact the proposed change would have on the conservation of > address space. We determined how many LIRs in our service region had > not used more than a /20 from their initial /19 allocation within one > year. The results are as follows: > > Of 1410 LIRs checked 304 (22%) had assigned not more than a /20 during > the first 12 months of operations. This means that 78% of the LIRs had > used more than a /20 within one year. The total amount of allocated but, > after one year, not yet assigned address space was equivalent to 19 /16s. > Some of the LIRs which did not have assigned more than a /20 after one > year have since become inactive and the address space concerned will not > be assigned in the foreseeable future. However 272 of the 304 are still > operational and it is likely that most of them will assign more address > space in the future. > > Further investigations showed that about 50% of those LIRs who haven't > used more than a /20 appear to be multihomed. > > > Conclusions > ----------- > > These results have been presented to the LIR WG at the 31. RIPE Meeting > in Edinburgh. The LIR WG is the body defining local address space > policy for the RIPE NCC. The LIR WG didn't feel that this is a reason > to change the current allocation policy. The benefits for conservation > are not significant. > > However, the consequences for aggregation are likely to be noticeable > if 80% of LIRs require a second allocation within a year. > Furthermore the LIR WG expressed concerns about the routability of > longer pefixes in the light of current prefix-length dependent filtering > and flap dampening policies. > > Under the current circumstances the LIR WG did not see a valid reason to > change the current allocation policy. We ask the ARIN membership to > take this into consideration and consider other ways of achieving > the aims of the proposed change. > --- To: Edvard Tuinder <[email protected]> cc: [email protected] Fcc: sent Subject: Re: Is ripe allocating /24's? In-reply-to: Your message of "Tue, 20 Oct 1998 11:00:42 +0200." <[email protected]> -------- In message <[email protected]>, Edvard Tuinder writes: >On .nanog you wrote: >>A provider has made the claim to me that RIPE is allocating /24's >>addresses to various European providers. Is this true? What affect >>does this have on providers with prefix-length filters? >> >>Or is this provider just mis-reading the RIPE allocation database. > >I think he is misreading the allocation database. The minimum allocation >size used to be /19 and will become (or is) /20 to facilitate smaller >providers. A /24 will not be allocated. > >What may be the case is that when you get *assigned* a /19, you're not >allowed to use it without RIPE's knowledge. During your first own assignements >, >you'll have to ask RIPE for approval. But that does _not_ imply that you're >not allowed to announce the full block (which is even specifically noted >in the doc's, it's just that you're not allowed ot _use_ (or re-assign) >anything. > >-Ed >-- >Edvard Tuinder >Cistron Internet Services Finger [email protected] for PGP key > --- Jeremy Porter, Freeside Communications, Inc. [email protected] PO BOX 80315 Austin, Tx 78708 | 512-458-9810 http://www.fc.net In message <[email protected]>, Edvard Tuinder writes: >On .nanog you wrote: >>A provider has made the claim to me that RIPE is allocating /24's >>addresses to various European providers. Is this true? What affect >>does this have on providers with prefix-length filters? >> >>Or is this provider just mis-reading the RIPE allocation database. > >I think he is misreading the allocation database. The minimum allocation >size used to be /19 and will become (or is) /20 to facilitate smaller >providers. A /24 will not be allocated. > >What may be the case is that when you get *assigned* a /19, you're not >allowed to use it without RIPE's knowledge. During your first own assignements >, >you'll have to ask RIPE for approval. But that does _not_ imply that you're >not allowed to announce the full block (which is even specifically noted >in the doc's, it's just that you're not allowed ot _use_ (or re-assign) >anything. > >-Ed >-- >Edvard Tuinder >Cistron Internet Services Finger [email protected] for PGP key > --- Jeremy Porter, Freeside Communications, Inc. [email protected] PO BOX 80315 Austin, Tx 78708 | 512-458-9810 http://www.fc.net
|