Network Working Group                                      Barr Hibbs
     INTERNET-DRAFT                                       (no affiliation)
     Category:  Informational                                February 2003
          Implementation Issues with RFC 2131, "Dynamic Host Configuration
                    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-
        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
        The list of Internet-Draft Shadow Directories can be accessed at
     Copyright Notice
        Copyright (C) 2003, The Internet Society.  All Rights Reserved.
        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
        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
        " 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
        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
        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
     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
        "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
        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
        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,
        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
        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
        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 "".  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..."
        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
        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 " 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"  ->
        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"  ->
        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
        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
        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
     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
        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
        Phone:  +1-(415)-648-3920
        Fax:  +1-(415)-648-9017
     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
        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
     Hibbs                Expires: Feb 2003 + 6 months           [Page 19]