Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/dhc/dhc-minutes-93nov.txt

Text File | 1994-02-16 | 8KB | 191 lines

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