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@cs.utk.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