> 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