Re: [routing-wg] RIPE Document Published - ripe-555, Address Space Managed by the RIPE NCC
Dear Alexander, On 7/10/12 10:46 AM, Alexander Gall wrote:
On Mon, 09 Jul 2012 15:24:31 +0200, Andrea Cima <andrea@ripe.net> said:
Dear colleagues, The RIPE Document ripe-555, "Address Space Managed by the RIPE NCC", has been published. The document is available at: https://www.ripe.net/ripe/docs/ripe-555/ This RIPE Document updates ripe-510 and now points to the extended delegated statistics containing the full list of resources that the RIPE NCC manages. The document also reflects the fact that the RIPE NCC needs to be able to issue blocks of any size from any /8, so the document was updated accordingly. Am I the only one who is confused by this document? I don't care much about IPv4, but this scares me:
The smallest prefix assigned by the RIPE NCC from any IPv6 range is a /48.
A /48 is the minimum assignment size for IPv6 PI and IXP assignments. Please see: http://www.ripe.net/ripe/docs/ripe-552#IPv6_PI_Assignments http://www.ripe.net/ripe/docs/ripe-451
At the same time, this text from RIPE-510, Section 4 has been removed
Network operators taking routing decisions based on prefix length are requested and encouraged to route at least blocks of sizes corresponding to the longest prefix and larger.
If this means what I naively think it does, I'd have missed the entire discussion about what I would perceive as a fundamental change in policy.
RIPE 555 is not a RIPE Policy document but a RIPE NCC organisational document. The scope of this document is to list the address space managed by the RIPE NCC.
So, I guess I'm just thoroughly confused. Can somebody help me understand what exactly RIPE-555 means?
I apologise if I have not been clear about the changes. I will try to clarify further. RIPE 510 listed only the /8s allocated to the RIPE NCC by IANA. With RIPE 555, our aim is to provide the full and current list of all address space managed by the RIPE NCC, therefore increasing the quality of the data provided. Please also note that not all blocks allocated to the RIPE NCC from IANA in the past are still fully managed by the RIPE NCC. Some IP address space was transferred to AFRINIC, for example. For this reason, we removed the static list and refer to the extended FTP stats, which contain accurate and up-to-date information. This is also the reason why the route sets for these /8s in the RIPE Database (see section 1 of RIPE 510) will be removed. I hope this clarifies. If not, please don't hesitate to contact me. Best regards, Andrea Cima RIPE NCC
Hello Andrea Thanks for the quick feedback. Please see my comments inline. On Tue, 10 Jul 2012 13:37:43 +0200, Andrea Cima <andrea@ripe.net> said:
Dear Alexander,
On 7/10/12 10:46 AM, Alexander Gall wrote:
On Mon, 09 Jul 2012 15:24:31 +0200, Andrea Cima <andrea@ripe.net> said:
Dear colleagues, The RIPE Document ripe-555, "Address Space Managed by the RIPE NCC", has been published. The document is available at: https://www.ripe.net/ripe/docs/ripe-555/ This RIPE Document updates ripe-510 and now points to the extended delegated statistics containing the full list of resources that the RIPE NCC manages. The document also reflects the fact that the RIPE NCC needs to be able to issue blocks of any size from any /8, so the document was updated accordingly. Am I the only one who is confused by this document? I don't care much about IPv4, but this scares me:
The smallest prefix assigned by the RIPE NCC from any IPv6 range is a /48.
A /48 is the minimum assignment size for IPv6 PI and IXP assignments. Please see: http://www.ripe.net/ripe/docs/ripe-552#IPv6_PI_Assignments http://www.ripe.net/ripe/docs/ripe-451
Ok. I try to explain below why the current formulation can appear to be misleading for some people that used RIPE-510 for a particular purpose.
At the same time, this text from RIPE-510, Section 4 has been removed
Network operators taking routing decisions based on prefix length are requested and encouraged to route at least blocks of sizes corresponding to the longest prefix and larger.
If this means what I naively think it does, I'd have missed the entire discussion about what I would perceive as a fundamental change in policy.
RIPE 555 is not a RIPE Policy document but a RIPE NCC organisational document. The scope of this document is to list the address space managed by the RIPE NCC.
You may underestimate the relevance of this document for operators :) Either that or I overestimate it.
So, I guess I'm just thoroughly confused. Can somebody help me understand what exactly RIPE-555 means?
I apologise if I have not been clear about the changes. I will try to clarify further.
RIPE 510 listed only the /8s allocated to the RIPE NCC by IANA. With RIPE 555, our aim is to provide the full and current list of all address space managed by the RIPE NCC, therefore increasing the quality of the data provided.
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). 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, -- Alex
[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,
Dear Alexander, all, On 7/10/12 5:29 PM, Alexander Gall wrote:
You may underestimate the relevance of this document for operators :)
After considering the operators feedback about RIPE-510 & RIPE555, RIPEstat developers have created another visual interpretation of RIR "delegations" data: an interactive widget in which you can query for any address space prefix (0/0, 2000::/3 or 5/8, for example) and receive a prefix size distribution as an output: https://stat.ripe.net/widget/rir-prefix-size-distribution You can use the resulting output to determine a cutting-off point for the filtering based on the minimum allocation size: for example, if the 213/8 block has only XX % prefixes smaller then /24, you might decide that it is safe to not accept those prefixes. Or you can go for the /25 or /23 instead. A data call API is also available for the scripting and creating your own favorite filters. We are interested in your feedback: - do you find this useful? - how can we improve it, so that it suits your needs even better? We already have multiple ideas for the additional features in the next release of the widget, but we are very much looking forward to hear from you and make a new widget or improve this one based on your needs! More information is available in the RIPE Labs article: https://labs.ripe.net/Members/becha/rir-prefix-size-distribution-in-ripestat Regards, Vesna -- Vesna Manojlovic BECHA@ripe.net Senior Community Builder +31205354444 for Measurements Tools RIPE NCC http://ripe.net
participants (3)
-
Alexander Gall -
Andrea Cima -
Vesna Manojlovic