classful routes redux

Thu Nov 3 21:14:35 UTC 2005

On Thu, 3 Nov 2005, Richard A Steenbergen wrote:

> 
> 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.

ack that.

assign one ipv6 prefix to every asn of sufficient size that most will not need 
to request additional space

whilst i'm at the mic here, ditch the idea of microassignments, just give out a 
standard /32 block ... lets not start out with ge 33 prefixes in the table when 
theres no need

Steve