draft-ietf-dhc-implementation-00.txt   draft-ietf-dhc-implementation-01.txt 
Network Working Group Barr Hibbs Network Working Group Barr Hibbs
INTERNET-DRAFT (no affiliation) INTERNET-DRAFT (no affiliation)
Category: Informational February 2003 Category: Informational Rob Stevens
(no affiliation)
October 2003
Implementation Issues with RFC 2131, "Dynamic Host Configuration Implementation Issues with RFC 2131, "Dynamic Host Configuration
Protocol" Protocol"
<draft-ietf-dhc-implementation-00.txt> <draft-ietf-dhc-implementation-01.txt>
Saved Monday, February 24, 2003, 12:51:05 AM Saved Friday, October 24, 2003, 8:08:15 AM8:05:56 AM PT8:08:15 AM
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 41 skipping to change at page 1, line 43
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) 2003, The Internet Society. All Rights Reserved. Copyright (C) 2003, The Internet Society. All Rights Reserved.
Abstract Abstract
This memo identifies implementation issues with RFC 2131, "Dynamic This memo identifies implementation issues with RFC 2131, "Dynamic
Host Configuration Protocol," reported by a number of implementors, Host Configuration Protocol," reported by a number of implementers,
assesses the severity of the problem, then proposes changes to RFC assesses the severity of the problem, then proposes changes to RFC
2131 intended to overcome the issues. This is intended for use as 2131 intended to overcome the issues. This is intended for use as
the basis for discussion of RFC 2131 before it is proposed for the basis for discussion of RFC 2131 before it is proposed for
Internet Standard status. Internet Standard status.
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction...................................................3
2. Issues with RFC 2131...........................................3 2. Issues with RFC 2131...........................................3
2.1. The DHCP Client Identifier.................................3 2.1. Outdated RFC Boilerplate...................................3
2.2. Address-in-Use Detection...................................4 2.2. Organization and Typography................................4
2.3. DHCP Relay Agents..........................................4 2.2.1. Outdated References...................................4
2.4. Host Name, Domain Name, and FQDNs..........................4 2.2.2. Typographical Errors..................................4
2.5. Conflicts with Host Requirements [RFC1123].................4 2.2.3. Omissions.............................................5
2.6. What Are Default Values?...................................4 2.2.4. Tables................................................5
2.7. Overloading of DHCPREQUEST.................................5 2.2.5. Inconsistencies.......................................5
2.8. DHCPRELEASE................................................5 2.3. Policy issues..............................................6
2.9. Which Options to Return?...................................5 2.4. The Client Hardware Address, "chaddr"......................7
2.10. Recovery from Address Assignment Conflicts................6 2.5. The DHCP Client Identifier.................................7
2.11. Interaction with DNS......................................6 2.5.1. Uniqueness............................................7
2.12. Client and Server Administration..........................6 2.5.2. Prohibition in DHCPOFFER and DHCPACK..................8
2.13. Lack of Clarity...........................................6 2.6. Address-in-Use Detection...................................9
2.13.1. Vendor and User Classes..............................7 2.6.1. Client-side ARP.......................................9
2.13.2. Option Selection.....................................7 2.6.2. Server side PING......................................9
2.13.3. Client / Server retransmission.......................8 2.6.3. Other Mechanisms.....................................10
2.13.4. Transmission of DHCP NAKs............................8 2.7. DHCP Relay Agents.........................................10
2.13.5. Minimum size of a BOOTP / DHCP frame.................8 2.7.1. Relay Agent Source Addresses.........................10
2.13.6. Use of ciaddr........................................9 2.7.2. Relay Agent Port Usage...............................10
2.13.7. Duplicate IP address detection.......................9 2.8. Host Name, Domain Name, and FQDNs.........................11
2.13.8. Clarify use of Vendor class identifier (form).......10 2.9. Overloading of DHCPREQUEST................................11
2.13.9. DHCP MTU option.....................................11 2.10. DHCPINFORM...............................................11
2.13.10. SHOULDs that should be MUSTs.......................12 2.11. Unicast of DHCPDISCOVER..................................12
2.13.11. Just wrong.........................................12 2.12. DHCPRELEASE..............................................13
2.13.12. Just unclear.......................................13 2.13. Client state diagram.....................................13
2.14. Inconsistencies..........................................13 2.14. Options..................................................13
2.15. Escape Hatches or Trapdoors in Protocol..................14 2.14.1. Which Options to Return?............................14
2.16. Typographical Errors.....................................14 2.14.2. Multiple Instances of Options.......................16
3. Suggested Changes to RFC 2131.................................16 2.14.3. Option Ordering.....................................16
4. Intellectual Property.........................................17 2.14.4. Options 66 and 67...................................16
5. Notes.........................................................17 2.15. Vendor Classes...........................................17
5.1. Issues....................................................17 2.15.1. Character set.......................................17
5.2. Changes from Prior Drafts.................................17 2.15.2. Form of the name space..............................17
6. Acknowledgements..............................................17 2.15.3. Relationship to vendor options......................17
7. IANA Considerations...........................................18 2.15.4. Multiplicity........................................18
8. Security Considerations.......................................18 2.16. Client/Server Retransmission.............................19
9. References....................................................18 2.17. Transmission of DHCPNAKs.................................19
10. Editors' Addresses...........................................18 2.18. Use of ciaddr............................................20
11. Full Copyright Statement.....................................19 2.19. Size of a BOOTP/DHCP frame...............................20
2.19.1. Minimum size........................................20
2.19.2. Maximum Size, MTU, and Message Size option..........20
2.20. Use of giaddr............................................22
2.21. Address Selection........................................22
2.22. Use of "secs" field......................................22
2.23. Use of "htype" and "hlen" fields.........................23
2.24. Use of xid field.........................................23
2.25. Options in DHCPOFFER and DHCPACK.........................24
2.26. Lease times..............................................24
2.27. Miscellaneous............................................25
3. Intellectual Property.........................................26
4. Notes.........................................................26
4.1. Issues....................................................26
4.2. Changes from Prior Drafts.................................27
5. Acknowledgements..............................................28
6. IANA Considerations...........................................28
7. Security Considerations.......................................28
8. References....................................................28
9. Editors' Addresses............................................29
10. Full Copyright Statement.....................................29
1. Introduction 1. Introduction
This memo was produced by the DHC Working Group and attempts to This memo was produced by the DHC Working Group and attempts to
identify all known implementation issues with RFC 2131 as a basis for identify all known implementation issues with RFC 2131 as a basis for
discussion of RFC 2131 before it is published as an Internet discussion of RFC 2131 before it is published as an Internet
Standard. Standard.
This memo grew from a discussion item during the DHC Working Group This memo grew from a discussion item during the DHC Working Group
meeting at IETF-55 in Atlanta during November 2002. meeting at IETF-55 in Atlanta during November 2002.
The editors have solicited input through a general call for The editors have solicited input through a general call for
participation and by direct request to all implementors that they participation and by direct request to all implementers that they
could identify. The list of contributors to this effort is presented could identify
in Appendix A, while the list of vendors contacted is presented in
Appendix B.
The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT,"
NOT," "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this
"OPTIONAL" in this document are to be interpreted as described in document are to be interpreted as described in document [RFC2119].
document [RFC2119].
2. Issues with RFC 2131 2. Issues with RFC 2131
This list may not include every implementation issue for RFC 2131 as This list may not include every implementation issue for RFC 2131 as
it is based on reported problems and those known to the editor. it is based on reported problems and those known to the editors.
2.1. The DHCP Client Identifier 2.1. Outdated RFC Boilerplate
DHCP servers must somehow uniquely identify DHCP clients that are 1. "Status of This Memo" should be replaced with standardized
requesting services in order to correctly configure the client. RFC language for RFCs as described in "Guidelines to Authors of
2131 provides two specific methods for identifying a client: (1) the Internet-Drafts," dated September 5, 2002.
client identifier (DHCP Option 61) [RFC2132], and (2) the "chaddr"
field of the BOOTPREQUEST packet. 2. Section 1.4, "Requirements," should be replaced with standardized
language referring to RFC 2119 regarding the definition and
interpretation of specific key words.
3. References should be separated into normative and non-normative
sections.
2.2. Organization and Typography
2.2.1. Outdated References
1. References to the "Assigned Numbers" RFC [STD 2, RFC 1700]
should be changed to the "Assigned Numbers" database
maintained by IANA. References are found in Tables 3 and 5,
and in the "References" section.
2. References to the "Interaction between DHCP and BOOTP" RFC
1534 should be integrated with the text of the memo, and RFC
1534 deprecated.
2.2.2. Typographical Errors
1. Page 23, third paragraph of section 4.1 -- "recieved" should
be "received."
2. Page 23, sixth paragraph of section 4.1 -- refers to RFC 1533,
not RFC 2132.
3. Page 15, Figure 3. Table misformatted.
4. Page 18, Figure 4. Table misformatted.
5. Page 25, ninth paragraph of section 4.1 -- "uicast" should be
"unicast."
6. Page 38, first paragraph after Table 5. Orphaned sentence:
"The DHCPREQUEST message contains the same 'xid' as the
DHCPOFFER message." No it doesn't. Not only that, but this
sentence makes no sense in its current location. It should be
removed.
7. Page 39, Last paragraph of 4.4.3 should be moved up as the
last paragraph of 4.4.2. When the text for DHCPINFORM was
added, the text describing what a client should do if no
DHCPACK is received was mistakenly pushed below it.
8. Apostrophes (') are used as single quotation marks, but
outside of an enclosing quotation (") throughout the document.
9. Page 30, section 4.3.1, second from last bullet: "...client’s
vendor class identifier and client's classes identified in the
server". This text makes no sense and should be deleted.
10. Inconsistent style regarding placement of periods (.), commas
(,) and semi-colons (;) with respect to quotation marks
throughout the document.
11. Quotation marks (single and double) are overused through the
document.
2.2.3. Omissions
In several places there is missing or incomplete information,
including:
1. Table 3, pages 27 and 28. . The "options" entry for "DHCPNAK"
in the "fields" portion of the table is missing. All entries
in this line should refer to the subsequent "options" table.
2. Page 33, Table 4, and Page 35, Figure 5, do not include the
"DHCPINFORM" message.
3. Table 5, pages 37 and 38. The "options" entry for
"DHCPDECLINE, DHCPRELEASE" is missing. All entries in this
line should refer to the subsequent table.
2.2.4. Tables
1. Table 3 (pages 28 and 29) and Table 5 (pages 37 and 38) should
be separated into two tables each for readability.
2. Table 4 should be reorganized to show all messages (except
DHCPRELEASE) that are sent from each client state.
3. The "Host Configuration Parameters" table now in an appendix
should be omitted and described in a revised "DHCP Options"
document (RFC 2132).
2.2.5. Inconsistencies
1. Page 1, Abstract, "TCPIP" should be "TCP/IP" – as it is in the
rest of the document.
2. Page 10, Table 3, description of 'htype' and 'hlen' fields does
not capitalize "Ethernet."
3. Lack of consistency when describing "IP broadcast." Sometimes it
is "0xffffffff IP broadcast," elsewhere "limited broadcast," or
"broadcast." Suggest using the "255.255.255.255 IP broadcast
address" form, as that is the most specific. Specific references
include:
Page 19, third paragraph of section 3.2, List item #2
Page 23, fifth paragraph of section 4.1 (twice)
Page 25, thirteenth paragraph of section 4.1 (twice)
Page 32, section 4.3.2, third bullet item
Page 32, section 4.3.2, fifth bullet item
Page 36, second paragraph of section 4.4.1
Page 39, last paragraph of section 4.4.1
Page 39, second paragraph of section 4.4.3
4. Lack of consistency when referring to the BROADCAST (B) flag: it
is also referred to as the "broadcast bit."
5. Table 3, "Fields and options used by DHCP servers," is
problematic. It indicates that we MUST fill in both the "Server
Identifier" (and siaddr) in our DHCPACK (and DHCPNAK) response.
That's a change from the same table in RFC 1541 that specifies
this is a "MAY" (and which is consistent with RFC 2132 section
9.7 and identical RFC 1533 section 9.5 wording).
2.3. Policy issues
There has in general been a certain amount of overlap in DHCP between
protocol and policy. The matters include lease times, whether
servers are willing to extend leases, timeouts, and re-transmission.
We SHOULD clarify what is dictated by the protocol and what is a
policy decision at a given site.
The DHC Working Group philosophy ought to be to constrain client
behavior more closely than server behavior. DHCP interactions are
initiated (and continued) by clients: clients outnumber servers by
many tens of thousands to one; client implementers cannot be quite
certain of all the environments in which their client may ultimately
appear, whereas server implementations may be designed for very
specific environments. Policy is likely to be a matter of
centralized control, whereas clients are not likely to enjoy a
sufficient status to impose policy on servers.
The previous paragraph implies that the WORKING GROUP should tighten
the protocol with respect to such issues as retries and backoffs,
whereas servers should not be constrained on issues such as how to
uniquely identify clients, whether to offer or extend leases etc.
2.4. The Client Hardware Address, "chaddr"
The value of "chaddr" MUST NOT change from DHCPDISCOVER to
DHCPREQUEST, although the wording in table 3 makes this point
unclear.
Further, the length of "chaddr" SHOULD be exactly specified by
"hlen," which SHOULD match the address length for "htype."
2.5. The DHCP Client Identifier
2.5.1. Uniqueness
DHCP servers must uniquely identify DHCP clients requesting services
in order to correctly configure the client. RFC 2131 provides two
specific methods for identifying a client: (1) the client identifier
(DHCP Option 61) [RFC2132], and (2) the "chaddr" field of the
BOOTPREQUEST packet.
Confusion arises from the language of RFC 2131 Section 4.2. A DHCP Confusion arises from the language of RFC 2131 Section 4.2. A DHCP
client "...MAY choose to explicitly provide the identifier through client "...MAY choose to explicitly provide the identifier through
the 'client identifier' option. If the client supplies a 'client the 'client identifier' option. If the client supplies a 'client
identifier', the client MUST use the same 'client identifier' in all identifier,' the client MUST use that same identifier in all
subsequent messages, and the server MUST use that identifier to subsequent messages, and the server MUST use that identifier to
identify the client. If the client does not provide a 'client identify the client. If the client does not provide a 'client
identifier' option, the server MUST use the contents of the 'chaddr' identifier' option, the server MUST use the contents of the 'chaddr'
field to identify the client." field to identify the client."
The text of the quoted section goes on to state that subnet The text of the quoted section goes on to state that subnet
uniqueness is a requirement for an identifier, but points out that uniqueness is a requirement for an identifier, but points out that
"chaddr" may not satisfy that requirement. Two alternative "chaddr" may not satisfy that requirement. Two alternatives for a
suggestions for a unique identifier are and unspecified unique identifier were given: an unspecified manufacturer's serial
manufacturer's hardware identifier or a DNS name. number or a DNS name.
RFC 2132 adds to the confusion by stating that the client identifier RFC 2132 adds to the confusion by stating that the client identifier
"...is expected to be unique for all clients in an administrative "...is expected to be unique for all clients in an administrative
domain" without specifying what an "administrative domain" is. domain" without specifying what an "administrative domain" is.
RFC 2132 continues by suggesting use of "...type-value pairs similar RFC 2132 continues by suggesting use of "...type-value pairs similar
to the 'htype'/'chaddr' fields defined in..." [RFC951], and that a to the 'htype'/'chaddr' fields defined in" [RFC951], and that a
"...hardware type of 0 (zero) should be used when the value field "...hardware type of 0 (zero) should be used when the value field
contains an identifier other than a hardware address (e.g., a fully contains an identifier other than a hardware address (e.g., a fully
qualified domain name)." qualified domain name)."
This suggestion of using type-value pairs has been widely adopted by This suggestion of using type-value pairs has been widely adopted by
DHCP client implementors, but the suggestion fails to heed the DHCP client implementers, but the suggestion fails to heed the
warning about uniqueness issues with "chaddr." warning about uniqueness issues with "chaddr."
RFC 2131 SHOULD have made global (or, at least, "administrative RECOMMENDATIONS:
domain"), rather than subnet, uniqueness MANDATORY for the "client
identifier."
RFC 2131 SHOULD NOT have suggested the use of DNS names for the o RFC 2131 SHOULD have made required the "client identifier"
either to be globally unique or, to be unique within an
"administrative domain," and, in the latter case, defined
"administrative domain."
o RFC 2131 SHOULD NOT have suggested the use of DNS names for the
"client identifier" without also suggesting some mechanism for "client identifier" without also suggesting some mechanism for
maintaining a consistent name-to-address mapping. maintaining a consistent name-to-address mapping.
RFC 2132 SHOULD NOT have suggested using the "htype" and "chaddr" o RFC 2132 SHOULD NOT have suggested using the "htype" and
fields as a type-value pair because of the warning in RFC 2131 "chaddr" fields as a type-value pair because of the warning in
Section 4.2 about potential problems using "chaddr" for the purpose. RFC 2131 Section 4.2 about potential problems using "chaddr"
for the purpose.
RFC 2132 SHOULD NOT have used the word "should" when suggesting the o RFC 2132 SHOULD NOT have used the word "SHOULD" when suggesting
use of type-value pairs for "client identifier" with a type of 0 the use of type-value pairs for "client identifier" with a type
(zero) when the value is anything other than a hardware address. of 0 (zero) when the value is anything other than a hardware
address.
2.2. Address-in-Use Detection 2.5.2. Prohibition in DHCPOFFER and DHCPACK
2.3. DHCP Relay Agents Table 3, in the "options" section, specifies that the server MUST NOT
send the "client identifier" in the DHCPOFFER or DHCPACK messages,
but MAY send it in a DHCPNAK message. There is no very good reason
why DHCPNAK should be treated differently, and there is considerable
utility in returning the client identifier, as it allows clients
further corroboration, beyond that implied by matching "xid’s" (see
2.23), that they are the intended recipient.
(To be added) RECOMMENDATIONS:
2.4. Host Name, Domain Name, and FQDNs Change the text in Table 3, for all three message types, to read:
"MAY -- if included, MUST BE the client identifier sent by the
client".
(To be added) 2.6. Address-in-Use Detection
2.5. Conflicts with Host Requirements [RFC1123] RFC 2131 Page 7, section 1.6, second set of bullet items, first
bullet says that DHCP must: "Guarantee that any specific network
address will not be in use by more than one client at a time," but
the protocol as later described does not fulfill this requirement.
(To be added) Two mechanisms are presented: an ARP request generated by the client;
and an ICMP echo request generated by the server:
2.6. What Are Default Values? o Page 12, second paragraph of section 2.2, last sentence
(To be added) o Page 13, list item 2, section 3.1
2.7. Overloading of DHCPREQUEST
The DHCPREQUEST message is sent by the client in several different o Page 38, first paragraph after Table 5, section 4.4.1
states: INIT, INIT-REBOOT, REBINDING, and RENEWING. Differentiation
among the states is done according to the context of other packet
fileds.
2.8. DHCPRELEASE 2.6.1. Client-side ARP
There were several MUST NOT entries in the table that specifies the To meet the requirement of RFC 2131 page 7, a DHCP client MUST send
inclusion of options in the DHCPRELEASE. A bogus DHCPRELEASE should an ARP request for the IP address contained in a DHCPACK before using
not be allowed to release a lease I set about to check if any it. This is presently a SHOULD:
"illegal" options were included in the DHCPRELEASE message and toss
the request with a complaint if there were.
Some customers complained that a particular vendor included the o Page 12, second paragraph of section 2.2: "... and the client
"hostname" option and that this seemed innocuous. The vendor said SHOULD probe the newly received address, e.g., with ARP"
that their reading of the RFC allows such an option to be included.
In a table just above the table that specifies "all others" as MUST There has been confusion on this topic because many clients are
NOT there is the word "unused" for "options" for the DHCPRELEASE. sending an ARP reply (after the DHCPACK). This often has nothing to
Could that be what the vendor was thinking? do with DHCP, and is triggered in many systems whenever an interface
IP address changes. (Without access to kernel code there is nothing
one can do about it.)
What is appropriate here? It is also unclear why these MUST NOT's RECOMMENDATIONS:
exist.
2.9. Which Options to Return? o The Working Group should consider whether to make client ARP a
MUST.
There is some question about the intent of RFC 2131 with regard to 2.6.2. Server side PING.
the client options to send. In Section 3.5 there is no mention of a
minimum set of parameters to be sent to a requesting client, nor any
mention of which parameters to send if the client does not request
any.
"First, most parameters have defaults defined in the Host ICMP is inherently unreliable. Furthermore since success is "no
Requirements RFCs; if the client receives no parameters from the response" it is an imprecise matter to decide how long to wait before
server that override the defaults, a client uses those default one is certain that no response will ever occur. A possible
values." The list of parameters with a cross-reference to the suggestion is a back off and retry for ping.
defining RFC is given in Appendix A of RFC 2131.
Several sources contend that there is no parameter in the list for In cable modem environments, PING is not helpful because it is the
which a viable default value exists, which raises the issue of cable modem termination system (CMTS) that replies from its cache: a
viability of the technique described in this section for reducing cache which may not be perfectly reliable and which in many cases has
total server response message size. been constructed by listening to the DHCP traffic in the first place!
It is known that some network administrators try to block propagation
of ICMP ECHO messages through internal routers, which removes one of
the two address conflict detection mechanisms.
RFC 2131 is silent on the question of whether or not the server MUST, RECOMMENDATIONS:
SHOULD, or MAY choose not to send an option if its value is the same
as a default per the Host Requirements.
Section 3.5 of RFC 2131 describes two mechanisms to limit the number o Use of ICMP on the server should be a “MAY”, not a “SHOULD”.
of options sent, but offers no guidance for what to do when there is
more data than will fit in a response packet. Can the options be
somehow prioritized? Could additional options be obtained using the
DHCPINFORM mechanism?
Section 4.3.1 presents apparently conflicting specifications for how 2.6.3. Other Mechanisms
to select values for options requested by a client:
"IF the server has been explicitly configured with a default Both the ICMP ECHO (Ping) and Address Resolution Protocol (ARP)
value for the parameter, the server MUST include that value in mechanisms are very lightweight by design, depending on clients with
an appropriate option in the 'option' field, ELSE conflicting addresses to "defend" their address by responding to
queries to show that an address is in use. Is there a better
alternative to ICMP ECHO and ARP that is backward-compatible with
these two protocols?
"IF the server recognizes the parameter as a parameter defined 2.7. DHCP Relay Agents
in the Host Requirements Document, the server MUST include the
default value for that parameter as given in the Host
Requirements Document in an appropriate option in the 'option'
field, ELSE
"The server MUST NOT return a value for that parameter" 2.7.1. Relay Agent Source Addresses
The second of these statements seems contrary to the intent of There should be some text that specifies what the relay agent should
minimizing the amount of data sent by the server: if the scope of use for the IP source address of relayed packets. Because relay
the Host Requirements RFCs applies to all Internet-connected hosts, agents change the payload ("giaddr" and relay agent option 82) their
then a DHCP server SHOULD NOT have to supply these values -- they operation does not amount to IP forwarding. The IP source address
should already be assumed by the client as the default for the they use should be their own. [Aside: for security purposes it might
requested option. have been better than they retain the source IP address of the
original packet, but it is too late to change all that.]
2.10. Recovery from Address Assignment Conflicts 2.7.2. Relay Agent Port Usage
(To be added) Relay agents should use port 67 as the source port number. Relay
agents always listen on port 67, but port 68 has sometimes been used
as the source port number probably because it was copied from the
source port of the incoming packet.
2.11. Interaction with DNS Cable modem vendors would like to install filters blocking outgoing
packets with source port 67.
(To be added) RECOMMENDATIONS:
2.12. Client and Server Administration o Relay agents MUST use 67 as their source port number.
(To be added) o Relay agents MUST NOT forward packets with non-zero giaddr
unless the source port number on the packet is 67.
2.13. Lack of Clarity 2.8. Host Name, Domain Name, and FQDNs
This section identifies parts of RFC 2131 where the intended meaning A fully qualified domain name (FQDN) consists of two conceptual
is unclear. parts: the host name portion and the domain name portion. Host
names consist of one or more non-null parts separated by the ISO
period (.) character ("separator") while domain names consist of two
or more non-null parts delimited by the separator, one of which must
be a valid top-level domain (TLD) name. DHCP options exist for
hostname (option 12) and domain name (option 15), and are proposed
for FQDN (draft-ietf-dhc-fqdn-option-05.txt) but the FQDN option is
not required to be a concatenation of hostname and domain name.
2.13.1. Vendor and User Classes Should RFC 2131 explicitly state that the client FQDN MUST be the
host name (option 12) concatenated with the domain name (option 15)?
Page 3, section 1.1, first paragraph - includes the following 2.9. Overloading of DHCPREQUEST
sentence: "The classing mechanism for identifying DHCP clients to
DHCP servers has been extended to include "vendor" classes as defined
in sections 4.2 and 4.3." Vendor classing has been there since RFC
1541, thus there isn't anything new about it. Should this section be
referring to User classing?
2.13.2. Option Selection The client sends a DHCPREQUEST message from several different states:
INIT, INIT-REBOOT, REBINDING, and RENEWING. Differentiation among
the states is done according to the context of other message fields
and option values. At this point there probably can be no change in
this usage, but the content of other message fields and option values
should be carefully reviewed to ensure consistency
Should a DHCP server return all options that have been explicitly 2.10. DHCPINFORM
configured, or return only those options a client has requested
regardless of what is configured on the server? Clients are required
to include the same parameter request list on all messages. There
are two diverging schools of thought regarding which options should
be returned: always return every option configured by the network
administrator, or only return those options specifically requested by
a client.
A DHCP server should always return options that have been configured The intent of DHCPINFORM messages is to allow clients to query
by the network administrator, for the following reasons: servers for configuration information WHETHER OR NOT their IP address
has been assigned by DHCP.
1. Consistency. A network administrator wants all of the configured Section 3.4 Para 2 Page 21 states: "The server SHOULD check the
options to show up on each client on the network, regardless of network address in a DHCPINFORM message for consistency." What the
client vendor. server should be checking is a mystery. Possibly the intent was that
servers should verify that the source IP address in the packet is
identical to the "ciaddr." Since the server should reply to
"ciaddr," this affords some measure of security, preventing third
parties from discovering configuration information pertaining to
other clients. Whether that is desirable, or whether instead
DHCPINFORM should be available to third parties, such as proxies, has
never been resolved.
2. A DHCP client is likely only going to request the options it Section 4.4.4 Para 1, "Use of broadcast and unicast," hints that
supports. However, there are many application layer options that clients may be able to broadcast DHCPINFORM messages to servers: "The
are not used by the DHCP client but are useful to applications. DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST and DHCPINFORM
messages, unless the client knows the address of a DHCP server."
3. A DHCP client would either need to be configured or updated to This text suggests that a DHCP client may choose to broadcast a
request new options. The whole idea of DHCP is to keep DHCPINFORM request for whatever reason, and points out the need for
configuration on the server, not on the client, which is pointed clarification of all text concerning multiple server responses and
out in: Page 7, second and third bullets of section 1.6. consistency of returned options.
At Connectathon, the argument was made that some DHCP clients would RECOMMENDATIONS:
break if they received new options, and therefore a DHCP server
should only return the options a client requested.
o Page 5, second paragraph of section 1.3 o DHCPINFORM messages should be included in Table 4 to summarize
the fields and options usage with this message type.
o Page 21, first paragraph of section 3.5 o The Working Group should consider the ramifications of
permitting third party DHCPINFORMs, that is, DHCPINFORM
messages NOT sent by the DHCP client, but by other processes
having access to the ports.
o Page 29, list items entitled "Parameters requested by the o Section 4.3.1, "DHCPDISCOVER Message," and section 4.3.2,
client, according to the following rules:" "DHCPREQUEST Message" briefly mention consistency and uniform
responses from multiple servers: this text SHOULD be clarified
to state what consistency is expected or required of the
server, and what a client should do if a server supplies
inconsistent data.
o Page 36, first paragraph of section 4.4.1 2.11. Unicast of DHCPDISCOVER
2.13.3. Client / Server retransmission
Because DHCP servers are the passive participants and DHCP clients Section 4.4.4 Para 1, "Use of broadcast and unicast," hints that
are the active participants, the DHCP protocol is susceptible to clients may be able to unicast DHCPDISCOVER messages to servers: "The
poorly behaved clients (retransmit too fast). However, there is no DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST and DHCPINFORM
text describing this susceptibility. Furthermore, the use of the messages, unless the client knows the address of a DHCP server."
power-of-2 retransmission algorithm is a SHOULD/MAY. This probably
should be a MUST. If we need different retransmission algorithms for
different media, then we should develop / document them in table
form. The specification as it stands is too loose and does cause
inter-operability problems.
1. Page 17, third paragraph of list item 5, section 3.1 This would be pointless unless "ciaddr" were non-zero, because the
server would not know how to respond. Neither does table 4 admit the
possibility.
2. Page 24, eighth paragraph of section 4.1 We believe it is common practice for BOOTP Relay Agents to only fill-
in "giaddr" for broadcast packets. This requires investigation:
such behavior would restrict the use of unicast DHCPDISCOVER messages
to the same subnet on which the server resides -- a very restricted
condition.
3. Page 36, first paragraph of section 4.4.1 One circumstance in which this might make sense is for proxies
gathering IP addresses on behalf of other clients. In that case the
proxy could put its own IP address in "ciaddr" and perhaps use
multiple different client identifiers in multiple transmissions.
Table 5, however, asserts that ciaddr must be zero.
2.13.4. Transmission of DHCP NAKs RECOMMENDATIONS:
DHCP NAKs MUST be broadcast. However, the text describing a server's o The Working Group should consider whether to allow this kind of
behavior when the client is accessible through a BOOTP relay agent is proxy usage, and what changes that might imply to RFC 2131.
inconsistent.
1. Page 19, last paragraph of list item 2, section 3.2 o Tables 4 and 5 SHOULD be updated to reflect the possibility of
unicast DHCPDISCOVER messages.
2. Page 23, fifth paragraph of section 4.1 o Figure 5 SHOULD be updated to reflect the uses of unicast and
broadcast packets
3. Page 32, Last paragraph of "DHCPREQUEST generated during INIT- 2.12. DHCPRELEASE
REBOOT state:" bullet, section 4.3.2.
This last reference describes the behavior that's required -- a There are several MUST NOT entries in the "options" portion of RFC
server MUST set the broadcast bit in order for the relay agent to 2131 table 5 specifying the inclusion of options in the DHCPRELEASE.
properly broadcast the DHCPNAK. We just need to either refer to it Some customers complained that a particular vendor included the
in the first two references or duplicate it there. "hostname" option and that this seemed innocuous. The vendor said
that their reading of the RFC allows such an option to be included.
2.13.5. Minimum size of a BOOTP / DHCP frame In the "fields" portion of table 5 there is the word "unused" for the
"sname" and "file" fields of a DHCPRELEASE message, while "options"
for the DHCPRELEASE was left blank.
RFC 951 states that a BOOTP frame is 300 bytes in length. Some BOOTP A DHCPRELEASE message SHOULD be subject to some verification criteria
relay agents thus drop frames less than 300 bytes in length. RFC 951 to reduce the chance of a bogus release. Two possible changes to
is explicit on this point, but RFC 2131 just refers to RFC 951. We these tables are:
SHOULD add a line stating that the minimum size of a DHCP frame is
300 bytes in reference:
Page 10, first paragraph after Table 1, section 2 1. In the "fields" portion of table 5, change the "xid" from
"selected by client" to "xid from server DHCPACK message."
After all, DHCP is intended to be backward compatible with BOOTP. 2. In the "options" portion of table 5, change the entry for
"client identifier" from "MAY" to "client identifier used in
the DHCPDISCOVER message."
2.13.6. Use of ciaddr 2.13. Client state diagram
RFC 951 - clients use ciaddr when they've received an IP address from Section 4.3.1 and Figure 5 do not accurately describe DHCP client
a source outside of BOOTP, and thus should be able to respond to behavior: DHCP clients send messages to servers from the INIT, INIT-
ARPs. REBOOT, SELECTING, REQUESTING, and BOUND states, not from RENEWING or
REBINDING.
The text in RFC 2131 is mostly supportive of this point with the o Change the text of section 4.3.1 and it's schematic
following exception: representation in Figure 5 to correctly represent the states,
transitions, triggering events, and messages sent.
Page 21, first sentence of last para, section 3.4: "The server 2.14. Options
SHOULD check the network address in a DHCPINFORM message for
consistency, but MUST NOT check for an existing lease."
This line should be struck from the document. Servers trust ciaddr, The language in RFC 2131 concerning whether and which options to
period. return to the client is convoluted and apparently contradictory.
Likewise, the following line should also be struck: 2.14.1. Which Options to Return?
Page 32, "DHCPREQUEST generated during REBINDING state:", There are two opposing philosophies regarding which options servers
section 4.3.2: "The DHCP server SHOULD check 'ciaddr' for should return to clients: to return every option with values within
correctness before replying to the DHCPREQUEST" the client’s scope, or to return only those options specifically
requested by a client and within scope. The following arguments have
been cited:
2.13.7. Duplicate IP address detection Supporting the return of every option:
The specification specifies the requirement that DHCP guarantee that o Consistency. A network administrator wants all of the
an IP address is not in use. However, the protocol itself does not configured options to show up on each client on the network,
meet this requirement. regardless of client vendor.
Page 7, Second set of bullet items, first bullet, section 1.6 o A DHCP client is likely only to request the options it
specifies that "Guarantee that any specific network address will not supports. However, many application layer options are not used
be in use by more than one DHCP client at a time." by the DHCP client but are useful to applications.
This should be "host" rather than "DHCP client." The specification o A DHCP client would either need to be configured or updated to
describes two mechanisms, a ICMP echo request generated by the DHCP request new options. The whole idea of DHCP is to keep
server and an ARP request generated by the DHCP client. To meet this configuration on the server, not on the client, which is
requirement, I think a DHCP client MUST validate the IP address pointed out in: Page 7, second and third bullets of section
contained in a DHCPACK before using it, and that a DHCP server MAY 1.6.
validate an IP address using an ICMP echo request before OFFERing it
to a client. Right now, both mechanisms are SHOULD's. Relevant
references:
o Page 12, second paragraph of section 2.2, last sentence Supporting the return only of requested options:
o Page 13, list item 2, section 3.1 o Some DHCP clients may reject packets containing options that
they did not request especially if they are ignorant of their
semantics; therefore a DHCP server should only return the
options requested.
o Page 38, first paragraph after Table 5, section 4.4.1 o The DHCP packet size is limited. Options are often configured
2.13.8. Clarify use of Vendor class identifier (form) on a per-network rather than a per-client basis, and to return
unwanted options risks exhausting the space available while
options remain which the client needs.
What characters are legal? RFC 2131 does little to resolve the matter. Two different sections
are relevant: section 3.5 describes mechanisms to limit the number of
options sent, while section 4.3.1 subsequently presents an apparently
conflicting description of how to select values for options requested
by the client.
RFC 2131, Section 3.5:
"First, most parameters have defaults defined in the Host
Requirements RFCs; if the client receives no parameters from
the server that override the defaults, a client uses those
default values."
The list of parameters with a cross-reference to the defining RFC is
given in Appendix A of RFC 2131.
Several sources contend that virtually none of the parameters in the
list have a meaningful default value, which raises the issue of
viability of the technique described in this section for reducing
total server response message size.
Even if the option has a default value defined in [RFC1122], RFC 2131
is silent on the question of whether or not the server MUST, SHOULD,
or MAY choose not to send that option when its value is the same as
the default.
RFC 2131, Section 4.3.:
"IF the server has been explicitly configured with a default
value for the parameter, the server MUST include that value in
an appropriate option in the 'option' field, ELSE
"IF the server recognizes the parameter as a parameter defined
in the Host Requirements Document, the server MUST include the
default value for that parameter as given in the Host
Requirements Document in an appropriate option in the 'option'
field, ELSE
"The server MUST NOT return a value for that parameter."
The word "default" in the first statement seems misplaced. The
second statement seems contrary to the intent of minimizing the
amount of data sent by the server: if the scope of the Host
Requirements RFCs applies to all Internet-connected hosts, then a
DHCP server SHOULD NOT have to supply these values -- they should
already be assumed by the client as the default for the requested
option.
There is no mention of a minimum set of parameters to be sent to a
requesting client, nor any mention of which parameters to send if the
client does not request any not any guidance for what to do when
there is more data than will fit in a response packet. Can the
options be somehow prioritized? Could additional options be obtained
using the DHCPINFORM mechanism? Should an additional bit in the
"flags" field be defined as a "packet overflow" bit?
RECOMMENDATIONS:
o Clients MUST include the same parameter request list on all
messages.
o Clients MUST be prepared to receive responses containing
options they did not request and/or whose semantics are
unknown. They MAY choose silently to ignore such options.
o Language implying that parameters in "Requirements for Internet
Hosts" have defaults should be removed.
2.14.2. Multiple Instances of Options
Page 24, seventh paragraph, section 4.1: "Options may appear only
once, unless otherwise specified in the options document. The client
concatenates the values of multiple instances of the same option into
a single parameter list for configuration." The first sentence
should start out "Options MUST appear only once, unless...." The
second sentence belongs in the options memo [RFC2132] for options
where there can be multiple instances. Together, these two sentences
are confusing.
2.14.3. Option Ordering
A number of clients require that the DHCP message type be the first
option (after the magic cookie).
RECOMMENDATIONS:
o With the exception of option 82, which must be last (save
option 255 which acts as a terminator), the client MUST NOT
make any assumption about the ordering of options.
2.14.4. Options 66 and 67
Options 66 (TFTP server name) and 67 (bootfile name) were introduced
as an alternative to the fixed fields "sname" and "file" in BOOTP.
As discussed elsewhere, space is at a premium in DHCP, and reserving
64 octets ("sname") and 128 octets ("file") to contain values are
that potentially, and commonly, much shorter is wasteful.
Furthermore, the existence of these options allows the client to
either request those values from the server or not, according to
need.
At present, servers are at liberty to return values for these options
in either the fixed fields, or encapsulated like any other DHCP
option. Clients have sometimes assumed only the former. RFC 2131
should address this issue.
RECOMMENDATIONS:
o Using "sname" and "file" for these options SHOULD be
deprecated.
o Clients MUST be prepared, at least for the time being, for
either method of delivery.
2.15. Vendor Classes
Page 3, section 1.1, first paragraph - includes the following
sentence: "The classing mechanism for identifying DHCP clients to
DHCP servers has been extended to include "vendor" classes as defined
in sections 4.2 and 4.3." Vendor classing has been there since RFC
1541, thus there is nothing new about it. Should this section be
referring to User classing?
2.15.1. Character set
Some new clients have spaces in their identifier, which broke some Some new clients have spaces in their identifier, which broke some
implementations with configuration file records delimited by implementations with configuration file records delimited by
whitespace. whitespace.
What is the form of the name space? 2.15.2. Form of the name space
Originally (1541 time-frame), we had discussed using "Stock An early suggestion (RFC 1541 time-frame), expressed symbolically,
symbol/Organization...." form to prevent collisions between vendors, was the form "Stock symbol/Organization...." e.g., "SUNW.class-
e.g., "SUNW.class-1.class-2" or "CMU.edu.class-1.class-2". This 1.class-2" or "CMU.edu.class-1.class-2". This would have had the
text should be included in 2132. advantage of preventing collisions between vendors. This was not
adopted, and it is probably too late to resurrect it.
Text describing each unique vendor class identifier can support a 253 2.15.3. Relationship to vendor options
unique encapsulated option name space. Some folks think that there
is only one 253 unique encapsulated option name space, and return the
same values to *any* client returning *any* vendor class identifier.
Obviously, we should include text to clarify the relationship between
Vendor Class identifier and the encapsulated Vendor option.
How many Vendor class identifiers can a client have? Text is needed describing how each unique vendor class identifier
implies a 254 unique encapsulated option name space. There are 254,
because even within the vendor space options 0 and 255 retain their
meaning as the pad value and terminator, respectively. An occasional
misconception is that there is only a single unique encapsulated 254
option name space shared by all vendors, with the effect that the
same values being returned to *any* client regardless of vendor class
identifier. Obviously, we should include text to clarify the
relationship between Vendor Class identifier and the encapsulated
Vendor option.
Only one, as there is only one DHCP client vendor. It is impossible 2.15.4. Multiplicity.
to have more than one, since there would be no way to know which
encapsulated option went with which Vendor Class. How many vendor class identifiers can a client have? One only,
because the client is unique to a specific vendor. If the client
were to send more than one vendor class option it would be impossible
for the server to decide which set of encapsulated vendor options to
select.
Here is some more text regarding vendor options from a note from Mike Here is some more text regarding vendor options from a note from Mike
Carney regarding the use of Vendor class / encapsulated options: Carney regarding the use of vendor class / encapsulated options:
"Successful Vendor class support requires the ability to configure a Vendor class support requires the ability to configure a DHCP
DHCP server to support a new vendor class by associating that vendor server to support a new vendor class by associating that vendor
class identifier with 253 options whose types can then be defined by class identifier with 254 options whose types can then be
following the DHCP client's documentation. Each group of 253 options defined by following the DHCP client's documentation. Each
has the "scope" of that Vendor. For example, let's say we have the group of 254 options has the "scope" of that vendor. For
following two clients: example, suppose we have the following two clients:
Vendor Class "SunBeam.Toaster.2slots" Vendor Class "SunBeam.Toaster.2slots"
Options for this class: Options for this class:
Code Len Data Code Len Data
1 2 Darkness setting 1 2 Darkness setting ( a 2 byte integer)
Darkness setting is a 2 byte integer.
Vendor Class "GE.Answering.Machine" Vendor Class "Voxpopulis.Answering.Machine"
Options for this class: Options for this class:
Code Len Data Code Len Data (X bytes ASCCI string, of the answer message)
1 X Outgoing message 1 X Outgoing message
Outgoing message is an ASCII string, X bytes long, consisting Both clients are on the same network ("Kitchen"), and are clients of
of the text of the answer message. the same DHCP server. Note that both use encapsulated option code 1.
Both clients are on the same network "Kitchen," and are clients of
the same DHCP server. Note that both use Encapsulated option code 1.
Looks like a conflict, but it isn't. Looks like a conflict, but it isn't.
In the syntax of the DHCP server's configuration table, I configure In the syntax of the DHCP server's configuration table, one
two new options, each which has the "scope" of the vendor class. configures two new options, each which has the "scope" of the vendor
class.
What this means is that when the toaster boots, the DHCP server only What this means is that when the toaster boots, the DHCP server only
returns vendor class options associated with the returns vendor class options associated with the
"SunBeam.Toaster.2slots" class. When the answering machine boots, "SunBeam.Toaster.2slots" class. When the answering machine boots, it
it only seens vendor class options associated with the only sees vendor class options associated with the
"GE.Answering.Machine" class. Clients of vendor classes not "GE.Answering.Machine" class. Clients of vendor classes not
currently configured on the server don't see any encapsulated vendor currently configured on the server don't see any encapsulated vendor
options, since the server hasn't been configured to support that options.
vendor class. The DHCP server can make this distinction based upon:
o The client identifies it's vendor class. 2.16. Client/Server Retransmission
o The server can be (and has been) configured to associate each Because DHCP servers are the passive participants and DHCP clients
client's vendor options with the client's class identifier. are the active participants, the DHCP protocol is susceptible to
poorly behaved clients (retransmitting too fast, for example).
However, there is no text describing this susceptibility.
Furthermore, the use of the power-of-2 retransmission algorithm is a
SHOULD/MAY. This probably should be a MUST. If we need different
retransmission algorithms for different media, then we should
develop/document them in table form. The specification as it stands
is too loose and does cause inter-operability problems:
2.13.9. DHCP MTU option 1. Page 16, section 3.1, last sentence of list item 3.1.
DHCP messages can't be fragmented, since there is no way to deliver 2. Page 17, third paragraph of list item 5, section 3.1
them to remote networks via a relay agent (fragments won't contain
the BOOTP header which the relay agent needs to deliver the DHCP
response). As such, Clients really SHOULD communicate their link-
layer frame size to the DHCP server via the DHCP MTU option. We
should clarify this point both in the DHCP and BOOTP specifications.
We should consider changing SHOULD to MUST in this case. 3. Page 24, eighth paragraph of section 4.1
Page 21, second para, section 3.5 4. Page 36, first paragraph of section 4.4.1
2.13.10. SHOULDs that should be MUSTs
There are many SHOULDs and SHOULD NOTs that should be converted into 2.17. Transmission of DHCPNAKs
MUSTs or MUST NOTs. Too many to list, but here's a few:
4. Page 12, second paragraph of section 2.2: "... and the client DHCPNAKs MUST be broadcast or unicast to at the link level because
SHOULD probe the newly received address, e.g. with ARP" (MUST) the client has no valid IP address. The same comment applies to
DHCPOFFERs but with one significant difference: a DHCPOFFER has a
valid "yiaddr" which a relay agent can use as the destination IP
address. It is not clear that whatever mechanism relay agents are
using to transmit offers will work when "yiaddr" is 0.0.0.0.
Therefore, for safety’s sake, the servers MUST set the broadcast bit
in DHCPNAK packets. The text describing a server's behavior when the
client is accessible through a BOOTP relay agent does not do this:
5. Page 16, item 4, section 3.1 "The server SHOULD NOT check the 1. Page 19, last paragraph of list item 2, section 3.2
offered network address at this point." (MUST NOT)
6. Page 16, item 5, section 3.1 "The client SHOULD perform a final 2. Page 23, fifth paragraph of section 4.1
check on the parameters..." (MUST)
7. Page 17, item 5, section 3.1 "The client SHOULD wait a minimum of 3. Page 32, Last paragraph of "DHCPREQUEST generated during INIT-
ten seconds..." (MUST) REBOOT state," bullet, section 4.3.2.
8. Page 18, item 2, section 3.2 "Servers SHOULD NOT check that the This last describes the behavior that's required -- a server MUST set
client's network address is already in use;..." (MUST NOT) the broadcast bit in order for the relay agent to properly broadcast
the DHCPNAK.
9. Page 19, item 2, second para, section 3.2 "...servers SHOULD RECOMMENDATION
respond with a DHCPNAK message to the client" (MUST) The o Items (1) and (2) above should either duplicate the text of
following sentences are rather dubious in this paragraph as well. (3), or should reference section 4.3.2.
10. Page 21, first para, section 3.4 "The servers SHOULD unicast the 2.18. Use of ciaddr
DHCPACK replay to the address given int he 'ciaddr' field of the
DHCPINFORM message" (MUST)
11. Page 22, last para, section 3.5 "If a server receives a DHCP According to RFC 951 and RFC 1542, clients use "ciaddr" when they've
request message with an invalid 'requested IP address', the received an IP address from a source outside of BOOTP/DHCP, and can
server SHOULD respond to the client with a DHCPNAK message..." respond to ARPs.
(MUST)
and so on. We should review the MAY/SHOULD/MUST (NOT)s in the spec, The text in RFC 2131 is mostly supportive of this point with the
and tighten up those we can. SHOULDs should list the valid following exception:
exceptions (some do; most don't).
2.13.11. Just wrong Page 32, "DHCPREQUEST generated during REBINDING state:"
section 4.3.2: "The DHCP server SHOULD check 'ciaddr' for
correctness before replying to the DHCPREQUEST."
Page 23, fifth para, section 4.1: "If the 'giaddr field is zero and This line should be struck from the document. Servers trust
the 'ciaddr' field is nonzero, then the server unicasts DHCPOFFER and "ciaddr," period.
DHCPACK messages to the address in 'ciaddr'". True for DHCPACK,
false for DHCPOFFER (a DHCPDISCOVER will never have anything but 0 as
ciaddr)
Page 24, seventh para, section 4.1: "Options may appear only once, 2.19. Size of a BOOTP/DHCP frame
unless otherwise specified in the options document. The client
concatenates the values of multiple instances of the same option into
a single parameter list for configuration" The first sentence should
start out "Options MUST appear only once, unless...". The second
sentence belongs in the options draft for options where there can be
multiple instances. Together, these two sentences are confusing.
2.13.12. Just unclear The description in RFC 2131 relating to the size constraints of DHCP
packets (Page 10, first paragraph after Table 1, section 2) is
inadequate.
Page 30, second from last bullet, section 4.3.1. This item makes no 2.19.1. Minimum size.
sense: "client's vendor class identifiers and client's classes
identified in the server.."?
Page 16, last sentence of list item 3, section 3.1 "The client times RFC 951 states that a minimum BOOTP frame is 300 octets in length.
out and retransmits the DHCPDISCOVER message if the client receives Some BOOTP relay agents have been known to drop frames of less than
no DHCPOFFER messages." How long should the client wait? 300 octets. RFC 951 is explicit on this point, but RFC 2131 just
refers to RFC 951. Since DHCP is intended to be backward compatible
with BOOTP, the protocol should continue to observe this lower bound.
2.14. Inconsistencies RECOMMENDATIONS:
1. Page 1, Abstract, "TCPIP" should be "TCP/IP" -- like it is in the o Text should be added stating explicitly that the minimum size
rest of the document. of a DHCP frame is 300 octets.
2. Lack of consistency when describing "IP broadcast." Sometimes 2.19.2. Maximum Size, MTU, and Message Size option
it's 0xffffffff IP broadcast, other times "limited broadcast" or
"broadcast." Suggest using the "255.255.255.255 IP broadcast
address" form, as that is the most specific.
3. Page 19, third paragraph of section 3.2, List item #2 It has been thought necessary to avoid fragmentation of the IP
packets in DHCP/BOOTP due to concerns that some clients would be
unable to reassemble fragments before the IP stack is properly
configured. RFC 951 states "For simplicity it is assumed that the
BOOTP packet is never fragmented". Regardless of theoretical
limitations in IP stack implementations, it is certain that there are
several DHCP/BOOTP implementations, at both ends of the protocol,
which will not reassemble.
4. Page 23, fifth paragraph of section 4.1 Various comments in the WORKING GROUP imply that fragmentation could
be avoided were the client consistently to include the MTU of the
link layer interface. But clients cannot be expected to be omniscient
about other media over which packets travel en route to servers.
Servers that must be endowed with this knowledge, which they MUST use
to avoid packet fragmentation.
5. Page 25, thirteenth paragraph of section 4.1 Once the IP stack is configured, and the IP stack is fully
configured, the aforementioned limitation ceases to exist, and later
stages of the protocol could allow larger packets (up to the UDP
limit). DHCPINFORMs, especially, could benefit from this relaxation.
There probably should be explicit text to allow larger packets
(presumably up to the maximum PDU size) for later stages of the
protocol.
6. Page 32, section 4.3.2, third bullet item A number of clients send small packets with the assumption that
servers will not return a packet that is any larger than the one
received from the client. The client MUST NOT make this assumption.
If the client cannot process a response larger than a certain size,
the client MUST use the message size option to inform servers of this
size. Note that this is NOT the same option as the MTU.
7. Page 32, section 4.3.2, fifth bullet item RECOMMENDATIONS:
8. Page 36, second paragraph of section 4.4.1 o Servers and relay agents MUST ensure that IP datagram
fragmentation does not occur at any stage in the protocol
before the client IP stack is fully configured.
9. Page 39, last paragraph of section 4.4.1 o Clients SHOULD communicate their link-layer frame size to the
DHCP server via the DHCP MTU option.
10. Page 39, second paragraph of section 4.4.3 o Clients MUST NOT assume that servers will return a packet no
larger than the one they send. If the client has a limit on the
size of the packet that it can process it MUST convey that
limit to the server in the "maximum message size" option (57)
11. Page 40, first paragraph of 4.4.4 o Page 21, second paragraph, section 3.5, the first sentence
SHOULD be changed to "The client SHOULD include the 'maximum
DHCP message size' option to let the server know how large the
server may make its DHCP messages, and the value of this option
SHOULD be the MTU of the [client] network interface being
configured."
12. Page 40, second paragraph of 4.4.4 o The WORKING GROUP SHOULD consider whether to allow
fragmentation of packets after the client is fully configured,
and how servers can divine this fact (e.g. a non-zero
"ciaddr").
13. Page 41, fifth paragraph of 4.4.5 2.20. Use of giaddr
2.15. Escape Hatches or Trapdoors in Protocol
This section describes incomplete changes that result in Page 23, fifth paragraph, section 4.1: "If the 'giaddr’ field is
interoperability problems. zero and the 'ciaddr' field is nonzero, then the server unicasts
DHCPOFFER and DHCPACK messages to the address in 'ciaddr.'" True for
DHCPACK, false for DHCPOFFER (a DHCPDISCOVER will never have anything
but 0 as "ciaddr.")
2.21. Address Selection
Page 27, third paragraph, section 4.3.1: "Note that, in some network Page 27, third paragraph, section 4.3.1: "Note that, in some network
architectures (e.g., internets with more than on IP subnet assigned architectures (e.g., internets with more than on IP subnet assigned
to a physical network segment), it may be the case that the DHCP to a physical network segment), it may be the case that the DHCP
client should be assigned an address from a different subnet than the client should be assigned an address from a different subnet than the
address recording in 'giaddr.'" We go through great detail in the address recording in 'giaddr.'"
rest of the draft trying to get the use of giaddr clear as it relates
to BOOTP relay agents (RFC 951 and RFC 1542), then this sentence
basically "undoes" this work. Serving multiple IP networks on the
same wire should be either described in detail in its own section
(with caveats) or as a separate informational RFC. Otherwise, the
use of giaddr is unclear.
2.16. Typographical Errors There are two differing view of this sentence:
1. Page 23, second paragraph of section 4.1 - "recieved" -> There is considerable detail in the rest of RFC 2131 trying to
"received" get the use of "giaddr" clear as it relates to BOOTP relay
agents (RFC 951 and RFC 1542), then this sentence basically
"undoes" this work. Serving multiple IP networks on the same
wire should be either described in detail in its own section
(with caveats) or as a separate informational RFC. Otherwise,
the use of "giaddr" is unclear.
2. Page 23, sixth paragraph of section 4.1 - refers to RFC 1533, not Alternatively:
RFC 2132
3. Page 15, Figure 3. Table misformatted. Additional supporting text should be added to RFC 2131 to the
effect that servers having knowledge of network topology MAY
choose to offer an address inconsistent with "giaddr" but
consistent with that topology. Furthermore, the address
offered may differ depending upon the contents of the vendor
class, user class, and even the client identifier. All of
these things are policy matters for the server.
4. Page 18, Figure 4. Table misformatted. 2.22. Use of "secs" field
5. Page 25, eleventh paragraph of section 4.1 - "uicast" -> The "secs" field has not been discussed much: many clients simply
"unicast" leave its value as zero, and few if any servers have used its value
to modify their behavior. These practices seem acceptable. The value
of "secs" SHOULD be the elapsed time (in seconds) since the client
began trying to acquire or extend a lease on an IP address. A
sixteen bit field, its maximum value is 65536. It is conceivable
that due to server or network failure that a client may have been
waiting longer than this.
6. Page 33, Table 4 - missing column for DHCPINFORM RECOMMENDATIONS:
7. Page 38, First paragraph after Table 5. Orphaned sentence: "The o A client MAY choose to leave to ignore the secs field. If so
DHCPREQUEST message contains the same 'xid' as the DHCPOFFER its value MUST be set to zero. If the client chooses to insert
message" No it doesn't. Not only that, but this sentence makes a value, the value SHOULD be time elapsed since the client
no sense in its current location. It should be removed. began negotiating for an IP address. If the client has been
waiting longer than 65536 seconds its value SHOULD be 65536.
The value SHOULD NOT wrap around to zero.
8. Page 39, Last paragraph of 4.4.3 should be moved up as the last 2.23. Use of "htype" and "hlen" fields
paragraph of 4.4.2. When the text for DHCPINFORM was added, the
text describing what a client should do if no DHCPACK is received
was mistakenly pushed below it.
2.17. Use of "secs" field At least one vendor has used chaddr as a place holder for a value
2.18. Use of "htype" and "hlen" fields. that was not in fact a link-layer (hardware) address, while at the
same type using an htype of 1 (meant to be Ethernet) but an hlen of
16 (instead of 6). Many servers will reject a packet with this kind
of inconsistency between the htype and hlen fields.
This is directed at vendors who try to support their certain products Values of htype not equal to zero MUST correspond to the link-level
by creating chaddr's with an htype of 1 (meant to be Ethernet) but an medium to which the DHCP client is attached according to IANA’s
hlen of 16. We should have language to suggest that an htype of zero Assigned Numbers database.
should be used in this case.
2.19. Options in DHCPOFFER and DHCPACK RECOMMENDATIONS:
o The value of hlen MUST be consistent with the length of a link-
level address implied by htype.
o An htype of zero SHOULD be used to mean that chaddr is an
identifier unrelated to a specific link-level medium.
2.24. Use of xid field
This field exists to allow clients to match replies to requests. In
two places RFC 2131 erroneously states that the client should use the
"xid" in the server’s DHCPOFFER as the value in its follow up request
o Table 5 DHCPREQUEST column
o Section 4.4.1 Para 5
In principle the 32 bits of "xid" should be sufficient to make the
chance of collisions almost nil, provided that it is randomly
generated as 2131 suggests in section 4.4.1 paragraph 3. However,
some vendors have admitted to generating "xid" which may not be
sufficiently uniformly distributed.
The randomness requirement on "xid" is not as stringent as would be
required, say, in selecting a cryptographic key. It is quite
permissible that the initial key be predictable given sufficient
knowledge of the client, but clients MUST ensure that these
identifiers are generated in such a way that the chance of collision
with other clients in the DHCP administrative domain is what one
should expect from a truly random number.
Permitting the use of the same "xid" on a re-transmission might
marginally improve the efficiency of the protocol. Server responses
to the first transmission, which arrived after the timeout and
retransmission would be accepted, and might avoid yet another client
timeout.
2.25. Options in DHCPOFFER and DHCPACK
RFC 2131 says that the options delivered in these two cases should RFC 2131 says that the options delivered in these two cases should
not be in conflict. It does not say what "conflict" means in that not be in conflict. It does not say what "conflict" means in that
case. This SHOULD be clarified as follows: case. This SHOULD be clarified.
RECOMMENDATIONS:
o Servers MAY deliver a full configuration in a DHCPOFFER, but o Servers MAY deliver a full configuration in a DHCPOFFER, but
are NOT required to do so. The DHCPOFFER MUST contain an IP are NOT required to do so. The DHCPOFFER MUST contain an IP
address and a lease time, but MAY NOT contain any other address and a lease time, and MAY contain other information.
information. As a client will presumably choose among multiple As a client will presumably choose among multiple offers based
offers based on some criteria, perhaps completeness of on some criteria, perhaps completeness of response, the server
response, the server SHOULD be permitted to return the SHOULD be permitted to return the 'parameter request list'
'parameter request list' including the option code for each including the option code for each option it is prepared to
option it is prepared to deliver in a DHCPACK message. deliver in a DHCPACK message.
o In a DHCPACK message the lease time offered MUST be *at least o In a DHCPACK message, the lease time offered MUST be at least
as long* as that in the DHCPOFFER. The IP address MUST be the as long as that in the DHCPOFFER. The IP address MUST be the
same. same.
o The options delivered in a DHCPACK message MAY NOT be identical o The options delivered in a DHCPACK message MAY differ from
to those in a DHCPOFFER. The motivation for this is that some those in a DHCPOFFER. Some DHCP servers attempt to balance the
DHCP servers attempt to balance the load for other services by load for other services by permuting lists. For instance, a
permuting lists. Thus a server configured with 3 DNS server server configured with 3 DNS server addresses may rotate that
addresses may rotate that list each time a client is serviced. list each time a client is serviced. It is a problem for some
It is a problem for the server to deliver an identical OFFER servers to deliver an identical OFFER and ACK (it implies
and ACK (it implies keeping state.) keeping state.)
2.20. Lease times. o If a particularly long option list must be delivered to the
client, it might not be possible to fit all options in the DHCP
payload of a UDP packet. RFC 2131 appears to permit a long
list of options to be sent partly in the DHCPOFFER message and
partly in the DHCPACK message.
RFC 2131 has some rather woolly language (section 4.3.1) which might 2.26. Lease times.
be interpreted as constraining the duration of a lease that can be
offered based on past history or what the client wants. This SHOULD
be rewritten to make clear that in a DHCPOFFER a server can offer
whatever lease time that local policy finds acceptable, without
regard to what the client requests, or what was offered last time
around.
Also, for RENEWALS, it should be made clear that servers are not RFC 2131 has some language (section 4.3.1) that might be interpreted
as constraining the duration of a lease that can be offered based on
past history or what the client wants. This SHOULD be rewritten to
make clear that in a DHCPOFFER a server can offer whatever lease time
that local policy finds acceptable, without regard to what the client
requests, or what was offered last time around. If a server offers a
longer lease than the client requested, the client can simply enter
the RENEWING or REBINDING states, or send a DHCPRELEASE message
according to its desired [earlier] times.
For RENEWALS, the text should be made clear that servers are not
obligated to extend leases merely because the client wishes an obligated to extend leases merely because the client wishes an
extension (see also general comment below about policy.) extension [see also general comment below about policy.]
There has sometimes been an issue with T1 and T2 times as follows. There has sometimes been an issue with T1 and T2 times as follows.
Let's say that a new lease is offered with a certain T0 (T0 is lease Let's say that a new lease is offered with a certain T0 (T0 is lease
duration) and T1 = T0/2. Then, when T1 expired, the client attempts duration) and T1 = T0/2. Then, when T1 expired, the client attempts
a renewal. The server in question, for whatever reason, does not a renewal. The server in question, for whatever reason, does not
want to extend the lease, but is willing to confirm the residual time want to extend the lease, but is willing to confirm the residual time
(=T0/2). If it also returns T1 in the options, it should ensure that (T0/2). If it also returns T1 in the options, it should ensure that
T1 is adjusted from the original value of for otherwise the new ACK T1 is adjusted from the original value else the new ACK will have T0
will have T0 and T1 identical. and T1 identical.
2.21. Option ordering 2.27. Miscellaneous
A number of clients exist that require that the DHCP message type be There are many SHOULDs and SHOULD NOTs that should perhaps be
the first option (after the magic cookie). We SHOULD restate that converted into MUSTs or MUST NOTs. Here is a summary:
the client MUST NOT make any such assumption. The only known
ordering constraint concerns option 82, which is last. CMTS vendors
want it to be last, but suppose someone else wants their pet option
to be last also -- how would we resolve this conflict?
2.22. Packet size 1. Page 16, item 4, section 3.1 "The server SHOULD NOT check the
offered network address at this point." (MUST NOT)
In general clients will not be able to synthesize a fragmented UDP 2. Page 16, item 5, section 3.1 "The client SHOULD perform a
packet before the IP stack is properly configured. That is the final check on the parameters..." (MUST)
underlying logic behind the BOOTP packet size limitation. But in a
DHCPINFORM, or any other transfer when the client is fully
configured, there is no such limitation. There probably should be
explicit text to allow larger packets (presumably up to the maximum
PDU size) for later stages of the protocol.
2.23. Policy issues 3. Page 17, item 5, section 3.1 "The client SHOULD wait a minimum
of ten seconds..." (MUST)
There has in general been a certain amount of overlap in DHCP between 4. Page 18, item 2, section 3.2 "Servers SHOULD NOT check that
protocol and policy. The matters include lease times, whether the client's network address is already in use..." (MUST NOT)
servers are willing to extend leases, timeouts, and re-transmission.
We SHOULD clarify what is dictated by the protocol and what is a 5. Page 19, item 2, second paragraph, section 3.2 "...servers
policy decision at a given site. SHOULD respond with a DHCPNAK message to the client" (MUST).
The following sentences are rather dubious in this paragraph
as well.
3. Suggested Changes to RFC 2131 6. Page 21, first paragraph, section 3.4 "The servers SHOULD
unicast the DHCPACK replay to the address given in the
'ciaddr' field of the DHCPINFORM message" (MUST)
This section contains specific wording changes to RFC 2131, based on 7. Page 22, last paragraph, section 3.5 "If a server receives a
the identified issues. DHCP request message with an invalid 'requested IP address',
the server SHOULD respond to the client with a DHCPNAK
message..." (MUST)
4. Intellectual Property RECOMMENDATIONS:
o The WORKING GROUP should review the MAY/SHOULD/MUST (NOT)s in
RFC 2131. Those SHOULDs that remain should list the valid
exceptions (some do; most don't).
3. Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. standards-related documentation can be found in BCP-11.
skipping to change at page 17, line 28 skipping to change at page 26, line 36
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF Secretariat. specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to practice rights that may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
5. Notes 4. Notes
This section will be removed when this memo goes to Working Group This section will be removed when this memo goes to Working Group
Last Call. Last Call.
5.1. Issues 4.1. Issues
Not all of these issues have been resolved. Some may become items Open, unresolved issues about RFC 2131 include:
for future study, while some will probably be dropped.
5.2. Changes from Prior Drafts 1. What is the correct use of client identifier in DHCPOFFER and
DHCPACK messages?
The "-00" revision is the initial version of this memo, submitted to 2. Are there any effective alternatives to ICMP ECHO and ARP for
address-in-use detection?
3. What is the definition of a Fully Qualified Domain Name?
4. Should DHCPINFORM messages be allowed from client proxies?
5. Should client proxies, in general, be allowed, and how does a
client proxy know the IP address of a DHCP server?
6. Should a DHCP server send only options requested by a client,
or should a server send all options for which it is configured
with a value?
7. Should required usage of "xid" and "client identifier" be
changed to support server verification of DHCPRELEASE
messages?
8. What is the correct statement about selecting an IP address to
offer a client when the offered address is on a different
subnet than the client's "giaddr?"
9. Should a new flags bit to signify "more options data
available" be added?
10. Do we need a new "Maximum Relay MTU Size" option to ensure
that all reply packets sent by a server will pass without
fragmenting or dropping packets?
11. Would it help to set a sort of "more to come" option,
indicating that more options will follow in a consecutive
DHCPACK, where the subsequent DHCPACKs would have a
"additional information" option indicating that the message
contains only new options data similar to a DHCPACK in
response to a DHCPINFORM message?
12. Are unicast DHCPDISCOVER messages permitted? What are the
requirements for specific message fields and options in this
case?
13. What level of consistency is required among responses from
multiple servers?
4.2. Changes from Prior Drafts
The "-01" revision contains substantial changes following a detailed
review of DHC Working Group mailing list discussions on RFC 2131
clarification issues, consideration of several directed questions,
and comments received by the authors. Changes include:
o Reorganization of the document to group all typographical
errors together, separate from protocol or policy issues.
o Elimination of "Interaction with DNS" and "Client and Server
Administration" sections because the authors saw no clear
resolution to the topics.
o Creation of an issues list in section 4.1.
The "-00" revision was the initial version of this memo, submitted to
the Internet-Drafts editor on 23 February 2003. the Internet-Drafts editor on 23 February 2003.
6. Acknowledgements 5. Acknowledgements
This document is the result of work undertaken the by DHCP working This document is the result of work undertaken the by DHCP working
group. The editors would like to include a number of contributors to group. The editors would like to include a number of contributors to
this effort including Mike Carney of Sun Microsystems and Steve this effort including Mike Carney of Sun Microsystems, Steve Tulloh
Tulloh of Shadow Support. of Shadow Support, Bernie Volz, Ted Lemon of Nominum, Simon Vogl,
Edward Mascarenhas of SGI, Andre Kostur of Incognito, Bud Millwood of
Weird Solutions, Patrick Guélat of ImproWare Network Services, and
Swamy Narasimha of Nokia.
7. IANA Considerations 6. IANA Considerations
This memo contains no values requiring IANA attention. This memo contains no values requiring IANA attention.
8. Security Considerations 7. Security Considerations
(To be defined when suggested text changes for RFC 2131 are (To be defined when suggested text changes for RFC 2131 are
completed.) completed.)
A separate Internet-Draft is being created to provide a complete A separate Internet-Draft is being created to provide a complete
threat analysis of RFCs 2131 and 3118. threat analysis of RFCs 2131 and 3118.
9. References 8. References
[STD 2] Reynolds, J., and J. Postel, "Assigned Numbers," STD 2, RFC
1700, July 1992.
[RFC951] Croft, W., and J. Gilmore, "Bootstrap Protocol," RFC 951, [RFC951] Croft, W., and Gilmore, J., "Bootstrap Protocol," RFC 951,
September 1985. September 1985.
[RFC1123] R. Braden, "Requirements for Internet Hosts -- Application [RFC1123] R. Braden, "Requirements for Internet Hosts -- Application
and Support," RFC 1123, October 1989. and Support," October 1989.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol," RFC [RFC1542] W. Wimer, "Clarifications and Extensions for the Bootstrap
2131, March 1997. Protocol" RFC 1542, October 1993
[RFC2132] Alexander, S. and Droms, R., "DHCP Options and BOOTP [RFC2131] Droms, R., "Dynamic Host Configuration Protocol," March 1997.
Vendor Extensions," RFC 2132, March 1997.
[RFC3203 , Yves T'Joens and Christian Hublet, Peter De Schrijver, [RFC2132] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor
"The DHCP Reconfigure Extension," July 2001. Extensions," March 1997.
<draft-ietf-dhc-leasequery-04.txt> Rich Woundy and Kim Kinnear, "DHCP [RFC3203] T'Joens, Y., Hublet, C., and De Schrijver, P., "The DHCP
Lease Query," November 2002. Reconfigure Extension," July 2001.
10. Editors' Addresses <draft-ietf-dhc-leasequery-05.txt> Woundy, R., and Kinnear, K., "DHCP
Lease Query," March 2003.
<draft-ietf-dhc-fqdn-option-05.txt>, Stapp, M., and Rekhter, Y., "The
DHCP Client FQDN Option," November 2002.
<draft-swamy-dhc-client-id-00.txt>, Narasimha, S., "Client Identifier
option in server replies," July 2003.
9. Editors' Addresses
Richard Barr Hibbs Richard Barr Hibbs
952 Sanchez Street 952 Sanchez Street
San Francisco, California 94114-3362 San Francisco, California 94114-3362
USA USA
Phone: +1-(415)-648-3920 Phone: +1-(415)-648-3920
Fax: +1-(415)-648-9017
Email: rbhibbs@pacbell.net Email: rbhibbs@pacbell.net
11. Full Copyright Statement
Rob Stevens
308 Arthur Ave
Aptos California 95003-5202
USA
Phone:+1-(831)-688-9722
E-mail: robs@cruzio.com
10. Full Copyright Statement
Copyright (C) The Internet Society, 2003. All Rights Reserved. Copyright (C) The Internet Society, 2003. All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.However, this included on all such copies and derivative works.However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
skipping to change at line 859 skipping to change at page 31, line 4
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
APPENDIX A: List of Vendors
------------------------------------------------------------------------
|Vendor |Product |E-mail Address |
------------------------------------------------------------------------
|2Wire |HomePortal |support@2Wire.com |
|3Com |Home Gateway | |
|3e Technologies | | |
| International |Magnum |info@3eti.com |
|3K Group |Turbo Cell |info@3kgroup.com |
|Accelerated | | |
| Technology |Nucleus |support@acceleratedtechnology.com|
|ActionTec | | |
| Electronics | | |
|ADTRAN |Netvanta 2100 | |
|Agere Systems |Orinoco RG-1000 | |
|Apple Computer | |cheshire@apple.com |
|Appliansys |DNSBox 300 | |
|Argus | | |
| Technologies |EtherAccess 2000 |info@arguscorp.com |
|Ateonix Networks |NASAS-2040 |tech@ateonix.com |
|Avaya |WAP | |
|Barbed Wire | | |
| Technologies | | |
|Broadband | | |
| Gateways |Evolo | |
|Caldera/SCO |Open Linux | |
| | Eserver |info@sco.com |
|Cayman Systems | | |
|CheckPoint | | |
| Software | | |
|Cisco Systems |Network | |
| |Registrar |kkinnear@cisco.com |
|Cisco Systems |AIR-AP3000 | |
|Clavister | | |
|CLinux | | |
|Compaq |Connection Point | |
|vCoNet | | |
| Communications |XpressIP 8550 | |
|Cygsoft | |support@cygsoft.com |
|D-Link |DI-700 | |
|Efficient | | |
| Networks | | |
|Esoft |Redphish | |
|Filanet |Interjak | |
------------------------------------------------------------------------
------------------------------------------------------------------------
|Vendor |Product |E-mail Address |
------------------------------------------------------------------------
|FTP Software | | |
|Helios |PCShare | |
|Incognito | | |
| Software |Address Commander|support@incognito.com |
|InfoBlox |DNS One |support@infoblox.com |
|Internet Software | | |
| Consortium |DHCPD |Ted.Lemon@nominum.com |
|AttachNet |Internet Pro SOHO|support@attachnet.com |
|InterNiche |Portable DHCP | |
| Techologies |Server |support@iniche.com |
|JH Software |Simple DNSPlus |support@jhsoft.com |
|Leviton |Internet Gateway | |
|Lightning |MultiCOM | |
|LinkSys |WAP-11 | |
|Lucent | | |
| Technologies |VitalQIP | |
|Matrox Electronic | | |
| Systems |iSwitch |networks.techsupport@matrox.com |
|UMax Technologies |UGate-3300 |support@umaxcare.com |
|MDL Corporation |FileZerver NAS |help@mdlcorp.com |
|Microsoft | | |
| Corporation |Windows Server | |
|MobiWave |Spyroz |support@mobiwave.com |
|Multi-Tech | | |
| Systems |RouteFinder VPN |support@multitech.com |
|N3K |VitalQIP |info@n3k.co.uk |
|Net Integration | | |
| Technologies |Net Integrator |support@net-itech.com |
|Netgear |RP334 | |
|NetWinder | | |
|Network | | |
| TeleSystems | |suppport@shadowsupport.com |
|Nokia |IP30 |internetapac@nokia.com |
|Nominum, Inc. |DCS |Eric.Luce@nominum.com |
|Nortel |Net ID |gww@nortelnetworks.com |
|Novell | | |
|On Technology |IP Track |support@on.com |
|Panasonic |KX-HGW200 | |
|Paul Smith | | |
| Computer Svcs |vDHCP |support@pscs.co.uk |
|PGP |PGP-5 | |
|Phoenix | | |
| Technologies |ViewPoint | |
------------------------------------------------------------------------
------------------------------------------------------------------------
|Vendor |Product |E-mail Address |
------------------------------------------------------------------------
|Powerwallz |ProShield | |
|PresiNET Systems | | |
|Proxim |Skyline | |
|Rapidstream |Rapidstream 500 | |
|Siemens | | |
|SnapGear | |support@snapgear.com |
|Sonic Wall |SOHO | |
|Sun Microsystems | | |
|Symantec |VPN-100 | |
|Teneo |NetScreen | |
|Threshold | | |
| Networks |Edge | |
|Trellis Network | | |
| Services |DNS ONE | |
|Weird Solutions |DHCP Turbo | |
------------------------------------------------------------------------
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/