North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
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 <firstname.lastname@example.org> http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)