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