Once we start handing out addresses whose practical scope is less than
global, we either need proxies (eg NAT) or multi-homing.
I disagree.
One reason I disagree is that when we make global addresses unreachable,
this is usually done because policy dictates that those hosts not be
reachable from some portions of the net. Allowing those hosts to
be reachable by NAT or via other addresses would circumvent such
policies.
Another reason I disagree is that from an architectural standpoint it is
better to have fewer addresses for a host and expect the network to filter
out traffic that is not permitted by policy, than it is to have more
addresses for a host and expect applications to choose the correct addresses.
The former strategy is both simpler to implement consistently in the network,
and easier to support in applications.
Few to none of the
limited scope or multi-homing problems are specific to site locals. In
fact, site locals have a slight advantage in a multi-homing situation in
that they promise that they do not have global scope, and thus may be
singled out by address selection algorithms.
This doesn't help, because the application rarely cares about whether an
address has global scope - what it cares about is whether the address
is reachable by itself or its peers. Since the application is generally
unaware of the scopes to which its peers have access, there is no way that
it can know whether a global address or a scoped address is better for
its peers.
What does work is to have a single address for each of its peers, and to
expect the network to route traffic there if policy and conditions permit.
This separation of function is fundamental to the Internet architecture -
the network, not the application, is responsible for routing.
But despite the title, site-local addresses are only one example of a
broader category of addresses that these problems apply to.
Well, there are multiple categories that SLs fit into, ranging from
scoped addresses to potentially unreachable addresses to IP addresses
and beyond. And there are problems associated with all of these. But
if you are trying to say that all of the problems with SLs also exist
with these other categories, you are simply wrong. Even creating an
additional category of scoped addresses (beyond link local) introduces
more problems than we would have with just link local addresses.
Site locals as
currently specified do add additional issues for architecture (DNS and SBRs)
if not correctly managed.
One question is whether the burden of correctly managing SLs is worth
the gain. Or perhaps the correct way to manage SLs is to not use them at
all in connected networks.
However, at the client and application level,
most site-local alternatives suggested here (everything except fully
provider independent routed addresses, without address-based filtering) fall
foul of the same problems as site local addresses themselves.
That's true only if you ignore the additional problems that scoped addresses
create for applications.
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]
