Hi Robert & Keith, this is an interesting discussion. The fact that the scope field is not a part of the address in cases like Link Local is the problem. >From my perspective as an application implementer it is the problem. Current applications works with addresses assuming (and this is very natural) that there can be only one entity with this number (Also a very long number 16 bytes!). What happens is that for these special case (Link Local mainly) the application will have to look at the scope field in the socket to find out which zone it is. You pointed right that the zone number is actually a part of the address. May I add: which doesn't exist on the address. There are some amusing implications on implementers for instance BSD stores the IfIndex on the address itself (the second byte of the address). A direct result of this zoning is also that the application now has to distinguish between the addresses Link Local look at the scope Global don't look at the scope. Isn't porting a current application to support 16 bytes is hard enough? By the way, the neighbor discovery RFC clearly states that the fact that multi-homed hosts will not function well is known to them and they ask us the developers to experiment with it and give them feedback. Here is the feedback: Link Local addresses should be globally unique addresses so scoping shouldn't be a problem (64 bits should do...). We are still debating what to do with this... We thought we have a simple scheme for a solution for this, apparently we have to work a little bit more. Any suggestion for simplifying our lives will be welcomed.
Shuki -----Original Message----- From: Robert Elz [mailto:kre@;munnari.OZ.AU] Sent: Tuesday, October 22, 2002 4:17 AM To: Keith Moore Cc: Brian Zill; sasson, shuki; [EMAIL PROTECTED] Subject: Re: Link Local Address usage for multi-home host. Date: Mon, 21 Oct 2002 17:03:58 -0400 From: Keith Moore <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | 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. 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. 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. There's nothing about scoping that changes that in the slightest. Of course, the appropriate scope info has to be available with each address. The DNS has no way to return that info (nor do we have any global naming scheme for scopes that would allow it to), which is one reason why limited scope addresses should never appear in the DNS, except where the limited scope is (for other reasons) defined to be the universe (which is how we get by putting our current global addresses in the DNS - the globe of concern is "our globe" and all global addresses by definition refer to it). Other means of locating suitable limited scope addresses need to provide the scope information as a by product (which in many cases can be done by simply using the appropriate scope identifier from the interface over which the address was discovered). 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. 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. Certainly that's something that apps aren't doing now - but they should be. It certainly isn't anything like as burdensome as the picture you have been painting of the difficulties involved. kre -------------------------------------------------------------------- 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] --------------------------------------------------------------------
