[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]
Versions: 00 01 02
Network Working Group Barr Hibbs
INTERNET-DRAFT (no affiliation)
Category: Informational February 2003
Implementation Issues with RFC 2131, "Dynamic Host Configuration
Protocol"
<draft-ietf-dhc-implementation-00.txt>
Saved Monday, February 24, 2003, 12:51:05 AM
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) 2003, The Internet Society. All Rights Reserved.
Abstract
This memo identifies implementation issues with RFC 2131, "Dynamic
Host Configuration Protocol," reported by a number of implementors,
assesses the severity of the problem, then proposes changes to RFC
2131 intended to overcome the issues. This is intended for use as
the basis for discussion of RFC 2131 before it is proposed for
Internet Standard status.
Hibbs Expires: Feb 2003 + 6 months [Page 1]
Internet Draft RFC 2131 Implementation Issues February 2003
Table of Contents
1. Introduction...................................................2
2. Issues with RFC 2131...........................................3
2.1. The DHCP Client Identifier.................................3
2.2. Address-in-Use Detection...................................4
2.3. DHCP Relay Agents..........................................4
2.4. Host Name, Domain Name, and FQDNs..........................4
2.5. Conflicts with Host Requirements [RFC1123].................4
2.6. What Are Default Values?...................................4
2.7. Overloading of DHCPREQUEST.................................5
2.8. DHCPRELEASE................................................5
2.9. Which Options to Return?...................................5
2.10. Recovery from Address Assignment Conflicts................6
2.11. Interaction with DNS......................................6
2.12. Client and Server Administration..........................6
2.13. Lack of Clarity...........................................6
2.13.1. Vendor and User Classes..............................7
2.13.2. Option Selection.....................................7
2.13.3. Client / Server retransmission.......................8
2.13.4. Transmission of DHCP NAKs............................8
2.13.5. Minimum size of a BOOTP / DHCP frame.................8
2.13.6. Use of ciaddr........................................9
2.13.7. Duplicate IP address detection.......................9
2.13.8. Clarify use of Vendor class identifier (form).......10
2.13.9. DHCP MTU option.....................................11
2.13.10. SHOULDs that should be MUSTs.......................12
2.13.11. Just wrong.........................................12
2.13.12. Just unclear.......................................13
2.14. Inconsistencies..........................................13
2.15. Escape Hatches or Trapdoors in Protocol..................14
2.16. Typographical Errors.....................................14
3. Suggested Changes to RFC 2131.................................16
4. Intellectual Property.........................................17
5. Notes.........................................................17
5.1. Issues....................................................17
5.2. Changes from Prior Drafts.................................17
6. Acknowledgements..............................................17
7. IANA Considerations...........................................18
8. Security Considerations.......................................18
9. References....................................................18
10. Editors' Addresses...........................................18
11. Full Copyright Statement.....................................19
1. Introduction
This memo was produced by the DHC Working Group and attempts to
identify all known implementation issues with RFC 2131 as a basis for
Hibbs Expires: Feb 2003 + 6 months [Page 2]
Internet Draft RFC 2131 Implementation Issues February 2003
discussion of RFC 2131 before it is published as an Internet
Standard.
This memo grew from a discussion item during the DHC Working Group
meeting at IETF-55 in Atlanta during November 2002.
The editors have solicited input through a general call for
participation and by direct request to all implementors that they
could identify. The list of contributors to this effort is presented
in Appendix A, while the list of vendors contacted is presented in
Appendix B.
The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL
NOT," "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and
"OPTIONAL" in this document are to be interpreted as described in
document [RFC2119].
2. Issues with RFC 2131
This list may not include every implementation issue for RFC 2131 as
it is based on reported problems and those known to the editor.
2.1. The DHCP Client Identifier
DHCP servers must somehow uniquely identify DHCP clients that are
requesting services in order to correctly configure the client. RFC
2131 provides two specific methods for identifying a client: (1) the
client identifier (DHCP Option 61) [RFC2132], and (2) the "chaddr"
field of the BOOTPREQUEST packet.
Confusion arises from the language of RFC 2131 Section 4.2. A DHCP
client "...MAY choose to explicitly provide the identifier through
the 'client identifier' option. If the client supplies a 'client
identifier', the client MUST use the same 'client identifier' in all
subsequent messages, and the server MUST use that identifier to
identify the client. If the client does not provide a 'client
identifier' option, the server MUST use the contents of the 'chaddr'
field to identify the client."
The text of the quoted section goes on to state that subnet
uniqueness is a requirement for an identifier, but points out that
"chaddr" may not satisfy that requirement. Two alternative
suggestions for a unique identifier are and unspecified
manufacturer's hardware identifier or a DNS name.
RFC 2132 adds to the confusion by stating that the client identifier
"...is expected to be unique for all clients in an administrative
domain" without specifying what an "administrative domain" is.
Hibbs Expires: Feb 2003 + 6 months [Page 3]
Internet Draft RFC 2131 Implementation Issues February 2003
RFC 2132 continues by suggesting use of "...type-value pairs similar
to the 'htype'/'chaddr' fields defined in..." [RFC951], and that a
"...hardware type of 0 (zero) should be used when the value field
contains an identifier other than a hardware address (e.g., a fully
qualified domain name)."
This suggestion of using type-value pairs has been widely adopted by
DHCP client implementors, but the suggestion fails to heed the
warning about uniqueness issues with "chaddr."
RFC 2131 SHOULD have made global (or, at least, "administrative
domain"), rather than subnet, uniqueness MANDATORY for the "client
identifier."
RFC 2131 SHOULD NOT have suggested the use of DNS names for the
"client identifier" without also suggesting some mechanism for
maintaining a consistent name-to-address mapping.
RFC 2132 SHOULD NOT have suggested using the "htype" and "chaddr"
fields as a type-value pair because of the warning in RFC 2131
Section 4.2 about potential problems using "chaddr" for the purpose.
RFC 2132 SHOULD NOT have used the word "should" when suggesting the
use of type-value pairs for "client identifier" with a type of 0
(zero) when the value is anything other than a hardware address.
2.2. Address-in-Use Detection
2.3. DHCP Relay Agents
(To be added)
2.4. Host Name, Domain Name, and FQDNs
(To be added)
2.5. Conflicts with Host Requirements [RFC1123]
(To be added)
2.6. What Are Default Values?
(To be added)
Hibbs Expires: Feb 2003 + 6 months [Page 4]
Internet Draft RFC 2131 Implementation Issues February 2003
2.7. Overloading of DHCPREQUEST
The DHCPREQUEST message is sent by the client in several different
states: INIT, INIT-REBOOT, REBINDING, and RENEWING. Differentiation
among the states is done according to the context of other packet
fileds.
2.8. DHCPRELEASE
There were several MUST NOT entries in the table that specifies the
inclusion of options in the DHCPRELEASE. A bogus DHCPRELEASE should
not be allowed to release a lease I set about to check if any
"illegal" options were included in the DHCPRELEASE message and toss
the request with a complaint if there were.
Some customers complained that a particular vendor included the
"hostname" option and that this seemed innocuous. The vendor said
that their reading of the RFC allows such an option to be included.
In a table just above the table that specifies "all others" as MUST
NOT there is the word "unused" for "options" for the DHCPRELEASE.
Could that be what the vendor was thinking?
What is appropriate here? It is also unclear why these MUST NOT's
exist.
2.9. Which Options to Return?
There is some question about the intent of RFC 2131 with regard to
the client options to send. In Section 3.5 there is no mention of a
minimum set of parameters to be sent to a requesting client, nor any
mention of which parameters to send if the client does not request
any.
"First, most parameters have defaults defined in the Host
Requirements RFCs; if the client receives no parameters from the
server that override the defaults, a client uses those default
values." The list of parameters with a cross-reference to the
defining RFC is given in Appendix A of RFC 2131.
Several sources contend that there is no parameter in the list for
which a viable default value exists, which raises the issue of
viability of the technique described in this section for reducing
total server response message size.
RFC 2131 is silent on the question of whether or not the server MUST,
SHOULD, or MAY choose not to send an option if its value is the same
as a default per the Host Requirements.
Hibbs Expires: Feb 2003 + 6 months [Page 5]
Internet Draft RFC 2131 Implementation Issues February 2003
Section 3.5 of RFC 2131 describes two mechanisms to limit the number
of options sent, but offers no guidance for what to do when there is
more data than will fit in a response packet. Can the options be
somehow prioritized? Could additional options be obtained using the
DHCPINFORM mechanism?
Section 4.3.1 presents apparently conflicting specifications for how
to select values for options requested by a client:
"IF the server has been explicitly configured with a default
value for the parameter, the server MUST include that value in
an appropriate option in the 'option' field, ELSE
"IF the server recognizes the parameter as a parameter defined
in the Host Requirements Document, the server MUST include the
default value for that parameter as given in the Host
Requirements Document in an appropriate option in the 'option'
field, ELSE
"The server MUST NOT return a value for that parameter"
The second of these statements seems contrary to the intent of
minimizing the amount of data sent by the server: if the scope of
the Host Requirements RFCs applies to all Internet-connected hosts,
then a DHCP server SHOULD NOT have to supply these values -- they
should already be assumed by the client as the default for the
requested option.
2.10. Recovery from Address Assignment Conflicts
(To be added)
2.11. Interaction with DNS
(To be added)
2.12. Client and Server Administration
(To be added)
2.13. Lack of Clarity
This section identifies parts of RFC 2131 where the intended meaning
is unclear.
Hibbs Expires: Feb 2003 + 6 months [Page 6]
Internet Draft RFC 2131 Implementation Issues February 2003
2.13.1. Vendor and User Classes
Page 3, section 1.1, first paragraph - includes the following
sentence: "The classing mechanism for identifying DHCP clients to
DHCP servers has been extended to include "vendor" classes as defined
in sections 4.2 and 4.3." Vendor classing has been there since RFC
1541, thus there isn't anything new about it. Should this section be
referring to User classing?
2.13.2. Option Selection
Should a DHCP server return all options that have been explicitly
configured, or return only those options a client has requested
regardless of what is configured on the server? Clients are required
to include the same parameter request list on all messages. There
are two diverging schools of thought regarding which options should
be returned: always return every option configured by the network
administrator, or only return those options specifically requested by
a client.
A DHCP server should always return options that have been configured
by the network administrator, for the following reasons:
1. Consistency. A network administrator wants all of the configured
options to show up on each client on the network, regardless of
client vendor.
2. A DHCP client is likely only going to request the options it
supports. However, there are many application layer options that
are not used by the DHCP client but are useful to applications.
3. A DHCP client would either need to be configured or updated to
request new options. The whole idea of DHCP is to keep
configuration on the server, not on the client, which is pointed
out in: Page 7, second and third bullets of section 1.6.
At Connectathon, the argument was made that some DHCP clients would
break if they received new options, and therefore a DHCP server
should only return the options a client requested.
o Page 5, second paragraph of section 1.3
o Page 21, first paragraph of section 3.5
o Page 29, list items entitled "Parameters requested by the
client, according to the following rules:"
o Page 36, first paragraph of section 4.4.1
Hibbs Expires: Feb 2003 + 6 months [Page 7]
Internet Draft RFC 2131 Implementation Issues February 2003
2.13.3. Client / Server retransmission
Because DHCP servers are the passive participants and DHCP clients
are the active participants, the DHCP protocol is susceptible to
poorly behaved clients (retransmit too fast). However, there is no
text describing this susceptibility. Furthermore, the use of the
power-of-2 retransmission algorithm is a SHOULD/MAY. This probably
should be a MUST. If we need different retransmission algorithms for
different media, then we should develop / document them in table
form. The specification as it stands is too loose and does cause
inter-operability problems.
1. Page 17, third paragraph of list item 5, section 3.1
2. Page 24, eighth paragraph of section 4.1
3. Page 36, first paragraph of section 4.4.1
2.13.4. Transmission of DHCP NAKs
DHCP NAKs MUST be broadcast. However, the text describing a server's
behavior when the client is accessible through a BOOTP relay agent is
inconsistent.
1. Page 19, last paragraph of list item 2, section 3.2
2. Page 23, fifth paragraph of section 4.1
3. Page 32, Last paragraph of "DHCPREQUEST generated during INIT-
REBOOT state:" bullet, section 4.3.2.
This last reference describes the behavior that's required -- a
server MUST set the broadcast bit in order for the relay agent to
properly broadcast the DHCPNAK. We just need to either refer to it
in the first two references or duplicate it there.
2.13.5. Minimum size of a BOOTP / DHCP frame
RFC 951 states that a BOOTP frame is 300 bytes in length. Some BOOTP
relay agents thus drop frames less than 300 bytes in length. RFC 951
is explicit on this point, but RFC 2131 just refers to RFC 951. We
SHOULD add a line stating that the minimum size of a DHCP frame is
300 bytes in reference:
Page 10, first paragraph after Table 1, section 2
After all, DHCP is intended to be backward compatible with BOOTP.
Hibbs Expires: Feb 2003 + 6 months [Page 8]
Internet Draft RFC 2131 Implementation Issues February 2003
2.13.6. Use of ciaddr
RFC 951 - clients use ciaddr when they've received an IP address from
a source outside of BOOTP, and thus should be able to respond to
ARPs.
The text in RFC 2131 is mostly supportive of this point with the
following exception:
Page 21, first sentence of last para, section 3.4: "The server
SHOULD check the network address in a DHCPINFORM message for
consistency, but MUST NOT check for an existing lease."
This line should be struck from the document. Servers trust ciaddr,
period.
Likewise, the following line should also be struck:
Page 32, "DHCPREQUEST generated during REBINDING state:",
section 4.3.2: "The DHCP server SHOULD check 'ciaddr' for
correctness before replying to the DHCPREQUEST"
2.13.7. Duplicate IP address detection
The specification specifies the requirement that DHCP guarantee that
an IP address is not in use. However, the protocol itself does not
meet this requirement.
Page 7, Second set of bullet items, first bullet, section 1.6
specifies that "Guarantee that any specific network address will not
be in use by more than one DHCP client at a time."
This should be "host" rather than "DHCP client." The specification
describes two mechanisms, a ICMP echo request generated by the DHCP
server and an ARP request generated by the DHCP client. To meet this
requirement, I think a DHCP client MUST validate the IP address
contained in a DHCPACK before using it, and that a DHCP server MAY
validate an IP address using an ICMP echo request before OFFERing it
to a client. Right now, both mechanisms are SHOULD's. Relevant
references:
o Page 12, second paragraph of section 2.2, last sentence
o Page 13, list item 2, section 3.1
o Page 38, first paragraph after Table 5, section 4.4.1
Hibbs Expires: Feb 2003 + 6 months [Page 9]
Internet Draft RFC 2131 Implementation Issues February 2003
2.13.8. Clarify use of Vendor class identifier (form)
What characters are legal?
Some new clients have spaces in their identifier, which broke some
implementations with configuration file records delimited by
whitespace.
What is the form of the name space?
Originally (1541 time-frame), we had discussed using "Stock
symbol/Organization...." form to prevent collisions between vendors,
e.g., "SUNW.class-1.class-2" or "CMU.edu.class-1.class-2". This
text should be included in 2132.
Text describing each unique vendor class identifier can support a 253
unique encapsulated option name space. Some folks think that there
is only one 253 unique encapsulated option name space, and return the
same values to *any* client returning *any* vendor class identifier.
Obviously, we should include text to clarify the relationship between
Vendor Class identifier and the encapsulated Vendor option.
How many Vendor class identifiers can a client have?
Only one, as there is only one DHCP client vendor. It is impossible
to have more than one, since there would be no way to know which
encapsulated option went with which Vendor Class.
Here is some more text regarding vendor options from a note from Mike
Carney regarding the use of Vendor class / encapsulated options:
"Successful Vendor class support requires the ability to configure a
DHCP server to support a new vendor class by associating that vendor
class identifier with 253 options whose types can then be defined by
following the DHCP client's documentation. Each group of 253 options
has the "scope" of that Vendor. For example, let's say we have the
following two clients:
Vendor Class "SunBeam.Toaster.2slots"
Options for this class:
Code Len Data
1 2 Darkness setting
Darkness setting is a 2 byte integer.
Hibbs Expires: Feb 2003 + 6 months [Page 10]
Internet Draft RFC 2131 Implementation Issues February 2003
Vendor Class "GE.Answering.Machine"
Options for this class:
Code Len Data
1 X Outgoing message
Outgoing message is an ASCII string, X bytes long, consisting
of the text of the answer message.
Both clients are on the same network "Kitchen," and are clients of
the same DHCP server. Note that both use Encapsulated option code 1.
Looks like a conflict, but it isn't.
In the syntax of the DHCP server's configuration table, I configure
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
returns vendor class options associated with the
"SunBeam.Toaster.2slots" class. When the answering machine boots,
it only seens vendor class options associated with the
"GE.Answering.Machine" class. Clients of vendor classes not
currently configured on the server don't see any encapsulated vendor
options, since the server hasn't been configured to support that
vendor class. The DHCP server can make this distinction based upon:
o The client identifies it's vendor class.
o The server can be (and has been) configured to associate each
client's vendor options with the client's class identifier.
2.13.9. DHCP MTU option
DHCP messages can't be fragmented, since there is no way to deliver
them to remote networks via a relay agent (fragments won't contain
the BOOTP header which the relay agent needs to deliver the DHCP
response). As such, Clients really SHOULD communicate their link-
layer frame size to the DHCP server via the DHCP MTU option. We
should clarify this point both in the DHCP and BOOTP specifications.
We should consider changing SHOULD to MUST in this case.
Page 21, second para, section 3.5
Hibbs Expires: Feb 2003 + 6 months [Page 11]
Internet Draft RFC 2131 Implementation Issues February 2003
2.13.10. SHOULDs that should be MUSTs
There are many SHOULDs and SHOULD NOTs that should be converted into
MUSTs or MUST NOTs. Too many to list, but here's a few:
4. Page 12, second paragraph of section 2.2: "... and the client
SHOULD probe the newly received address, e.g. with ARP" (MUST)
5. Page 16, item 4, section 3.1 "The server SHOULD NOT check the
offered network address at this point." (MUST NOT)
6. Page 16, item 5, section 3.1 "The client SHOULD perform a final
check on the parameters..." (MUST)
7. Page 17, item 5, section 3.1 "The client SHOULD wait a minimum of
ten seconds..." (MUST)
8. Page 18, item 2, section 3.2 "Servers SHOULD NOT check that the
client's network address is already in use;..." (MUST NOT)
9. Page 19, item 2, second para, section 3.2 "...servers SHOULD
respond with a DHCPNAK message to the client" (MUST) The
following sentences are rather dubious in this paragraph as well.
10. Page 21, first para, section 3.4 "The servers SHOULD unicast the
DHCPACK replay to the address given int he 'ciaddr' field of the
DHCPINFORM message" (MUST)
11. Page 22, last para, section 3.5 "If a server receives a DHCP
request message with an invalid 'requested IP address', the
server SHOULD respond to the client with a DHCPNAK message..."
(MUST)
and so on. We should review the MAY/SHOULD/MUST (NOT)s in the spec,
and tighten up those we can. SHOULDs should list the valid
exceptions (some do; most don't).
2.13.11. Just wrong
Page 23, fifth para, section 4.1: "If the 'giaddr field is zero and
the 'ciaddr' field is nonzero, then the server unicasts DHCPOFFER and
DHCPACK messages to the address in 'ciaddr'". True for DHCPACK,
false for DHCPOFFER (a DHCPDISCOVER will never have anything but 0 as
ciaddr)
Page 24, seventh para, section 4.1: "Options may appear only once,
unless otherwise specified in the options document. The client
concatenates the values of multiple instances of the same option into
a single parameter list for configuration" The first sentence should
Hibbs Expires: Feb 2003 + 6 months [Page 12]
Internet Draft RFC 2131 Implementation Issues February 2003
start out "Options MUST appear only once, unless...". The second
sentence belongs in the options draft for options where there can be
multiple instances. Together, these two sentences are confusing.
2.13.12. Just unclear
Page 30, second from last bullet, section 4.3.1. This item makes no
sense: "client's vendor class identifiers and client's classes
identified in the server.."?
Page 16, last sentence of list item 3, section 3.1 "The client times
out and retransmits the DHCPDISCOVER message if the client receives
no DHCPOFFER messages." How long should the client wait?
2.14. Inconsistencies
1. Page 1, Abstract, "TCPIP" should be "TCP/IP" -- like it is in the
rest of the document.
2. Lack of consistency when describing "IP broadcast." Sometimes
it's 0xffffffff IP broadcast, other times "limited broadcast" or
"broadcast." Suggest using the "255.255.255.255 IP broadcast
address" form, as that is the most specific.
3. Page 19, third paragraph of section 3.2, List item #2
4. Page 23, fifth paragraph of section 4.1
5. Page 25, thirteenth paragraph of section 4.1
6. Page 32, section 4.3.2, third bullet item
7. Page 32, section 4.3.2, fifth bullet item
8. Page 36, second paragraph of section 4.4.1
9. Page 39, last paragraph of section 4.4.1
10. Page 39, second paragraph of section 4.4.3
11. Page 40, first paragraph of 4.4.4
12. Page 40, second paragraph of 4.4.4
13. Page 41, fifth paragraph of 4.4.5
Hibbs Expires: Feb 2003 + 6 months [Page 13]
Internet Draft RFC 2131 Implementation Issues February 2003
2.15. Escape Hatches or Trapdoors in Protocol
This section describes incomplete changes that result in
interoperability problems.
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.'" We go through great detail in the
rest of the draft trying to get the use of giaddr clear as it relates
to BOOTP relay agents (RFC 951 and RFC 1542), then this sentence
basically "undoes" this work. Serving multiple IP networks on the
same wire should be either described in detail in its own section
(with caveats) or as a separate informational RFC. Otherwise, the
use of giaddr is unclear.
2.16. Typographical Errors
1. Page 23, second paragraph of section 4.1 - "recieved" ->
"received"
2. Page 23, sixth paragraph of section 4.1 - refers to RFC 1533, not
RFC 2132
3. Page 15, Figure 3. Table misformatted.
4. Page 18, Figure 4. Table misformatted.
5. Page 25, eleventh paragraph of section 4.1 - "uicast" ->
"unicast"
6. Page 33, Table 4 - missing column for DHCPINFORM
7. Page 38, First paragraph after Table 5. Orphaned sentence: "The
DHCPREQUEST message contains the same 'xid' as the DHCPOFFER
message" No it doesn't. Not only that, but this sentence makes
no sense in its current location. It should be removed.
8. Page 39, Last paragraph of 4.4.3 should be moved up as the last
paragraph of 4.4.2. When the text for DHCPINFORM was added, the
text describing what a client should do if no DHCPACK is received
was mistakenly pushed below it.
2.17. Use of "secs" field
Hibbs Expires: Feb 2003 + 6 months [Page 14]
Internet Draft RFC 2131 Implementation Issues February 2003
2.18. Use of "htype" and "hlen" fields.
This is directed at vendors who try to support their certain products
by creating chaddr's with an htype of 1 (meant to be Ethernet) but an
hlen of 16. We should have language to suggest that an htype of zero
should be used in this case.
2.19. Options in DHCPOFFER and DHCPACK
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
case. This SHOULD be clarified as follows:
o Servers MAY deliver a full configuration in a DHCPOFFER, but
are NOT required to do so. The DHCPOFFER MUST contain an IP
address and a lease time, but MAY NOT contain any other
information. As a client will presumably choose among multiple
offers based on some criteria, perhaps completeness of
response, the server SHOULD be permitted to return the
'parameter request list' including the option code for each
option it is prepared to deliver in a DHCPACK message.
o In a DHCPACK message the lease time offered MUST be *at least
as long* as that in the DHCPOFFER. The IP address MUST be the
same.
o The options delivered in a DHCPACK message MAY NOT be identical
to those in a DHCPOFFER. The motivation for this is that some
DHCP servers attempt to balance the load for other services by
permuting lists. Thus a server configured with 3 DNS server
addresses may rotate that list each time a client is serviced.
It is a problem for the server to deliver an identical OFFER
and ACK (it implies keeping state.)
2.20. Lease times.
RFC 2131 has some rather woolly language (section 4.3.1) which might
be interpreted as constraining the duration of a lease that can be
offered based on past history or what the client wants. This SHOULD
be rewritten to make clear that in a DHCPOFFER a server can offer
whatever lease time that local policy finds acceptable, without
regard to what the client requests, or what was offered last time
around.
Also, for RENEWALS, it should be made clear that servers are not
obligated to extend leases merely because the client wishes an
extension (see also general comment below about policy.)
Hibbs Expires: Feb 2003 + 6 months [Page 15]
Internet Draft RFC 2131 Implementation Issues February 2003
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
duration) and T1 = T0/2. Then, when T1 expired, the client attempts
a renewal. The server in question, for whatever reason, does not
want to extend the lease, but is willing to confirm the residual time
(=T0/2). If it also returns T1 in the options, it should ensure that
T1 is adjusted from the original value of for otherwise the new ACK
will have T0 and T1 identical.
2.21. Option ordering
A number of clients exist that require that the DHCP message type be
the first option (after the magic cookie). We SHOULD restate that
the client MUST NOT make any such assumption. The only known
ordering constraint concerns option 82, which is last. CMTS vendors
want it to be last, but suppose someone else wants their pet option
to be last also -- how would we resolve this conflict?
2.22. Packet size
In general clients will not be able to synthesize a fragmented UDP
packet before the IP stack is properly configured. That is the
underlying logic behind the BOOTP packet size limitation. But in a
DHCPINFORM, or any other transfer when the client is fully
configured, there is no such limitation. There probably should be
explicit text to allow larger packets (presumably up to the maximum
PDU size) for later stages of the protocol.
2.23. Policy issues
There has in general been a certain amount of overlap in DHCP between
protocol and policy. The matters include lease times, whether
servers are willing to extend leases, timeouts, and re-transmission.
We SHOULD clarify what is dictated by the protocol and what is a
policy decision at a given site.
3. Suggested Changes to RFC 2131
This section contains specific wording changes to RFC 2131, based on
the identified issues.
Hibbs Expires: Feb 2003 + 6 months [Page 16]
Internet Draft RFC 2131 Implementation Issues February 2003
4. Intellectual Property
The IETF takes no position regarding the validity or scope of any
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
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
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
5. Notes
This section will be removed when this memo goes to Working Group
Last Call.
5.1. Issues
Not all of these issues have been resolved. Some may become items
for future study, while some will probably be dropped.
5.2. Changes from Prior Drafts
The "-00" revision is the initial version of this memo, submitted to
the Internet-Drafts editor on 23 February 2003.
6. Acknowledgements
This document is the result of work undertaken the by DHCP working
group. The editors would like to include a number of contributors to
this effort including Mike Carney of Sun Microsystems and Steve
Tulloh of Shadow Support.
Hibbs Expires: Feb 2003 + 6 months [Page 17]
Internet Draft RFC 2131 Implementation Issues February 2003
7. IANA Considerations
This memo contains no values requiring IANA attention.
8. Security Considerations
(To be defined when suggested text changes for RFC 2131 are
completed.)
A separate Internet-Draft is being created to provide a complete
threat analysis of RFCs 2131 and 3118.
9. References
[STD 2] Reynolds, J., and J. Postel, "Assigned Numbers," STD 2, RFC
1700, July 1992.
[RFC951] Croft, W., and J. Gilmore, "Bootstrap Protocol," RFC 951,
September 1985.
[RFC1123] R. Braden, "Requirements for Internet Hosts -- Application
and Support," RFC 1123, October 1989.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol," RFC
2131, March 1997.
[RFC2132] Alexander, S. and Droms, R., "DHCP Options and BOOTP
Vendor Extensions," RFC 2132, March 1997.
[RFC3203 , Yves T'Joens and Christian Hublet, Peter De Schrijver,
"The DHCP Reconfigure Extension," July 2001.
<draft-ietf-dhc-leasequery-04.txt> Rich Woundy and Kim Kinnear, "DHCP
Lease Query," November 2002.
10. Editors' Addresses
Richard Barr Hibbs
952 Sanchez Street
San Francisco, California 94114-3362
USA
Phone: +1-(415)-648-3920
Fax: +1-(415)-648-9017
Email: rbhibbs@pacbell.net
Hibbs Expires: Feb 2003 + 6 months [Page 18]
Internet Draft RFC 2131 Implementation Issues February 2003
11. Full Copyright Statement
Copyright (C) The Internet Society, 2003. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
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
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"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.
Hibbs Expires: Feb 2003 + 6 months [Page 19]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/