On Wed, Nov 02, 2005 at 04:14:31PM -0800, Bill Woodcock wrote:
On Wed, 2 Nov 2005, Fred Baker wrote: > While I think /32, /48, /56, and /64 are reasonable prefix lengths > for what they are proposed for, I have this feeling of early > fossilization when it doesn't necessarily make sense.
Yeah, that's what seems important to me here... I mean, I've lived through the whole classful thing once... I'm still not clear why there are people who want to do it again.
Well to be fair, classful routing actually did have a few advantages. Longest prefix match lookups have historically always been very difficult, so difficult that it held back the speed of routers for years. We've only recently been able to get a handle on the problem in hardware. Also, some of the original motivations behind CIDR starts to go out the window when you have enough IP space that you can hand out huge chunks ahead of immediate need. Who cares about efficient utilization or "but I only need a /35 and you gave me a whole /32, I'm wasting so much space" when there is not a space shortage. Just allocate enough space that you will never need to upgrade, you'll be doing more good than trying to predict or restrict your usage and creating more routing entries later when you need more space. Of course none of this is a compelling argument for classful routing. We've pretty much got the longest prefix match thing covered at this point, and claims that we need to scale bgp to support 2^128 routes so that everyone can multihome their refrigerators are a load of crap. Also, just because 2^128 is a big number does not mean that all IPv6 space is infinite, and there is no reason to get short-sighted. If we're really going to end up in a situation where a /64 is a "host", then a /48 is the equivilent of a /16 on IPv4. That is a decent sized chunk for "small" users, but hardly infinite. If you are a larger provider with a /32 and you have to hand out /48s to everyone, it is like only having a /16 yourself. Imagine a large cable company who had to give an IP to every customer and trying to get it all done in a single /16. Suddenly all this massive space seems to be running low. /56s and the like as allocations seem like a really bad and short-sighted idea, unless we're talking about it for nothing more than "business-class end-user service" like a /27 on a business grade DSL circuit today. I'm still not seeing any reason that everything can't work itself out through existing means. Make the preferred allocation size from RIRs /32, to be given out to large networks or anyone with an ASN who asks for one. Make the preferred reallocation size for enterprises /48, and make it the smallest block which can be announced in BGP (with the expectation that /32s will be the primary announcement). Make the preferred assignment for end-users (cable modems and such) /64, and use the remaining 64 bits as a giant waste of time but one that makes certain we won't have to deal with NAT ever again. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)