Subject: [dhcwg] ID's: DHCP Discovery Extensions / Interface Information Option

From: "Rentschler, Markus" <[email-masked]>
Date: Mon, 3 Nov 2003 11:41:33 +0100

Hello DHC-WG,

I seem to have missed the deadline for ID submission, but need some
criticism/feedback on the issues described in the enclosed drafts. Please
read through the documents and let me know your comments.

The abstracts of these drafts are given here:

-- DHCP Discovery Extensions --

   This draft defines simple protocol enhancements to DHCP so that it
   can be used for the following applications:

   - Discovery of clients in the network
   - DHCP server redundancy
   - Server-initiated configuration of clients

   The discovery mechanism described here is built upon and coexists
   with BOOTP according to RFC 1542 and DHCP according to RFC 2131 
   and RFC 3203.
   It allows server-initiated communication to specific or all clients 
   in the network, using the DHCP packet format. Other DHCP servers
   in the network can be provided with information about all
   existing client configurations and will therefore be able to take
   over if the main server fails.

 <<draft-rentschler-dhc-discovery-00.txt>> 

-- DHCP Interface Information Option --

   This draft defines a new option to inform the server about
   the client's physical interface it is connected to.
   This information may be used together with the relay agent 
   information option (RFC 3046) for the purpose of topology 
   recognition.

 <<draft-rentschler-dhc-interface-opt-00.txt>> 

Best Regards,
           Markus Rentschler

---

From: "Barr Hibbs" <[email-masked]>
Date: Wed, 5 Nov 2003 15:47:40 -0800

>    over if the main server fails.
...I object to this draft for several reasons:
   1. it alters the fundamental nature of DHCP protocol exchanges from
      client-initiated to server-initiated (RFC 3203 notwithstanding, as
      there are no known implementations of RFC 3203.)
   2. it seems to require that the basic model of server operation be
      changed from stateless to stateful with respect to DHCP clients
   3. it specifies the collection and maintenance of configuration data
      about it's clients that appears to significantly increase the 
      amount of stable storage required of a server
   4. it has the potential to trigger broadcast storms through what I 
      view as ill-considered transmission of broadcast packets to 
      potentially tens or hundreds of thousands of clients, each packet
      requesting another broadcast packet in response
   5. it overrides the expected default behavior of DHCP servers -- that
      a server never (well, almost never) sends an unrequested option to
      a client
   6. it mandates that a client IP stack and DHCP client software be at
      least partially operational before the DHCP client has fully
      initialized the IP stack -- a window of opportunity that is in
      almost every conceivable case less than 64 seconds, and largely
      less than 2-4 seconds, hardly a compelling argument for the extra
      complexity and functionality
   7. it apparently mandates the use of option 61, client identifier,
      which is optional per RFC 2131
   8. it requires a DHCP client to adopt a new state machine to allow
      for forced configuration changes using the DHCPCONFIGURE message,
      but does not specify state transitions
   9. it requires a client to respond to a DHCPCONFIGURE message with
      a DHCPRELEASE message, followed by a DHCPREPORT message, but does
      not discuss side-effects of such behavior:  for example, if a 
      client had previously dynamically updated a DNS server with it's
      IP address information, it presumably MUST also update DNS after
      a DHCPCONFIGURE message forces a new IP address on the client
  10. it's not clear that some network elements such as switches will
      even be able to forward packets to clients before the client
      initiates the RFC 2131 message exchange -- many switches do not
      keep a port open for an uninitialized client 

>    information option (RFC 3046) for the purpose of topology 
...this draft presumes a mode of operation for a DHCP server which is
not compatible with RFC 2131, namely that it calls for the server to 
send an [unrequested by the client] option code to the client in the
parameter request list that requires a response from the client to
the server.

This might better be a sub option for the Relay Agent Information Option, 
to be added by Relay Agents so equipped for packets forwarded towards
the server.

--Barr

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