Date: Thu, 08 Feb 2001 14:39:18 -0600
From: Brian E Carpenter <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
This whole discussion has veered somewhere so far off into left field
that it has ceased to become relevant to anything.
There's no way the IETF (or ipngwg) is going to mandate two faced
DNS for anything - and only that would allow any ipngwg solution
which used two faced DNS to make site local addressing work, so
that simply isn't going to happen.
Beyond that it simply doesn't matter what sites decide, for good or
bad, reasons to do on their own networks, if they want to spend
lots, and increase maintenance problems, for no rational benefit that
I can find - there's no way I can stop them. Nor do I care much.
But there's no way you are going to ever convince me to do such a
dumb thing...
But ...
| Do you really want DNS to contain tens of millions of RRs for
| unreachable hosts?
The short answer to that is "yes".
A slightly longer answer is that the DNS would already have all
that information if two-faced DNS is how the private namespace is
being managed (rather than NIS or something). It is just that
some of it isn't being made visible to most of the world. It is
still all there. Having it there and visible makes no difference.
If I can't reach the host, I'm unlikely to be racing about looking
up its name either, so whether those tens of millions of hosts are
there & visible or not is going to be irrelevant to me, but they
are there anyway (but with more headaches for the site if the site
is using two faced DNS to "hide" them).
If you can really find a site that is running two faced DNS in
order to be nice to the rest of us by keeping the overall DNS size
smaller, then give them a plaque for effort, tell them while
appreciated, they're wasting their time, and to just let the rest
of us ignore their huge local DNS space, they don't need to hide it.
That is if you can find anyone doing it for that motive...
But can we possibly return to the more relevant question of just how
we are going to discover the site local address of a node which is
reachable that way, so it can be used...
And to give this message just a small amount of on-point content, I
don't think the method in Erik's draft will work as is, as - as was
pointed out before - it requires all nodes to know the method, and
I suspect we have already gone too far with v6 deployment for that.
We're already at the stage where only incremental changes can be
made now (that's a good thing!)
There are a couple of other minor problems as well, but compared
to that one, I don't think they matter.
So, I suggest that we keep all of the draft, except for the site
local addresses in the DNS (other than for isolated sites of course).
Instead, when a node has determined that its partner node is in the
same site (using the mechanisms from the draft), and if it implements
this method, and if it has not been configured (globally, or by the
application for this particular connection) to use only global addresses,
then have it send an ICMP "tell me your site local addresses" to the
partner node, and wait a short time (should be configurable, but let's
say bounded at 20ms to give an idea). That packet it sends from its
own site-local address. If it gets a response, and the response contains
any site local addresses, then it uses (one of) those addresses for
the connection (for the packet) (and caches the result for a while as well).
If it gets no response, or gets an ICMP "site local source exiting the site"
then it simply uses the global address.
Most often, what this will do is add one RTT to the startup time for
known local nodes, the first time that a connection is to be initiated
to the node (incoming connections don't do any of this, only when
initiating one, it would likely be done in the "translate name to address"
routines - just as Erik postulates).
The requirement for this to work, is that all nodes have global addresses,
if any nodes at the site do (ie: except for isolated sites, which would
simply stick their site-locals in the DNS).
Nothing at a connected site can have only a site local address (or there
would be nothing to find in the DNS in the first place). [Aside: it
doesn't matter if the global address is found in a "private" DNS or the
regular global one].
A site local that is found in the DNS ought be treated just as if it was
a global address (for the purposes of connection establishment) - that
makes isolated sites work transparently (no need for any special config
to know if a site is isolated or not), and even allows people to site site
locals in their private DNS if they feel inclined. Obviously the "tell me
your site local" address would never be used when starting with a site-local.
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]
--------------------------------------------------------------------
