| While I certainly support the idea of usable micro allocations, and have | voiced my support on various ARIN mailing lists for it, it should be | remembered that the same folks who generally espouse restrictive filtering | policies are also those who voice the greatest opposition to a realistic | micro allocation policy. Their argument normally underscores the somewhat | facetious issue of routing table size. In hopes of correcting this somewhat, let me say that not only am I a strong supporter of filtering, I have also suggested fairly seriously to some registry-types that it is fair to allocate individual /32s as necessary to contain address consumption. That is, the registries are correctly focusing on that resource-management, and should spend energies on reclaiming wasted space (hello MIT!) rather than on managing multiple scarce resources. ISPs can and will filter or otherwise penalize users of long and/or flappy prefixes as dynamicism forces them to do so. Since filtering can become REALLY aggressive if and as necessary, nobody should worry that ISPs will be so overwhelmed that the RIRs have to help out with this problem. | Ad hominem attacks against individuals [are bad] But but it's open season on "folks" who make "facetious" arguments? Sean.
Also sprach Sean M. Doran
I have also suggested fairly seriously to some registry-types that it is fair to allocate individual /32s as necessary to contain address consumption.
Praise the Lord! I'm not alone in this. I've always thought prefix-length filtering was incredibly inane. Since the length of the prefix bears little correlation to the "importance" of the network being advertised, there is little reason to filter based on the length of the prefix. Filter flapping routes? Sure. Filter RFC1918 space? No brainer. Filtering on prefix length? There's just no solidly backed up reasoning to support it that I've heard. A network that has the operational need to be multi-homed will add a route to the default-free area, its as simple as that (barring some major architectural changes to the protocols in use on the Internet.) If we're going to have the routes in the default-free, let's at least try to minimize. Encourage re-numbering into fewer blocks and returning those blocks to ARIN? Here's a thought. When you give out a new block of IP addresses to an organization, require that, within a certain time period (a year?) they relinquish two blocks back to ARIN. Obviously there is going to be a limit to how far you can go with this...if the organiztion only has a single block, then it can't turn two in if its allocated a new block since that would leave it with no space. A policy like this (and this is obviously *extremely* rough) would have the effect of encouraging re-numbering, and designing networks in ways that renumbering isn't quite as onerous, it would also reduce the number of blocks being advertised by the organization. IgLou, for example, has 6 blocks that we advertise...we're pretty much small fry, but it would not be all that difficult for me to free up several of my blocks for relinquishing back to ARIN. Now, IgLou obviously isn't going to have a huge effect on reducing routing table size, but over time, this would reduce the number of routes in the default-free zone...or at least keep the growth in check. The trick is that a network needs to be able to obtain network blocks that are reasonably sized for their needs with little to no hassle. There are all sorts of variations on this policy theme that could be used to balance the needs of the Internet as a whole. The bottom line, though, is that the current policies in use don't address the problems that it is claimed that they were instituted to address...primarily address depletion and routing table size. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
On Fri, 28 Sep 2001, Jeff Mcadams wrote:
Since the length of the prefix bears little correlation to the "importance" of the network being advertised, there is little reason to filter based on the length of the prefix.
In addition to that, the prefix filtering mechanisms that are being discussed don't apply at all to providers who are allocated much larger blocks (/16+) yet feel the need to slice and dice it into individual /20's to steer traffic. Can someone who is in favor of implementing filters explain to me why slicing a /16 into 16 /20's is any different than slicing a /20 into 16 /24's? If the thought is "you're given a /20, i only want to see a /20.." then why doesn't "you're given a /18, I only want to see a /18" also apply? I don't have any hard evidence to know how much of an impact this actually has, but I would be very interested to see how many more specific /19's and /20's exist in a "verio-filtered" table that were allocated as /16's and shorter. Paul
On Fri, 28 Sep 2001, Sean M. Doran wrote:
let me say that not only am I a strong supporter of filtering, I have also suggested fairly seriously to some registry-types that it is fair to allocate individual /32s as necessary to contain address consumption.
So how is this supposed to work? For instance, I get a /27 and an AS number, and I want to multihome. But nobody will listen to my announcements. This is not a workable solution. It is possible to take the position that the responsibility of the ISPs to filter and the responsibility of the RIRs to assign are completely unrelated, but that only holds in theory. In practice, people want to get addresses they can use and use the addresses they can get. So there should be a reasonable overlap. Multihomers generally announce just a single route and there are less than 25k AS numbers so the majority of routes is NOT from multihomers so it seems somewhat harsh to effectively forbid multihoming. But while we're all discussing drafts on multi6, the routing table is still growing so some filtering should be expected. Is there really no way we can all agree on a filtering policy that keeps the routing table in check but still leaves some room for responsible multihoming? For instance: each AS gets to announce either a single route (regardless of prefix size) or only RIR-allocation-sized blocks. (The problem with this is that you can't make a reasonably sized filter that enforces this policy, so you would have to trust your peers to some degree.)
That is, the registries are correctly focusing on that resource-management, and should spend energies on reclaiming wasted space (hello MIT!) rather than on managing multiple scarce resources.
IP address space is only a scarce resource because it is allocated in huge chunks. If we would be able to re-allocate individual un-used IP addresses, we wouldn't run out for a _very_ long time. Iljitsch van Beijnum
Iljitsch van Beijnum wrote:
On Fri, 28 Sep 2001, Sean M. Doran wrote:
let me say that not only am I a strong supporter of filtering, I have also suggested fairly seriously to some registry-types that it is fair to allocate individual /32s as necessary to contain address consumption.
So how is this supposed to work? For instance, I get a /27 and an AS number, and I want to multihome. But nobody will listen to my announcements. This is not a workable solution.
Hello; I actually have some information on this - look at http://www.multicasttech.com/status/cidr.html and http://www.multicasttech.com/status/histogram.cidr.bgp Of the announcements we receive (we are multihomed to 3 ISP's, but not to Verio), 57.6 % of the prefixes are /24's, and about 1/2 of these are holes in another address block. Presumably, the other 1/2 are mostly /24's from the swamp. So, a Verio like filtering policy would filter out about 1/2 of the /24's (a little more, actually) and leave the rest. This seems somewhat arbitrary to me. By contrast, only ~ 0.1% of the announcements are /25's or longer. SO, in the spirit of setting the speed limit at the speed people actually drive, I would suggest that a reasonable solution would be to admit up to /24's. I know that this will not be an entirely popular opinion. -- Regards Marshall Eubanks
It is possible to take the position that the responsibility of the ISPs to filter and the responsibility of the RIRs to assign are completely unrelated, but that only holds in theory. In practice, people want to get addresses they can use and use the addresses they can get. So there should be a reasonable overlap.
Multihomers generally announce just a single route and there are less than 25k AS numbers so the majority of routes is NOT from multihomers so it seems somewhat harsh to effectively forbid multihoming.
But while we're all discussing drafts on multi6, the routing table is still growing so some filtering should be expected. Is there really no way we can all agree on a filtering policy that keeps the routing table in check but still leaves some room for responsible multihoming?
For instance: each AS gets to announce either a single route (regardless of prefix size) or only RIR-allocation-sized blocks.
(The problem with this is that you can't make a reasonably sized filter that enforces this policy, so you would have to trust your peers to some degree.)
That is, the registries are correctly focusing on that resource-management, and should spend energies on reclaiming wasted space (hello MIT!) rather than on managing multiple scarce resources.
IP address space is only a scarce resource because it is allocated in huge chunks. If we would be able to re-allocate individual un-used IP addresses, we wouldn't run out for a _very_ long time.
Iljitsch van Beijnum
T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com http://www.on-the-i.com Test your network for multicast : http://www.multicasttech.com/mt/ Check the status of multicast in real time : http://www.multicasttech.com/status/index.html
participants (5)
-
Iljitsch van Beijnum -
Jeff Mcadams -
Marshall Eubanks -
Paul Schultz -
smd＠clock.org