[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,