draft-ietf-dhc-implementation-01.txt   draft-ietf-dhc-implementation-02.txt 
Network Working Group Barr Hibbs Network Working Group R. Hibbs
INTERNET-DRAFT (no affiliation) INTERNET-DRAFT Richard Barr Hibbs, P.E.
Category: Informational Rob Stevens Category: Informational R. Stevens
(no affiliation) Expires: December 17, 2006 (no affiliation)
October 2003 June 15, 2006
Implementation Issues with RFC 2131, "Dynamic Host Configuration Implementation Issues with RFC 2131, "Dynamic Host Configuration
Protocol" Protocol (DHCPv4)"
<draft-ietf-dhc-implementation-01.txt> <draft-ietf-dhc-implementation-02.txt>
Saved Friday, October 24, 2003, 8:08:15 AM8:05:56 AM PT8:08:15 AM Saved: Tuesday, June 15, 2006, 13:27:17
Status of this Memo Intellectual Property Rights
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, each author represents that any
all provisions of Section 10 of RFC2026. applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Status of this Memo
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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other documents
time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as
material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html. http://www.ietf.org/1id-abstracts.html.
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.
Comments are solicited and should be addressed to the working
group's mailing list at dhcwg@ietf.org and/or the author(s).
Copyright Notice Copyright Notice
Copyright (C) 2003, The Internet Society. All Rights Reserved. Copyright (C) The Internet Society (2006).
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 implementers, 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...................................................3 1 Introduction...............................................4
2. Issues with RFC 2131...........................................3 2 Terminology................................................4
2.1. Outdated RFC Boilerplate...................................3 3 Applicability..............................................4
2.2. Organization and Typography................................4 4 Issues with RFC 2131.......................................5
2.2.1. Outdated References...................................4 4.1 Outdated RFC Boilerplate...............................5
2.2.2. Typographical Errors..................................4 4.2 Organization and Typography............................5
2.2.3. Omissions.............................................5 4.2.1 Outdated References.............................5
2.2.4. Tables................................................5 4.2.2 Typographical Errors............................5
2.2.5. Inconsistencies.......................................5 4.2.3 Omissions.......................................6
2.3. Policy issues..............................................6 4.2.4 Tables..........................................6
2.4. The Client Hardware Address, "chaddr"......................7 4.2.5 Inconsistencies.................................7
2.5. The DHCP Client Identifier.................................7 4.3 Policy Issues..........................................7
2.5.1. Uniqueness............................................7 4.4 The Client Hardware Address, "chaddr"..................8
2.5.2. Prohibition in DHCPOFFER and DHCPACK..................8 4.5 The DHCP Client Identifier.............................8
2.6. Address-in-Use Detection...................................9 4.5.1 Uniqueness......................................8
2.6.1. Client-side ARP.......................................9 4.5.2 Prohibition in DHCPOFFER and DHCPACK............9
2.6.2. Server side PING......................................9 4.6 Duplicate Address Detection............................9
2.6.3. Other Mechanisms.....................................10 4.6.1 Client-side ARP................................10
2.7. DHCP Relay Agents.........................................10 4.6.2 Server side PING...............................10
2.7.1. Relay Agent Source Addresses.........................10 4.6.3 Other Mechanisms...............................10
2.7.2. Relay Agent Port Usage...............................10 4.7 DHCP Relay Agents.....................................11
2.8. Host Name, Domain Name, and FQDNs.........................11 4.7.1 Relay Agent Source Addresses...................11
2.9. Overloading of DHCPREQUEST................................11 4.7.2 Relay Agent Port Usage.........................11
2.10. DHCPINFORM...............................................11 4.8 Host Name, Domain Name, and FQDNs.....................11
2.11. Unicast of DHCPDISCOVER..................................12 4.9 Overloading of DHCPREQUEST............................11
2.12. DHCPRELEASE..............................................13 4.10 DHCPINFORM...........................................12
2.13. Client state diagram.....................................13 4.11 Unicast of DHCPDISCOVER..............................12
2.14. Options..................................................13 4.12 DHCPRELEASE..........................................13
2.14.1. Which Options to Return?............................14 4.13 Client State Diagram.................................13
2.14.2. Multiple Instances of Options.......................16 4.14 Options..............................................14
2.14.3. Option Ordering.....................................16 4.14.1 Which Options to Return?......................14
2.14.4. Options 66 and 67...................................16 4.14.2 Multiple Instances of Options.................16
2.15. Vendor Classes...........................................17 4.14.3 Option Ordering...............................16
2.15.1. Character set.......................................17 4.14.4 Options 66 and 67.............................16
2.15.2. Form of the name space..............................17 4.15 Vendor Classes.......................................16
2.15.3. Relationship to vendor options......................17 4.15.1 Character Set.................................17
2.15.4. Multiplicity........................................18 4.15.2 Form of the Name Space........................17
2.16. Client/Server Retransmission.............................19 4.15.3 Relationship to Vendor Options................17
2.17. Transmission of DHCPNAKs.................................19 4.15.4 Multiplicity..................................17
2.18. Use of ciaddr............................................20 4.16 Client/Server Retransmission.........................18
2.19. Size of a BOOTP/DHCP frame...............................20 4.17 Transmission of DHCPNAKs.............................18
2.19.1. Minimum size........................................20 4.18 Use of ciaddr........................................19
2.19.2. Maximum Size, MTU, and Message Size option..........20 4.19 Size of a BOOTP/DHCP Frame...........................19
2.20. Use of giaddr............................................22 4.19.1 Minimum Packet Size...........................19
2.21. Address Selection........................................22 4.19.2 Maximum Size, MTU, and Message Size Option....19
2.22. Use of "secs" field......................................22 4.20 Use of giaddr........................................20
2.23. Use of "htype" and "hlen" fields.........................23 4.21 Address Selection....................................20
2.24. Use of xid field.........................................23 4.22 Use of "secs" Field..................................21
2.25. Options in DHCPOFFER and DHCPACK.........................24 4.23 Use of "htype" and "hlen" Fields.....................21
2.26. Lease times..............................................24 4.24 Use of "xid" Field...................................22
2.27. Miscellaneous............................................25 4.25 Options in DHCPOFFER and DHCPACK.....................22
3. Intellectual Property.........................................26 4.26 Lease Times..........................................23
4. Notes.........................................................26 4.27 Miscellaneous........................................23
4.1. Issues....................................................26 5 Proposed Replacements for RFC 2131 Figures and Tables.....25
4.2. Changes from Prior Drafts.................................27 5.1 Figures...............................................25
5. Acknowledgements..............................................28 5.1.1 Figure 1: Format of a DHCP message..............25
6. IANA Considerations...........................................28 5.1.2 Figure 2: Format of the 'flags' Field...........25
7. Security Considerations.......................................28 5.1.3 Figure 3: Timeline Diagram--Allocating a New
8. References....................................................28 Address...............................26
9. Editors' Addresses............................................29 5.1.4 Figure 4: Timeline Diagram--Reusing an Address..27
10. Full Copyright Statement.....................................29 5.1.4 Figure 5: State-Transition Diagram for DHCP
Clients...............................28
1. Introduction 5.2 Tables................................................29
5.2.1 Table 1: Description of fields in a DHCP
Message................................29
5.2.2 Table 2: DHCP Messages..........................30
5.2.3 Table 3: Fields Used by DHCP Servers............31
5.2.4 Table 4: Options Used by DHCP servers...........32
5.2.5 Table 5: Client Messages from Different States..32
5.2.6 Table 6: Fields Used by DHCP Clients............33
5.2.7 Table 7: Options Used by DHCP Clients...........34
5.2.8 Table 8: Host Configuration Parameters--IP
Layer..................................35
5.2.9 Table 9: Host Configuration Parameters--Link
Layer..................................36
5.2.10 Table 10: Host Configuration Parameters--TCP...36
6 Contributors..............................................37
7 IANA Considerations.......................................37
8 Security Considerations...................................37
9 References................................................37
9.1 Normative References..................................37
9.2 Informative References................................37
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
discussion of RFC 2131 before it is published as an Internet for 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 implementers that they participation and by direct request to all implementers that they
could identify could identify.
There are four possible outcomes of this work:
1. The RFC Editor could publish the agreed clarifications as a note
("Errata") linked to RFC 2131 in the RFC Editor's document
database. This almost insures that only the most conscientious
reviewer would ever read and apply the changes.
2. The proposed changes could be reworded and reformatted into a
new standards-track document, "RFC 2131 Errata." This has the
advantage of not disturbing RFC 2131 as it advances to Internet
Standard, but leaves the reader with multiple documents to read
for a full understanding of DHCP.
3. Proposed changes could be applied to RFC 2131 without assigning
a new document number, in effect becoming "RFC 2131-bis." This
course may not be open as the changes would still require IESG
approval, and it is unlikely that any changes other than
editorial or clarification would be permitted.
4. A new standards-track document would be created, obsoleting RFC
2131 (and possibly other documents as well.) This would
probably not require any more effort than outcome (2), but
conceivably take years to advance the document to full Standard.
The editors have not specifically addressed RFC 2132, although we
believe that it ought to be updated in conjunction with any updates
to RFC 2131. We propose that an update of the DHCP Options Document
should be separately considered in a second memo.
2 Terminology
The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT,"
"SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this
document are to be interpreted as described in document [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Issues with RFC 2131 3 Applicability
The intent of the work item that resulted in this memo was to
identify and clarify issues with RFC 2131 that made implementation
difficult, behavior ambiguous, or conflicted with other RFCs. The
authors imagined that RFC 2132 could also be updated as a result,
without expecting that additional RFCs might be affected.
As our investigation proceeded, it became evident that
clarifications might very well extend to other RFCs. The exact
scope of this effort will require additional discussion by the DHC
Working Group.
4 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 editors. it is based on reported problems and those known to the editors.
2.1. Outdated RFC Boilerplate 4.1 Outdated RFC Boilerplate
RECOMMENDATIONS:
1. "Status of This Memo" should be replaced with standardized 1. "Status of This Memo" should be replaced with standardized
language for RFCs as described in "Guidelines to Authors of language for RFCs as described in "Guidelines to Authors of
Internet-Drafts," dated September 5, 2002. Internet-Drafts," dated March 25, 2005.
2. Section 1.4, "Requirements," should be replaced with standardized 2. Section 1.4, "Requirements," should be replaced with
language referring to RFC 2119 regarding the definition and standardized language referring to RFC 2119 regarding the
interpretation of specific key words. definition and interpretation of specific key words.
3. References should be separated into normative and non-normative 3. References should be separated into normative and non-normative
sections. sections.
2.2. Organization and Typography 4.2 Organization and Typography
2.2.1. Outdated References 4.2.1 Outdated References
1. References to the "Assigned Numbers" RFC [STD 2, RFC 1700] RECOMMENDATIONS:
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 O References to the "Assigned Numbers" RFC [STD 2, RFC 1700]
1534 should be integrated with the text of the memo, and RFC should be changed to the "Assigned Numbers" database maintained
1534 deprecated. by IANA. References are found in Tables 3 and 5, and in the
"References" section.
2.2.2. Typographical Errors O References to the "Interaction between DHCP and BOOTP" RFC 1534
should be integrated with the text of the memo, and RFC 1534
deprecated.
1. Page 23, third paragraph of section 4.1 -- "recieved" should 4.2.2 Typographical Errors
be "received."
2. Page 23, sixth paragraph of section 4.1 -- refers to RFC 1533, RECOMMENDATIONS:
O Page 23, third paragraph of section 4.1 -- "received" should be
"received."
O Page 23, sixth paragraph of section 4.1 -- refers to RFC 1533,
not RFC 2132. not RFC 2132.
3. Page 15, Figure 3. Table misformatted. O Page 15, Figure 3. Table is misformatted.
4. Page 18, Figure 4. Table misformatted. O Page 18, Figure 4. Table is misformatted.
5. Page 25, ninth paragraph of section 4.1 -- "uicast" should be O Page 25, ninth paragraph of section 4.1 -- "uicast" should be
"unicast." "unicast."
O Page 38, first paragraph after Table 5. Orphaned sentence:
6. Page 38, first paragraph after Table 5. Orphaned sentence:
"The DHCPREQUEST message contains the same 'xid' as the "The DHCPREQUEST message contains the same 'xid' as the
DHCPOFFER message." No it doesn't. Not only that, but this DHCPOFFER message." No, it does not. Not only that, but this
sentence makes no sense in its current location. It should be sentence makes no sense in its current location. It should be
removed. removed.
7. Page 39, Last paragraph of 4.4.3 should be moved up as the O Page 39, Last paragraph of 4.4.3 should be moved up as the last
last paragraph of 4.4.2. When the text for DHCPINFORM was paragraph of 4.4.2. When the text for DHCPINFORM was added, the
added, the text describing what a client should do if no text describing what a client should do if no DHCPACK is
DHCPACK is received was mistakenly pushed below it. received was mistakenly pushed below it.
8. Apostrophes (') are used as single quotation marks, but O Apostrophes (') are used as single quotation marks, but outside
outside of an enclosing quotation (") throughout the document. of an enclosing quotation (") throughout the document.
9. Page 30, section 4.3.1, second from last bullet: "...client’s O Page 30, section 4.3.1, second from last bullet: "...client’s
vendor class identifier and client's classes identified in the vendor class identifier and client's classes identified in the
server". This text makes no sense and should be deleted. server". This text makes no sense and should be deleted.
10. Inconsistent style regarding placement of periods (.), commas O Inconsistent style regarding placement of periods (.), commas
(,) and semi-colons (;) with respect to quotation marks (,) and semi-colons (;) with respect to quotation marks
throughout the document. throughout the document.
11. Quotation marks (single and double) are overused through the O Quotation marks (single and double) are overused through the
document. document.
2.2.3. Omissions 4.2.3 Omissions
In several places there is missing or incomplete information, In several places there is missing or incomplete information,
including: including:
1. Table 3, pages 27 and 28. . The "options" entry for "DHCPNAK" O Table 3, pages 27 and 28. The "options" entry for "DHCPNAK" in
in the "fields" portion of the table is missing. All entries the "fields" portion of the table is missing. All entries in
in this line should refer to the subsequent "options" table. this line should refer to the subsequent "options" table.
Suggested replacements for Table 3 are shown in sections 5.2.3
and 5.2.4.
2. Page 33, Table 4, and Page 35, Figure 5, do not include the O Page 33, Table 4, and Page 35, Figure 5, do not include the
"DHCPINFORM" message. "DHCPINFORM" message. Suggested replacement for Table 4 is
shown in section 5.2.5.
3. Table 5, pages 37 and 38. The "options" entry for O Table 5, pages 37 and 38. The "options" entry for "DHCPDECLINE,
"DHCPDECLINE, DHCPRELEASE" is missing. All entries in this DHCPRELEASE" is missing. Suggested replacement for Table 5 is
line should refer to the subsequent table. shown in sections 5.2.6 and 5.2.7.
2.2.4. Tables 4.2.4 Tables
1. Table 3 (pages 28 and 29) and Table 5 (pages 37 and 38) should RECOMMENDATIONS:
be separated into two tables each for readability.
2. Table 4 should be reorganized to show all messages (except O Table 3 (pages 28 and 29) and Table 5 (pages 37 and 38) should
DHCPRELEASE) that are sent from each client state. be separated into two tables each for readability. Suggested
replacements for Table 3 are shown in sections 5.2.3 and 5.2.4,
and for Table 5 are show in sections 5.2.6 and 5.2.7.
3. The "Host Configuration Parameters" table now in an appendix O Table 4 should be reorganized to show all messages (except
DHCPRELEASE) that are sent from each client state. Suggested
replacement for Table 4 is shown in section 5.2.5.
O The "Host Configuration Parameters" table now in an appendix
should be omitted and described in a revised "DHCP Options" should be omitted and described in a revised "DHCP Options"
document (RFC 2132). document (RFC 2132). Suggested replacement for that table is
shown in sections 5.2.8-5.2.10.
2.2.5. Inconsistencies 4.2.5 Inconsistencies
1. Page 1, Abstract, "TCPIP" should be "TCP/IP" – as it is in the RECOMMENDATIONS:
O Page 1, Abstract, "TCPIP" should be "TCP/IP" – as it is in the
rest of the document. rest of the document.
2. Page 10, Table 3, description of 'htype' and 'hlen' fields does O Page 10, Table 3, description of 'htype' and 'hlen' fields does
not capitalize "Ethernet." not capitalize "Ethernet."
3. Lack of consistency when describing "IP broadcast." Sometimes it
is "0xffffffff IP broadcast," elsewhere "limited broadcast," or O Lack of consistency when describing "IP broadcast." Sometimes
"broadcast." Suggest using the "255.255.255.255 IP broadcast it is "0xffffffff IP broadcast," elsewhere "limited broadcast,"
address" form, as that is the most specific. Specific references or "broadcast." Suggest using the "255.255.255.255 IP broadcast
address" form, as that is the most specific. References
include: include:
Page 19, third paragraph of section 3.2, List item #2 a. Page 19, third paragraph of section 3.2, List item #2.
Page 23, fifth paragraph of section 4.1 (twice) b. Page 23, fifth paragraph of section 4.1 (twice).
Page 25, thirteenth paragraph of section 4.1 (twice) c. Page 25, thirteenth paragraph of section 4.1 (twice).
Page 32, section 4.3.2, third bullet item d. Page 32, section 4.3.2, third bullet item.
Page 32, section 4.3.2, fifth bullet item e. Page 32, section 4.3.2, fifth bullet item.
Page 36, second paragraph of section 4.4.1 f. Page 36, second paragraph of section 4.4.1.
Page 39, last paragraph of section 4.4.1 g. Page 39, last paragraph of section 4.4.1.
Page 39, second paragraph of section 4.4.3 h. Page 39, second paragraph of section 4.4.3.
4. Lack of consistency when referring to the BROADCAST (B) flag: it 4. Lack of consistency when referring to the BROADCAST (B) flag:
is also referred to as the "broadcast bit." it is also referred to as the "broadcast bit."
5. Table 3, "Fields and options used by DHCP servers," is 5. Table 3, "Fields and options used by DHCP servers," is
problematic. It indicates that we MUST fill in both the "Server problematic. It indicates that we MUST fill in both the "Server
Identifier" (and siaddr) in our DHCPACK (and DHCPNAK) response. Identifier" (and siaddr) in our DHCPACK (and DHCPNAK) response.
That's a change from the same table in RFC 1541 that specifies That is a change from RFC 1541 (which specifies a "MAY" and
this is a "MAY" (and which is consistent with RFC 2132 section which is consistent with RFC 2132 section 9.7 and identical to
9.7 and identical RFC 1533 section 9.5 wording). RFC 1533 section 9.5 wording).
2.3. Policy issues 4.3 Policy Issues
There has in general been a certain amount of overlap in DHCP between There has in general been a certain amount of overlap in DHCP
protocol and policy. The matters include lease times, whether between protocol and policy. The matters include lease times,
servers are willing to extend leases, timeouts, and re-transmission. whether servers are willing to extend leases, timeouts, and re-
transmission.
We SHOULD clarify what is dictated by the protocol and what is a We SHOULD clarify what is dictated by the protocol and what is a
policy decision at a given site. policy decision at a given site.
The DHC Working Group philosophy ought to be to constrain client The DHC Working Group philosophy ought to be to constrain client
behavior more closely than server behavior. DHCP interactions are behavior more closely than server behavior. DHCP interactions are
initiated (and continued) by clients: clients outnumber servers by initiated (and continued) by clients: clients outnumber servers by
many tens of thousands to one; client implementers cannot be quite many tens of thousands to one; client implementers cannot be quite
certain of all the environments in which their client may ultimately certain of all the environments in which their client may ultimately
appear, whereas server implementations may be designed for very appear, whereas server implementations may be designed for very
specific environments. Policy is likely to be a matter of specific environments. Policy is likely to be a matter of
centralized control, whereas clients are not likely to enjoy a centralized control, whereas clients are not likely to enjoy a
sufficient status to impose policy on servers. sufficient status to impose policy on servers.
The previous paragraph implies that the WORKING GROUP should tighten The previous paragraph implies that the WORKING GROUP should tighten
the protocol with respect to such issues as retries and backoffs, the protocol with respect to such issues as retries and backoffs,
whereas servers should not be constrained on issues such as how to whereas servers should not be constrained on issues such as how to
uniquely identify clients, whether to offer or extend leases etc. uniquely identify clients, whether to offer or extend leases etc.
2.4. The Client Hardware Address, "chaddr" 4.4 The Client Hardware Address, "chaddr"
The value of "chaddr" MUST NOT change from DHCPDISCOVER to The value of "chaddr" MUST NOT change from DHCPDISCOVER to
DHCPREQUEST, although the wording in table 3 makes this point DHCPREQUEST, although the wording in Table 3 makes this point
unclear. unclear.
Further, the length of "chaddr" SHOULD be exactly specified by Further, the length of "chaddr" SHOULD be exactly specified by
"hlen," which SHOULD match the address length for "htype." "hlen," which SHOULD match the address length for "htype."
2.5. The DHCP Client Identifier RECOMMENDATIONS:
2.5.1. Uniqueness O Update Table 3.
4.5 The DHCP Client Identifier
4.5.1 Uniqueness
DHCP servers must uniquely identify DHCP clients requesting services DHCP servers must uniquely identify DHCP clients requesting services
in order to correctly configure the client. RFC 2131 provides two in order to configure the client correctly. DHCP does not require
specific methods for identifying a client: (1) the client identifier global uniqueness for client identifiers, only uniqueness within the
(DHCP Option 61) [RFC2132], and (2) the "chaddr" field of the scope of [sub-] networks reachable by DHCP packets in any
BOOTPREQUEST packet. installation. This is sometimes called "subnet uniqueness."
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 that same 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 Section 4.2 goes on to state that subnet uniqueness is a
uniqueness is a requirement for an identifier, but points out that requirement for an identifier, but points out that "chaddr" may not
"chaddr" may not satisfy that requirement. Two alternatives for a satisfy that requirement. Two alternatives for a unique identifier
unique identifier were given: an unspecified manufacturer's serial were given: an unspecified manufacturer's serial number or a DNS
number or a DNS name. 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 implementers, 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."
RECOMMENDATIONS: RECOMMENDATIONS:
o RFC 2131 SHOULD have made required the "client identifier" 1. RFC 2131 SHOULD have made required the "client identifier"
either to be globally unique or, to be unique within an either to be globally unique or, to be unique within an
"administrative domain," and, in the latter case, defined "administrative domain," and, in the latter case, defined
"administrative domain." "administrative domain."
o RFC 2131 SHOULD NOT have suggested the use of DNS names for the 2. 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.
o RFC 2132 SHOULD NOT have suggested using the "htype" and 3. RFC 2132 SHOULD NOT have suggested using the "htype" and
"chaddr" fields as a type-value pair because of the warning in "chaddr" fields as a type-value pair because of the warning in
RFC 2131 Section 4.2 about potential problems using "chaddr" RFC 2131 Section 4.2 about potential problems using "chaddr" for
for the purpose. the purpose.
o RFC 2132 SHOULD NOT have used the word "SHOULD" when suggesting 4. RFC 2132 SHOULD NOT have used the word "SHOULD" when suggesting
the use of type-value pairs for "client identifier" with a type the use of type-value pairs for "client identifier" with a type
of 0 (zero) when the value is anything other than a hardware of 0 (zero) when the value is anything other than a hardware
address. address.
2.5.2. Prohibition in DHCPOFFER and DHCPACK 4.5.2 Prohibition in DHCPOFFER and DHCPACK
Table 3, in the "options" section, specifies that the server MUST NOT Table 3, in the "options" section, specifies that the server MUST
send the "client identifier" in the DHCPOFFER or DHCPACK messages, NOT send the "client identifier" in the DHCPOFFER or DHCPACK
but MAY send it in a DHCPNAK message. There is no very good reason messages, but MAY send it in a DHCPNAK message. There is no good
why DHCPNAK should be treated differently, and there is considerable reason why DHCPNAK should be treated differently, and there is
utility in returning the client identifier, as it allows clients considerable utility in returning the client identifier, as it
further corroboration, beyond that implied by matching "xid’s" (see allows clients further corroboration, beyond that implied by
2.23), that they are the intended recipient. matching "xid’s" (see 2.23), that they are the intended recipient.
RECOMMENDATIONS: RECOMMENDATION:
Change the text in Table 3, for all three message types, to read: Change the text in Table 3, for all three message-types, to read,
"MAY -- if included, MUST BE the client identifier sent by the "MAY -- if included, MUST BE the client identifier sent by the
client". client." Suggested replacement for Table 3 are shown in sections
5.2.3 and 5.2.4.
2.6. Address-in-Use Detection 4.6 Duplicate Address Detection
RFC 2131 Page 7, section 1.6, second set of bullet items, first RFC 2131 Page 7, section 1.6, second set of bullet items, first
bullet says that DHCP must: "Guarantee that any specific network 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 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. the protocol as later described does not fulfill this requirement.
Two mechanisms are presented: an ARP request generated by the client; Two mechanisms are presented: an ARP request generated by the
and an ICMP echo request generated by the server: client, and an ICMP ECHO request generated by the server:
o Page 12, second paragraph of section 2.2, last sentence O Page 12, second paragraph of section 2.2, last sentence.
o Page 13, list item 2, section 3.1 O Page 15, list item 2, section 3.1.
o Page 38, first paragraph after Table 5, section 4.4.1 O Page 38, first paragraph after Table 5, section 4.4.1.
2.6.1. Client-side ARP 4.6.1 Client-side ARP
To meet the requirement of RFC 2131 page 7, a DHCP client MUST send To meet the requirement of RFC 2131 page 7, a DHCP client MUST send
an ARP request for the IP address contained in a DHCPACK before using an ARP request for the IP address contained in a DHCPACK before
it. This is presently a SHOULD: using it. This is presently a SHOULD:
o Page 12, second paragraph of section 2.2: "... and the client Page 12, second paragraph of section 2.2: "... and the
SHOULD probe the newly received address, e.g., with ARP" client SHOULD probe the newly received address, e.g., with
ARP."
There has been confusion on this topic because many clients are There has been confusion on this topic because many clients are
sending an ARP reply (after the DHCPACK). This often has nothing to sending an ARP reply (after the DHCPACK). This often has nothing to
do with DHCP, and is triggered in many systems whenever an interface do with DHCP, and is triggered in many systems whenever an interface
IP address changes. (Without access to kernel code there is nothing IP address changes. (Without access to kernel code, there is
one can do about it.) nothing to be done about it.)
RECOMMENDATIONS: RECOMMENDATION:
o The Working Group should consider whether to make client ARP a The Working Group should consider whether to make client ARP a MUST.
MUST.
2.6.2. Server side PING. 4.6.2 Server side PING
ICMP is inherently unreliable. Furthermore since success is "no ICMP is inherently unreliable. Furthermore since success is "no
response" it is an imprecise matter to decide how long to wait before response" it is an imprecise matter to decide how long to wait
one is certain that no response will ever occur. A possible before one is certain that no response will ever occur. A possible
suggestion is a back off and retry for ping. suggestion is a back off and retry for ping.
In cable modem environments, PING is not helpful because it is the In cable modem environments, PING is not helpful because it is the
cable modem termination system (CMTS) that replies from its cache: a cable modem termination system (CMTS) that replies from its cache:
cache which may not be perfectly reliable and which in many cases has a cache which may not be perfectly reliable and which in many cases
been constructed by listening to the DHCP traffic in the first place! has been constructed by listening to the DHCP traffic in the first
It is known that some network administrators try to block propagation place!
of ICMP ECHO messages through internal routers, which removes one of
the two address conflict detection mechanisms.
RECOMMENDATIONS: 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.
o Use of ICMP on the server should be a “MAY”, not a “SHOULD”. RECOMMENDATION:
2.6.3. Other Mechanisms Use of ICMP on the server should be a "MAY", not a "SHOULD".
4.6.3 Other Mechanisms
Both the ICMP ECHO (Ping) and Address Resolution Protocol (ARP) Both the ICMP ECHO (Ping) and Address Resolution Protocol (ARP)
mechanisms are very lightweight by design, depending on clients with mechanisms are very lightweight by design, depending on clients with
conflicting addresses to "defend" their address by responding to conflicting addresses to "defend" their address by responding to
queries to show that an address is in use. Is there a better queries to show that an address is in use. Is there a better
alternative to ICMP ECHO and ARP that is backward-compatible with alternative to ICMP ECHO and ARP that is backward compatible with
these two protocols? these two protocols?
4.7 DHCP Relay Agents
2.7. DHCP Relay Agents 4.7.1 Relay Agent Source Addresses
2.7.1. Relay Agent Source Addresses
There should be some text that specifies what the relay agent should There should be some text that specifies what the relay agent should
use for the IP source address of relayed packets. Because relay use for the IP source address of relayed packets. Because relay
agents change the payload ("giaddr" and relay agent option 82) their agents change the payload ("giaddr" and relay agent option 82),
operation does not amount to IP forwarding. The IP source address their operation does not amount to IP forwarding. The IP source
they use should be their own. [Aside: for security purposes it might address they use should be their own. [Aside: for security
have been better than they retain the source IP address of the purposes it might have been better than they retain the source IP
original packet, but it is too late to change all that.] address of the original packet, but it is too late to change all
that.]
2.7.2. Relay Agent Port Usage RECOMMENDATION:
4.7.2 Relay Agent Port Usage
Relay agents should use port 67 as the source port number. Relay 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 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 as the source port number probably because it was copied from the
source port of the incoming packet. source port of the incoming packet.
Cable modem vendors would like to install filters blocking outgoing Cable modem vendors would like to install filters blocking outgoing
packets with source port 67. packets with source port 67.
RECOMMENDATIONS: RECOMMENDATIONS:
o Relay agents MUST use 67 as their source port number. O Relay agents MUST use 67 as their source port number.
o Relay agents MUST NOT forward packets with non-zero giaddr O Relay agents MUST NOT forward packets with non-zero giaddr
unless the source port number on the packet is 67. unless the source port number on the packet is 67.
2.8. Host Name, Domain Name, and FQDNs 4.8 Host Name, Domain Name, and FQDNs
A fully qualified domain name (FQDN) consists of two conceptual A fully qualified domain name (FQDN) consists of two conceptual
parts: the host name portion and the domain name portion. Host parts: the host name portion and the domain name portion. Host
names consist of one or more non-null parts separated by the ISO names consist of one or more non-null parts separated by the ISO
period (.) character ("separator") while domain names consist of two period (.) character ("separator") while domain names consist of two
or more non-null parts delimited by the separator, one of which must 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 be a valid top-level domain (TLD) name. DHCP options exist for
hostname (option 12) and domain name (option 15), and are proposed 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 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. not required to be a concatenation of hostname and domain name.
Should RFC 2131 explicitly state that the client FQDN MUST be the Should RFC 2131 explicitly state that the client FQDN MUST be the
host name (option 12) concatenated with the domain name (option 15)? host name (option 12) concatenated with the domain name (option 15)?
2.9. Overloading of DHCPREQUEST 4.9 Overloading of DHCPREQUEST
The client sends a DHCPREQUEST message from several different states: The client sends a DHCPREQUEST message from several different
INIT, INIT-REBOOT, REBINDING, and RENEWING. Differentiation among states: INIT, INIT-REBOOT, REBINDING, and RENEWING.
the states is done according to the context of other message fields Differentiation among the states is done according to the context of
and option values. At this point there probably can be no change in other message fields and option values. At this point, there
this usage, but the content of other message fields and option values probably can be no change in this usage, but the content of other
should be carefully reviewed to ensure consistency message fields and option values should be carefully reviewed to
ensure consistency.
2.10. DHCPINFORM 4.10 DHCPINFORM
The intent of DHCPINFORM messages is to allow clients to query The intent of DHCPINFORM messages is to allow clients to query
servers for configuration information WHETHER OR NOT their IP address servers for configuration information WHETHER OR NOT their IP
has been assigned by DHCP. address has been assigned by DHCP.
Section 3.4 Para 2 Page 21 states: "The server SHOULD check the Section 3.4 Para 2 Page 21 states: "The server SHOULD check the
network address in a DHCPINFORM message for consistency." What the network address in a DHCPINFORM message for consistency." What the
server should be checking is a mystery. Possibly the intent was that server should be checking is a mystery. Possibly the intent was
servers should verify that the source IP address in the packet is that servers should verify that the source IP address in the packet
identical to the "ciaddr." Since the server should reply to is identical to the "ciaddr." Since the server should reply to
"ciaddr," this affords some measure of security, preventing third "ciaddr," this affords some measure of security, preventing third
parties from discovering configuration information pertaining to parties from discovering configuration information pertaining to
other clients. Whether that is desirable, or whether instead other clients. Whether that is desirable, or whether instead
DHCPINFORM should be available to third parties, such as proxies, has DHCPINFORM should be available to third parties, such as proxies,
never been resolved. has never been resolved.
Section 4.4.4 Para 1, "Use of broadcast and unicast," hints that Section 4.4.4 Para 1, "Use of broadcast and unicast," hints that
clients may be able to broadcast DHCPINFORM messages to servers: "The clients may be able to broadcast DHCPINFORM messages to servers:
DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST and DHCPINFORM "The DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST and DHCPINFORM
messages, unless the client knows the address of a DHCP server." messages, unless the client knows the address of a DHCP server."
This text suggests that a DHCP client may choose to broadcast a This text suggests that a DHCP client may choose to broadcast a
DHCPINFORM request for whatever reason, and points out the need for DHCPINFORM request for whatever reason, and points out the need for
clarification of all text concerning multiple server responses and clarification of all text concerning multiple server responses and
consistency of returned options. consistency of returned options.
RECOMMENDATIONS: RECOMMENDATIONS:
o DHCPINFORM messages should be included in Table 4 to summarize O DHCPINFORM messages should be included in Table 4 to summarize
the fields and options usage with this message type. the fields and options usage with this message type. Suggested
replacement for Table 4 is shown in section 5.2.5.
o The Working Group should consider the ramifications of O The Working Group should consider the ramifications of
permitting third party DHCPINFORMs, that is, DHCPINFORM permitting third party DHCPINFORMs, that is, DHCPINFORM messages
messages NOT sent by the DHCP client, but by other processes NOT sent by the DHCP client, but by other processes having
having access to the ports. access to the ports.
o Section 4.3.1, "DHCPDISCOVER Message," and section 4.3.2, O Section 4.3.1, "DHCPDISCOVER Message," and section 4.3.2,
"DHCPREQUEST Message" briefly mention consistency and uniform "DHCPREQUEST Message" briefly mention consistency and uniform
responses from multiple servers: this text SHOULD be clarified responses from multiple servers: this text SHOULD be clarified
to state what consistency is expected or required of the to state what consistency is expected or required of the server,
server, and what a client should do if a server supplies and what a client should do if a server supplies inconsistent
inconsistent data. data.
2.11. Unicast of DHCPDISCOVER 4.11 Unicast of DHCPDISCOVER
Section 4.4.4 Para 1, "Use of broadcast and unicast," hints that Section 4.4.4 Paragraph 1, "Use of broadcast and unicast," hints
clients may be able to unicast DHCPDISCOVER messages to servers: "The that clients may be able to unicast DHCPDISCOVER messages to
DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST and DHCPINFORM servers: "The DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST and
messages, unless the client knows the address of a DHCP server." DHCPINFORM messages, unless the client knows the address of a DHCP
server."
This would be pointless unless "ciaddr" were non-zero, because the This would be pointless unless "ciaddr" were non-zero, because the
server would not know how to respond. Neither does table 4 admit the server would not know how to respond. Neither does table 4 admit
possibility. the possibility.
We believe it is common practice for BOOTP Relay Agents to only fill- We believe it is common practice for BOOTP Relay Agents to only
in "giaddr" for broadcast packets. This requires investigation: fill-in "giaddr" for broadcast packets. This requires
such behavior would restrict the use of unicast DHCPDISCOVER messages investigation: such behavior would restrict the use of unicast
to the same subnet on which the server resides -- a very restricted DHCPDISCOVER messages to the same subnet on which the server resides
condition. -- a very restricted condition.
One circumstance in which this might make sense is for proxies One circumstance in which this might make sense is for proxies
gathering IP addresses on behalf of other clients. In that case the gathering IP addresses on behalf of other clients. In that case,
proxy could put its own IP address in "ciaddr" and perhaps use the proxy could put its own IP address in "ciaddr" and perhaps use
multiple different client identifiers in multiple transmissions. multiple different client identifiers in multiple transmissions.
Table 5, however, asserts that ciaddr must be zero. Table 5, however, asserts that ciaddr must be zero.
RECOMMENDATIONS: RECOMMENDATIONS:
o The Working Group should consider whether to allow this kind of O The Working Group should consider whether to allow this kind of
proxy usage, and what changes that might imply to RFC 2131. proxy usage, and what changes that might imply to RFC 2131.
o Tables 4 and 5 SHOULD be updated to reflect the possibility of O Tables 4 and 5 SHOULD be updated to reflect the possibility of
unicast DHCPDISCOVER messages. unicast DHCPDISCOVER messages. Suggested replacements for
Tables 4 and 5 are shown in sections 5.2.5-5.2.7.
o Figure 5 SHOULD be updated to reflect the uses of unicast and O Figure 5 SHOULD be updated to reflect the uses of unicast and
broadcast packets broadcast packets. Suggested replacements for Figure 5 are
shown in sections 5.2.6 and 5.2.7.
2.12. DHCPRELEASE 4.12 DHCPRELEASE
There are several MUST NOT entries in the "options" portion of RFC There are several MUST NOT entries in the "options" portion of RFC
2131 table 5 specifying the inclusion of options in the DHCPRELEASE. 2131 table 5 specifying the inclusion of options in the DHCPRELEASE.
Some customers complained that a particular vendor included the Some customers complained that a particular vendor included the
"hostname" option and that this seemed innocuous. The vendor said "hostname" option and that this seemed innocuous. The vendor said
that their reading of the RFC allows such an option to be included. that their reading of the RFC allows such an option to be included.
In the "fields" portion of table 5 there is the word "unused" for the In the "fields" portion of table 5 there is the word "unused" for
"sname" and "file" fields of a DHCPRELEASE message, while "options" the "sname" and "file" fields of a DHCPRELEASE message, while
for the DHCPRELEASE was left blank. "options" for the DHCPRELEASE was left blank.
A DHCPRELEASE message SHOULD be subject to some verification criteria A DHCPRELEASE message SHOULD be subject to some verification
to reduce the chance of a bogus release. Two possible changes to criteria to reduce the chance of a bogus release. Two possible
these tables are: changes to these tables are:
1. In the "fields" portion of table 5, change the "xid" from O In the "fields" portion of table 5, change the "xid" from
"selected by client" to "xid from server DHCPACK message." "selected by client" to "xid from server DHCPACK message."
2. In the "options" portion of table 5, change the entry for O In the "options" portion of table 5, change the entry for
"client identifier" from "MAY" to "client identifier used in "client identifier" from "MAY" to "client identifier used in the
the DHCPDISCOVER message." DHCPDISCOVER message."
2.13. Client state diagram 4.13 Client State Diagram
Section 4.3.1 and Figure 5 do not accurately describe DHCP client Section 4.3.1 and Figure 5 do not accurately describe DHCP client
behavior: DHCP clients send messages to servers from the INIT, INIT- behavior: DHCP clients send messages to servers from the INIT,
REBOOT, SELECTING, REQUESTING, and BOUND states, not from RENEWING or INIT-REBOOT, SELECTING, REQUESTING, and BOUND states, not from
REBINDING. RENEWING or REBINDING.
o Change the text of section 4.3.1 and it's schematic RECOMMENDATION:
representation in Figure 5 to correctly represent the states,
transitions, triggering events, and messages sent.
2.14. Options Change the text of section 4.3.1 and its schematic representation in
Figure 5 to correctly represent the states, transitions, triggering
events, and messages sent. Suggested replacements for Figure 5 are
shown in sections 5.2.6 and 5.2.7.
4.14 Options
The language in RFC 2131 concerning whether and which options to The language in RFC 2131 concerning whether and which options to
return to the client is convoluted and apparently contradictory. return to the client is convoluted and apparently contradictory.
2.14.1. Which Options to Return? 4.14.1 Which Options to Return?
There are two opposing philosophies regarding which options servers There are two opposing philosophies regarding which options servers
should return to clients: to return every option with values within should return to clients: to return every option with values within
the client’s scope, or to return only those options specifically the client’s scope, or to return only those options specifically
requested by a client and within scope. The following arguments have requested by a client and within scope. The following arguments
been cited: have been cited:
Supporting the return of every option: O Supporting the return of every option:
o Consistency. A network administrator wants all of the a. Consistency. A network administrator wants all of the
configured options to show up on each client on the network, configured options to show up on each client on the network,
regardless of client vendor. regardless of client vendor.
o A DHCP client is likely only to request the options it b. A DHCP client is likely only to request the options it
supports. However, many application layer options are not used supports. However, many application layer options are not
by the DHCP client but are useful to applications. used by the DHCP client but are useful to applications.
o A DHCP client would either need to be configured or updated to c. A DHCP client would either need to be configured or updated
request new options. The whole idea of DHCP is to keep to request new options. The whole idea of DHCP is to keep
configuration on the server, not on the client, which is configuration on the server, not on the client, which is
pointed out in: Page 7, second and third bullets of section pointed out in: Page 7, second and third bullets of section
1.6. 1.6.
Supporting the return only of requested options: 5. Supporting the return only of requested options:
o Some DHCP clients may reject packets containing options that a. Some DHCP clients may reject packets containing options
they did not request especially if they are ignorant of their that they did not request especially if they are ignorant of
semantics; therefore a DHCP server should only return the their semantics; therefore a DHCP server should only return
options requested. the options requested.
o The DHCP packet size is limited. Options are often configured b. The DHCP packet size is limited. Options are often
on a per-network rather than a per-client basis, and to return configured on a per-network rather than a per-client basis,
unwanted options risks exhausting the space available while and to return unwanted options risks exhausting the space
options remain which the client needs. available while options remain which the client needs.
RFC 2131 does little to resolve the matter. Two different sections RFC 2131 does little to resolve the matter. Two different sections
are relevant: section 3.5 describes mechanisms to limit the number of are relevant: section 3.5 describes mechanisms to limit the number
options sent, while section 4.3.1 subsequently presents an apparently of options sent, while section 4.3.1 subsequently presents an
conflicting description of how to select values for options requested apparently conflicting description of how to select values for
by the client. options requested by the client.
RFC 2131, Section 3.5: 6. RFC 2131, Section 3.5:
"First, most parameters have defaults defined in the Host "First, most parameters have defaults defined in the Host
Requirements RFCs; if the client receives no parameters from Requirements RFCs; if the client receives no parameters from
the server that override the defaults, a client uses those the server that override the defaults, a client uses those
default values." default values."
The list of parameters with a cross-reference to the defining RFC is The list of parameters with a cross-reference to the defining RFC is
given in Appendix A of RFC 2131. given in Appendix A of RFC 2131.
Several sources contend that virtually none of the parameters in the Several sources contend that virtually none of the parameters in the
list have a meaningful default value, which raises the issue of list have a meaningful default value, which raises the issue of
viability of the technique described in this section for reducing viability of the technique described in this section for reducing
total server response message size. total server response message size.
Even if the option has a default value defined in [RFC1122], RFC 2131 Even if the option has a default value defined in [RFC1122], RFC
is silent on the question of whether or not the server MUST, SHOULD, 2131 is silent on the question of whether or not the server MUST,
or MAY choose not to send that option when its value is the same as SHOULD, or MAY choose not to send that option when its value is the
the default. same as the default.
RFC 2131, Section 4.3.: 7. RFC 2131, Section 4.3:
"IF the server has been explicitly configured with a default "IF the server has been explicitly configured with a default
value for the parameter, the server MUST include that value in value for the parameter, the server MUST include that value
an appropriate option in the 'option' field, ELSE in an appropriate option in the 'option' field, ELSE IF the
server recognizes the parameter as a parameter defined in
"IF the server recognizes the parameter as a parameter defined the Host Requirements Document, the server MUST include the
in the Host Requirements Document, the server MUST include the
default value for that parameter as given in the Host default value for that parameter as given in the Host
Requirements Document in an appropriate option in the 'option' Requirements Document in an appropriate option in the
field, ELSE 'option' field, ELSE the server MUST NOT return a value for
that parameter."
"The server MUST NOT return a value for that parameter."
The word "default" in the first statement seems misplaced. The The word "default" in the first statement seems misplaced. The
second statement seems contrary to the intent of minimizing the second statement seems contrary to the intent of minimizing the
amount of data sent by the server: if the scope of the Host amount of data sent by the server: if the scope of the Host
Requirements RFCs applies to all Internet-connected hosts, then a Requirements RFCs applies to all Internet-connected hosts, then a
DHCP server SHOULD NOT have to supply these values -- they should DHCP server SHOULD NOT have to supply these values -- they should
already be assumed by the client as the default for the requested already be assumed by the client as the default for the requested
option. option.
There is no mention of a minimum set of parameters to be sent to a 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 requesting client, nor any mention of which parameters to send if
client does not request any not any guidance for what to do when 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 there is more data than will fit in a response packet. Can the
options be somehow prioritized? Could additional options be obtained options be somehow prioritized? Could additional options be
using the DHCPINFORM mechanism? Should an additional bit in the obtained using the DHCPINFORM mechanism? Should an additional bit
"flags" field be defined as a "packet overflow" bit? in the "flags" field be defined as a "packet overflow" bit?
RECOMMENDATIONS: RECOMMENDATIONS:
o Clients MUST include the same parameter request list on all O Clients MUST include the same parameter request list on all
messages. messages.
o Clients MUST be prepared to receive responses containing O Clients MUST be prepared to receive responses containing options
options they did not request and/or whose semantics are they did not request and/or whose semantics are unknown. They
unknown. They MAY choose silently to ignore such options. MAY choose silently to ignore such options.
o Language implying that parameters in "Requirements for Internet O Language implying that parameters in "Requirements for Internet
Hosts" have defaults should be removed. Hosts" have defaults should be removed.
2.14.2. Multiple Instances of Options 4.14.2 Multiple Instances of Options
Page 24, seventh paragraph, section 4.1: "Options may appear only Page 24, seventh paragraph, section 4.1: "Options may appear only
once, unless otherwise specified in the options document. The client once, unless otherwise specified in the options document. The
concatenates the values of multiple instances of the same option into client concatenates the values of multiple instances of the same
a single parameter list for configuration." The first sentence option into a single parameter list for configuration."
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 RECOMMENDATION:
The first sentence SHOULD begin "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.
4.14.3 Option Ordering
A number of clients require that the DHCP message type be the first A number of clients require that the DHCP message type be the first
option (after the magic cookie). option (after the magic cookie).
RECOMMENDATIONS: RECOMMENDATION:
o With the exception of option 82, which must be last (save With the exception of option 82, which must be last (save option 255
option 255 which acts as a terminator), the client MUST NOT which acts as a terminator), the clients MUST NOT make any
make any assumption about the ordering of options. assumption about the ordering of options.
2.14.4. Options 66 and 67 4.14.4 Options 66 and 67
Options 66 (TFTP server name) and 67 (bootfile name) were introduced Options 66 (TFTP server name) and 67 (bootfile name) were introduced
as an alternative to the fixed fields "sname" and "file" in BOOTP. as an alternative to the fixed fields "sname" and "file" in BOOTP.
As discussed elsewhere, space is at a premium in DHCP, and reserving As discussed elsewhere, space is at a premium in DHCP, and reserving
64 octets ("sname") and 128 octets ("file") to contain values are 64 octets ("sname") and 128 octets ("file") to contain values are
that potentially, and commonly, much shorter is wasteful. that potentially, and commonly, much shorter is wasteful.
Furthermore, the existence of these options allows the client to Furthermore, the existence of these options allows the client to
either request those values from the server or not, according to either request those values from the server or not, according to
need. need.
At present, servers are at liberty to return values for these options At present, servers are at liberty to return values for these
in either the fixed fields, or encapsulated like any other DHCP options in either the fixed fields, or encapsulated like any other
option. Clients have sometimes assumed only the former. RFC 2131 DHCP option. Clients have sometimes assumed only the former. RFC
should address this issue. 2131 should address this issue.
RECOMMENDATIONS: RECOMMENDATIONS:
o Using "sname" and "file" for these options SHOULD be 1. Using "sname" and "file" for these options SHOULD be deprecated.
deprecated.
o Clients MUST be prepared, at least for the time being, for 2. Clients MUST be prepared, at least for the time being, for
either method of delivery. either method of delivery.
2.15. Vendor Classes 4.15 Vendor Classes
Page 3, section 1.1, first paragraph - includes the following Page 3, section 1.1, first paragraph - includes the following
sentence: "The classing mechanism for identifying DHCP clients to sentence: "The classing mechanism for identifying DHCP clients to
DHCP servers has been extended to include "vendor" classes as defined DHCP servers has been extended to include "vendor" classes as
in sections 4.2 and 4.3." Vendor classing has been there since RFC defined in sections 4.2 and 4.3." Vendor classing has been there
1541, thus there is nothing new about it. Should this section be since RFC 1541, thus there is nothing new about it. Should this
referring to User classing? section be referring to User classing?
4.15.1 Character Set
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.
2.15.2. Form of the name space 4.15.2 Form of the Name Space
An early suggestion (RFC 1541 time-frame), expressed symbolically, An early suggestion (RFC 1541 time-frame), expressed symbolically,
was the form "Stock symbol/Organization...." e.g., "SUNW.class- was the form "Stock symbol/Organization...." e.g., "SUNW.class-
1.class-2" or "CMU.edu.class-1.class-2". This would have had the 1.class-2" or "CMU.edu.class-1.class-2". This would have had the
advantage of preventing collisions between vendors. This was not advantage of preventing collisions between vendors. This was not
adopted, and it is probably too late to resurrect it. adopted, and it is probably too late to resurrect it.
2.15.3. Relationship to vendor options 4.15.3 Relationship to Vendor Options
Text is needed describing how each unique vendor class identifier Text is needed describing how each unique vendor class identifier
implies a 254 unique encapsulated option name space. There are 254, implies a 254 unique encapsulated option name space. There are 254,
because even within the vendor space options 0 and 255 retain their because even within the vendor space options 0 and 255 retain their
meaning as the pad value and terminator, respectively. An occasional meaning as the pad value and terminator, respectively. An
misconception is that there is only a single unique encapsulated 254 occasional misconception is that there is only a single unique
option name space shared by all vendors, with the effect that the encapsulated 254 option name space shared by all vendors, with the
same values being returned to *any* client regardless of vendor class effect that the same values being returned to *any* client
identifier. Obviously, we should include text to clarify the regardless of vendor class identifier. Obviously, we should include
relationship between Vendor Class identifier and the encapsulated text to clarify the relationship between Vendor Class identifier and
Vendor option. the encapsulated Vendor option.
2.15.4. Multiplicity. 4.15.4 Multiplicity
How many vendor class identifiers can a client have? One only, How many vendor class identifiers can a client have? Only one class
because the client is unique to a specific vendor. If the client identifier, because the client is unique to a specific vendor. If
were to send more than one vendor class option it would be impossible the client were to send more than one vendor class option it would
for the server to decide which set of encapsulated vendor options to be impossible for the server to decide which set of encapsulated
select. 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 by Mike
Carney regarding the use of vendor class / encapsulated options: Carney regarding the use of vendor class / encapsulated options:
Vendor class support requires the ability to configure a DHCP Vendor class support requires the ability to configure a
server to support a new vendor class by associating that vendor DHCP server to support a new vendor class by associating
class identifier with 254 options whose types can then be that vendor class identifier with 254 options whose types
defined by following the DHCP client's documentation. Each can then be defined by following the DHCP client's
group of 254 options has the "scope" of that vendor. For documentation. Each group of 254 options has the "scope" of
example, suppose we have the following two clients: that vendor. For 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 ( a 2 octet integer)
1 2 Darkness setting ( a 2 byte integer)
Vendor Class "Voxpopulis.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 4 Outgoing message index (pointer to messages)
1 X Outgoing message
Both clients are on the same network ("Kitchen"), and are clients of Both clients are on the same network ("Kitchen"), and are clients of
the same DHCP server. Note that both use encapsulated option code 1. the same DHCP server. Note that both use encapsulated option code
Looks like a conflict, but it isn't. 1. Looks like a conflict, but it is not: in the syntax of the DHCP
server's configuration table, one configures two new options, each
In the syntax of the DHCP server's configuration table, one 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, it "SunBeam.Toaster.2slots" class. When the answering machine boots,
only sees vendor class options associated with the it 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 do not see any encapsulated
options. vendor options.
2.16. Client/Server Retransmission 4.16 Client/Server Retransmission
Because DHCP servers are the passive participants and DHCP clients Because DHCP servers are the passive participants and DHCP clients
are the active participants, the DHCP protocol is susceptible to are the active participants, the DHCP protocol is susceptible to
poorly behaved clients (retransmitting too fast, for example). poorly behaved clients (retransmitting too fast, for example).
However, there is no text describing this susceptibility. However, there is no text describing this susceptibility.
Furthermore, the use of the power-of-2 retransmission algorithm is a Furthermore, the use of the power-of-2 retransmission algorithm is a
SHOULD/MAY. This probably should be a MUST. If we need different SHOULD/MAY. This probably should be MUST. If we need different
retransmission algorithms for different media, then we should retransmission algorithms for different media, then we should
develop/document them in table form. The specification as it stands develop/document them in table form. The specification as it stands
is too loose and does cause inter-operability problems: is too loose and does cause inter-operability problems:
1. Page 16, section 3.1, last sentence of list item 3.1. O Page 16, section 3.1, last sentence of list item 3.1.
2. Page 17, third paragraph of list item 5, section 3.1 O Page 17, third paragraph of list item 5, section 3.1
3. Page 24, eighth paragraph of section 4.1 O Page 24, eighth paragraph of section 4.1
4. Page 36, first paragraph of section 4.4.1 O Page 36, first paragraph of section 4.4.1
2.17. Transmission of DHCPNAKs 4.17 Transmission of DHCPNAKs
DHCPNAKs MUST be broadcast or unicast to at the link level because DHCPNAKs MUST be broadcast or unicast to at the link level because
the client has no valid IP address. The same comment applies to the client has no valid IP address. The same comment applies to
DHCPOFFERs but with one significant difference: a DHCPOFFER has a DHCPOFFERs but with one significant difference: a DHCPOFFER has a
valid "yiaddr" which a relay agent can use as the destination IP valid "yiaddr" which a relay agent can use as the destination IP
address. It is not clear that whatever mechanism relay agents are address. It is not clear that whatever mechanism relay agents are
using to transmit offers will work when "yiaddr" is 0.0.0.0. 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 Therefore, for safety’s sake, the servers MUST set the broadcast bit
in DHCPNAK packets. The text describing a server's behavior when the in DHCPNAK packets. The text describing a server's behavior when
client is accessible through a BOOTP relay agent does not do this: the client is accessible through a BOOTP relay agent does not do
this:
1. Page 19, last paragraph of list item 2, section 3.2 O Page 19, last paragraph of list item 2, section 3.2.
2. Page 23, fifth paragraph of section 4.1 O Page 23, fifth paragraph of section 4.1.
3. Page 32, Last paragraph of "DHCPREQUEST generated during INIT- O Page 32, Last paragraph of "DHCPREQUEST generated during INIT-
REBOOT state," bullet, section 4.3.2. REBOOT state," bullet, section 4.3.2.
This last describes the behavior that's required -- a server MUST set This last describes the behavior that is required -- a server MUST
the broadcast bit in order for the relay agent to properly broadcast set the broadcast bit in order for the relay agent to properly
the DHCPNAK. broadcast the DHCPNAK.
RECOMMENDATION RECOMMENDATION:
o Items (1) and (2) above should either duplicate the text of
(3), or should reference section 4.3.2.
2.18. Use of ciaddr Items (1) and (2) above should either duplicate the text of (3), or
should reference section 4.3.2.
According to RFC 951 and RFC 1542, clients use "ciaddr" when they've 4.18 Use of ciaddr
received an IP address from a source outside of BOOTP/DHCP, and can
respond to ARPs. According to RFC 951 and RFC 1542, clients use "ciaddr" when they
have received an IP address from a source outside of BOOTP/DHCP, and
can respond to ARPs.
The text in RFC 2131 is mostly supportive of this point with the The text in RFC 2131 is mostly supportive of this point with the
following exception: following exception:
Page 32, "DHCPREQUEST generated during REBINDING state:" Page 32, "DHCPREQUEST generated during REBINDING state:"
section 4.3.2: "The DHCP server SHOULD check 'ciaddr' for section 4.3.2: "The DHCP server SHOULD check 'ciaddr' for
correctness before replying to the DHCPREQUEST." correctness before replying to the DHCPREQUEST."
RECOMMENDATION:
This line should be struck from the document. Servers trust This line should be struck from the document. Servers trust
"ciaddr," period. "ciaddr," period.
2.19. Size of a BOOTP/DHCP frame 4.19 Size of a BOOTP/DHCP Frame
The description in RFC 2131 relating to the size constraints of DHCP The description in RFC 2131 relating to the size constraints of DHCP
packets (Page 10, first paragraph after Table 1, section 2) is packets (Page 10, first paragraph after Table 1, section 2) is
inadequate. inadequate.
2.19.1. Minimum size. 4.19.1 Minimum Packet Size
RFC 951 states that a minimum BOOTP frame is 300 octets in length. RFC 951 states that a minimum BOOTP frame is 300 octets in length.
Some BOOTP relay agents have been known to drop frames of less than Some BOOTP relay agents have been known to drop frames of less than
300 octets. RFC 951 is explicit on this point, but RFC 2131 just 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 refers to RFC 951. Since DHCP is intended to be backward compatible
with BOOTP, the protocol should continue to observe this lower bound. with BOOTP, the protocol should continue to observe this lower
bound.
RECOMMENDATIONS: RECOMMENDATION:
o Text should be added stating explicitly that the minimum size Text should be added stating explicitly that the minimum size of a
of a DHCP frame is 300 octets. DHCP frame is 300 octets.
2.19.2. Maximum Size, MTU, and Message Size option 4.19.2 Maximum Size, MTU, and Message Size Option
It has been thought necessary to avoid fragmentation of the IP It has been thought necessary to avoid fragmentation of the IP
packets in DHCP/BOOTP due to concerns that some clients would be packets in DHCP/BOOTP due to concerns that some clients would be
unable to reassemble fragments before the IP stack is properly unable to reassemble fragments before the IP stack is properly
configured. RFC 951 states "For simplicity it is assumed that the configured. RFC 951 states, "For simplicity it is assumed that the
BOOTP packet is never fragmented". Regardless of theoretical BOOTP packet is never fragmented." Regardless of theoretical
limitations in IP stack implementations, it is certain that there are limitations in IP stack implementations, it is certain that there
several DHCP/BOOTP implementations, at both ends of the protocol, are several DHCP/BOOTP implementations, at both ends of the
which will not reassemble. protocol, which will not reassemble.
Various comments in the WORKING GROUP imply that fragmentation could Various comments in the WORKING GROUP imply that fragmentation could
be avoided were the client consistently to include the MTU of the be avoided were the client consistently to include the MTU of the
link layer interface. But clients cannot be expected to be omniscient link layer interface. However, clients cannot be expected to be
about other media over which packets travel en route to servers. omniscient about other media over which packets travel en route to
Servers that must be endowed with this knowledge, which they MUST use servers. Servers must be endowed with this knowledge, which they
to avoid packet fragmentation. MUST use to avoid packet fragmentation.
Once the IP stack is configured, and the IP stack is fully Once the IP stack is configured, and the IP stack is fully
configured, the aforementioned limitation ceases to exist, and later configured, the aforementioned limitation ceases to exist, and later
stages of the protocol could allow larger packets (up to the UDP stages of the protocol could allow larger packets (up to the UDP
limit). DHCPINFORMs, especially, could benefit from this relaxation. limit). DHCPINFORMs, especially, could benefit from this
There probably should be explicit text to allow larger packets relaxation. There probably should be explicit text to allow larger
(presumably up to the maximum PDU size) for later stages of the packets (presumably up to the maximum PDU size) for later stages of
protocol. the protocol.
A number of clients send small packets with the assumption that A number of clients send small packets with the assumption that
servers will not return a packet that is any larger than the one servers will not return a packet that is any larger than the one
received from the client. The client MUST NOT make this assumption. received from the client. Clients MUST NOT assume this. If the
If the client cannot process a response larger than a certain size, client cannot process a response larger than a certain size, the
the client MUST use the message size option to inform servers of this client MUST use the message size option to inform servers of this
size. Note that this is NOT the same option as the MTU. size. Note that this is NOT the same option as the MTU.
RECOMMENDATIONS: RECOMMENDATIONS:
o Servers and relay agents MUST ensure that IP datagram O Servers and relay agents MUST ensure that IP datagram
fragmentation does not occur at any stage in the protocol fragmentation does not occur at any stage in the protocol before
before the client IP stack is fully configured. the client IP stack is fully configured.
o Clients SHOULD communicate their link-layer frame size to the O Clients SHOULD communicate their link-layer frame size to the
DHCP server via the DHCP MTU option. DHCP server via the DHCP MTU option.
o Clients MUST NOT assume that servers will return a packet no 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 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 size of the packet that it can process it MUST convey that limit
limit to the server in the "maximum message size" option (57) to the server in the "maximum message size" option (57).
o Page 21, second paragraph, section 3.5, the first sentence O Page 21, second paragraph, section 3.5, the first sentence
SHOULD be changed to "The client SHOULD include the 'maximum SHOULD be changed to "The client SHOULD include the 'maximum
DHCP message size' option to let the server know how large the DHCP message size' option to let the server know how large the
server may make its DHCP messages, and the value of this option server may make its DHCP messages, and the value of this option
SHOULD be the MTU of the [client] network interface being SHOULD be the MTU of the [client] network interface being
configured." configured."
o The WORKING GROUP SHOULD consider whether to allow O The WORKING GROUP SHOULD consider whether to allow fragmentation
fragmentation of packets after the client is fully configured, of packets after the client is fully configured, and how servers
and how servers can divine this fact (e.g. a non-zero can divine this fact (e.g. a non-zero "ciaddr.")
"ciaddr").
2.20. Use of giaddr 4.20 Use of giaddr
Page 23, fifth paragraph, section 4.1: "If the 'giaddr’ field is Page 23, fifth paragraph, section 4.1: "If the 'giaddr’ field is
zero and the 'ciaddr' field is nonzero, then the server unicasts zero and the 'ciaddr' field is nonzero, then the server unicasts
DHCPOFFER and DHCPACK messages to the address in 'ciaddr.'" True for DHCPOFFER and DHCPACK messages to the address in 'ciaddr.'" True
DHCPACK, false for DHCPOFFER (a DHCPDISCOVER will never have anything for DHCPACK, false for DHCPOFFER (a DHCPDISCOVER will never have
but 0 as "ciaddr.") anything but 0 as "ciaddr.")
2.21. Address Selection
Page 27, third paragraph, section 4.3.1: "Note that, in some network 4.21 Address Selection
architectures (e.g., internets with more than on IP subnet assigned
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
address recording in 'giaddr.'"
Page 27, third paragraph, section 4.3.1: "Note that, in some
network architectures (e.g., internets with more than on IP subnet
assigned 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 address recording in 'giaddr.'"
There are two differing view of this sentence: There are two differing view of this sentence:
There is considerable detail in the rest of RFC 2131 trying to There is considerable detail in the rest of RFC 2131 trying
get the use of "giaddr" clear as it relates to BOOTP relay to get the use of "giaddr" clear as it relates to BOOTP
agents (RFC 951 and RFC 1542), then this sentence basically relay agents (RFC 951 and RFC 1542), then this sentence
"undoes" this work. Serving multiple IP networks on the same "undoes" this work. Serving multiple IP networks on the
wire should be either described in detail in its own section same wire should be either described in detail in its own
(with caveats) or as a separate informational RFC. Otherwise, section (with caveats) or as a separate informational RFC.
the use of "giaddr" is unclear. Otherwise, the use of "giaddr" is unclear.
Alternatively: Alternatively:
Additional supporting text should be added to RFC 2131 to the Additional supporting text should be added to RFC 2131 to
effect that servers having knowledge of network topology MAY the effect that servers having knowledge of network topology
choose to offer an address inconsistent with "giaddr" but MAY choose to offer an address inconsistent with "giaddr"
consistent with that topology. Furthermore, the address but consistent with that topology. Furthermore, the address
offered may differ depending upon the contents of the vendor offered may differ depending upon the contents of the vendor
class, user class, and even the client identifier. All of class, user class, and even the client identifier. All of
these things are policy matters for the server. these things are policy matters for the server.
2.22. Use of "secs" field 4.22 Use of "secs" Field
The "secs" field has not been discussed much: many clients simply The "secs" field has not been discussed much: many clients simply
leave its value as zero, and few if any servers have used its value leave its value as zero, and few if any servers have used its value
to modify their behavior. These practices seem acceptable. The value to modify their behavior. These practices seem acceptable. The
of "secs" SHOULD be the elapsed time (in seconds) since the client value of "secs" SHOULD be the elapsed time (in seconds) since the
began trying to acquire or extend a lease on an IP address. A client began trying to acquire or extend a lease on an IP address.
sixteen bit field, its maximum value is 65536. It is conceivable 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 that due to server or network failure that a client may have been
waiting longer than this. waiting longer than this.
RECOMMENDATIONS: RECOMMENDATION:
o A client MAY choose to leave to ignore the secs field. If so A client MAY choose to leave to ignore the secs field. If so, its
its value MUST be set to zero. If the client chooses to insert value MUST be set to zero. If the client chooses to insert a value,
a value, the value SHOULD be time elapsed since the client the value SHOULD be time elapsed since the client began negotiating
began negotiating for an IP address. If the client has been for an IP address. If the client has been waiting longer than 65536
waiting longer than 65536 seconds its value SHOULD be 65536. seconds its value SHOULD be 65536. The value SHOULD NOT wrap around
The value SHOULD NOT wrap around to zero. to zero.
2.23. Use of "htype" and "hlen" fields 4.23 Use of "htype" and "hlen" Fields
At least one vendor has used chaddr as a place holder for a value At least one vendor has used chaddr as a place holder for a value
that was not in fact a link-layer (hardware) address, while at the 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 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 16 (instead of 6). Many servers will reject a packet with this kind
of inconsistency between the htype and hlen fields. of inconsistency between the htype and hlen fields.
Values of htype not equal to zero MUST correspond to the link-level Values of htype not equal to zero MUST correspond to the link-level
medium to which the DHCP client is attached according to IANA’s medium to which the DHCP client is attached according to IANA’s
Assigned Numbers database. Assigned Numbers database.
RECOMMENDATIONS: RECOMMENDATIONS:
o The value of hlen MUST be consistent with the length of a link- 1. The value of hlen MUST be consistent with the length of a link-
level address implied by htype. level address implied by htype.
o An htype of zero SHOULD be used to mean that chaddr is an 2. An htype of zero SHOULD be used to mean that chaddr is an
identifier unrelated to a specific link-level medium. identifier unrelated to a specific link-level medium.
2.24. Use of xid field 4.24 Use of "xid" Field
This field exists to allow clients to match replies to requests. In This field exists to allow clients to match replies to requests. In
two places RFC 2131 erroneously states that the client should use the two places RFC 2131 erroneously states that the client should use
"xid" in the server’s DHCPOFFER as the value in its follow up request the "xid" in the server’s DHCPOFFER as the value in its follow up
request.
o Table 5 DHCPREQUEST column 1. Table 5, DHCPREQUEST column.
o Section 4.4.1 Para 5 2. Section 4.4.1, Paragraph 5.
In principle the 32 bits of "xid" should be sufficient to make the In principle, the 32 bits of "xid" should be sufficient to make the
chance of collisions almost nil, provided that it is randomly chance of collisions almost nil, provided it is randomly generated
generated as 2131 suggests in section 4.4.1 paragraph 3. However, as 2131 suggests in section 4.4.1 paragraph 3. However, some
some vendors have admitted to generating "xid" which may not be vendors have admitted to generating "xid" which may not be
sufficiently uniformly distributed. sufficiently uniformly distributed.
The randomness requirement on "xid" is not as stringent as would be The randomness requirement on "xid" is not as stringent as would be
required, say, in selecting a cryptographic key. It is quite required, say, in selecting a cryptographic key. It is quite
permissible that the initial key be predictable given sufficient permissible that the initial key be predictable given sufficient
knowledge of the client, but clients MUST ensure that these knowledge of the client, but clients MUST ensure that these
identifiers are generated in such a way that the chance of collision identifiers are generated in such a way that the chance of collision
with other clients in the DHCP administrative domain is what one with other clients in the DHCP administrative domain is what one
should expect from a truly random number. should expect from a truly random number.
Permitting the use of the same "xid" on a re-transmission might Permitting the use of the same "xid" on a re-transmission might
marginally improve the efficiency of the protocol. Server responses marginally improve the efficiency of the protocol. Server responses
to the first transmission, which arrived after the timeout and to the first transmission, which arrived after the timeout and
retransmission would be accepted, and might avoid yet another client retransmission would be accepted, and might avoid yet another client
timeout. timeout.
2.25. Options in DHCPOFFER and DHCPACK 4.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. case. This SHOULD be clarified.
RECOMMENDATIONS: RECOMMENDATIONS:
o Servers MAY deliver a full configuration in a DHCPOFFER, but 1. Servers MAY deliver a full configuration in a DHCPOFFER, but are
are NOT required to do so. The DHCPOFFER MUST contain an IP NOT required to do so. The DHCPOFFER MUST contain an IP address
address and a lease time, and MAY contain other information. and a lease time, and MAY contain other information. As a
As a client will presumably choose among multiple offers based client will presumably choose among multiple offers based on
on some criteria, perhaps completeness of response, the server some criteria, perhaps completeness of response, the server
SHOULD be permitted to return the 'parameter request list' SHOULD be permitted to return the 'parameter request list'
including the option code for each option it is prepared to including the option code for each 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 2. In a DHCPACK message, the lease time offered MUST be at least as
as long as that in the DHCPOFFER. The IP address MUST be the long as that in the DHCPOFFER. The IP address MUST be the same.
same.
o The options delivered in a DHCPACK message MAY differ from 3. The options delivered in a DHCPACK message MAY differ from those
those in a DHCPOFFER. Some DHCP servers attempt to balance the in a DHCPOFFER. Some DHCP servers attempt to balance the load
load for other services by permuting lists. For instance, a for other services by permuting lists. For instance, a server
server configured with 3 DNS server addresses may rotate that configured with three DNS server addresses may rotate that list
list each time a client is serviced. It is a problem for some each time a client is serviced. It is a problem for some
servers to deliver an identical OFFER and ACK (it implies servers to deliver an identical OFFER and ACK (it implies
keeping state.) keeping state.)
o If a particularly long option list must be delivered to the 4. If a particularly long option list must be delivered to the
client, it might not be possible to fit all options in the DHCP 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 payload of a UDP packet. RFC 2131 appears to permit a long list
list of options to be sent partly in the DHCPOFFER message and of options to be sent partly in the DHCPOFFER message and partly
partly in the DHCPACK message. in the DHCPACK message.
2.26. Lease times. 4.26 Lease Times
RFC 2131 has some language (section 4.3.1) that might be interpreted 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 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 history or what the client wants. This SHOULD be rewritten to make
make clear that in a DHCPOFFER a server can offer whatever lease time clear that in a DHCPOFFER a server can offer whatever lease time
that local policy finds acceptable, without regard to what the client that local policy finds acceptable, without regard to what the
requests, or what was offered last time around. If a server offers a client requests, or what was offered last time around. If a server
longer lease than the client requested, the client can simply enter offers a longer lease than the client requested, the client can
the RENEWING or REBINDING states, or send a DHCPRELEASE message simply enter the RENEWING or REBINDING states, or send a DHCPRELEASE
according to its desired [earlier] times. message according to its desired [earlier] times.
For RENEWALS, the text should be made clear that servers are not 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 us say that a new lease is offered with a certain T0 (T0 is
duration) and T1 = T0/2. Then, when T1 expired, the client attempts lease duration) and T1 = T0/2. Then, when T1 expired, the client
a renewal. The server in question, for whatever reason, does not attempts a renewal. The server in question, for whatever reason,
want to extend the lease, but is willing to confirm the residual time does not want to extend the lease, but is willing to confirm the
(T0/2). If it also returns T1 in the options, it should ensure that residual time (T0/2). If it also returns T1 in the options, it
T1 is adjusted from the original value else the new ACK will have T0 should ensure that T1 is adjusted from the original value else the
and T1 identical. new ACK will have T0 and T1 identical.
2.27. Miscellaneous 4.27 Miscellaneous
There are many SHOULDs and SHOULD NOTs that should perhaps be There are many SHOULDs and SHOULD NOTs that should perhaps be
converted into MUSTs or MUST NOTs. Here is a summary: converted into MUSTs or MUST NOTs. Here is a summary:
1. Page 16, item 4, section 3.1 "The server SHOULD NOT check the 1. Page 16, item 4, section 3.1 "The server SHOULD NOT check the
offered network address at this point." (MUST NOT) offered network address at this point." (MUST NOT)
2. Page 16, item 5, section 3.1 "The client SHOULD perform a 2. Page 16, item 5, section 3.1 "The client SHOULD perform a final
final check on the parameters..." (MUST) check on the parameters..." (MUST)
3. Page 17, item 5, section 3.1 "The client SHOULD wait a minimum 3. Page 17, item 5, section 3.1 "The client SHOULD wait a minimum
of ten seconds..." (MUST) of ten seconds..." (MUST)
4. Page 18, item 2, section 3.2 "Servers SHOULD NOT check that 4. Page 18, item 2, section 3.2 "Servers SHOULD NOT check that the
the client's network address is already in use..." (MUST NOT) client's network address is already in use..." (MUST NOT)
5. Page 19, item 2, second paragraph, section 3.2 "...servers 5. Page 19, item 2, second paragraph, section 3.2 "...servers
SHOULD respond with a DHCPNAK message to the client" (MUST). SHOULD respond with a DHCPNAK message to the client" (MUST).
The following sentences are rather dubious in this paragraph The following sentences are rather dubious in this paragraph as
as well. well.
6. Page 21, first paragraph, section 3.4 "The servers SHOULD 6. Page 21, first paragraph, section 3.4 "The servers SHOULD
unicast the DHCPACK replay to the address given in the unicast the DHCPACK replay to the address given in the 'ciaddr'
'ciaddr' field of the DHCPINFORM message" (MUST) field of the DHCPINFORM message" (MUST)
7. Page 22, last paragraph, section 3.5 "If a server receives a 7. Page 22, last paragraph, section 3.5 "If a server receives a
DHCP request message with an invalid 'requested IP address', DHCP request message with an invalid 'requested IP address', the
the server SHOULD respond to the client with a DHCPNAK server SHOULD respond to the client with a DHCPNAK message...."
message..." (MUST) (MUST)
RECOMMENDATIONS: RECOMMENDATION:
o The WORKING GROUP should review the MAY/SHOULD/MUST (NOT)s in The WORKING GROUP should review the use of emphasis words (e.g.,
RFC 2131. Those SHOULDs that remain should list the valid MAY) in RFC 2131. Those SHOULDs that remain should list the valid
exceptions (some do; most don't). exceptions (some do; most don't).
3. Intellectual Property 5 Proposed Replacements for RFC 2131 Figures and Tables
The IETF takes no position regarding the validity or scope of any 5.1 Figures
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11.
Copies of claims of rights made available for publication and any 5.1.1 Figure 1: Format of a DHCP message
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any 0 1 2 3
copyrights, patents or patent applications, or other proprietary 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
rights that may cover technology that may be required to practice +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
this standard. Please address the information to the IETF Executive | op (1) | htype (1) | hlen (1) | hops (1) |
Director. +---------------+---------------+---------------+---------------+
| xid (4) |
+-------------------------------+-------------------------------+
| secs (2) | flags (2) |
+-------------------------------+-------------------------------+
| ciaddr (4) |
+---------------------------------------------------------------+
| yiaddr (4) |
+---------------------------------------------------------------+
| siaddr (4) |
+---------------------------------------------------------------+
| giaddr (4) |
+---------------------------------------------------------------+
| |
| chaddr (16) |
| |
| |
+---------------------------------------------------------------+
| |
| sname (64) |
+---------------------------------------------------------------+
| |
| file (128) |
+---------------------------------------------------------------+
| |
| options (variable) |
+---------------------------------------------------------------+
4. Notes Figure 1: Format of a DHCP Message
This section will be removed when this memo goes to Working Group 5.1.2 Figure 2: Format of the 'flags' Field
Last Call.
4.1. Issues . . . . . . . . . . 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Open, unresolved issues about RFC 2131 include: -----------------------------------------------
| Key: |
| B: BROADCAST flag |
| MBZ: MUST BE ZERO (reserved for future use) |
-----------------------------------------------
1. What is the correct use of client identifier in DHCPOFFER and Figure 2: Format of the 'flags' Field
DHCPACK messages? 5.1.3 Figure 3: Timeline Diagram--Allocating a New Address
2. Are there any effective alternatives to ICMP ECHO and ARP for Server Server
address-in-use detection? (not selected) Client (selected)
3. What is the definition of a Fully Qualified Domain Name? v v v
| | |
| Begins initialization |
| | |
| ______________/|\______________ |
|/ DHCPDISCOVER | DHCPDISCOVER \|
| | |
Determines | Determines
configuration | configuration
| | /|
|\ | ____________/ |
| \___________ | / DHCPOFFER |
| DHCPOFFER \ |/ |
| \ | |
| \| |
| Collects replies |
| Selects configuration |
| | |
| ______________/|\______________ |
|/ DHCPREQUEST | DHCPREQUEST \|
| | |
| | Commits|
| | configuration|
| | |
| | ______________/|
| |/ DHCPACK |
| | |
| Initialization complete |
| | |
. . .
. . .
| | |
| Graceful shutdown |
| | |
| |\______________ |
| | DHCPRELEASE \|
| | |
| | Discards|
| | lease|
| | |
v v v
4. Should DHCPINFORM messages be allowed from client proxies? Figure 3: Timeline Diagram of Messages Exchanged between DHCP Client
and Servers When Allocating a New Network Address
5.1.4 Figure 4: Timeline Diagram--Reusing an Address
5. Should client proxies, in general, be allowed, and how does a Server Client Server
client proxy know the IP address of a DHCP server? v v v
| | |
| Begins |
| initialization |
| | |
| /|\ |
| ____________/ | \___________ |
| /DHCPREQUEST | DHCPREQUEST\ |
|/ | \|
| | |
Locates | Locates
configuration | configuration
| | |
|\ | /|
| \ | ___________/ |
| \ | / DHCPACK |
| \ _______ |/ |
| DHCPACK\ | |
| Initialization |
| complete |
| \| |
| | |
| (Subsequent |
| DHCPACKS |
| ignored) |
| | |
| | |
v v v
6. Should a DHCP server send only options requested by a client, Figure 4: Timeline Diagram of Messages Exchanged between DHCP
or should a server send all options for which it is configured Client and Servers When Reusing a Previously Allocated Address
with a value? 5.1.4 Figure 5: State-Transition Diagram for DHCP Clients
7. Should required usage of "xid" and "client identifier" be +-------+
changed to support server verification of DHCPRELEASE Have Unexpired | | Do Not Have
messages? +---- Lease ------| START |--- Lease ----+
V | | V
+--------+ +-------+ +-------+
| | +-------------------------->| |<-------------------+
| INIT- | | +------------------>| INIT | |
| REBOOT | DHCPNAK/ | +-------->| |<---------------+ |
| | Restart | | +---+---+ | |
+----+---+ | | | | | |
| | DHCPNAK/ | Broadcast | |
Broadcast | Discard offer | DHCPDISCOVER | |
DHCPREQUEST | | DHCPACK | | |
| | | (not accepted)/ v | |
V | | Send +-----------+ | |
+---------+-+ | DHCPDECLINE | |<-----+ | |
| | | | | SELECTING | | | |
| REBOOTING | | +----+ | | DHCPOFFER/ | |
| | | | +-+-------+-+ Collect | |
+-+---------+ | | | | replies | |
| | | Select offer/ | | | |
DHCPACK/ | | send +--------+ | |
Record lease, set | | DHCPREQUEST | |
timers T1, T2 +-+----+-----+ | DHCPNAK, |
| | |<-------+ Lease expires/ |
| +-------->| REQUESTING | Halt network |
| | | | | |
| DHCPOFFER/ +-+--------+-+ +-----------+ | |
| Discard | | | | | |
| | | DHCPACK (accepted)/ +----+ REBINDING +---+ |
| +-----------+ Record lease, set | | | |
| timers T1, T2 | +-----------+ |
| | DHCPACK/ ^ |
| | Record lease, set | |
| | timers T1, T2 | |
| | | T2 expires/ |
| v | Broadcast |
| +-----+-+ | DHCPREQUEST |
+----------------->| +<-----------+ | |
+-------------------+ BOUND +-------------------------+ |
| DHCPOFFER,+--->| |<-------------+ |
| DHCPACK, or| +-+---+-+ | |
| DHCPNAK/ | | | DHCPACK/ |
| Discard +------+ | Record lease, set |
| T1 expires/ timers T1, T2 |
| Send DHCPREQUEST | |
| to leasing server +-----+----+ |
| | | | |
Lease expires/ | | RENEWING +--DHCPNAK/ ----->|
halt network +--------->| | halt network |
| +----------+ |
+-----------------------------------------------------------------+
8. What is the correct statement about selecting an IP address to Figure 5: State-transition diagram for DHCP clients
offer a client when the offered address is on a different 5.2 Tables
subnet than the client's "giaddr?"
9. Should a new flags bit to signify "more options data 5.2.1 Table 1: Description of fields in a DHCP Message
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 |FIELD |OCTETS|DESCRIPTION |
fragmenting or dropping packets? -----------------------------------------------------------------------
|'op' | 1 |Message op code / message type. |
| | |1 = BOOTREQUEST, 2 = BOOTREPLY |
|'htype' | 1 |Hardware address type, see ARP section in "Assigned |
| | |Numbers" RFC; e.g., '1' = 10mb Ethernet. |
|'hlen' | 1 |Hardware address length (e.g., '6' for 10mb |
| | |Ethernet). |
|'hops' | 1 |Client sets to zero, optionally used by relay agents|
| | |when booting via a relay agent. |
|'xid' | 4 |Transaction ID, a random number chosen by the |
| | |client, used by the client and server to associate |
| | |messages and responses between a client and a |
| | |server. |
|'secs' | 2 |Filled in by client, seconds elapsed since client |
| | |began address acquisition or renewal process. |
|'flags' | 2 |Flags (see Figure 2). |
|'ciaddr' | 4 |Client IP address; only filled in if client is in |
| | |BOUND, RENEW or REBINDING state and can respond |
| | |to ARP requests. |
|'yiaddr' | 4 |"your" (client) IP address. |
|'siaddr' | 4 |IP address of next server to use in bootstrap; |
| | |returned in DHCPOFFER, DHCPACK by server. |
|'giaddr' | 4 |Relay agent IP address, used in booting via a |
| | |relay agent. |
|'chaddr' | 16 |Client hardware address. |
|'sname' | 64 |Optional server host name, null terminated string. |
|'file' | 128 |Boot file name, null terminated string; "generic" |
| | |name or null in DHCPDISCOVER, fully qualified |
| | |directory-path name in DHCPOFFER. |
|'options'|vari- |Optional parameters field. See the options |
| | able|documents for a list of defined options. |
-----------------------------------------------------------------------
11. Would it help to set a sort of "more to come" option, Table 1: Description of Fields in a DHCP message
indicating that more options will follow in a consecutive 5.2.2 Table 2: DHCP Messages
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 |Message |Usage |
case? ---------------------------------------------------------------------
|DHCPDISCOVER|Client broadcast to locate available servers. |
| | |
|DHCPOFFER |Server to client in response to DHCPDISCOVER with |
| |offer of configuration parameters. |
| | |
|DHCPREQUEST |Client message to servers either (a) requesting |
| |offered parameters from one server and implicitly |
| |declining offers from all others, (b) confirming |
| |correctness of previously allocated address after, |
| |e.g., system reboot, or (c) extending the lease on a |
| |particular network address. |
| | |
|DHCPACK |Server to client with configuration parameters, |
| |including committed network address. |
| | |
|DHCPNAK |Server to client indicating client's notion of network|
| |address is incorrect (e.g., client has moved to new |
| |subnet) or client's lease as expired |
| | |
|DHCPDECLINE |Client to server indicating network address is already|
| |in use. |
| | |
|DHCPRELEASE |Client to server relinquishing network address and |
| |canceling remaining lease. |
| | |
|DHCPINFORM |Client to server, asking only for local configuration |
| |parameters; client already has externally configured |
| |network address. |
---------------------------------------------------------------------
13. What level of consistency is required among responses from Table 2: DHCP Messages
multiple servers? 5.2.3 Table 3: Fields Used by DHCP Servers
4.2. Changes from Prior Drafts ---------------------------------------------------------------------
|Field |DHCPOFFER |DHCPACK |DHCPNAK |
---------------------------------------------------------------------
|'op' |2 |2 |2 |
|'htype' | (From "Assigned Numbers" Database) |
|'hlen' | (Hardware address length in octets) |
|'hops' |0 |0 |0 |
|'xid' |'xid' from client |'xid' from client |'xid' from client |
| |DHCPDISCOVER |DHCPREQUEST |DHCPREQUEST |
| |message |message |message |
|'secs' |0 |0 |0 |
|'ciaddr' |0 |'ciaddr' from |0 |
| | |DHCPREQUEST or 0 | |
|'yiaddr' |IP address offered |IP address |0 |
| |to client |assigned to client| |
|'siaddr' |IP address of next |IP address of next|0 |
| |bootstrap server |bootstrap server | |
|'flags' |'flags' from |'flags' from |'flags' from |
| |client DHCPDISCOVER|client DHCPREQUEST|client DHCPREQUEST|
| |message |message |message |
|'giaddr' |'giaddr' from |'giaddr' from |'giaddr' from |
| |client DHCPDISCOVER|client DHCPREQUEST|client DHCPREQUEST|
| |message |message |message |
|'chaddr' |'chaddr' from |'chaddr' from |'chaddr' from |
| |client DHCPDISCOVER|client DHCPREQUEST|client DHCPREQUEST|
| |message |message |message |
|'sname' |Server host name |Server host name |(unused) |
| |or options |or options | |
|'file' |Client boot file |Client boot file |(unused) |
| |name or options |name or options | |
|'options'|(see Table 4) |(see Table 4) |(see Table 4) |
---------------------------------------------------------------------
The "-01" revision contains substantial changes following a detailed Table 3: Fields Used by DHCP Servers
review of DHC Working Group mailing list discussions on RFC 2131 5.2.4 Table 4: Options Used by DHCP servers
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. |Option |DHCPOFFER|DHCPACK |DHCPNAK |
---------------------------------------------------------------------
|Requested IP address |MUST NOT |MUST NOT |MUST NOT|
|IP address lease time |MUST |MUST (DHCPREQUEST) |MUST NOT|
| | |MUST NOT (DHCPINFORM)| |
|Use 'file'/'sname' fields |MAY |MAY |MUST NOT|
|DHCP message type |DHCPOFFER|DHCPACK |DHCPNAK |
|Parameter request list |MUST NOT |MUST NOT |MUST NOT|
|Message |SHOULD |SHOULD |SHOULD |
|Client identifier |MUST NOT |MUST NOT |MAY |
|Vendor class identifier |MAY |MAY |MAY |
|Server identifier |MUST |MUST |MUST |
|Maximum message size |MUST NOT |MUST NOT |MUST NOT|
|All others |MAY |MAY |MUST NOT|
---------------------------------------------------------------------
o Elimination of "Interaction with DNS" and "Client and Server Table 4: Options Used by DHCP servers
Administration" sections because the authors saw no clear
resolution to the topics.
o Creation of an issues list in section 4.1. 5.2.5 Table 5: Client Messages from Different States
The "-00" revision was the initial version of this memo, submitted to ---------------------------------------------------------------------
the Internet-Drafts editor on 23 February 2003. | |INIT-REBOOT |SELECTING |RENEWING |REBINDING |
---------------------------------------------------------------------
|broad/uni-cast|broadcast |broadcast |unicast |broadcast |
|server-ip |MUST NOT |MUST |MUST NOT |MUST NOT |
|requested-ip |MUST |MUST |MUST NOT |MUST NOT |
|ciaddr |zero |zero |IP address |IP address|
---------------------------------------------------------------------
5. Acknowledgements Table 5: Client Messages from Different States
5.2.6 Table 6: Fields Used by DHCP Clients
---------------------------------------------------------------------
|Field |DHCPDISCOVER, |DHCPREQUEST |DHCPDECLINE, |
| |DHCPINFORM | |DHCPRELEASE |
---------------------------------------------------------------------
|'op' |1 |1 |1 |
|'htype' | (From "Assigned Numbers" Database) |
|'hlen' | (Hardware address length in octets) |
|'hops' |0 |0 |0 |
|'xid' |selected by client|'xid' from server |selected by |
| | |DHCPOFFER message |client |
|'secs' |seconds since |seconds since |0 |
| |DHCP process |DHCP process | |
| |started |started | |
|'flags' |Set 'BROADCAST' |Set 'BROADCAST' |0 |
| |flag if client |flag if client | |
| |requires broadcast|requires broadcast | |
| |reply |reply | |
|'ciaddr' |0 (DHCPDISCOVER) |0 or client's |0 (DHCPDECLINE) |
| |client's |network address |client's network |
| |network address |(BOUND/RENEW/REBIND)|address |
| |(DHCPINFORM) | |(DHCPRELEASE) |
|'yiaddr' |0 |0 |0 |
|'siaddr' |0 |0 |0 |
|'giaddr' |0 |0 |0 |
|'chaddr' |client's hardware |client's hardware |client's hardware|
| |address |address |address |
|'sname' |options, if |options, if |(unused) |
| |indicated in |indicated in | |
| |'sname/file' |'sname/file' | |
| |option; otherwise |option; otherwise | |
| |unused |unused | |
|'file' |options, if |options, if |(unused) |
| |indicated in |indicated in | |
| |'sname/file' |'sname/file' | |
| |option; otherwise |option; otherwise | |
| |unused |unused | |
|'options'|(see Table 7) |(see Table 7) |(see Table 7) |
---------------------------------------------------------------------
Table 6: Fields Used by DHCP Clients
5.2.7 Table 7: Options Used by DHCP Clients
---------------------------------------------------------------------
|Option |DHCPDISCOVER,|DHCPREQUEST |DHCPDECLINE, |
| |DHCPINFORM | |DHCPRELEASE |
---------------------------------------------------------------------
|Requested IP address |MAY |MUST (in |MUST |
| |(DISCOVER) |SELECTING or |(DHCPDECLINE)|
| |MUST NOT |INIT-REBOOT) |MUST NOT |
| |(INFORM) |MUST NOT (in |(DHCPRELEASE)|
| | |BOUND or | |
| | |RENEWING) | |
|IP address lease time |MAY |MAY |MUST NOT |
| |(DISCOVER) | | |
| |MUST NOT | | |
| |(INFORM) | | |
|Use 'file'/'sname' |MAY |MAY |MAY |
|fields | | | |
|DHCP message type |DHCPDISCOVER/|DHCPREQUEST |DHCPDECLINE/ |
| |DHCPINFORM | |DHCPRELEASE |
|Client identifier |MAY |MAY |MAY |
|Vendor class identifier|MAY |MAY |MUST NOT |
|Server identifier |MUST NOT |MUST (after |MUST |
| | |SELECTING) | |
| | |MUST NOT (after| |
| | |INIT-REBOOT, | |
| | |BOUND, RENEWING| |
| | |or REBINDING) | |
|Parameter request list |MAY |MAY |MUST NOT |
|Maximum message size |MAY |MAY |MUST NOT |
|Message |SHOULD NOT |SHOULD NOT |SHOULD |
|Site-specific |MAY |MAY |MUST NOT |
|All others |MAY |MAY |MUST NOT |
---------------------------------------------------------------------
Table 7: Options Used by DHCP Clients
5.2.8 Table 8: Host Configuration Parameters--IP Layer
---------------------------------------------------------------------
| IP-layer parameters, per host: |
---------------------------------------------------------------------
|Parameter | Permissible Values | Reference |
---------------------------------------------------------------------
|Be a router | on/off | HR 3.1 |
|Non-local source routing | on/off | HR 3.3.5 |
|Policy filters for | | |
|non-local source routing | (list) | HR 3.3.5 |
|Maximum reassembly size | integer | HR 3.3.2 |
|Default TTL | integer | HR 3.2.1.7 |
|PMTU aging timeout | integer | MTU 6.6 |
|MTU plateau table | (list) | MTU 7 |
---------------------------------------------------------------------
| IP-layer parameters, per interface: |
---------------------------------------------------------------------
|Parameter | Permissible Values | Reference |
---------------------------------------------------------------------
|IP address | (address) | HR 3.3.1.6 |
|Subnet mask | (address mask) | HR 3.3.1.6 |
|MTU | integer | HR 3.3.3 |
|All-subnets-MTU | on/off | HR 3.3.3 |
|Broadcast address flavor | 0.0.0.0 or | HR 3.3.6 |
| | 255.255.255.255 | |
|Perform mask discovery | on/off | HR 3.2.2.9 |
|Be a mask supplier | on/off | HR 3.2.2.9 |
|Perform router discovery | on/off | RD 5.1 |
|Router solicitation address | (address) | RD 5.1 |
|Default routers, list of: | | |
| router address | (address) | HR 3.3.1.6 |
| preference level | integer | HR 3.3.1.6 |
|Static routes, list of: | | |
| destination | (host/subnet/net) | HR 3.3.1.2 |
| destination mask | (address mask) | HR 3.3.1.2 |
| type-of-service | integer | HR 3.3.1.2 |
| first-hop router | (address) | HR 3.3.1.2 |
| ignore redirects | on/off | HR 3.3.1.2 |
| PMTU | integer | MTU 6.6 |
| perform PMTU discovery | on/off | MTU 6.6 |
---------------------------------------------------------------------
| Key: |
| HR -- Host Requirements Communications Layers (RFC 1122, |
| Internet Standard) |
| MTU -- Path MTU Discovery (RFC 1191, Proposed Standard) |
| RD -- Router Discovery (RFC 1256, Proposed Standard) |
---------------------------------------------------------------------
Table 8: Host Configuration Parameters--IP Layer
5.2.9 Table 9: Host Configuration Parameters--Link Layer
---------------------------------------------------------------------
| Link-layer parameters, per interface: |
---------------------------------------------------------------------
|Parameter | Permissible Values | Reference |
---------------------------------------------------------------------
|Trailers | on/off | HR 2.3.1 |
|ARP cache timeout | integer | HR 2.3.2.1 |
|Ethernet encapsulation | (RFC 894/RFC 1042) | HR 2.3.3 |
---------------------------------------------------------------------
| Key: |
| HR -- Host Requirements Communications Layers (RFC 1122, |
| Internet Standard) |
---------------------------------------------------------------------
Table 9: Host Configuration Parameters--Link Layer
5.2.10 Table 10: Host Configuration Parameters--TCP
---------------------------------------------------------------------
| TCP parameters, per host: |
---------------------------------------------------------------------
|Parameter | Permissible Values | Reference |
---------------------------------------------------------------------
|TTL | integer | HR 4.2.2.19 |
|Keep-alive interval | integer | HR 4.2.3.6 |
|Keep-alive data size | 0/1 | HR 4.2.3.6 |
---------------------------------------------------------------------
| Key: |
| HR -- Host Requirements Communications Layers (RFC 1122, |
| Internet Standard) |
---------------------------------------------------------------------
Table 10: Host Configuration Parameters--TCP
6 Contributors
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
this effort including Mike Carney of Sun Microsystems, Steve Tulloh to this effort including Mike Carney of Sun Microsystems, Steve
of Shadow Support, Bernie Volz, Ted Lemon of Nominum, Simon Vogl, Tulloh of Shadow Support, Bernie Volz, Ted Lemon of Nominum, Simon
Edward Mascarenhas of SGI, Andre Kostur of Incognito, Bud Millwood of Vogl, Edward Mascarenhas of SGI, Andre Kostur of Incognito, Bud
Weird Solutions, Patrick Guélat of ImproWare Network Services, and Millwood of Weird Solutions, Patrick Guélat of ImproWare Network
Swamy Narasimha of Nokia. Services, and Swamy Narasimha of Nokia.
6. IANA Considerations 7 IANA Considerations
This memo contains no values requiring IANA attention. This memo contains no values requiring IANA attention.
7. Security Considerations 8 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 threat
threat analysis of RFCs 2131 and 3118. analysis of RFCs 2131 and 3118.
8. References 9 References
9.1 Normative References
[RFC951] Croft, W., and Gilmore, J., "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," October 1989. and Support," October 1989.
[RFC1542] W. Wimer, "Clarifications and Extensions for the Bootstrap [RFC1542] W. Wimer, "Clarifications and Extensions for the Bootstrap
Protocol" RFC 1542, October 1993 Protocol" RFC 1542, October 1993
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol," March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol," March
1997.
[RFC2132] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and Droms, R., "DHCP Options and BOOTP
Extensions," March 1997. Vendor Extensions," March 1997.
9.2 Informative References
[RFC3203] T'Joens, Y., Hublet, C., and De Schrijver, P., "The DHCP [RFC3203] T'Joens, Y., Hublet, C., and De Schrijver, P., "The DHCP
Reconfigure Extension," July 2001. Reconfigure Extension," July 2001.
<draft-ietf-dhc-leasequery-05.txt> Woundy, R., and Kinnear, K., "DHCP [RFC4388] Woundy, R., and Kinnear, K., "Dynamic Host Configuration
Lease Query," March 2003. Protocol (DHCP) Leasequery," February 2006.
<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 <draft-ietf-dhc-fqdn-option-13.txt>, Stapp, M., and Rekhter, Y.,
option in server replies," July 2003. "The DHCP Client FQDN Option," March 2006.
9. Editors' Addresses Authors' Addresses
Richard Barr Hibbs Barr Hibbs
Richard Barr Hibbs, P.E.
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
Email: rbhibbs@pacbell.net E-mail: rbhibbs@pacbell.net
Rob Stevens Rob Stevens
308 Arthur Ave 308 Arthur Avenue
Aptos California 95003-5202 Aptos, California 95003-5202
USA USA
Phone:+1-(831)-688-9722 Phone:+1-(831)-688-9722
E-mail: robs@cruzio.com E-mail: robs@cruzio.com
10. Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society, 2003. All Rights Reserved. Copyright (C) The Internet Society (2006). All rights reserved.
This document and translations of it may be copied and furnished to This document is subject to the rights, licenses and restrictions
others, and derivative works that comment on or otherwise explain it contained in BCP 78, and except as set forth therein, the authors
or assist in its implementation may be prepared, copied, published retain all their rights.
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be This document and the information contained herein are provided on
revoked by the Internet Society or its successors or assigns. an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This document and the information contained herein is provided on an Intellectual Property
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
APPENDIX A: List of Vendors The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
------------------------------------------------------------------------ Copies of IPR disclosures made to the IETF Secretariat and any
|Vendor |Product |E-mail Address | assurances of licenses to be made available, or the result of an
------------------------------------------------------------------------ attempt made to obtain a general license or permission for the use
|2Wire |HomePortal |support@2Wire.com | of such proprietary rights by implementers or users of this
|3Com |Home Gateway | | specification can be obtained from the IETF on-line IPR repository
|3e Technologies | | | at http://www.ietf.org/ipr.
| International |Magnum |info@3eti.com |
|3K Group |Turbo Cell |info@3kgroup.com | The IETF invites any interested party to bring to its attention any
|Accelerated | | | copyrights, patents or patent applications, or other proprietary
| Technology |Nucleus |support@acceleratedtechnology.com| rights that may cover technology that may be required to implement
|ActionTec | | | this standard. Please address the information to the IETF at ietf-
| Electronics | | | ipr@ietf.org.
|ADTRAN |Netvanta 2100 | |
|Agere Systems |Orinoco RG-1000 | | Acknowledgement
|Apple Computer | |cheshire@apple.com |
|Appliansys |DNSBox 300 | | Funding for the RFC Editor function is provided by the IETF
|Argus | | | Administrative Support Activity (IASA).
| Technologies |EtherAccess 2000 |info@arguscorp.com |
|Ateonix Networks |NASAS-2040 |tech@ateonix.com | APPENDIX: NOTES
|Avaya |WAP | |
|Barbed Wire | | | This appendix will be removed when this memo goes to Working Group
| Technologies | | | Last Call.
|Broadband | | |
| Gateways |Evolo | | Issues List
|Caldera/SCO |Open Linux | |
| | Eserver |info@sco.com | Open, unresolved issues about RFC 2131 include:
|Cayman Systems | | |
|CheckPoint | | | 1. What is the correct use of client identifier in DHCPOFFER and
| Software | | | DHCPACK messages?
|Cisco Systems |Network | |
| |Registrar |kkinnear@cisco.com | 2. Are there any effective alternatives to ICMP ECHO and ARP for
|Cisco Systems |AIR-AP3000 | | address-in-use detection?
|Clavister | | |
|CLinux | | | 3. What is the definition of a Fully Qualified Domain Name?
|Compaq |Connection Point | |
|vCoNet | | | 4. Should DHCPINFORM messages be allowed from client proxies?
| Communications |XpressIP 8550 | |
|Cygsoft | |support@cygsoft.com | 5. Should client proxies, in general, be allowed, and how does a
|D-Link |DI-700 | | client proxy know the IP address of a DHCP server?
|Efficient | | |
| Networks | | | 6. Should a DHCP server send only options requested by a client, or
|Esoft |Redphish | | should a server send all options for which it is configured with
|Filanet |Interjak | | a value?
------------------------------------------------------------------------
------------------------------------------------------------------------ 7. Should required usage of "xid" and "client identifier" be
|Vendor |Product |E-mail Address | changed to support server verification of DHCPRELEASE messages?
------------------------------------------------------------------------
|FTP Software | | | 8. What is the correct statement about selecting an IP address to
|Helios |PCShare | | offer a client when the offered address is on a different subnet
|Incognito | | | than the client's "giaddr?"
| Software |Address Commander|support@incognito.com |
|InfoBlox |DNS One |support@infoblox.com | 9. Should a new flags bit to signify "more options data available"
|Internet Software | | | be added?
| Consortium |DHCPD |Ted.Lemon@nominum.com |
|AttachNet |Internet Pro SOHO|support@attachnet.com | 10. Do we need a new "Maximum Relay MTU Size" option to ensure that
|InterNiche |Portable DHCP | | all reply packets sent by a server will pass without fragmenting
| Techologies |Server |support@iniche.com | or dropping packets?
|JH Software |Simple DNSPlus |support@jhsoft.com |
|Leviton |Internet Gateway | | 11. Would it help to set a sort of "more to come" option, indicating
|Lightning |MultiCOM | | that more options will follow in a consecutive DHCPACK, where
|LinkSys |WAP-11 | | the subsequent DHCPACKs would have a "additional information"
|Lucent | | | option indicating that the message contains only new options
| Technologies |VitalQIP | | data similar to a DHCPACK in response to a DHCPINFORM message?
|Matrox Electronic | | |
| Systems |iSwitch |networks.techsupport@matrox.com | 12. Are unicast DHCPDISCOVER messages permitted? What are the
|UMax Technologies |UGate-3300 |support@umaxcare.com | requirements for specific message fields and options in this
|MDL Corporation |FileZerver NAS |help@mdlcorp.com | case?
|Microsoft | | |
| Corporation |Windows Server | | 13. What level of consistency is required among responses from
|MobiWave |Spyroz |support@mobiwave.com | multiple servers?
|Multi-Tech | | |
| Systems |RouteFinder VPN |support@multitech.com | 14. Can the REBINDING state be entered from the BOUND state on
|N3K |VitalQIP |info@n3k.co.uk | expiration of T2, or only if there is a timeout in RENEWING
|Net Integration | | | state?
| Technologies |Net Integrator |support@net-itech.com | 15. Should the text of RFC 4361, Node-Specific Client Identifiers,
|Netgear |RP334 | | be folded into a revised RFC 2131 and RFC 2132?
|NetWinder | | |
|Network | | | 16. Should the text of RFC 4388, DHCP Leasequery, be folded into a
| TeleSystems | |suppport@shadowsupport.com | revised RFC 2131 and RFC 2132?
|Nokia |IP30 |internetapac@nokia.com |
|Nominum, Inc. |DCS |Eric.Luce@nominum.com | Changes from Prior Drafts
|Nortel |Net ID |gww@nortelnetworks.com |
|Novell | | | "-00" Draft
|On Technology |IP Track |support@on.com |
|Panasonic |KX-HGW200 | | The "-00" revision was the initial version of this memo, submitted
|Paul Smith | | | to the Internet-Drafts editor on 23 February 2003.
| Computer Svcs |vDHCP |support@pscs.co.uk |
|PGP |PGP-5 | | "-01" Draft
|Phoenix | | |
| Technologies |ViewPoint | | 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,
|Vendor |Product |E-mail Address | and comments received by the authors. Changes include:
------------------------------------------------------------------------
|Powerwallz |ProShield | | O Reorganization of the document to group all typographical errors
|PresiNET Systems | | | together, separate from protocol or policy issues.
|Proxim |Skyline | |
|Rapidstream |Rapidstream 500 | | O Elimination of "Interaction with DNS" and "Client and Server
|Siemens | | | Administration" sections because the authors saw no clear
|SnapGear | |support@snapgear.com | resolution to the topics.
|Sonic Wall |SOHO | |
|Sun Microsystems | | | O Creation of an issues list in section 4.1.
|Symantec |VPN-100 | |
|Teneo |NetScreen | | "-02" Draft
|Threshold | | |
| Networks |Edge | | The "-02" revision consists of numerous minor typographical,
|Trellis Network | | | spelling, and grammatical updates, plus:
| Services |DNS ONE | |
|Weird Solutions |DHCP Turbo | | O Replaced all Internet-Draft Boilerplate with current versions.
------------------------------------------------------------------------
O Removed all of Section 5, "Notes" to this appendix.
O Replaced Section 5 with the proposed figures and tables for use
with revised text of RFC 2131-bis.
O Removed Appendix A.
O Separation of Section 9, "References," into Normative and
Informative subsections.
O Updated Authors' Addresses.
O Added text to Section 4.5.1 covering RFC 4361, "Node-Specific
Client Identifiers for DHCPv4."
O Recent mailing list discussion about the correct use of the
"secs" field was incorporated into Section 4.22.
 End of changes. 288 change blocks. 
682 lines changed or deleted 1193 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/