in many enterprise/organizational situations, and at least some
home networking ones, communication among hosts on the local
network is very important, perhaps equally important as
communication with outside hosts.
I didn't claim otherwise; in fact I suspect that internal communication
is often viewed as more important than external communication. However,
what I said was "users don't *just* care about local apps" (emphasis
added). Which, for instance, is why there is a demand for ALGs in NATs.
Now, in the IPv6 "multiple addresses per host" model, it would
make perfect sense to assign every host on such a subnet an
address that was specific to that subnet (or enterprise) and,
for those hosts that needed external accessibility, an
additional, presumably globally-routable, address.
It might seem to make perfect sense at first glance, but I'm not sure
that it holds up under analysis. First, as long as hosts are free to
assign their own addresses, using DHCP (or RA) as a means of access
control to external links doesn't seem very robust. Second, the
design decision to use multiple prefixes has consequences for
applications that are almost certainly unintended and undesirable.
Now having a set of addresses that are stable across provider changes
really does seem useful, but I see no inherent reason that such
addresses should be only unique (or valid) within the local network.
Lots of good ideas got passed over in the IPng discussion.
Despite that, I think that IPv6 ended up "about right" -
modulo a few warts like A6 and SL and over-reliance on address
selection. By "about right" I mean that I think that if the
warts are fixed it will become feasible to gracefully extend
the IPv6 architecture in useful ways - such as to provide the
capability to use identifiers rather than locators - without
invalidating hosts or apps that were written to the basic IPv6
Keith, I think I agree with you about the "despite that" part of
the above (I certainly agree about the "passed over" part).
However, if our confusion about how to best handle multiple
addresses per host, and where to do so, results in our moving to
a "one host, one address" model and a flat, IP-level, address
space, I think some of the "graceful extension" potential will
disappear. Indeed, if we go down that path --which I think you
have been advocating, although I'm not sure-- I suspect that we
had better have a general routing solution that is not dependent
on address aggregation before we move much further forward with
Frankly I don't know where this needs end up. I don't think it ends up
with a purely "one host, one address" model, for a variety of reasons. I
do think it might end up with a model where there are "distinguished
addresses" (or if you prefer, identifiers) for hosts that are generally
preferred over other addresses or identifiers, but can be automatically
forwarded and/or mapped to locators that can be routed by traditional
I'm looking at various ways of doing this, some of which involve
site-relative locators and some of which don't. So far I haven't seen a
case wehre relative locators are required. They can make certain cases
easier- particularly isolated newtorks. But they seem to make the
overall solution more complex and less robust, even when they're not
exposed to applications.
I'm still working on understanding this landscape, so I might find a
compelling case for site-relative locators. But I suspect not.