CURRENT MEETING REPORT (June 8, 1990) Reported by Ralph Droms/ Bucknell University Introduction ------------ John Veizades, Jeff Mogul, Greg Minshall, Bob Morgan, Leo McLaughlin and Ralph Droms attended a ``mid-term'' meeting of the Dynamic Host Configuration working group. Jeff Mogul was kind enough to host the meeting at DEC's Western Research Lab. The purpose of the meeting was to discuss the mechanism for network address allocation proposed at the Pittsburgh IETF plenary. The participants were chosen to represent the two mechanisms as presented at the Pittsburgh meeting. The time and location were chosen for the convenience of the participants. The allocation mechanism under discussion at this meeting describes the way in which DHC servers allocate and transmit network addresses to DHC clients. This new mechanism was first proposed by Leo and Jeff at the Pittsburgh meeting. In this mechanism, the DHC servers allocate and return a single network address to a requesting client. Discussion ---------- The DHC WG generally agrees that the new DHC protocol should be based on the existing BOOTP protocol. The primary motivations behind this decision are the desire to capture BOOTP forwarding agent code in existing routers and the desire to avoid inventing a new protocol when an existing protocol can be used. The WG further agrees that the new protocol should be first defined to carry network layer configuration parameters to the client: network address, subnet mask, broadcast address and local network MTU. The question arises: how shall the DHC server select a network address to return to the client? There are several points on which one can compare the two network address allocation mechanisms discussed in the introduction: o Relative complexity of client and server code o Accuracy/correctness of allocated addresses o Compatibility with existing BOOTP clients o Ability to maintain coherent distributed information about allocated addresses The explicit allocation mechanism has appeal because it captures existing BOOTP clients and because it can make the client code much simpler. However, at the Pittsburgh meeting there was much discussion about whether the central allocation mechanism could be made to work; would it be too complex and would it be possible to maintain the global database required for distributed allocation of addresses? 1 New Mechanism -------------- At the June meeting, we developed an outline of the specific address mechanism, which we present for comment here. From the client's point of view, the new DHC protocol works the same as the existing BOOTP mechanism. In fact, we expect existing BOOTP clients to interoperate with DHC servers without requiring any change to initialization software. There are some new, optional transactions that optimize the interaction between DHC clients and servers: o Client sends DHC request for network parameters o Server sends response with network parameters and explicit network address (Note: This assumes the client receives at least one reply. If no replies arrive, the client may, at the discretion of local administration, enter ``genesis state'' [see below for details].) o (Opt.) Client updates local network ARP caches with an ARP broadcast reply o (Opt.) Client releases unused addresses from duplicate server responses o (Opt.) Client releases selected address during orderly close Problem Areas with Explicit Allocation -------------------------------------- The first problem area encountered by a server when explicitly allocating a specific network address rather than a range of addresses is determining which addresses are already in use and which may be allocated or reallocated. Because the server may not be on the same subnet as the client, the server must use an ICMP echo message to probe for hosts already using a specific address. Thus all participants using network addresses in the dynamic allocation range (whether statically or dynamically allocated) must implement ICMP echo message processing. Some hosts, while implementing ICMP echo processing, may go into a state where ICMP echo requests are ignored for extended periods. The client request protocol includes two new extensions to help the server handle such clients: o ``brain damage'' - indicating that the client may ignore ICMP requests o ``reserve forever'' - requesting permanent allocation of a network address To meet the goal of reissuing the same network address to a host whenever possible, while allowing more hosts on a subnet than addresses available for allocation (obviously, not all hosts can be active simultaneously), the server must be able to timeout the allocation of an address to a host, and reuse addresses in LRU order. The optional 2 ``release address'' message from the client to the server also helps the server determine when a network address may be reallocated The second problem area, which was discussed at some length in Pittsburgh, is the mechanism through which multiple servers can coordinate the allocation of addresses. We believe this is not a difficult problem. First, note that the problem only arises when multiple servers share responsibility for allocation of addresses on a single subnet. Second, the servers need not interact dynamically, after every network address is allocated. Rather, the address space for the target subnet can be partitioned among the servers, which each only allocate addresses from its own partition. Periodically, the servers exchange allocation information, possibly repartitioning the currently unallocated addresses to reflect client request load. Genesis State -------------- In the absence of any servers, clients may choose to enter ``genesis state''. This state is intended for use in small networks in which resources for support of DHC servers may not be available (the ``dentist's office'' network). In genesis state, the client picks an IP address, probes for any current use of that address and then defends the selected address using ARP. The genesis state mechanism looks much like the Athena NIP address allocation mechanism. Conclusion ---------- The problem areas in a protocol where network addresses are explicitly selected by a possibly remote server seem to be identifiable and can be surmounted by careful design of the protocol and server behavior. The advantages of explicit network address allocation appear to outweigh the disadvantages, and I recommend the DHC WG further investigate the new address allocation mechanism. 3