My view is that in the absence of strong discouragement of SL addresses (with a few clearly valid use cases as exceptions), applications will be expected to work well with a mixture of SL and global addresses - even if IETF doesn't expect that. So I don't think it's sufficient to simply say "folks can use SLs if they want to", or even "site mode apps don't have to talk to global mode apps" - the former will create a support burden for apps and the latter won't match with user expectations.
I doubt there are many inherently "site mode" apps. I'm sure there are some, but offhand I can't think of any. The trick is to provide recommendations that make it simple to do the right thing. A general discouragment of SLs would accomplish this. Trying to outline all (and have applications detect and handle) of the specific cases where SLs *could* be used is very difficult. Keith > I don't understand why we are spending so much time on this issue. I get > this impression that the folks who haven't yet implemented support for > site-local addresses are worried that they will suddenly be stuck > implementing and testing a bunch of code they don't want. That's really > not the case. > > I do not advocate requiring every host and router implementation to have > multi-site support. I think all that's required for host implementations > is the default address selection rules, and all that's required for > router implementations is to have two modes (either all interfaces are > in the same site so site-locals are treated like globals, or all > interfaces are in different sites so site-locals are filtered). This is > really very little burden for host and router implementations. > > I do not advocate requiring applications to work well on multi-sited > hosts. Some developers will want to support this, some will not and > that's OK. > > For distributed applications that do referrals, a simple policy is to > run in either "global mode" (only using global addresses) or "site mode" > (only using site-local addresses). This takes very little code to > implement. Anything more sophisticated should be at the discretion of > the developer. -------------------------------------------------------------------- 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] --------------------------------------------------------------------
