Date: Mon, 10 Jun 2002 12:42:10 +0300 (EEST)
From: Pekka Savola <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| Bit pattern is not relevant of course (except how it is handled by
| "legacy" implementations, which is why I tossed 3ffe:eff3::/32 in the
| air).
But how is the handling by legacy implementations any different than
what you would require anyway?
| What I'd like is that there wouldn't need to be special handling for
| site-local addresses.
How can there not be?
| If you really wanted to have Site Border Routers,
| you would just be shooting in your own foot (like with 10.0.0.0/8 etc.
| today).
If there are to be uses of non-unique addressing (site locals, 1918's
or anything else) then there has to be borders. And if there are
borders, then there has to be border routers. Something has to keep
one use of the addresses separate from others.
Perhaps what you want to discourage is multi-site nodes ?
(Usually would be a router, but doesn't have to be).
As I recall, when site locals were first discussed, there were 3
possibilities for how the border between one site and other would be
handled.
One was to have only single site nodes, but allow links to be in multiple
sites. That doesn't work at all with the current packet/addressing
formats, as there's no way to tell on the wire which site a packet would
belong to, so that one's just a write off.
Two was to have only single site nodes, only single site links, and
non-site links (DMZs) between sites.
Three is what we have now - single site links, and multi-site nodes.
This was all debated and settled so long ago, I've even forgotten which
of the two (feasible) proposals I supported, though I suspect it was
probably the one called "two" above. Which is what you're also probably
really suggesting here.
However, upon reflection, there is comparatively little to be gained
by that choice over the third one (some things get simpler to explain
while the lack of regularity makes others harder to fathom, and some
stuff becomes simply impossible to manage - like if two sites are
connected via a router that has LANS for each site connected to it,
there's no convenient link to make be the DMZ).
Scoping has to exist for link locals to work anyway, and so routers need
to deal with that (and link locals, and their properties, are too deeply
ingrained now to possibly contemplate their removal). By their very
nature, link locals require multi-scope nodes to exist, or we could not
have routers at all.
The only real difference between 2 & 3 above for implementations, given
that apps can run on "routers" and that apps need to be able to use link
local addressing if necessary (for the unconnected dentist's office nets)
so all the scoping architecture needs to exist - all that would be gained
is that in (2) a router would have a different decision to make before
forwarding site local addresses - rather than "is this link in the same
site?" it would need to ask "is this link in a DMZ?"
Is that (trivial) simplification really worth the loss of flexibility?
The difficult part of handing any situation where there are multiple
addresses is how to decide which address should get used, initially.
This is just the same when a node as two global addresses (whether they're
in different prefixes, or the same one) or when it has global & private
addresses.
In IPv4 we just ignore the question mostly - a node with two global
addresses we just toss a coin. And nodes with private addresses mostly
just don't get given global addresses (and/or the two are treated for
essentially all purposes as if they belonged to two different nodes).
For IPv6 we're being asked to actually attempt to provide some answers
to this question - as essentially all nodes (certainly the vast majority)
with private addresses will also have global ones.
kre
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
