On Thu, Apr 24, 2003 at 12:55:29PM -0700, Tony Hain wrote: (I'm going to clip much of this email to concentrate on those areas that need further discussion.) > > o In light of the fact that not every host has a DNS name, > > how do you propose multi-party P2P applications should do > > referrals? It would be helpful if you established the normal > > mode of operation for such situations. > > As I said in the note to JCK, I have been imprecise about 'name' so > whatever the app uses to get a handle from the local stack is what it > needs to pass around. If A connects to B, and B wishes to pass the connection info to C, B only has the address with which A accessed B. If A and B are in the same site and used site-local communication, and C is not in that site, B does not have enough information to refer C to A. Hence, your suggestion does not solve this case. > Doing otherwise ignores the reality that the > network does not look the same from all points. I agree, and in fact, that's what I'm asking you how to work around. > > If I'm at > > work and wish to > > use both my work network *and* my home network via a VPN > > connection, I expect I would want my laptop to be a > > multi-site node. If this is the case, do I > > need to use %interface_name at the end of all IP's I give to > > applications I > > use? How would DNS lookups work on a multi-site node if > > site-locals are stored in DNS? > > The name resolver would have to track which interface / site it got > answers from because any limited scope resolution is only applicable in > that interface / site context. That's true, and that sufficiently solves one side of the problem. However, the other side of the problem is knowing which name resolver to go to in the first place. If I use my home resolver, I won't be able to get the address of (e.g.) my printer, but if I use my work resolver, I won't be able to get the address of my toaster. Do I need to always check both? It seems that we're encountering this situation because DNS implicitly assumes (at least in my limited understanding) that choice of a DNS proxy should not affect the results. > > o Do you envision support for Margaret's idea of multiple > > concentric rings of security (possibly using site-locals)? > > If a node in the outermost ring is not able to talk to a node > > in the innermost ring using a site-local address because of > > filtering, but is permitted to use a global address, how > > shall applications react when the site-local "hint" is > > actually misleading? > > Personally I consider those security zones as different sites. This gets > into the poor definition of 'site', but we were intentionally vague > there. There is no difference between an FEC0 or 2001-w/Bellovin-Zill > flag prefix in how one would solve this problem. The fact that SL does > not provide multiple concentric security zones is not a failure of SL, > because that was not a design requirement (again we need to agree on the > problems to be solved). Well, that's a fair answer. By the way, I do applaud your effort in making a site-locals requirements document. I think such a document will ultimately be useful if it presents requirements in such a way that people who wish to replace the functionality that site-locals provide know what needs replacing. Thanks, -jj -- Hacker is to software engineer as Climbing Mt. Everest is to building a Denny's there.
