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 * *