Roeland M.J. Meyer writes...
At 02:16 AM 6/1/98 -0700, Patrick W. Gilmore wrote:
At 12:52 PM 5/31/98 -0700, Roeland M.J. Meyer wrote:
There is a definite business case for portable /21's. First off, I understand the technical need to limit ASN's to /19's so I don't need lecture #101. However, those limits were set quite some time ago. When can we reduce them? Has technology stood still?
You understand "the technical need to limit ASN's to /19's"? I don't, perhaps you could explain it to me.
I agreed to the stipulation, in advance so I wouldn't get lecture #101, yet again. The issue here is that ASN's get around prefix filtering, to my understanding. If everyone had an ASN then we'd be right back to they problem that started prefix filtering in the first place, ever growing, and humongous, router tables. Legacy routers have problems with this.
There are two basic problems: 1. The number of available ASNs is finite and usage is growing. 2. The number of route prefixes impacts on router performance and is growing rapidly. The greatest concern seems not to be #1 but instead #2. The idea of limiting prefixes being honored to /19 and shorter is one approach to limiting the number of prefixes. However, this tactic has the counterproductive effect of discouraging smaller (and more numerous) providers and businesses from being efficient in their usage of IP address space, for networks that need less space than a /19 allows. We can suggest that this /19 boundary be changed. Moving it to /18 would further reduce the number of prefixes, but create more demand on IP space. Moving it to /20 would decrease the demand on IP space, but increase the number of prefixes. What we need is a solution where we don't have to make tradeoffs between increases in the number of prefixes and increased waste of IP space. The prefixes glut comes from two different situations. One of them is the increasing number of autonomous, or multi-homed, networks. The other is the multitudes of un-aggregated and unaggregateable prefixes being announced in each AS. IPv6 may make it easier to eventually do all the aggregation that is needed, but it would NOT decrease the number of distinct autonomous networks that need to separately announce. If IPv6 allocates space in differing sizes (for example, UUNET may be given a /64 with 18446744073709551616 addresses, but MOM-AND-POP.NET maybe be given "only" a /80 with 281474976710656 addresses) we are still going to see network size bias and discrimination when it comes to filtering route prefixes. People will find (very clever) ways to use up their /80 so they can then ask for maybe a /64. If IPv6 allocates everyone the same exact network size (for example /64) no matter how big or small they are, it can end the bias and discrimination. We'll still have lots of routes, but at least in this case we could have just one route prefix per entity. Still, very large businesses could ask for multiple blocks or even large blocks for reasons of doing various strategies of network partitioning, and the problem of routes comes back since we'll either have varying sizes of prefixes (and the bias) or we'll have multiple prefixes (and the glut). While IPv6 needs to be considered, the immediate problem is still IPv4. One idea I had that could reduce the number of prefixes would be to make some limit on the number of prefixes per AS. This could be either a flat limit on the number of prefixes, or a partitioned limit on the number of prefixes per each size (same in each size). I like the latter because it does discourage keeping multitudes of small network pieces (which is probably why prefix filtering really got started in the first place). Unfortunately, access lists are not smart enough to count prefixes per AS to apply a limit, so some new code would have to be added to the BGP logic in the routers to do this. I would suggest the default limit be set at 2 prefixes per prefix size /17 through /24, with a total limit of 5 prefixes in this whole range, and no limit (for now) on prefixes of /16 or shorter. It may be necessary to exclude certain network block ranges from these counts. The best solution distributes the least information level for each autonomous network. Unfortunately, ASNs do not alone provide enough information so we still have prefixes. I wish there was a way out of that. I did develop an idea along those lines a couple years ago. But it is probably too late to do something like that in IPv6 now. -- Phil Howard | stop0550@lame4ads.org a7b7c8d2@spam1mer.org crash881@dumb9ads.com phil | stop0ads@no0where.net ads8suck@s8p4a2m4.org no1spam6@no9place.com at | stop0ads@dumb9ads.edu eat8this@spammer9.com stop3506@dumbads6.com ipal | w6x1y5z0@s3p8a7m1.com ads0suck@spam3mer.edu eat2this@lame9ads.org dot | blow4me8@spam1mer.com end2it58@lame9ads.com a1b8c1d3@no4place.net net | no5way49@dumbads9.org suck3it5@dumb8ads.net ads2suck@no6place.org