Date:        Wed, 1 May 2002 18:12:03 -0700
    From:        Steve Deering <[EMAIL PROTECTED]>
    Message-ID:  <v04220800b8f635701fe6@[171.71.119.70]>

Sorry, I haven't been reading this list for the past few weeks,
so this is a bit late.

  | No, "this week's" version of the proposed solution is to use three well-
  | known, site-local unicast addresses.

How can this work if the server isn't in the same site as the client?
Is the intent to require that servers (DNS currently, but others as
well) must live in the same site as the clients?

Whether this is reasonable or not largely depends upon how site boundaries
will be set - maybe I missed it, but I don't recall anything actually
specifying that, it seems to have been left very vague, and perhaps just
"obvious".   Which is always dangerous.

To take the kind of example that is relevant here, I would always have
assumed that my house will be a site - that way I keep on using my stable
site local addresses when I change providers (and at least possibly,
global addresses).   That's why I thought the notion of sites existed.

But I'm most likely not going to want to run a DNS server (back end resolver
we're talking about here) in my house (or I personally might, but many others
probably won't).

So, if the site boundary is the link between my house and my ISP, how do
I get to find the DNS back end, which is something that my ISP is providing
for me?   (For local address resolution I can use something like mDNS if
that ever gets off the ground, of even /etc/hosts, as I would be using site
local addressing for all internal comms, and I can make those addresses
very stable).

I'm also not likely to be running a DHCP server, so "you have to use
managed addresses in that case" isn't a suitable answer.

kre



--------------------------------------------------------------------
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]
--------------------------------------------------------------------

Reply via email to