Subject: RE: [dhcwg] Review of Service-Discovery-Type options in DHCP

From: Chris Pearson <[email-masked]>
Date: Tue, 16 Jul 2002 16:54:22 -0700

More DNS is better:

     3. DHCP provides no mechanism for a client to request configuration
        options without also requesting address lease renewal.  Lease
        renewal would be a highly undesirable side-effect of service
        discovery.

     4. Service discover is often initiated by applications (rather than
        by the IP stack).  DNS is an application-level, request-response,
        protocol that is supported by established APIs.  DHCP, on the other
        hand, is an integral part of the IP stack -- DHCP implementations
        that I know of don't provide an API.

     5. DHCP client requests (DHCPREQUEST) must be subnet-broadcast and
        perhaps relayed, while DNS queries are unicast.

I have to agree that DNS SRV doesn't address topology-based server
assignment.

-- CCP

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Tuesday, July 16, 2002 3:21 AM
To: Stuart Cheshire
Cc: DHCP discussion list
Subject: Re: [dhcwg] Review of Service-Discovery-Type options in DHCP

What you propose is perfectly workable, but I don't see how it's *better* 
than what DHCP already provides.   That is, we have something that works 
now.   Why is the DNS a better choice as a resource discovery server?   I 
can think of some reasons, but I'm not sure why you think this makes sense,
  so I'm grasping at straws a bit - the reasons I can think of in favor of 
DNS are ones you have stated, and I don't have a real problem with them, 
but I don't find them particularly compelling either.

DNS is better:

     1. I already have to have a DNS server.   With IPv6,
        I don't have to have a DHCP server.   So this is
        one less thing I have to configure/deploy.
     2. DNS servers understand administrative domains,
        and administrative domains are a good way to
        determine which clients should use which servers.

DHCP is better:

     1. DHCP already solves the problem of locating services,
        so we don't have to kludge something into the DNS
        namespace.
     2. DHCP servers understand the network topology, and
        topology is a good way to determine which clients
        should use which servers.
     3. You have to have a DHCP server anyway - how are you
        going to get the IP address of your DNS server?

Arguments (1) are true, although I don't find argument 1 for DNS 
particularly compelling.   The other arguments aren't true - they're just 
opinions, and not necessarily even particularly valid opinions.   My 
feeling here is that using DNS as a server location protocol is chancy at 
best, and so I don't want to switch from DHCP to DNS, but I can't prove 
that I'm right on this.

Can you come up with a really compelling argument for using one over the 
other?

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Wed, 17 Jul 2002 14:39:04 +0900

>         renewal would be a highly undesirable side-effect of service

Not true.   DHCPv4 provides DHCPINFORM.   DHCPv6 provides Information 
Request.

>         protocol

> 4a. that is supported by established APIs.

>  4b. DHCP, on the other
>         hand, is an integral part of the IP stack --

> 4c. DHCP implementations

You are actually making four points here.   I agree with (4), (4a) and (4b)
, but not (4c).   There is no reason not to have an API for DHCP, and there'
s no particular sense in which such an API would be more or less good than 
the common DNS API which, BTW, is not a standard.

My reason for disagreeing with (4c), btw, is that in fact every operating 
system out there except one puts the DHCP client at the application level,
  not in the stack, and indeed it's an application-layer protocol - it's 
layered on top of UDP.   Ironically, the one operating system where it's 
easy to use DHCPINFORM is the one where DHCP is in the stack, because a 
DHCPINFORM client can do a DHCPINFORM without running into the problem of 
competing with the userland DHCP client in binding to port 68.

>         perhaps relayed, while DNS queries are unicast.

Again, this is almost completely untrue.   The _only_ DHCPREQUEST that is 
ever broadcast is the first one, when the DHCP client has no IP address.   
Every subsequent DHCPREQUEST is unicast, unless something is wrong (e.g., 
the DHCP server hasn't responded to unicast renewals for a long time).

So I would say that the only substantive argument you've advanced is the 
lack of an API for DHCP, which I agree is a problem.