[routing-wg] RIPE Document Published - ripe-555, Address Space Managed by the RIPE NCC

[Andrea Cima]

[Copied ipv6-ops and v6ops mailing lists due to ongoing discussions 
about the same subject]

Hi Alexander,

On 7/10/12 5:29 PM, Alexander Gall wrote:

> That's much appreciated.  However, this list is missing a piece of
> information that some people have been using for many years to
> generate "martian/bogon"-type route filters.  From the old "longest
> prefix per block" list (and there is, or at least used to be such a
> list for every RIR), these people (like us) generate filters for BGP
> that deny all longer prefixes in such a range.  I don't see how we can
> infer this information from the file.  For example, how do we know
> exactly which IPv6 block has been set aside for IXP assignments in
> order to allow more specific prefixes in it?  Even if this information
> is available from somwhere (though I wouldn't know where), it would be
> useful to have a single place where this is recorded (and this place
> used to be RIPE-510 and its predecessors).

Both of IPv4 and IPv6 policies allow de-aggregation of allocations now. 
The requirement to announce an IPv6 allocation as one prefix only was 
removed from the policy in year 2009, please see:
https://www.ripe.net/ripe/policies/proposals/2009-06

IPv6 Address Policy requires that IPv6 PI assignments are made from a 
separate address block. This is described in RIPE 555. There is no such 
requirement in the policies for IPv6 IXP or TLD anycast. Root server 
assignments are all /32 and thus presumably not the subject of any 
filtering (Sascha, I hope this answers your question as well).

This document has been updated frequently in the past due to changes in 
policies and address assignment and allocation strategies, while at the 
same time not offering a very detailed view of the address space managed 
by the RIPE NCC. This version of the document is expected to change much 
less frequently while any loss of detailed information would be 
compensated by the published extended delegated statistics.

We understand however that you may want to filter based on prefix lengths.
The single data source for this is extended FTP stats we started 
publishing at
ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest
There you can see exactly which blocks were issued.

As explained above, the changes made to RIPE 510 have the aim to 
increase the quality of the data provided to operators. If however there 
is a strong feeling in the community to include additional information 
in RIPE 555, we will do so. In this case however it would be better if 
we could collect the feedback through a single mailing list. Therefore I 
would suggest the NCC Services Mailing List.

Best regards,
Andrea Cima
RIPE NCC


> Section 4 also has tremendous potential for misunderstandings, given
> the meaning of "longest prefix" in RIPE-510, which differs
> substantially from that of the /29 and /48 mentioned in RIPE-555.
>
> Regards,