Well, um, er... it wasn't going to be this long but I got
started, and then put some math in it (I'm sorry, I know
math is hardly operational) and then some history.
Hit "D" now if your brain is mush.
E
Phil Howard wrote...
Suppose TCP/IP had been designed from the beginning with 64-bits of flat
address space divided 32/32. We would not have the space crunch at all
Actually I beg to differ. IP was designed to handle a variety of network
sizes, and to automatically infer the size of the network from the number
of contiguous set bits in the first octet. You can skip most of the next
two paragraph but read the line in the ***'s...
DECnet, to contrast, was originally designed for 4-bit addressing. "After
all, Nobody could afford more than 16 machines." Eventually DEC realized
the error of their ways and upgraded to 8-bit addressing. "After
all, Nobody could afford more than 256 machines." But WANs were becoming
popular, and SPAN (discussed elsewhere, precursor to NSI) wanted to do it,
and HEPNET (discussed elsewhere) wanted to do it.
This resulted in DECnet V4, 16 bits of address space broken 6/10 into
"Areas" of "nodes." Worked great for small private networks, badly for
larger networks. Large internetworks were impossible as only 64 "areas"
could exist. *** This shortsighted design spec required workarounds
("hidden areas", "poor man's routing") which REQUIRED that the USER
know and specify the ROUTE from END TO END. ***
IP provided a solution where (suprise, surprise) routing was handled at
L3 and was oblivious to the user. It isn't until now, when most users
are "used to unreliable service" that traceroute has become a popular
end-user tool. If users expected their cars to be as reliable as the
cheap-ass $20/mo Internet Providers, there would be no warranty business
for GM, but let me jump back off this soapbox, as I digress.
Anyway, IP has the strong point that network sizing is (now) a dynamic
entity, so that a network (set of contiguous address space) is sized to
the needs of the organization. The whole set of networks is limited to
N bits (32 now, 64 under IPv6), but the masking is not fixed.
I don't take issue with "It's too bad IP wasn't designed 64..." but
rather that "32/32" is the end-all. I think 2^32 network spaces SOUNDS
enough now, but pre-allocates obscene parts of the address space for
no reason. Well, ok, to conserve routing entries. However, when you
consider that we now have ~45K routes, o(45K) is five orders of magnitude
off from o(4E9). It behooves us not to "make it easier" on the router
by limiting it to 4E9 entries since the problem is already "outside a
known technological solution today." (Well, with L3 anyway.)
Recall that in 1982 memory was not cheap. IBM had introduced the PC
the year before with 256K, upgradable to 640K. Memory was about $500/k
and addressing was 16 bits, minis to 32, Crays to 64. In the 80's the
NSFNET NSS could originally only handle one ASN announcing a route,
then eventually upgraded to 4... These were memory and processing
limitations.
A table of 2^32 8-octet entries (4GB) is something that BACK THEN
was inconceivable for memory storage. Today we consider that it
would be possible to size the table at
2^32 entries of destination, gateway, netlength(mask), flag?
8 octets 4x8 octets 1 octet
2^32 x 40 = 1.6E11 Bytes of table space. If you take the Cisco approach
to store this in multiple ways so you can fast-cache access to the
routes vs a sequential search, it appears to take 5x storage, or
8E11GB. Add the router code, and we're talking a box with a terrabyte
of RAM. That's a tad more than today's boxes.
Now contrast this with 64/? variable networks.
2^64 entries of 40 octets =~ 6E20 Bytes.
The technological difference between today's high-availability processors
and either of those two goals are so vast that "trying to save on space..."
wins nothing until we know what our real goalpost is.
If we hit IPv6 Implementation Year and Yer Average Router can only handle
2E10Bytes, someone's gonna say "29/35?". That would be the time to
haggle bits 
Well, back to sleep.
E