> But the first thing to remember is that there are
> tradeoffs. Yes, infinitely long addresses are nice,
> but they're much harder to store in programs (you
> can no longer use a simple fixed-size structure for
> any tuple that includes an address) ...
Sure you can. You just allocated the fixed space generously, _and_ you
include code that traps any address with more bytes than you can handle. If
that ever happens, you rebuild your table with a larger fixed space. You
might include code to catch addresses that approach the limit so that you
have time to rebuild the table at your leisure, rather than when the routing
actually fails, of course.
> ... and (more importantly) route, since the router
> has to use the entire address in making its decision.
Why does it need the entire address?
You only need the entire address if addresses are assigned arbitrarily from
the address space, such that no subset of the complete address is in itself
sufficient to complete any portion of the routing. That is indeed a problem
today, with address allocation that does not necessarily strictly following
routing requirements. But that was imposed by the very fact of trying to
allocate a fixed space in advance. In a variable-length address space, you
don't have to anticipate any kind of advance allocation--you can just add
digits to addresses where they are required, and routers only need to look
at enough of an address to figure out where it should go next. In a
variable-length scheme, you can be sure that any address that begins with
19283 always goes down the route you have for 19283, no matter what the
remaining digits are. (Naturally, you could route with finer granularity at
some nodes, if you wanted to, but you wouldn't necessarily be obligated to
do that.)
> Furthermore, if it's a variable-length address, the
> router has to know where the end is, in order to look
> at the next field.
Just put that up front. For example, prefix the address with a length byte.
If the byte is zero, the address is four bytes long (compatible with IPv4).
If it is one, the address is five bytes long. And so on, up to 254+4= 258
bytes long. If the byte is 255, however (unlikely, but this scheme would
provide for _any_ address length), then the _next_ byte specifies additional
bytes to be added to 254 (i.e., lengths of 254 through 508 bytes). This
second byte follows the same pattern, and so on. You'll never run out of
addresses this way, ever.
It's not really hard. You just have to write the code up front to handle
it. And if you don't want to allow for infinite capacity (you have to stop
somewhere, in any practical implementation), you just make darn sure that
you have code that will trap any address longer than you can handle. If
anything ever hits the trap, you change some parameters and recompile, and
you're back online.
> Even if the destination address comes first, routers have
> to look at the source address because of ACLs -- though
> you don't want address-based security (and you shouldn't
> want it), you still need anti-spoofing filters.
Hmm... I don't know. If you restrict the address field to routing only, do
you still need anti-spoofing? A given address can lead to only one
endpoint, unless I'm missing something here.
> One reason is something that was pointed out by a number
> of people: code that isn't exercised generally doesn't
> work well. If we didn't have really long addresses in
> use from the beginning, some major implementations wouldn't
> support them properly.
It's a lot easier to fix a bug than to rewrite the protocol from scratch
when it runs out of capacity.
> There have been designs for [geographic addressing], I
> should add, such as the Metropolitan Area Exchanges.
> But for those to work, assorted ISPs would have
> to co-operate on a large scale, something that I
> don't think will happen.
Why would they have to cooperate in a variable-length scheme? They would
only allocate addresses on their branch. They could route within their
branch without knowing or caring about other branches (as long as they know
the high-order digits identifying their own branches, which someone else
would assign to them). And if they ever saw addresses with high-order
digits that didn't match their own assigned digits, they'd know that the
address meant "elsewhere." Of course, finer granularity would be possible,
but not required.
That's how telephones work. If you call someone in Mongolia from the U.S.,
the U.S. exchanges don't have to know or care about the trailing digits in
the number; they only have to look at enough of the number to know to route
the call towards Mongolia. Can you imagine what the telephone system would
be like if every country had to know every detail about the numbering system
of every other country?
> Phone numbers are allocated geographically, but that
> only works because historically, most areas only had
> one monopoly phone company.
That's not a requirement. Just assign additional companies an additional
branch. At most, the new companies would add one digit to the address.
> ... but telephone networks do one lookup per call, not
> one per packet.
I should think you'd be able to optimize this, especially since, with a
variable-length scheme, you only need to look as far as necessary to pick a
route. If you have a route for 12847, you know that 12847xxxxxx is always
going to take that route. Depending on how many outbound routes you have,
this could be very fast indeed.
-- Anthony
