let me see if I can clarify this by restating it.
1. Apps know best what kinds of services they need. The network doesn't know
this unless the app has some way of telling the network
(e.g. TOS/QoS/diffserv/intserv/packet-class flavor-of-the-year).
2. The network knows best where hosts are located, and how to get packets from
here to there (if possible). The network also knows whether it's permitted to
send packets from here to there (perhaps limited by available routes or
policy, perhaps limited by packet filtering). Most apps don't know these
things and shouldn't have to know them. However it can be useful if the
network has some way to tell hosts and apps that it's not possible to get
packets from here to there, and the reason for that. Traditionally ICMP has
fulfilled this role.
Now there are apps that have to know about network topology, such as network
management tools. But in general we don't want to burden hosts and apps with
having to have this kind of knowledge, because there's no good way to get it
from the network, and to make it work reliably would require requiring the
network to feed routing and policy information to potentially all hosts.
3. Neither the kind of service being requested/provided nor information
about whether traffic is permitted should be wired into an IP address -
First because it forces a binding between policy and/or service and network
location which is inflexible and doesn't scale well; second because it
invites/begs/demands hosts and apps to know about network topology - i.e. to
second-guess the network.
4. Hosts shouldn't have to pick the "right" source or destination address in
order to get the network to do its job of getting the bits from here to there
(for some well-defined "here" and "there"), because hosts don't have the
requisite knowledge to do this, and because a requirement to pick the right
destination address means that addresses don't have a consistent meaning from
one source host to another. To the extent that a host has to pick the "right"
interface, it needs to be possible to make the right choice from information
that the host normally has at hand (like matching prefix lengths).
Similarly, using address selection as a means to select a particular service
quality, or a particular security level, etc. is a best a stopgap measure
because once again it requires apps to know about specific address ranges
and/or network topology.
Note that scoped addresses make it difficult for each of the network, hosts,
and apps to do their jobs - the network can't tell whether it can get the
traffic to the destination because the destination address is ambiguous (so
for instance, how can it tell the difference between "prohibited" and "no
route to destination" and "no such host" - and while it might have unambiguous
rules for how to route such addresses, that doesn't mean the traffic went to
the right place); hosts can't tell which interface to use to send the traffic;
and apps can't tell whether or not the address is usable to reach the desired
peer (either locally or by another peer).
--
Does any of the above mean that apps should never explicitly select source
and/or destination addresses or interfaces? No, it means our network
architecture should not expect ordinary apps to make such selections
in order to sucessfully obtain services from the network.
Now, because of mobile IP and privacy addresses, we're still going to have
situations where apps need to give their hosts an idea of what kinds of
addresses they need. E.g. Does the app need an address that continues to work
as the host moves, or will the in-care-of address do? Does it prefer an
address that is stably associated with the host, or is a temporary address
more appropriate? But the answers to both of these questions *are* things
that the app can be expected to know. Furthermore, unlike service quality or
security, these things inherently require address selection. And unlike
site-local, these properties are essentially opaque to other hosts in the
network - thus we cannot expect/demand that other hosts use information
embedded in the address and behave differently for different kinds of
addresses.
And of course it will always be possible to set up or encounter situations
where apps that have knowledge about the network topology (or which
exhaustively try all known source/destination pairs) can succeed where apps
that don't go to extreme measures will fail. In some ways this is an argument
about how we divide up the burden - which burdens we should place on hosts and
apps and which ones we should place on the network. And the essence of the
argument is: don't expect either one to make decisions about things it
doesn't know about. And this further argues for not having more addresses for
a host than necessary, for not using multiple addresses as a mechanism to
provide different levels of access to a host, and for eschewing ambiguous
addresses.
Keith
> > I disagree that the IP stack can supply reasonable defaults in
> > the face of multiple scopes. The criteria for choosing a
> > source address varies widely from one application to another.
> > Some applications need stable addresses, others need addresses
> > usable from all of their potential peers, others need to
> > choose the source address that results in the best performance
> > (where there is more than one meaning of 'best performance').
> > The default address selection rules are at best a guess.
> >
> > We should let the network do routing, so that hosts and apps
> > aren't expected to make routing decisions.
>
> Keith,
>
> I don't understand your point here, and would like to. It seems
> to me that your first paragraph ("I disagree...") suggests that
> the applications need to specify the addresses/interfaces
> because they know their needs and the stack can't figure it out.
> And the second argues for pushing the decisions onto the
> network, which has no information at all (and, if it had it,
> could probably apply it only by changing addresses mid-flight --
> NAT-like or worse). That suggests to me a conclusion of "not
> application, not stack, not network either" which leaves very
> few options.
>
> If I ignore that apparent contradiction, I'm left with the
> conclusion that we need some new addressing and routing
> abstractions so that the applications can tell the stack (and
> the stack might tell, or negotiate with, the network) what
> considerations they need optimized and do so without specifying
> specific addresses or inspecting components of addresses. It
> seems to me that such abstractions would also eliminate one of
> the arguments against site local: having an application able to
> tell the stack:
>
> * I need a local address
>
> * I need an appropriate address for routing to <DNS name>
>
> * I need a completely-global address
>
> Are all far more reasonable than having the application itself
> recognize particular addresses or prefixes and trying to figure
> out which ones make sense in its context. It also _might_
> suggest that we need to reexamine ICMP in the IPv6 context to be
> sure that, if the stack needs information from the network to
> make satisfactory choices along these lines, it can ask them
> without, e.g., trying to set up one or more TCP connections (or
> sending UDP packet using an unspecified protocol) and waiting
> for the responses or timeouts.
>
> Is that really where we need to be headed and, if so, is anyone
> doing the work rather than being stuck on "local-good /
> local-bad", "scope-necessary / scope-bad", types of arguments?