> > I don't follow your analogy. Let me try one of my own. Expecting > > apps to use SLs is like expecting that someone who is married to > > a person named "mary" will be equally satisfied with the person > > named "mary" in whatever town he happens to be in (if there is one), > > or that he'll be satisfied if he cannot telephone his wife (or reaches > > a different person) if he isn't in his hometown. > > Ah. I understand now, and this does highlight a potential problem. It's > not just about filtering traffic between sites. In the case where a node > leaves one site and moves to another, all site-scoped references to the old > site must be invalidated too.
I hadn't thought of that case, but you are right. For a host using mobile-ip the site-local address is not necessarily more stable than the global address. > If I have a cached reference to "mary" in my original site, it is unlikely > to do what I expect in my new site. > > The presence of the interface id will help reduce this problem, but will not > eliminate it. Well, the host knows that it has moved, and any processes on that host can figure it out by various means. With some work the host and applications could invalidate their own references to site locals from the old site. However the host may not be able to invalidate other hosts' or processes' references to that hosts's old site-local address. > So a problem with site locals is that applications must not pass these > addresses (and perhaps names) around as if they were globally scoped, which > means that any application that could distribute or store addresses should > be aware of them and behave accordingly. Alternatively, the user has to > make sure that the purity of the site is preserved. Both options have > drawbacks. Seems right. And one of my primary goals here is to relieve applications of the burden of trying to deal with site-locals when those applications cross site boundaries. Having those apps refuse to use SLs and LLs in referrals (when globals are available) is a reasonable strategy as long as those apps have global addresses to use instead. > Using unique addresses and prefixes removes the non-uniqueness problem > (addresses moved outside their intended scope simply fail), but reintroduces > the need for administration. I'm not sure what you mean by 'the need for administration'. Or are you just saying that we need a way to assign unique prefixes for those sites? 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] --------------------------------------------------------------------
