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         [email protected]
Steve Alexander          [email protected]
James Allard             [email protected]
Jim Barnes               [email protected]
Monroe Bridges           [email protected]
Michael Carney           [email protected]
Jonathan Didner          [email protected]
Thomas Dimitri           [email protected]
Ralph Droms              [email protected]
Roger Fajman             [email protected]
Shawn Gillam             [email protected]
Robert Gilligan          [email protected]
Marc Hasson              [email protected]
Ronald Jacoby            [email protected]
Rick Jones               [email protected]
Akira Kato               [email protected]
Byonghak Kim             [email protected]
Andrew Knutsen           [email protected]
David Lapp               [email protected]
Fred Lien                [email protected]
Glenn Mansfield          [email protected]
Jun Matsukata            [email protected]
Sath Nelakonda           [email protected]
Steve Parker             [email protected]
Isil Sebuktekin          [email protected]
Satya Sharma             [email protected]
Robert Stevens           [email protected]
John Tavs                [email protected]
Fumio Teraoka            [email protected]
Susan Thomson            [email protected]
Akihiro Tominaga         [email protected]
Keisuke Uehara           [email protected]
Jean Yao                 [email protected]
Weiping Zhao             [email protected]

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.