home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
dhc
/
dhc-minutes-93nov.txt
< prev
next >
Wrap
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 kannan@dsmail.lkg.dec.com
Steve Alexander stevea@lachman.com
James Allard jallard@microsoft.com
Jim Barnes barnes@xylogics.com
Monroe Bridges monroe@cup.hp.com
Michael Carney mwc@sun.com
Jonathan Didner jonb@bangate.compaq.com
Thomas Dimitri tommyd@microsoft.com
Ralph Droms droms@bucknell.edu
Roger Fajman raf@cu.nih.gov
Shawn Gillam shawn@timonware.com
Robert Gilligan Bob.Gilligan@Eng.Sun.Com
Marc Hasson marc@mentat.com
Ronald Jacoby rj@sgi.com
Rick Jones raj@cup.hp.com
Akira Kato kato@wide.ad.jp
Byonghak Kim bhkim@cosmos.kaist.ac.kr
Andrew Knutsen andrewk@sco.com
David Lapp lapp@waterloo.hp.com
Fred Lien fred@speedster.ca.boeing.com
Glenn Mansfield glenn@aic.co.jp
Jun Matsukata jm@eng.isas.ac.jp
Sath Nelakonda sath@lachman.com
Steve Parker sparker@ossi.com
Isil Sebuktekin isil@nevin.bellcore.com
Satya Sharma ssharma@chang.austin.ibm.com
Robert Stevens robs@join.com
John Tavs tavs@vnet.ibm.com
Fumio Teraoka tera@csl.sony.co.jp
Susan Thomson set@bellcore.com
Akihiro Tominaga tomy@sfc.wide.ad.jp
Keisuke Uehara kei@cs.uec.ac.jp
Jean Yao yao@cup.hp.com
Weiping Zhao zhao@nacsis.ac.jp