Subject: RE: Stateless DNS discovery draft

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 15 Apr 2002 12:24:36 +0200

> I still don't see the point of this mechanism in the first 
  > place.  Any
  > general implementation is going to need to support something that
  > configure DNS when the special conditions needed for this mechanism
  > don't apply, and the total size of the minimal DHCP client one would
  > need to solve the general case (and the general NTP case, and the
  > general XYZ-server case) just is not that big.  There's a 
  > slight code
  > size saving if one only considers DNS, but once one starts thinking
  > about other services, the code size costs start tipping the 
  > other way,
  > even in specialized cases such Hesham's 3GPP example.

=> 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. 

  > I am also concerned about the operational implications of either
  > 
  > (a) needing two different mechanisms to configure DNS, one for the
  >     simple case, the other for the general case, or 
  > 
  > (b) reimplementing the entire general case for each protocol that
  >     needs configuration (DNS, NTP, ...) just to avoid (a).
  > 

=> So would you support a generic mechanism that does 
not require a third party server? I mean if the 
DNS discovery was not limited to the DNS, would 
that be a better approach?
I'm just trying to understand if the argument is:

a. Just use DHCP, we don't want anything else, or
b. Let's not have a separate mechanism for each
   server. 

If a) then I disagree, there has been good steps 
taken towards stateless autoconfig in IPv6. I 
don't think we should mandate a server-based
discovery all the time. 
If b) then I can understand. 

FWIW, we have deployment cases where this draft makes
a lot of sense and there is no alternative to it. 
And it just happens that DNS is the one server
that needs to be discovered. Maybe that's not
a good enough justification for the draft, but 
I'm failing to see any concrete side effects 
that would result from using this extremely simple
draft. Which is a usual problem with philosophical
arguments. Not that I'm underestimating the 
value of philosophical arguments. 

Hesham

  > I think that Randy Bush pegged the basic issue back in Salt 
  > Lake City:
  > there's a basic philosphical disagreement here between 
  > viewpoints, one
  > of which holds that it's better to use a single generalized
  > lightweight config mechanism for all services and the other of which
  > holds that it's better to make each config mechanism independent.
  > 
  > I think the single generalized protocol approach both is likely to
  > scale better and is likely to require less protocol work and code
  > space in the long run, particularly given that such a 
  > protocol already
  > exists.
  > 
  > Which brings me back to my original point: I don't 
  > understand why the
  > IPv6 WG needs to reinvent the wheel here.
  > --------------------------------------------------------------------
  > 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]
  > --------------------------------------------------------------------
  > 
--------------------------------------------------------------------
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: Mon, 15 Apr 2002 17:49:56 -0400

At Mon, 15 Apr 2002 12:24:36 +0200, Hesham Soliman wrote:
> 
> OK, but we still have two options in IPv6 for address

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.

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.

   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.

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.

   I am also well aware that it is not just the IPv6 WG that has been
   chasing this weird idea of things walk like servers and quack like
   servers but are called something else.  I disagree with the people
   chasing this idea in other WGs in those WGs, but there appear to be
   people chasing it here too, so I guess I need to disagree with it
   here too.

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.

> So would you support a generic mechanism that does not require a
> third party server? I mean if the DNS discovery was not limited to
> the DNS, would that be a better approach?  I'm just trying to
> understand if the argument is:
>
> If a) then I disagree, there has been good steps taken towards
> stateless autoconfig in IPv6. I don't think we should mandate a
> server-based discovery all the time.  If b) then I can understand.

I'm suggesting both, but for different reasons, and in neither case am
I suggesting that we should get rid of all forms of stateless
autoconfig in IPv6.

(b) is an architectural argument with a philosphical component.

(a) is because the Information Request mechanism in DHCP already
provides exactly the necessary service, and I still have not received
any good answer as to why the IPv6 WG needs to reinvent this wheel.

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

> And it just happens that DNS is the one server that needs to be
> discovered.

As I've stated before, even if one were to assume for purposes of
discussion that DNS is the only service that needs to be discovered
today, I think that's unlikely to remain true in the future.  In
particular, I strongly suspect that NTP (well, some kind of time
protocol) will be required to verify DNSSEC signatures.  I am aware
that some people don't think that end nodes will ever need to do that,
but I think that those people are confused.  For more information on
this subject, please see the draft that Derek Atkins and I wrote about
DNS threats and the extent to which DNSSEC can be used to combat them.

> Maybe that's not a good enough justification for the draft, but I'm
> failing to see any concrete side effects that would result from
> using this extremely simple draft.

Multiple mechanisms that do the same thing with no significant benefit
from the choice are not harmless if they both have to be implmented.
They cost in code size, program complexity, increased vulnerability to
clever attacks, and so forth.

In this case, since the mechanism being proposed is (IMNSHO) inferior
to a mechanism that already exists, I don't see the point of the
exercise.

> Which is a usual problem with philosophical arguments. Not that I'm
> underestimating the value of philosophical arguments.

Glad there's something on which we can agree. :)

--Rob

---

From: [email-masked]
Date: Tue, 16 Apr 2002 11:47:58 +0900

speaking from RFC246[012] behavior point of view...

>the queries and responses across routers.

	this "Information-Request" behavior happens only when O bit is set in
	router advertisement packet (see RFC2461 page 19).  the problem
	"stateless DNS discovery" draft is trying to address is, how to
	discover DNS server when O bit is not set.

	btw - it is still unclear to me if "administered (stateful) mechanism"
	mentioned in RFC2461 is DHCPv6, or some other protocol.
	it is not explicitly stated anywhere.

itojun

---

From: Rob Austein <[email-masked]>
Date: Tue, 16 Apr 2002 02:01:01 -0400

> 	discover DNS server when O bit is not set.

Thanks for the specific reference.  Right, RFCs 2461 and 2462 say that
one should only use the "stateful" configuration mechanism when the
"O" bit (or the "M" bit) is set, but given that DHCPv6 Information
Request is stateless (except in the sense that "stateful" is sometimes
used as a euphemism for "DHCP"), I don't see the text in RFCs 2461 and
2462 as settling this one way or the other.

To reiterate (briefly): the stateless/stateful distinction makes sense
for address configuration.  For non-address-configuration, all the
protocols we're talking about are stateless.

> 	it is not explicitly stated anywhere.

Right, DHCPv6 is cited as an example, but that's all.

---

From: Robert Elz <[email-masked]>
Date: Tue, 16 Apr 2002 20:56:11 +0700

Date:        Tue, 16 Apr 2002 02:01:01 -0400
    From:        Rob Austein <[email-masked]>
    Message-ID:  <[email-masked]>

  | To reiterate (briefly): the stateless/stateful distinction makes sense
  | for address configuration.  For non-address-configuration, all the
  | protocols we're talking about are stateless.

Yes, "stateless" is the wrong word - what people are mostly meaning is
"adminstratorless" or "configuration free" or similar - that is, it all
just works without anyone configuring anything, anywhere.

Whether this makes any sense at all for the DNS is debatable, but perhaps
it might be nice to not require configuration of any more than the DNS
server (ie: configure zone files, and everything else is automatic - if
the zone files are setup for dynamic DNS, then the initial configured file
would need no more than SOA and NS records - nodes should automatically
(somehow) find the server, and then add themselves to it when they have
allocated themselves addresses).   Much of this may be pipe dream time,
as at the very least, something needs to be telling the nodes what domain
to use...

The "server" that is mostly talked about is the any thing that would
require any kind of configuration in order to supply information to a
node.

kre

---

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

> why we shouldn't allow the option for _real_ stateless 

Thank you Rob for starting the discussion on this issue. IMO, there is
quite a lack of technical clarity on what "stateless" DNS discovery is
(or should be), and if or why it is required.

> By 'real' I mean, we can't claim true stateless autoconfig when a
> crucial service like the DNS still requires a server.

This sounds like a possible requirement that a solution would need to
satisify. I'd like to better understand what the exact requirements
are of the problem. Lacking that, it's hard to have a technical
discussion about various solutions and how they satisfy (or do not
satisfy) actual requirements. I say this because I've had a number of
discussions with various folk, and there seems to be a number of
unstated assumptions that different people are making. Without
understanding those assumptions, and seeing whether there is actual WG
agreement on those assumptions, it's hard to see how we're going to
pick/develop a solution on which there is consensus.

Some things I've heard:

- no dependency on a third-party server
- no configuration required by admin
- something that "just works" for roaming users. (?)
- something that addresses the case where the O bit in RAs is not set
- don't reinvent the wheel without compelling reason
- don't end up with multiple ways of doing the same thing
- can't use DHCP because DHCP ... (isn't liked, isn't done, is
  state, is too complex, requires configuration, ...)

I'm not necessarily agreeing with any or all of the above. But I think
it would be useful to have an explicit discussion about the
assumptions/requirements folks have that are driving them towards a
particular solution.

What other requirements do folks have?

> FWIW, we have deployment cases where this draft makes a lot of sense
> and there is no alternative to it.  And it just happens that DNS is
> the one server that needs to be discovered. Maybe that's not a good
> enough justification for the draft, but I'm failing to see any
> concrete side effects that would result from using this extremely
> simple draft.

Well, for one thing, the current draft may not actually solve the
problem at hand (but since I'm not sure I understand the problem, I'm
not entirely sure...). In Minneapolis, it was pointed out that the use
of a site-local address meant the ISP and customer had to be in the
same site, which seemed to be a problem.

Thomas

---

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

> just works without anyone configuring anything, anywhere.

And note that this can be done today using existing protocols. SLP,
for example, does exactly this. But for reasons that are unclear to
me, SLP has been rejected as somehow not being appropriate.

And, one can imagine DHC doing this. Either through inform, or by
having information from the server providing the actual services
(e.g., DNS) registering itself with DHC. Some protocol work would be
needed for this, but it would have the benefit of generalizing to
other services that will likely need the same functionality. Also,
this could be done behind the scene *without* client
modifications. IMO, here is certainly value in having one way to do
DNS server discovery on clients.

And, oddly enough, this is again reinventing SLP, which has a
Directory Agent capability where servers register with DAs.

Thomas

---

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

> 	discover DNS server when O bit is not set.

It is probably worth pointing out that the wording in 2461 was put in
quite a long time ago, well before we had a DHCPv6 and may well
warrant some (re)thinking about whether those bits still make sense in
their current form. For example, we could just say always invoke DHC
for non-address configuration in all cases and do away with the O bit.

Another possible view is that routers in practice will always set the
O bit to 1, precisely so that clients can discover DNS config via
DHC. In this case, we don't need an alternate way to learn of DNS
servers.

It seems to me that the argument "we need a non-DHCP way of doing this
to deal with the case with the O bit being 0" is a bit of an
artificial problem. To me, the argument alone doesn't justify doing
something explicit for a "stateless" DNS  discovery.

I.e, maybe the reason the O bit is set to 0 is because there is no DNS
server config information available. In that case, doing any sort of
DNS discovery is a waste of time.

> 	it is not explicitly stated anywhere.

That is because at the time there was nothing to point to. I think the
assumption has always been that it would be DHC. But as I say above,
it might well be worth re-thinking whether we still do need the O bit
and what its actual semantics should be given what we know today.

Thomas