classful routes redux

Richard A Steenbergen ras at e-gerbil.net
Thu Nov 3 21:10:11 UTC 2005


On Thu, Nov 03, 2005 at 03:29:35PM -0500, Todd Vierling wrote:
> On Thu, 3 Nov 2005, Stephen J. Wilcox wrote:
> 
> > well, /56 /48 /32 seem to have resonance but are not special in any way
> 
> Well, they are somewhat special.  All of them are on eight-bit boundaries.
> The importance of this comes in when deciding how to lay out a routing table
> in a gate array or memory-based table.
> 
> A routing table capable of handling a flat 2^128 addressing space goes
> beyond the realm of known physics -- and flat 2^64 comes close, at least for
> a while (consider semiconductor atomic weights, and the fact that 1 mole is
> approximately 2^79 atoms).  That's quite a stretch, but should give a hint
> as to why flat addressing does not work for every model.

Come on now, a lot of new routing gear made today can just barely handle 
2^18 routes, and even the high end stuff tops out at 2^20. We're nowhere 
near handling 2^32 routes even for IPv4, nor should we be, so lets not 
start the whole "but ipv6 has more space therefore routes will increase to 
7873289439872361837492837493874982347932847329874293874" nonsense again.

Removing the extreme restrictions on IP space allocation by being able to 
allocate chunks so large that you would RARELY need to go back for a 
second block would immediate reduce the size of the routing table. Let me 
state the stats again for the record:

Total ASes present in the Internet Routing Table:                 20761
Origin-only ASes present in the Internet Routing Table:           18044
Origin ASes announcing only one prefix:                            8555
Transit ASes present in the Internet Routing Table:                2717

There are just not that many distinct BGP speaking networks out there, nor 
will there ever be. NOW is the time to make certain that IPv6 deployments 
makes sense in practice and not just in theory, so we don't work ourselves 
into exactly the same mess that we did in IPv4. Lets stop trying to solve 
theoretical scaling problems which will never happen at the expense of 
creating problems which actually DO exist, and apply a little bit of 
common sense.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)



More information about the NANOG mailing list