RIPE NCC CIDR blocks - smallest allocations
During the RIPE 36 meeting in Budapest there was a request to publish the list of CIDR blocks allocated by the RIPE NCC and the smallest allocation issued from each of them. This is it: 62/8: /19 193/8: /29 # Contain small PI assignments 194/8: /29 # Contain small PI assignments 195/8: /29 # Contain small PI assignments 212/8: /19 213/8: /19 217/8: /20 We shall put this information permanently on our website. regards, Joao Damas Head of External Services RIPE NCC
During the RIPE 36 meeting in Budapest there was a request to publish the list of CIDR blocks allocated by the RIPE NCC and the smallest allocation issued from each of them.
This is it:
62/8: /19 193/8: /29 # Contain small PI assignments 194/8: /29 # Contain small PI assignments 195/8: /29 # Contain small PI assignments 212/8: /19 213/8: /19 217/8: /20
We shall put this information permanently on our website.
thank you joao! would other rirs be so kind as to do the same, keep them updated, and link the lists to eachother or something? (yes, i know some do) randy
On Wed, 21 Jun 2000, Randy Bush wrote: randy> > During the RIPE 36 meeting in Budapest there was a request to publish randy> > the list of CIDR blocks allocated by the RIPE NCC and the smallest randy> > allocation issued from each of them. randy> > randy> > We shall put this information permanently on our website. randy> randy> thank you joao! randy> randy> would other rirs be so kind as to do the same, keep them updated, and link randy> the lists to eachother or something? (yes, i know some do) http://www.apnic.net/db/RIRs.html . -- Bruce Campbell <bruce.campbell@apnic.net> +61-7-3367-0490 Systems Administrator Regional Internet Registry Asia Pacific Network Information Centre For the Asia Pacific Region
[ note reduced cc:s ]
would other rirs be so kind as to do the same, keep them updated, and link the lists to eachother or something? (yes, i know some do) http://www.apnic.net/db/RIRs.html .
given three to five rirs, i can probably remember their names. the referenced page lacks prefix sizes, the subject here. randy
hi Randy, APNIC can certainly document on our web site the minimum allocations made in each of our /8 blocks. I'll post an announcement to the various lists when it is done. Best wishes, Anne Manager, Member Services -- See you at the APNIC Meeting - Brisbane, Australia 25 - 27 October 2000 | http://www.apnic.net/meetings/ ***************************************************** On Thu, 22 Jun 2000, Randy Bush wrote:
[ note reduced cc:s ]
would other rirs be so kind as to do the same, keep them updated, and link the lists to eachother or something? (yes, i know some do) http://www.apnic.net/db/RIRs.html .
given three to five rirs, i can probably remember their names. the referenced page lacks prefix sizes, the subject here.
randy
hi anne,
APNIC can certainly document on our web site the minimum allocations made in each of our /8 blocks. I'll post an announcement to the various lists when it is done.
that would be appreciated. among other things, we net.filtet.nazis can then link to it. randy
http://www.apnic.net/db/RIRs.html . Interesting but it doesn't contain the data in Joao's posting nor does it contain the equivalent data from the other registries. Mark.
Seeing this mail, together with the cyclic discussions on NANOG about prefix filters and 'does anyone know if Provider X is filtering prefixes from block Y at mask Z' type problems, got me thinking that it might be a good idea for the RIPE community to come up with a set of recommendations for BGP prefix filters. It would have a number of advantages. - a standard prefix filter recommendation would always be in synch with Registry practices. - it would lower the effort barrier for people to implement prefix filtering in the first place, and therefore foster stability of the global routing system. - it would at least help to align the filtering practices of Providers a little bit, so that debugging routing problems becomes a little bit less like guesswork... hopefully fewer threads like 'does anyone know if Provider X is filtering prefixes from block Y at mask Z?' I am thinking of something broadly along the lines of RIPE-210 for route dampening. Feedback? Phil At 17:32 21.06.00 +0200, Joao Luis Silva Damas wrote:
During the RIPE 36 meeting in Budapest there was a request to publish the list of CIDR blocks allocated by the RIPE NCC and the smallest allocation issued from each of them.
This is it:
62/8: /19 193/8: /29 # Contain small PI assignments 194/8: /29 # Contain small PI assignments 195/8: /29 # Contain small PI assignments 212/8: /19 213/8: /19 217/8: /20
We shall put this information permanently on our website.
regards,
Joao Damas Head of External Services RIPE NCC
Philip Bridge Nextra (Schweiz) AG <www.nextra.ch> Tel: +41 031 985 88 06 / Mobile: +41 79 659 75 50 E-Mail: <mailto:bridge@nextra.ch> Disclaimer: <http://www.nextra.ch/signature_nw.html>
Seeing this mail, together with the cyclic discussions on NANOG about prefix filters and 'does anyone know if Provider X is filtering prefixes from block Y at mask Z' type problems, got me thinking that it might be a good idea for the RIPE community to come up with a set of recommendations for BGP prefix filters.
in my culture, due to legal considerations to do with things like restraint of trade, you would have to be extremely careful to phrase it NOT as 'recommendations' but maybe as "if you for some reason wanted to create filters to match rir allocation boundaries, this is what they would look like for vendors x, y, and z." i.e. technical coding advice, not filtering policy recommendations. randy
Point taken. Note that I am suggesting this goes a bit further than just filters that match registry allocation boundaries. I would suggest that the 'recommendation' could address all the things that often crop up in prefix filters - RFC1918 blocks - A class space now being allocated as /19 or /20 - 0.0.0.0 - TWD - sub /24 masks ...and so on. It is also worth noting that RIPE-210 is a 'recommendation'. Would your concerns also apply to this? Phil At 03:21 27.06.00 -0700, Randy Bush wrote:
Seeing this mail, together with the cyclic discussions on NANOG about prefix filters and 'does anyone know if Provider X is filtering prefixes from block Y at mask Z' type problems, got me thinking that it might be a good idea for the RIPE community to come up with a set of recommendations for BGP prefix filters.
in my culture, due to legal considerations to do with things like restraint of trade, you would have to be extremely careful to phrase it NOT as 'recommendations' but maybe as "if you for some reason wanted to create filters to match rir allocation boundaries, this is what they would look like for vendors x, y, and z." i.e. technical coding advice, not filtering policy recommendations.
randy
Philip Bridge Nextra (Schweiz) AG <www.nextra.ch> Tel: +41 031 985 88 06 / Mobile: +41 79 659 75 50 E-Mail: <mailto:bridge@nextra.ch> Disclaimer: <http://www.nextra.ch/signature_nw.html>
Yes, such a document could be useful. We're using a prefix-list as shown below. We could use it as a starting-point to establish a standard prefix filter, or as Randy put it, a prefix filter technical coding advice. ip prefix-list sanity seq 5 deny 0.0.0.0/0 ip prefix-list sanity seq 10 deny 10.0.0.0/8 le 32 ip prefix-list sanity seq 15 deny 127.0.0.0/8 le 32 ip prefix-list sanity seq 20 deny 172.16.0.0/12 le 32 ip prefix-list sanity seq 25 deny 192.0.2.0/24 le 32 ip prefix-list sanity seq 30 deny 192.168.0.0/16 le 32 ip prefix-list sanity seq 35 deny 169.254.0.0/16 le 32 ip prefix-list sanity seq 40 permit 0.0.0.0/0 le 32 /Rosenbecker -- Fredrik Rosenbecker IP-Only AB On 27-Jun-00 philip bridge wrote:
Seeing this mail, together with the cyclic discussions on NANOG about prefix filters and 'does anyone know if Provider X is filtering prefixes from block Y at mask Z' type problems, got me thinking that it might be a good idea for the RIPE community to come up with a set of recommendations for BGP prefix filters. It would have a number of advantages.
- a standard prefix filter recommendation would always be in synch with Registry practices. - it would lower the effort barrier for people to implement prefix filtering in the first place, and therefore foster stability of the global routing system. - it would at least help to align the filtering practices of Providers a little bit, so that debugging routing problems becomes a little bit less like guesswork... hopefully fewer threads like 'does anyone know if Provider X is filtering prefixes from block Y at mask Z?'
I am thinking of something broadly along the lines of RIPE-210 for route dampening.
Feedback?
Phil
At 17:32 21.06.00 +0200, Joao Luis Silva Damas wrote:
During the RIPE 36 meeting in Budapest there was a request to publish the list of CIDR blocks allocated by the RIPE NCC and the smallest allocation issued from each of them.
This is it:
62/8: /19 193/8: /29 # Contain small PI assignments 194/8: /29 # Contain small PI assignments 195/8: /29 # Contain small PI assignments 212/8: /19 213/8: /19 217/8: /20
We shall put this information permanently on our website.
regards,
Joao Damas Head of External Services RIPE NCC
Philip Bridge Nextra (Schweiz) AG <www.nextra.ch> Tel: +41 031 985 88 06 / Mobile: +41 79 659 75 50 E-Mail: <mailto:bridge@nextra.ch> Disclaimer: <http://www.nextra.ch/signature_nw.html>
On 2000-06-27T12:25:34, Fredrik Rosenbecker <fredrik.rosenbecker@ip-only.net> said:
Yes, such a document could be useful. We're using a prefix-list as shown below. We could use it as a starting-point to establish a standard prefix filter, or as Randy put it, a prefix filter technical coding advice.
What is also very helpful is to point out the usefulness of anti-spoofing rules - ie filter your own netblocks when they are announced to you, _including_ more specific routes ;-) Sincerely, Lars Marowsky-Brie <lmb@suse.de> -- Perfection is our goal, excellence will be tolerated. -- J. Yahl
At 12:29 27.06.00 +0200, Lars Marowsky-Bree wrote:
On 2000-06-27T12:25:34, Fredrik Rosenbecker <fredrik.rosenbecker@ip-only.net> said:
Yes, such a document could be useful. We're using a prefix-list as shown below. We could use it as a starting-point to establish a standard prefix filter, or as Randy put it, a prefix filter technical coding advice.
What is also very helpful is to point out the usefulness of anti-spoofing rules - ie filter your own netblocks when they are announced to you, _including_ more specific routes ;-)
Hm. Yes. But this gets us into a controversial issue since filtering more specifics from your own netblocks means your multihomed customers don't get connectivity to you when the line between you and them is down. I am a bit worried about expanding the scope of this to the point where we get bogged down in arguments about such practices. It seems to me that there is a large body of non-controversial practices that simply require collation and documentation in order to acheive a major effect. We should stick to those, at least in the first instance. Phil
Sincerely, Lars Marowsky-Br�e <lmb@suse.de>
-- Perfection is our goal, excellence will be tolerated. -- J. Yahl
Philip Bridge Nextra (Schweiz) AG <www.nextra.ch> Tel: +41 031 985 88 06 / Mobile: +41 79 659 75 50 E-Mail: <mailto:bridge@nextra.ch> Disclaimer: <http://www.nextra.ch/signature_nw.html>
I'd consider that the non-controversial set are listed in Bill Manning's draft. Adding to that adds potential for controversy... Mind you, documenting in a generic sense what providers do might be a good idea for the sake of accurate implementation. It would have to be clearly stated that this is documenting current practice by some and is in no way a recommendation to follow suit. As I've said before, there are people who simply cut and paste configurations.... philip -- At 14:11 27/06/00 +0100, philip bridge wrote:
At 12:29 27.06.00 +0200, Lars Marowsky-Bree wrote:
On 2000-06-27T12:25:34, Fredrik Rosenbecker <fredrik.rosenbecker@ip-only.net> said:
Yes, such a document could be useful. We're using a prefix-list as shown below. We could use it as a starting-point to establish a standard prefix filter, or as Randy put it, a prefix filter technical coding advice.
What is also very helpful is to point out the usefulness of anti-spoofing rules - ie filter your own netblocks when they are announced to you, _including_ more specific routes ;-)
Hm. Yes. But this gets us into a controversial issue since filtering more specifics from your own netblocks means your multihomed customers don't get connectivity to you when the line between you and them is down.
I am a bit worried about expanding the scope of this to the point where we get bogged down in arguments about such practices. It seems to me that there is a large body of non-controversial practices that simply require collation and documentation in order to acheive a major effect. We should stick to those, at least in the first instance.
Phil
Sincerely, Lars Marowsky-Br�e <lmb@suse.de>
-- Perfection is our goal, excellence will be tolerated. -- J. Yahl
Philip Bridge Nextra (Schweiz) AG <www.nextra.ch> Tel: +41 031 985 88 06 / Mobile: +41 79 659 75 50 E-Mail: <mailto:bridge@nextra.ch> Disclaimer: <http://www.nextra.ch/signature_nw.html>
ip prefix-list sanity seq 5 deny 0.0.0.0/0 ip prefix-list sanity seq 10 deny 10.0.0.0/8 le 32 ip prefix-list sanity seq 15 deny 127.0.0.0/8 le 32 ip prefix-list sanity seq 20 deny 172.16.0.0/12 le 32 ip prefix-list sanity seq 25 deny 192.0.2.0/24 le 32 ip prefix-list sanity seq 30 deny 192.168.0.0/16 le 32 ip prefix-list sanity seq 35 deny 169.254.0.0/16 le 32 ip prefix-list sanity seq 40 permit 0.0.0.0/0 le 32
if you are going to get into bogon filtering, you may want to look at draft-manning-dsua-03.txt fyi, this week our bogon filter looks like /* Filter some bogon routes. */ policy-statement bogon { term drop-bogons { from { /* Default */ route-filter 0/0 exact reject; /* Prefix is 0, any mask. */ route-filter 0/8 orlonger reject; /* 0/* May also want to reject ?/[0-6] */ route-filter 0/0 through 0.0.0.0/32 reject; /* Loopback */ route-filter 127/8 orlonger reject; /* Private */ route-filter 10/8 orlonger reject; route-filter 172.16/12 orlonger reject; route-filter 192.168/16 orlonger reject; /* Link local */ route-filter 169.254/16 orlonger reject; /* 1st and last B/C */ route-filter 128.0/16 orlonger reject; route-filter 191.255/16 orlonger reject; route-filter 192.0.0/24 orlonger reject; route-filter 223.255.255/24 orlonger reject; /* Test */ route-filter 192.0.2/24 orlonger reject; /* Multicast & higher */ route-filter 224/3 orlonger reject; } then reject; } } randy
Quite right. For something along the lines of RIPE-210 bogus filtering is a good starter (see draft-manning-dsua-03.txt). Then one could add own networks, and default and whatever the community finds usefull.
if you are going to get into bogon filtering, you may want to look at draft-manning-dsua-03.txt
/rosenbecker -- Fredrik Rosenbecker IP-Only AB
At the very least, such an activity could collect and classify various filtering policies. Phil At 12:25 27.06.00 +0200, Fredrik Rosenbecker wrote:
Yes, such a document could be useful. We're using a prefix-list as shown below. We could use it as a starting-point to establish a standard prefix filter, or as Randy put it, a prefix filter technical coding advice.
ip prefix-list sanity seq 5 deny 0.0.0.0/0 ip prefix-list sanity seq 10 deny 10.0.0.0/8 le 32 ip prefix-list sanity seq 15 deny 127.0.0.0/8 le 32 ip prefix-list sanity seq 20 deny 172.16.0.0/12 le 32 ip prefix-list sanity seq 25 deny 192.0.2.0/24 le 32 ip prefix-list sanity seq 30 deny 192.168.0.0/16 le 32 ip prefix-list sanity seq 35 deny 169.254.0.0/16 le 32 ip prefix-list sanity seq 40 permit 0.0.0.0/0 le 32
/Rosenbecker
-- Fredrik Rosenbecker IP-Only AB
On 27-Jun-00 philip bridge wrote:
Seeing this mail, together with the cyclic discussions on NANOG about prefix filters and 'does anyone know if Provider X is filtering prefixes from block Y at mask Z' type problems, got me thinking that it might be a good idea for the RIPE community to come up with a set of recommendations for BGP prefix filters. It would have a number of advantages.
- a standard prefix filter recommendation would always be in synch with Registry practices. - it would lower the effort barrier for people to implement prefix filtering in the first place, and therefore foster stability of the global routing system. - it would at least help to align the filtering practices of Providers a little bit, so that debugging routing problems becomes a little bit less like guesswork... hopefully fewer threads like 'does anyone know if Provider X is filtering prefixes from block Y at mask Z?'
I am thinking of something broadly along the lines of RIPE-210 for route dampening.
Feedback?
Phil
At 17:32 21.06.00 +0200, Joao Luis Silva Damas wrote:
During the RIPE 36 meeting in Budapest there was a request to publish the list of CIDR blocks allocated by the RIPE NCC and the smallest allocation issued from each of them.
This is it:
62/8: /19 193/8: /29 # Contain small PI assignments 194/8: /29 # Contain small PI assignments 195/8: /29 # Contain small PI assignments 212/8: /19 213/8: /19 217/8: /20
We shall put this information permanently on our website.
regards,
Joao Damas Head of External Services RIPE NCC
Philip Bridge Nextra (Schweiz) AG <www.nextra.ch> Tel: +41 031 985 88 06 / Mobile: +41 79 659 75 50 E-Mail: <mailto:bridge@nextra.ch> Disclaimer: <http://www.nextra.ch/signature_nw.html>
______________________________________________________________ Philip Bridge www.bridgenet.ch ______________________________________________________________ It might look like I'm doing nothing, but at the cellular level I'm really quite busy...
participants (8)
-
Anne Lord -
Bruce Campbell -
Fredrik Rosenbecker -
Joao Luis Silva Damas -
Lars Marowsky-Bree -
Mark Prior -
philip bridge -
philip bridge -
Philip Smith -
Randy Bush