> | because if you want apps to work reliably under these > | conditions then you are essentially asking hosts to do routing in > | the absence of routing information > > Sorry Keith, but what has routing got to do with anything? Address > scoping is really just yet another level of naming, it is an extension > to the address.
if an app has multiple addresses to choose from, and some work better than others, and the ability of the app to function effectively involves choosing an address, the app essentially needs routing information in order to make that choice. > Given any random address, with or without scoping information, there's > always a possibility that the address won't work, for all kinds of > reasons, so apps better be prepared to deal with that one way or another. yes, this possibility always exists. but we used to have a clean separation of function between the apps and the network - it was the network's job to get packets from source to destination, and the apps were not expected to know about network topology. that way the app writer can concentrate on how best to do the app's job, and the network could concentrate on routing packets. these days we are starting to expect the app (or more naively the host) to make decisions that require routing information, but without giving them the routing information. or in other words, we're saying "some routing problems are hard, so we'll make them the problem of the application writers and pretend that we've solved them". right. > That is, if you consider it important for an app to know which of several > possible addresses (perhaps all "global" address) will work before using > one, then you're right, there's a whole bunch of extra info that hosts would > need to somehow discover first, but in practice, that isn't what anything > does, "suck it and see" is the traditional approach - given multiple > addresses pick one (at random, though first come tends to be better) and > see if it works, if so, then fine, if not, go on to the next. that was a fine strategy when a host had only a couple of addresses, and they were global, and all of the addresses worked most of the time. it doesn't work well when hosts have several addresses of varying scope, especially when combined with very ephemeral address-to-host bindings. > There's nothing about scoping that changes that in the slightest. Of > course, the appropriate scope info has to be available with each address. and once you start trying to figure how to describe scopes you find that what you really need is a global address space and routing information. otherwise, what you're essentially saying is that having limited-scope addresses causes no problems that aren't addressed as soon as we have a solution to this other unsolved problem... > I know you're concerned about apps (protocols) which pass around addresses > in the data (and consequently which aren't limited by the normal scope > control measures). Where that happens the apps just need to take care not > to pass an address to a node where it isn't known to be meaningful. there's no way for the app to know that. > Since that's hard to determine, a simpler rule that works, is simply never > to pass an address of a lesser scope (more restricted scope) than the > address being used for the peer in the communications over which the > address is to be sent. no, this isn't sufficient either because the app has no idea of the peer's scope, much less the scope of the eventual users of those addresses. and as long as we're telling people that it's okay to use limited scope addresses instead of global addresses, such apps are going to fail in cases where they're expected to work. > Certainly that's something that apps aren't doing now - but they should be. that's extremely naive. there's no way for them to do this, but they should be doing it anyway. in other words, we don't want to actually solve the problems we're causing - we just want to pretend they're not problems until they go away. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
