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?
I don't think we're likely to be able to dispense with ICMP. Maybe we
can find more ways to make it more trustworthy. Or maybe we just need
to discourage people from filtering it.
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)
What I want to say is that if the peer isn't reachable because the
host or application didn't choose the right source or destination
address, this is never the host or the application's problem - it's
always the network's problem - because I don't see any way to allow
hosts and apps to reliably make the "right choice" in the absence of
routing information, and which allows addresses to be used in referrals.
(and while separating endpoint identifiers from addresses might be a
laudible architectural goal, we're nowhere near being able to integrate
it into the current archtitecture).
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)?
I'm saying that if your application knows that a particular connection
is only likely to be open for a short time, and/or that it can reliably
recover from broken connections, and that the source address isn't going
to be used for referrals to peers on other hosts, then it might want to
somehow tell its TCP/IP stack this, so the stack can use the in-care-of
address as the source address rather than the home address, thereby
bypassing any tunneling that might otherwise take place.
Which isn't quite the same thing as letting an app know it's on a mobile
host - though that would also be useful for some apps.
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?
I don't think address selection is an appropriate means for an
application to specify security. That's what IPsec and/or TLS are
for. (and yes, we need IPsec APIs)
nor do I think that an application should invest greater or less trust
in traffic that is sourced from or sunk to a particular address, at
least not without specifically being configured to do so, and certainly
not based on whether the address is site-local.
Keith