Dear Keith,
This posting was so helpful that we should probably change the
thread subject!
I have a few questions/comments.
Spencer
--- Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> wrote:
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).
Agreed.
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.
Agreed.
I would be thrilled if we spent some time thinking about ICMP in
an architectural way - however beautiful it was before ICMP
black holing, what we have now isn't consistently usable today.
We're spending time on point solutions (Matt Mathis on non-ICMP
path MTU discovery as one example), but is this the best we can
do?
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.
Agreed. We've been discouraging hosts from listening to routing
protocol exchanges for some time now.
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.
Agreed.
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).
Agreed.
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.
Strongly agreed here.
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).
This was my point (perhaps I wasn't clear enough) about the
difference between site-local and firewalling - if your peer
isn't reachable because of an explicit decision from a network
operator (firewall), that's one class of problem; if your peer
isn't reachable because you have an address that doesn't work,
BUT YOU COULD HAVE BEEN GIVEN ANOTHER ADDRESS THAT WOULD HAVE
WORKED (site-local), that's a different class of problem.
The thing that bugs me is, I don't have any idea how the
application can tell that they have the second class of problem
- even ignoring ICMP Unreachable black-holing for a moment. Am I
missing something? (I don't think I'm a Genius of IPv6)
--
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.
Agree.
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.
From RFC 3344, the current Mobile IP spec:
1.1. Protocol Requirements
[deleted down to]
A mobile node must be able to communicate with other nodes
that do
not implement these mobility functions. No protocol
enhancements are
required in hosts or routers that are not acting as any of
the new
architectural entities introduced in Section 1.5.
And I agree I'm extrapolating, but - I always thought language
like this said Mobile IP is a host IP networking thing, not a
host application thing.
I'm not sure I'm understanding what you're saying - are you
saying that my mobile host should know it's mobile (I believe
you), or that Mozilla on a mobile host should know it's mobile
(I'm struggling here)?
My understanding of Mobile IP was that the mobile host knows,
not Mozilla (or, at least, Mozilla works if it doesn't know).
Re: security - are you thinking of applications that prefer
site-local (in IPv4, probably NATed 1918 addresses) for
"security", or is there another common use of
addresses-for-security I don't know about?
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.
Agreed, because I think you're using "hosts" and "apps" almost
interchangeably here, to mean "not the network".
Keith