ietf
[Top] [All Lists]

Re: A follow up question

2003-04-24 15:38:56
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.





<Prev in Thread] Current Thread [Next in Thread>