CURRENT_MEETING_REPORT_ Reported by Ralph Droms/ Bucknell This meeting of the DHC WG concentrated on the details of the proposed DHC protocol. Specifically, the WG concentrated on the DHC protocol as used to initially configure the client's network layer. The WG agreed that the following parameters should be configured: o IP address o Subnet mask o Broadcast address o (Non-default or unusual) MTU - which may be required by some kinds of network hardware The WG has further agreed to base the DHC protocol on the BOOTP protocol, as extended by R. L. Morgan. The agenda items for this meeting, then, included the definition of the following: o Client behavior within the protocol o Server behavior o Router or other forwarding agent behavior o Protocol message formats There are two primary problems to be solved by the client: first, the client must decide which of possibly several sources of configuration information to use and second, the client must decide which IP address to use if given a range of addresses to choose from. The client may get configuration information from a local cache or from a DHC protocol server. If no configuration information is available (the ``genesis state''), the client should use a default configuration that allows interoperation with other clients on the same local net. Greg Minshall presented an algorithm (included with this report) that was discussed at the meeting. The genesis state was discussed at some length. The WG agreed that a client in the genesis state should use a distinguished network number, defined so that routers will never forward packets with the distinguished network number. This distinguished network number will allow interoperation between hosts on an isolated network, with no danger of genesis state packets leaking onto the internet if the isolated network becomes attached to an internet at some later time. The WG also discussed problems with the transition from genesis state to normally configured state. If an isolated net becomes attached while hosts are in genesis state, the hosts will either have to restart to obtain correct configuration parameters, or must be able to support interoperation with two logical nets on the same interface (both the genesis state network and the ``real'' network). The WG discussed router behavior briefly. We need to find out from router vendors about the details of existing BOOTP implementations so the WG can assess the impact of changes to the BOOTP protocol on 1 existing implementations and determine if a formal description of BOOTP forwarding agent behavior needs to be written. The final point of discussion sparked some real controversy. Before this meeting, the WG had discussed the IP assignment mechanism as an extension of the MIT and Morgan/BOOTP mechanisms, in which a client is provided a range of IP addresses from which it can choose a preferred IP address. At this meeting, an alternative proposal was presented, in which BOOTP servers were presumed to have sufficient knowledge of the network configuration so as to be able to determine and allocate a single IP address to a client. The presumption was that such a dynamic allocation mechanism would make the client code much simpler (in fact, existing BOOTP client code would work unchanged) at an acceptable cost in server complexity. The dissenting opinion was that the increased server complexity was not worth the simplification in the client code. As neither side had anything in writing, the WG had some difficulty in arguing the relative merits of the two mechanisms. The WG chair has scheduled a meeting for June 8 in which several of the participants in the WG discussion will present written descriptions of the two mechanisms for discussion. 2 ATTENDEES Douglas Bagnall bagnall_d@apollo.hp.com Terry Braun tab@kinetics.com Andrew Cherenson arc@sgi.com Peter DiCamillo cmsmainto@brownvm.brown.edu Hunaid Engineer hunaid@opus.cray.com Roger Fajman raf@cu.nih.gov Metin Feridun mferidun@bbn.com Karen Frisa karen@kinetics.com Greg Hollingsworth gregh@mailer.jhuapl.edu Tom Holodnik tjh@andrew.cmu.edu Mike Horowitz mah@shiva.com Leo McLaughter ljm@twg.com Greg Minshall minshall@kinetics.kinetics.com Jeffrey Mogul mogul@decwrl.dec.com Michael Reilly reilly@nsl.dec.com Jeffrey Schiller jis@athena.mit.edu Tim Seaver tas@mcnc.org Ted Soo-Hoo soo-hoo@dg-vtp.dg.com John Veizades veizades@apple.com Steve Waldbusser sw0l@andrew.cmu.edu Jonathan Wenocur jhw@shiva.com 3