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