> Date: Tue, 22 Oct 2002 13:41:57 -0400 > From: Keith Moore <[EMAIL PROTECTED]> > Message-ID: <[EMAIL PROTECTED]> > > | 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. > > Not really, it needs something similar perhaps, but it isn't routing > information.
let's put it this way - it needs information that is currently only available to the routing system, and isn't easily provided to hosts in any case. > And in any case, this is true any time there are multiple > possible addresses, scoping of some addresses has nothing to do with it. before IPv6 it has generally been sufficient if all addresses worked well, most of the time. one reason we didn't use multiple addresses as a means of providing redundant access in IPv4 is that it didn't work well - despite that, we somehow expect it to work well in IPv6. > | yes, this possibility always exists. but we used to have a clean > | separation of function between the apps and the network > > We still do, nothing has really changed. false. now we are expecting apps to make sense of a hodgepodge of addresses, some of which work only ephemerally, others of which are ambiguous, others of which work only in certain portions of the network. we're even saying that it's okay to expect apps to deal with hosts that only have addresses that are impaired in one or more of these ways - and apps have no way of knowing which addreses will work from a particular host at a particular time. > | 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. > > Much of that is just the same for v6, except that hosts might have > lots more addresses, and v4 or v6, name to address bindings don't last > forever any more. you might think of this as just a difference in degree, but it's a huge difference. > | 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. > > Global address space yes, routing information no. And the former > assumes that we actually want to deal with limited scope addresses > at a global level, which we almost certainly don't. Dealing with > them at a local level is sufficient. apps don't recognize topology boundaries - actually apps are routinely expected to work across topology boundaries. > | 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... > > no, we don't need to solve the hard problem to make them useful. yes, they can be useful - the question is whether they are worth the cost. the answer is no. > No, you didn't read what I wrote, I suspect. If A and B are communicating > using global addresses, then A sends B only global addresses. If A and > B are communicating using SL addresses (zone x) then A sends B only global > addresses, and SL addresses in zone x, which must be meaningful. If B > wants to send on the addresses to somewhere else (C) then it follows exactly > the same rule (and drops any SL zone x addresses if the would have to go > somewhere that isn't known to be in SL zone x). you're being overly simplistic. A and B don't have any idea whether their addresses are going to be used, whether or not they'll be used in a zone where they mean the same thing to nodes there that they mean to A and B. that and you're expecting applications to absorb a great deal of additional complexity for a very marginal gain. > If it turns out that there is no address left to send, then A & C can't > communicate, but that's evidently what was desired when the addresses were > assigned in the first place. If the administrators actually desire to > prevent hosts communicating, then that's what should be done. it's bad architecture to try to use address bits to indicate whether hosts are restricted from communicating. if hosts aren't supposed to communicate, the right solution is to block their communication at firewalls, not to expect every host/app to maintain a large 'key ring' of addresses. > In most cases, there will be global addresses, they'll work, and the issue > of whether some SL or even LL address might also work won't be terribly > relevant. seems like a dubious assumption given the way that SL and LL are being promoted. > The info that an app needs to make these particular choices is trivially > easily available, and while it is extra work that apps haven't done before, > it is by no means difficult to manage. as a writer of distributed apps, I emphatically disagree. > What is needed is that we get beyond the "here is THE address you must > use" methedology, and always allow a set of addresses to be communicated > (either directly, or by sending a name and having the recipient do name > to address translation). what is needed is to actually understand the implications of what you propose. I've tried to write code to do this, and it's really difficult. 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] --------------------------------------------------------------------
