CURRENT_MEETING_REPORT_ Reported by Ralph Droms/Bucknell University Minutes of the Dynamic Host Configuration Working Group (DHC) Since the last meeting of the DHC Working Group, DHCP was accepted as a Proposed Standard and the protocol specification was published as RFC 1541 (specification), RFC 1533 (options) and RFC 1534 (DHCP-BOOTP interoperation). J. Allard and Fred Lien organized two rounds of interoperability testing. At the second round of testing, 7 servers and 12 clients were tested: o Microsoft: NT server, NT client, DOS client o Sun: server and client o HP: client o Boeing: server and client o DEC: client o WIDE project (Japan): client, server and relay agent o SGI: server and client o Competitive Automation: server and client o FTP Software: Windows and OS/2 servers, Windows and DOS clients At present, there are no freely-distributable implementations. The WIDE project's implementation, described in a short presentation to the group, may be made available, but needs additional work first. The WIDE project, from Keio University, has implemented a DHCP server, client and relay agent, all based on UNIX and BPF (Berkeley Packet Filter). The server manages three databases: an available address pool, the set of client bindings and the known relay agents. The server uses ICMP echo to test for an address already in use before allocation. The server does not yet support the class identifier and vendor-specific data options, and the use of `sname' and `file' fields to hold options. The client is also built on BPF, as a library of functions for the various DHCP state transitions. Thus, the client software can be integrated into a variety of DHCP implementations. The relay agent uses BPF to communicate with the client and a socket to communicate with the server. The interoperability testing identified a set of ``minor'' problems. The group discussed these problems and devised solutions as follows: o Packet size: As BOOTP specifies smaller packets (300 octets) than DHCP (576 octets), the DHCP specification should be changed to explicitly allow smaller BOOTP packets. o Minimal protocol requirements: DHCP requires some minimal functions from the TCP/IP protocol software on a client(e.g., ability to accept unicast replies before the IP address has been configured); these requirements must be added to the protocol specification. o Use of `ciaddr' field: As RFC 1542 requires a client to be able to respond to ARP requests if it puts an address in `ciaddr', a client must use the `requested IP address' option in DHCPREQUEST packets. o Use of `server ID' in DHCPACK and DHCPNAK packets: Make the use of `server ID' a MUST requirement. o Change number of retries of DHCPREQUESTs to 4 (to match other retry specifications). o Use of `BROADCAST flag' in DHCPNAKs: Possibly; still under consideration. o Use of `XID': - Client MUST use unique, random XID (NOT a well-known constant!) for each client DHCP packet to avoid associating reply for client B with request from client A. - Changing XID for each retransmission seems to be an implementation detail (client can choose to change XID with each retransmission of a specific DHCP packet). o The group rejected the idea of a protocol version number. o Timeouts: The group concluded that the timeout back off mechanism is ``over-specified''. The specification will be changed to read that the mechanism SHOULD be employed, and the reasoning behind choosing a specific mechanism. o T2 not explicitly specified to be less than the lease time; specification to be fixed to reflect that requirement. o Size limit on a single option (255 octets) may be too small: Allow multiple copies of the same option. Specification and the use of `client ID,' and `client class' was discussed. The `client ID' field is supposed to address the problem of separating client identification by the server from the delivery of DHCP packets from the server to the client. That is, the server always needs a MAC address (supplied in `chaddr') for the client, through which messages can be delivered to the client, but the server may want to use some other identifier to track the binding of an IP address to that client. BOOTP overloads the MAC address with delivery and identification functions. It was decided to specify that DHCP servers should use `client ID' if supplied by the client and `chaddr' otherwise, for binding an IP address to a client. For the purposes of address binding, `client ID' is to be interpreted as an opaque string of octets. Text will be added to the protocol specification explaining the reasons for using `client ID' and possible effects of using `chaddr' (e.g., when Ethernet cards are moved between hosts). There was some discussion prior to the DHC meeting as to whether the `client class' option was under-specified. The concern was that, without further specification, interoperability among DHCP participants would be compromised as a result of different interpretations of the the `client class'. (See the DHC Working Group mailing list archive for more details.) The group felt that the primary use of `client class' will be in aggregation of clients; i.e., the description of a collection of identical clients by a single entry in the DHCP server database. The attendees concluded that this use can be met as follows: o Treat the `client class' option as an character string. o Recommend that vendors supply an initial value: - Should be ``descriptive of the product''. - Must be well-documented. - Must be useful in a DHCP database. - Must be configurable by the system administrator. o Allow system administrators to choose local values for `client class'. o Add text to the protocol specification suggesting how system administrators can use vendor-supplied or locally-configured `client identifier's. The attendees also discussed two issues related to other IETF working groups. First, the Domain Name System Working Group (DNS) is aware of the requirement for a network interface to DNS updates. DHC is not the only group making such a request. DNS is working on the problem. Second, the attendees decided to hold off on any changes to the DHCP specification to accommodate new versions of IP and IP addressing such as SIP or TUBA. There will be another round of interoperability testing in December after the latest changes to the protocol specification are integrated into the documentation. A copy of the text source used by the RFC Editor to generate the DHCP RFCs has been obtained, so revised documents can be generated that are consistent with the published RFCs. Attendees Kannan Alagappan kannan@dsmail.lkg.dec.com Steve Alexander stevea@lachman.com James Allard jallard@microsoft.com Jim Barnes barnes@xylogics.com Monroe Bridges monroe@cup.hp.com Michael Carney mwc@sun.com Jonathan Didner jonb@bangate.compaq.com Thomas Dimitri tommyd@microsoft.com Ralph Droms droms@bucknell.edu Roger Fajman raf@cu.nih.gov Shawn Gillam shawn@timonware.com Robert Gilligan Bob.Gilligan@Eng.Sun.Com Marc Hasson marc@mentat.com Ronald Jacoby rj@sgi.com Rick Jones raj@cup.hp.com Akira Kato kato@wide.ad.jp Byonghak Kim bhkim@cosmos.kaist.ac.kr Andrew Knutsen andrewk@sco.com David Lapp lapp@waterloo.hp.com Fred Lien fred@speedster.ca.boeing.com Glenn Mansfield glenn@aic.co.jp Jun Matsukata jm@eng.isas.ac.jp Sath Nelakonda sath@lachman.com Steve Parker sparker@ossi.com Isil Sebuktekin isil@nevin.bellcore.com Satya Sharma ssharma@chang.austin.ibm.com Robert Stevens robs@join.com John Tavs tavs@vnet.ibm.com Fumio Teraoka tera@csl.sony.co.jp Susan Thomson set@bellcore.com Akihiro Tominaga tomy@sfc.wide.ad.jp Keisuke Uehara kei@cs.uec.ac.jp Jean Yao yao@cup.hp.com Weiping Zhao zhao@nacsis.ac.jp