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

[Chris Pearson <[e-mail]>]

Thanks for the corrections.  A few more comments.

> Every subsequent DHCPREQUEST is unicast

RFC2131 para. 3.2 shows DHCPREQUEST for address reuse being broadcast.  That
may just be the example chosen, but it's certainly misleading.

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

Agreed.  However, I meant that DNS is an "application-level protocol" in the
sense that it is designed specifically to provide a service to applications
while DHCP primarily provides a service to the OS.

> the common DNS API ... is not a standard.

Of course not.  My point is simply that applications already interface with
DNS (minimally, gethostbyname), suggesting that DNS might be a more natural
choice to support application-driven service location requests.

Also, DNS dynamic update offers the potential to track low-frequency
changes in service availability -- how would DHCP support that?

-- CCP

-----Original Message-----
From: Ted Lemon [mailto:[e-mail]]
Sent: Tuesday, July 16, 2002 10:39 PM
To: Chris Pearson
Cc: DHCP discussion list; Stuart Cheshire
Subject: Re: [dhcwg] Review of Service-Discovery-Type options in DHCP


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

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

>      4. Service discover is often initiated by applications (rather than
>         by the IP stack).  DNS is an application-level, request-response,
>         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
>         that I know of don't provide an API.

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.

>      5. DHCP client requests (DHCPREQUEST) must be subnet-broadcast and
>         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.

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