Network Working Group Barr Hibbs INTERNET-DRAFT (no affiliation) Category: Informational February 2003 Implementation Issues with RFC 2131, "Dynamic Host Configuration Protocol" 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. 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]