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. It isn't always clear at what point RIPE has delegate something, and at what point a provider has registered a more specific route since the delegation and routing database appear to be merged in the RIPE model. And in fact the RBnet could aggregate many of these announcements.
Network [...] *>i62.76.0.0/22 [...] *>i62.76.4.0/23 [...] *>i62.76.6.0/23 [...] *>i62.76.8.0/24 [...] *>i62.76.122.0/24 [...] *>i62.76.124.0/23 [...] *>i62.76.128.0/23 [...] *>i62.76.130.0/24 [...] *>i62.76.136.0/23 [...] *>i62.76.144.0/21 [...]
-- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation
Hi Sean, Sean Donelan <SEAN@SDG.DRA.COM> writes: * 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. * * It isn't always clear at what point RIPE has delegate something, * and at what point a provider has registered a more specific route * since the delegation and routing database appear to be merged in * the RIPE model. And in fact the RBnet could aggregate many of these * announcements. In the RIPE NCC we distinguish between an ALLOCATION to a Local Internet Registry (Typically a larger ISP) and ASSIGNMENTS to the end users. The allocation is what is normally announced, unless specifically asked for a longer prefix we allocate a minimum of /19. The majority of Local Internet Registries seem to use more than a /20 in a year in the NCC's area of operations. The Local Internet Registries then assign this to their downstream. The RIPE NCC has no say in how the endusers/ISPs announce their addresses. Obviously we encourage people to aggregate and ask the Local Internet Registries to announce their allocation as one prefix if possible. You can distinguish an allocation by the inet-num object in the database having the status field with the value begining ALLOCATED. End user assignments have status: ASSIGNED.... This is the easiest way to distinguish them in the RIPE database. Sometimes endusers insist on having addresses independent of their provider. These are then often longer prefixes. If these are given then we give the clear warning that we give zero guarantee of routability and that there are (transit) providers using filters. All of the policies are defined in RIPE Documents available on our website www.ripe.net. The most important doc for this type of policy is presently RIPE-159. http://www.ripe.net/docs/ripe-159.html Hope this answers most of your questions. John Crain RIPE NCC * * > Network [...] * > *>i62.76.0.0/22 [...] * > *>i62.76.4.0/23 [...] * > *>i62.76.6.0/23 [...] * > *>i62.76.8.0/24 [...] * > *>i62.76.122.0/24 [...] * > *>i62.76.124.0/23 [...] * > *>i62.76.128.0/23 [...] * > *>i62.76.130.0/24 [...] * > *>i62.76.136.0/23 [...] * > *>i62.76.144.0/21 [...] * * * -- * Sean Donelan, Data Research Associates, Inc, St. Louis, MO * Affiliation given for identification not representation * *
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 ed@cistron.nl for PGP key
Edvard Tuinder <ed@cistron.net> writes: 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.
This is not correct. There are currently no plans to reduce the minimum allocation size from the current /19. To be precise about allocation vs assignment I quote from ripe-159 below. See this document at http://www.ripe.net/docs/ripe-159.html for details. Daniel 2.3. The Internet Registry System The Internet Registry system has been established to achieve the goals stated in Section 2.2. It con- sists of hierarchically organized Internet Reg- istries (IRs). Address space is typically assigned to end users by Local IRs. The address space assigned is taken from that allocated to the Local IR by the Regional IR. End users are those organi- zations operating networks in which the address space is used. ... Local IRs are typically operated by Internet Service Providers (ISPs). Local IRs hold allocations of address space for assignment to end users. Assigned address space is actually used to operate networks, whereas allocated address space is held by IRs for future assignments to end users. To achieve both the conservation and aggregation goals, only IRs can hold allocations of address space. ... 4.1. The Slow Start Mechanism To prevent allocating large blocks of address space that won't be assigned, the RIPE NCC has introduced the concept of a slow start for allocations. The idea is to allocate address space to Local IRs at the rate it will be assigned. The minimum size of an individual address space allocation is /19 (8192 addresses), and the maximum size is /16 (65536 addresses). The size of an allocation to a particu- lar Local IR is based solely on the rate that the IR has assigned previously allocated address space to end users. The slow start mechanism implements a consistent and fair policy for every Local IR with respect to allo- cations. Although the mechanism is similar to the assignment window mechanism described in Section 3.6, the policy it implements is different. The size of further allocations depends exclusively on the assignment rate of the Local IR concerned while the assignment window depends on the proficiency of the registry staff in evaluating requests and pro- cessing assignments. 4.2. First Allocation When a new Local IR starts up, it has no address space allocated to it. The first allocation will be made automatically by the RIPE NCC, generally upon receipt of the first assignment request from the Local IR. Because there is no information about the rate at which a new IR will make address assign- ments, the size of the first allocation is always a /19 (8092 addresses). Remember that the amount of space allocated does not determine the size of assignments a Local IR can make. As discussed at the end of Section 3, a new Local IR must have every assignment approved by the RIPE NCC until its assignment window is increased. 4.3. Further Allocations A Local IR can obtain additional allocations as required. A request should be submitted to the RIPE NCC when the currently allocated address space is nearly used up (about 90 percent), or if a single assignment will require a larger set of addresses than can be satisfied with the allocated address space. To obtain a new allocation, a Local IR should submit a request to the RIPE NCC which includes a complete list of the assignments made from all of their allocations. The RIPE NCC will check this information, compare it with assignments registered in the database and may request further information (such as documentation of some of the assignments) to determine the need for a new allocation. Addi- tional address space will be allocated after the information supplied with the request has been veri- fied, and a new allocation has been deemed neces- sary. Unfortunately, there is a tradeoff between the aggregation and conservation goals in making alloca- tions. To further aggregation, the RIPE NCC aims to allocate contiguous address ranges to a Local IR. However, because conservation of address space must also be taken into account, this is not always pos- sible. A new allocation to a registry can therefore not be expected to be contiguous with past alloca- tions. While the RIPE NCC always aims to further the aggregation goal, and therefore to allocate contigu- ous space, the RIPE policy is that under no circum- stances are multiple allocations made to the same Local IR guaranteed to be contiguous and aggregat- able with previous allocations.
I don't think RIPE has change their /19 allocations to registries. Hm... this from Ripe just last week: Forwarded message:
From dfk@ripe.net Wed Oct 14 06:28:45 1998 Message-Id: <199810141024.MAA19658@x46.ripe.net> To: Regional IR Boards <gar-boards@ripe.net> Subject: Initial Allocation Policy Cc: RIPE Local Internet Registries WG <lir-wg@ripe.net> From: Daniel Karrenberg <Daniel.Karrenberg@ripe.net> X-Organization: RIPE NCC X-Phone: +31 20 535 4444 Date: Wed, 14 Oct 1998 12:24:34 +0200 Sender: Daniel.Karrenberg@ripe.net
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 <ed@cistron.net> cc: nanog@merit.edu Fcc: sent Subject: Re: Is ripe allocating /24's? In-reply-to: Your message of "Tue, 20 Oct 1998 11:00:42 +0200." <199810200900.LAA17926@genius.cistron.net> -------- In message <199810200900.LAA17926@genius.cistron.net>, 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 ed@cistron.nl for PGP key
--- Jeremy Porter, Freeside Communications, Inc. jerry@fc.net PO BOX 80315 Austin, Tx 78708 | 512-458-9810 http://www.fc.net In message <199810200900.LAA17926@genius.cistron.net>, 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 ed@cistron.nl for PGP key
--- Jeremy Porter, Freeside Communications, Inc. jerry@fc.net PO BOX 80315 Austin, Tx 78708 | 512-458-9810 http://www.fc.net
Sean Donelan 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?
To quote the ripe-159 "European Internet Registry Policies and Procedures" document: "The minimum size of an individual address space allocation is /19"
Or is this provider just mis-reading the RIPE allocation database.
Probably...
It isn't always clear at what point RIPE has delegate something, and at what point a provider has registered a more specific route since the delegation and routing database appear to be merged in the RIPE model. And in fact the RBnet could aggregate many of these announcements.
Possibly some confusion between the routing registry ("route" objects) and the allocation and assignment registry ("inetnum" objects) which, for RIPE, are held in the same database? In the RIPE database inetnum objects have a status field which is either "ALLOCATED ..." (an allocation from the RIPE NCC regional registry to a local internet registry) or "ASSIGNED ..." (an assignment by a local IR to a customer). To find the first-level allocations from the RIPE NCC to local registries you can do, taking the 62/8 block as an example, whois -h whois.ripe.net "-T inetnum -r -m 62/8" (the RIPE whois client makes this slightly cleaner as the arguments don't have to be quoted)
Network [...] *>i62.76.0.0/22 [...] *>i62.76.4.0/23 [...] *>i62.76.6.0/23 [...] *>i62.76.8.0/24 [...] *>i62.76.122.0/24 [...] *>i62.76.124.0/23 [...] *>i62.76.128.0/23 [...] *>i62.76.130.0/24 [...] *>i62.76.136.0/23 [...] *>i62.76.144.0/21 [...]
In this case the 62.76/16 block was allocated to "ROSNIIROS Russian Institute for Public Networks" who have assigned smaller blocks to various organisations. Some of the corresponding routes may be aggregatable but others may not -- there seems to be a proliferation of autonomous systems in that part of the world, many announcing very small numbers of routes and not all even multi-homed... James
participants (6)
-
Daniel Karrenberg
-
Edvard Tuinder
-
James Aldridge
-
Jeremy Porter
-
John Crain
-
Sean Donelan