Subject: RE: Stateless DNS discovery draft

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 16 Apr 2002 17:48:10 +0200

> > OK, but we still have two options in IPv6 for address
  > > autoconfiguration: Stateless and Stateful. I don't understand
  > > why we shouldn't allow the option for _real_ stateless 
  > > autoconfig in IPv6. By 'real' I mean, we can't claim true
  > > stateless autoconfig when a crucial service like the 
  > > DNS still requires a server. 
  > 
  > Ok, so let's take this a piece at a time, with the 
  > understanding that
  > I'm not trying to pick on Hesham here.  I recognize that Hesham is
  > representing a point of view to which other members of the WG also
  > subscribe.  To paraphrase Tom Paxton, I'll try to be kind 
  > -- I expect
  > to fail miserably, but I'll try.

=> You've done well :)

  > 
  > 1) What, precisely, does the term "stateless" mean in this context?
  >    It suggests a belief that all the existing mechanisms 
  > for telling a
  >    host where to find DNS servers are keeping state recording which
  >    server addresses they've reported to which hosts.  That 
  > sure isn't
  >    the way that even "stateful" configuration (DHCPv4 with address
  >    leasing) works with the ISC DHCP server that's running on my
  >    network right now.

=> I understand. Perhaps stateful is used to refer 
to the fact that they keep a record of the DNS
address. But I agree that it is not really accurate. 

  >    The distinction between "stateless" and "stateful" 
  > configuration is
  >    meaningful for address configuration, and the IPv6 stateless
  >    address configuration mechanism is a good and useful thing.  I do
  >    not, however, see how the distinction applies to DNS server
  >    discovery, and find attempts to use the term in this 
  > context to be
  >    more confusing than useful.

=> Ok, I should say that the functionality I'd like
to see is the ability to discover a DNS without
relying on functional entities other than the 
DNS. (not necessarily the entire node, but the 
server itself, I think the term server is very 
clear and does not imply an entire node).

The point of the work is to limit the effects 
of third party node failures on discovering the 
DNS. I.e. When I'm running a network with a million
user devices in it, I can either spend money to
make sure that my DHCP server is super reliable
or, make sure that, at least the very basic 
functions of the server, are done e2e. That is,
between the end host and the DNS. 

  > 
  > 2) What, precisely, does "server" mean in this context?  DNS server?
  >    DHCP server?  What's a server, anyway?  A node?  A 
  > program running
  >    on a node?  A well-known port to which one can send 
  > certain queries
  >    and from which one sometimes gets back useful answers?
  > 
  >    I submit that discussion on this topic to date has confused at
  >    least two of these definitions.  I also submit that, since the
  >    discovery proposal we're discussing both uses a client/server
  >    protocol (DNS) to discover something and is in fact intended to
  >    discover a (DNS) server, the choice of terminology here 
  > is poor at
  >    best and (presumably accidently) obfuscatory at worst.

=> Believe it or not, I think we're in agreement.
I was not referring to an entire node. 

  > 
  > To be clear (well, clearer): when I suggested using DHCP in order to
  > locate DNS servers, I meant that entities that wish to locate an
  > entity that functions in the server role of the DNS protocol when
  > contacted at UDP port 53 might well do so by issuing DHCPv6
  > Information-Request messages and listening for relevant responses.
  > For the cases where the proposal you're talking about works at all,
  > the two are semantically equivilent except for details of well-known
  > port number, packet encoding, and the set of tricks used to 
  > propagate
  > the queries and responses across routers.

=> Exactly, but propagating information across 
routers is _the_ issue here. People were not 
comfortable with relying on multicast routing. 
Also having an additional function in every 
router (relay agent) to simply repackage this
single packet didn't seem like a good investment.
Hence the chosen 'transport' mechanism in the 
draft. The content could well look identical
to a DHCP message, but the issue is how to send 
this packet across the network. 

The other issue is, if we assume that the 
node containing the DNS will also act like
a DHCP server (for the sake of receiving this
single message (DHCP INFORM)), how does that
work in the presence of other DHCP servers
used for address configuration as well as 
configuring other parameters?
I've already claimed lack of deep knowledge on
DHCP, so there might be a pretty simple answer
for this, but I haven't heard it. 

  > > FWIW, we have deployment cases where this draft makes
  > > a lot of sense and there is no alternative to it. 
  > 
  > Given that the Information Request mechanism already exists 
  > in DHCPv6,
  > and is substantially identical to the DHCPINFORM mechanism which has
  > been part of the Draft Standard for DHCPv4 since 1997, I have a hard
  > time believing your statement if I take it literally, so I suspect
  > that you meant something else.

=> I've tried to explain above.

Thanks, 
Hesham
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Rob Austein <[email-masked]>
Date: Tue, 16 Apr 2002 13:34:15 -0400

At Tue, 16 Apr 2002 17:48:10 +0200, Hesham Soliman wrote:
> 
> Ok, I should say that the functionality I'd like to see is the
> ability to discover a DNS without relying on functional entities
> other than the DNS. (not necessarily the entire node, but the server
> itself, I think the term server is very clear and does not imply an
> entire node).

Sorry, but it really is not clear enough to sift fact from confusion
in some of the comments that people (not necessarily you) have made.

Ok, a "server" isn't a whole node, good.  But is it a process, or the
entity listening to a particular well-known port, or a collection of
subroutines that perform a particular set of conceptual functions?

If, say, a single process is listening to both port 53 and to port 67,
is that one server or two?

> The point of the work is to limit the effects of third party node
> failures on discovering the DNS. I.e. When I'm running a network
> with a million user devices in it, I can either spend money to make
> sure that my DHCP server is super reliable or, make sure that, at
> least the very basic functions of the server, are done e2e. That is,

So if the DHCP server role and the DNS server role were being
performed by the same "server", this would not be a problem.  Right?

> Believe it or not, I think we're in agreement.

Ok.

> Exactly, but propagating information across routers is _the_ issue
> here. People were not comfortable with relying on multicast routing.
> Also having an additional function in every router (relay agent) to
> simply repackage this single packet didn't seem like a good
> investment.  Hence the chosen 'transport' mechanism in the
> draft. The content could well look identical to a DHCP message, but
> the issue is how to send this packet across the network.

Right, and if I believed that DNS were the only non-addr-config data
we'd ever need to worry about, I might buy the argument, but I don't.

> The other issue is, if we assume that the node containing the DNS
> will also act like a DHCP server (for the sake of receiving this
> single message (DHCP INFORM)), how does that work in the presence of
> other DHCP servers used for address configuration as well as
> configuring other parameters?  I've already claimed lack of deep
> knowledge on DHCP, so there might be a pretty simple answer for
> this, but I haven't heard it.

Well, entities performing the server role of DHCP only answer Inform
requests when (they think) they have something useful to say.  The
specific mechanism by which multiple entities could act in the DHCP
server role on a single node is an implementation issue, but if you
want an example, it appears (from the man page, I haven't tried it)
that setsockopt(SO_REUSEPORT) would suffice on FreeBSD.

Thanks,

--Rob

---

From: Thomas Narten <[email-masked]>
Date: Wed, 17 Apr 2002 09:21:12 -0400

> address. But I agree that it is not really accurate.

Do DHC servers do that? Are they *required* too? And if they do, so
what? I.e., DHC servers can easily be configured to say "all clients
should use DNS server XXX". I.e., they give the same config
information to everyone. Is this explicitely recorded on a per-client
basis? I don't know that it is or needs to be or why that matters.

> clear and does not imply an entire node).

Why?

> DNS.

The above paragraph is much more restrictive than necessary to meet
this requirement. Hence, I keep coming back to wanting to understand
the real requirements.

> I.e. When I'm running a network with a million user devices in it, I
> can either spend money to make sure that my DHCP server is super
> reliable or, make sure that, at least the very basic functions of
> the server, are done e2e. That is, between the end host and the DNS.

I seriously have to wonder whether one can have a network with a
million users on it that *doesn't* have the need to configure services
other than DNS and that won't be needing to run DHC.

> comfortable with relying on multicast routing.

Well, if it is a requirement  that any DNS discovery solution NOT rely
on multicast, I think  the WG needs to have that discussion and make
it a requirement of the problem. There has been only limited
discussion on this point so far.

Thomas