North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: classful routes redux

  • From: Richard A Steenbergen
  • Date: Sat Nov 05 04:43:29 2005

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 <[email protected]>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)