This is only a rough draft - Megan 04/15/92 Here are the minutes from the DHC WG meeting in San Diego: The DHC WG held two meetings in San Diego, on Tuesday afternoon and Thursday morning. In addition, Ralph Droms gave a technical presentation to the IETF summarizing DHCP. In the Tuesday meeting, the WG discussed changes to DHCP, as reflected in a new version of the DHCP Internet Draft, dated March, 1992: o Modified introductory text to state that DHCP allows but does not require the configuration of higher level protocols. Vendor extensions for NIS have been defined. Others will be allowed. o Extended the definitions of the 'htype', 'hlen' and 'chaddr' fields to accommodate client identifiers that might not be hardware addresses. o Replaced 'byte' with 'octet' throughout. o Added text allowing servers to use the same local broadcast mechanism as BOOTP relay agents when sending DHCP messages to clients. o Added a new mechanism for clients that do not request dynamic address allocation. o Added a new 'message' vendor extension, which may be used by a server to pass an ASCII text message to a client, e.g., an error message if the server cannot satisfy a client request. Several minor changes were discussed, which will be integrated into a new version of the DHCP I-D: o The I-D will give details of mechanisms through which hosts can check to determine if its network address is already in use by another host. For example, a host using ARP can issue an ARP request for its network address to see if another host answers. As neither RFC 826 nor RFC 1122 address this use of ARP, the DHCP I-D must explicitly describe how a host can issue an ARP request for its own address; specifically, the host must use some other IP address (e.g., 0.0.0.0) as the 'sender's protocol address' in the ARP request to avoid corrupting other hosts' ARP caches. o Hosts must delay some short, random time at boot-up before issuing an initial DHCP message, to avoid swamping the network with multiple simultaneous DHCP messages in the case of synchronized host boot-up (e.g., power fail/recover cycle). o Figure 2 will be modified to include a second server and to delete the final DHCPRELEASE message. o Section 6.2.1 will be rewritten to reflect the use of the new REBOOTING state and DHCPREQUEST message by hosts that retain a network address across system reboots. 1 o The 'message' vendor extension will specify the use of NVT ASCII text. Use of MIME multi-media message format was considered and rejected. o The definitions of the vendor extensions (Appendix D in the March, 1992 Internet Draft) will be extracted and submitted as a separate Internet Draft. Definition of new vendor extensions in the future will require only the resubmission of the vendor extension Internet Draft, rather than the entire DHCP Internet Draft. o The DHCP specification Internet Draft will be rewritten with careful use of MUST/MUST NOT/SHOULD/SHOULD NOT/MAY to reduce ambiguity in the specification. Special attention will be paid to the specification of the fields to be used and the valid vendor extensions in each of the DHCP messages. There were also several topics that sparked longer discussions. These topics, in general, remain unresolved: o The relationship between BOOTP and DHCP should be clarified by renaming DHCP as BOOTP. o Various levels of compliance with the DHCP/BOOTP specification should be indicated by ``BOOTP Level 0,'' ``BOOTP Level 1'' and ``BOOTP Level 2.'' DISCUSSION: There is the potential for confusion on the part of naive users about the relationship between BOOTP and DHCP. For example, BOOTP clients will continue to work with DHCP servers; will DHCP clients work with BOOTP servers? The relay agents will still be known as ``BOOTP relay agents''; will those work with DHCP clients and servers? Some client implementations of DHCP may not include all the functions specified in the DHCP Internet Draft. In particular, members of the WG have expressed concern that some DHCP clients may be unable to enforce the network address lease rules, and may always require allocation of a network address with an infinite lease. The WG proposes renaming DHCP to BOOTP, and subsuming the specification of the current BOOTP protocol into the DHCP/BOOTP document. The various type of DHCP/BOOTP service would be names: -- BOOTP Level 0 -- BOOTP as defined in RFC 951. -- BOOTP Level 1 -- DHCP/BOOTP with automatic network address allocation and only infinite leases. -- BOOTP Level 2 -- DHCP/BOOTP with fully dynamic (finite lease) network allocation. o Does DHCP need to deliver more parameters in vendor extensions than will fit in a single DHCP message? 2 o If DHCP delivers more parameters than will fit in a single DHCP message, how should those additional parameters be delivered? DISCUSSION: Some members of the WG contend that DHCP must, indeed, be prepared to deliver more parameters than will fit in a single DHCP message. One argument in favor of that view is that specific sites will want to deliver additional DHCP parameters, and, if the DHCP document does not explicitly specify the use of a particular mechanism, each site may choose a local (and potentially incompatible) mechanism. Other members of the WG feel that DHCP can deliver sufficient parameters in a single message to configure a host. Based on the currently defined vendor extensions, and assuming ``reasonable'' lengths for variable length vendor extensions, DHCP could send all parameters specified by vendor extensions in roughly 280 octets. Counting the 'sname' and 'file' fields, a single DHCP message can deliver 502 octets of vendor extensions. Thus, DHCP can, at present, deliver all necessary parameters to a host in a single DHCP message. The WG discussed a mechanism called a ``bill of lading'' to provide reliable delivery of vendor extensions in multiple DHCP messages, if DHCP is defined to support vendor extensions in excess of 502 octets. A bill of lading is a bit vector representing all 256 vendor extensions. The DHCP server will deliver a bill of lading to the host, indicating which vendor extensions the host must receive with a 1 in the corresponding bit in the bit vector. The host will then repeatedly ask for DHCP parameters, checking off specific vendor extensions as they arrive, until all specified vendor extensions have been delivered. o Should a host use DHCP at every reboot to reacquire network parameters? o If the host cannot contact a DHCP server at reboot, should a host be allowed to reuse previously acquired network parameters? 1. Required use of DHCP: A DHCP host should likely be required to use DHCP whenever the local network parameters may have changed (e.g., system reboot, network failure and restart), as connected network may change w/o host's or user's knowledge (consider change inside wiring closet w/o user notification). 2. Application of lease: does the lease apply to just the network address or does it apply to all network parameters? I.e., host is allowed to reuse stored network address (careful here; host may have bogus network address and not be able to contact server). 3. Authority of DHCP server: should server be able to force host to take new network values; i.e., "remote manage" the host? DISCUSSION: The conversation about this topic began with consideration of whether or not to allow a DHCP host should be allowed to continue if it cannot contact a DHCP server at reboot. THere were strong arguments for and against -- for: allows for partial network operation even if DHCP servers are inaccessible; against: may allow misconfigured hosts to operate. Note that only network parameters can be misconfigured; 3 DHCP guarantees that any network address will be assigned to only one DHCP host. The WG then discussed the relation between the 'lease' and network parameters; should the lease apply to all parameters or just to the network address. A proposal was floated for another bit-vector to describe those network parameters to which the lease applied. The idea here is to provide some degree of network management through the guarantee that DHCP hosts would periodically reacquire new (possibly changed) network parameters.