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
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
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
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
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.
Hacker is to software engineer as
Climbing Mt. Everest is to building a Denny's there.