Anthony,
One interesting example: OSI NSAP addresses are variable length, with a
theoretical limit of 255 bytes I believe (perhaps there's an escape
mechanism to grow them longer?). There was an "implementors'
agreement" to limit the maximum length in actual use to 20 bytes "for now",
to make implementations practical. Two things happened:
(1) Almost all of the addressing plans designed for NSAPAs
produced addresses that were *exactly* 20 bytes long, in
some cases inserting padding in the middle of the address
to fill it out to 20 bytes! I suspect that was done to
make the address allocation job easier, e.g., making
sure delegation boundaries fell on byte boundaries.
(2) Many of the implementations ended up with the 20-byte limit
wired into them, such that the use of addresses longer than
20 bytes would have required updating most of the installed
base (the changes being of a similar nature to those required
to modify an IPv4 application or protocol to support IPv6).
This (admittedly anecdotal) example led me to surmise that:
- any variable-length address scheme will have a maximum size
imposed upon it, for pragmatic implementation reasons.
- any variable-length address scheme will quickly degenerate
into a fixed-length scheme of maximum size, for human nature
reasons (the humans being the people doing the address
allocation).
At which point, you are back to the problem you were trying to avoid.
I think the only reason this hasn't happened in the phone system is due
to resistance by humans to reading, writing, and entering very long
strings of digits. Unfortunately, computers aren't as fussy.
Perhaps you could think of IPv6 addresses as variable-length addresses
within a fixed-size container, in which the variable-length part is in
the middle and not at the right hand end? :-)
Anyway, as pointed out by others, the IPv6 work anticipates that there
may be a need to "rebalance" the address assignments (i.e., renumber) in
the future, if/when our predictions of where the growth will be turn out
to be wrong, which ought to be less painful than making the changes to
deployed implementations that your scheme would require whenever a
significant number of addresses started to exceed the length that caused
traps into the exception-handling code. And we avoid the risk of having
many very long addresses (in this case, longer than 16 bytes) being used,
which is important for a connectionless protocol like IP, in which the
addresses are overhead in every packet.
Steve