Network Working Group                                         Barr Hibbs
     INTERNET-DRAFT                                          (no affiliation)
     Category:  Informational                                February                                     Rob Stevens
                                                             (no affiliation)
                                                                 October 2003

          Implementation Issues with RFC 2131, "Dynamic Host Configuration
                                      Protocol"

                       <draft-ietf-dhc-implementation-00.txt>

                       <draft-ietf-dhc-implementation-01.txt>
          Saved Monday, February Friday, October 24, 2003, 12:51:05 8:08:15 AM8:05:56 AM PT8:08:15 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, implementers,
        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.

     Table of Contents

        1. Introduction...................................................2 Introduction...................................................3
        2. Issues with RFC 2131...........................................3
          2.1. Outdated RFC Boilerplate...................................3
          2.2. Organization and Typography................................4
            2.2.1. Outdated References...................................4
            2.2.2. Typographical Errors..................................4
            2.2.3. Omissions.............................................5
            2.2.4. Tables................................................5
            2.2.5. Inconsistencies.......................................5
          2.3. Policy issues..............................................6
          2.4. The Client Hardware Address, "chaddr"......................7
          2.5. The DHCP Client Identifier.................................3
          2.2. Identifier.................................7
            2.5.1. Uniqueness............................................7
            2.5.2. Prohibition in DHCPOFFER and DHCPACK..................8
          2.6. Address-in-Use Detection...................................4
          2.3. Detection...................................9
            2.6.1. Client-side ARP.......................................9
            2.6.2. Server side PING......................................9
            2.6.3. Other Mechanisms.....................................10
          2.7. DHCP Relay Agents..........................................4
          2.4. Agents.........................................10
            2.7.1. Relay Agent Source Addresses.........................10
            2.7.2. Relay Agent Port Usage...............................10
          2.8. Host Name, Domain Name, and FQDNs..........................4
          2.5. Conflicts with Host Requirements [RFC1123].................4
          2.6. What Are Default Values?...................................4
          2.7. FQDNs.........................11
          2.9. Overloading of DHCPREQUEST.................................5
          2.8. DHCPRELEASE................................................5
          2.9. Which Options to Return?...................................5 DHCPREQUEST................................11
          2.10. Recovery from Address Assignment Conflicts................6 DHCPINFORM...............................................11
          2.11. Interaction with DNS......................................6 Unicast of DHCPDISCOVER..................................12
          2.12. Client and Server Administration..........................6 DHCPRELEASE..............................................13
          2.13. Lack Client state diagram.....................................13
          2.14. Options..................................................13
            2.14.1. Which Options to Return?............................14
            2.14.2. Multiple Instances of Clarity...........................................6
            2.13.1. Vendor and User Classes..............................7
            2.13.2. Options.......................16
            2.14.3. Option Selection.....................................7
            2.13.3. Client / Server retransmission.......................8
            2.13.4. Ordering.....................................16
            2.14.4. Options 66 and 67...................................16
          2.15. Vendor Classes...........................................17
            2.15.1. Character set.......................................17
            2.15.2. Form of the name space..............................17
            2.15.3. Relationship to vendor options......................17
            2.15.4. Multiplicity........................................18
          2.16. Client/Server Retransmission.............................19
          2.17. Transmission of DHCP NAKs............................8
            2.13.5. Minimum size DHCPNAKs.................................19
          2.18. Use of ciaddr............................................20
          2.19. Size of a BOOTP / DHCP frame.................8
            2.13.6. BOOTP/DHCP frame...............................20
            2.19.1. Minimum size........................................20
            2.19.2. Maximum Size, MTU, and Message Size option..........20
          2.20. Use of ciaddr........................................9
            2.13.7. Duplicate IP address detection.......................9
            2.13.8. Clarify use giaddr............................................22
          2.21. Address Selection........................................22
          2.22. 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 "secs" field......................................22
          2.23. Use of "htype" and "hlen" fields.........................23
          2.24. Use of xid field.........................................23
          2.25. Options in Protocol..................14
          2.16. Typographical Errors.....................................14 DHCPOFFER and DHCPACK.........................24
          2.26. Lease times..............................................24
          2.27. Miscellaneous............................................25
        3. Suggested Changes to RFC 2131.................................16
        4. Intellectual Property.........................................17
        5. Notes.........................................................17
          5.1. Issues....................................................17
          5.2. Property.........................................26
        4. Notes.........................................................26
          4.1. Issues....................................................26
          4.2. Changes from Prior Drafts.................................17 Drafts.................................27
        5. Acknowledgements..............................................28
        6. Acknowledgements..............................................17
        7. IANA Considerations...........................................18
        8. Considerations...........................................28
        7. Security Considerations.......................................18 Considerations.......................................28
        8. References....................................................28
        9. References....................................................18
        10. Editors' Addresses...........................................18
        11. Addresses............................................29
        10. Full Copyright Statement.....................................19 Statement.....................................29

     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
        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 implementers 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. identify

        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. editors.

     2.1. The DHCP Client Identifier

        DHCP servers must somehow uniquely identify DHCP clients that are
        requesting services Outdated RFC Boilerplate

        1.  "Status of This Memo" should be replaced with standardized
            language for RFCs as described in order "Guidelines to Authors of
            Internet-Drafts," dated September 5, 2002.

        2.  Section 1.4, "Requirements," should be replaced with standardized
            language referring to correctly configure the client. RFC
        2131 provides two specific methods for identifying a client:  (1) 2119 regarding the
        client identifier (DHCP Option 61) [RFC2132], definition and (2) the "chaddr"
        field
            interpretation of specific key words.

        3.  References should be separated into normative and non-normative
            sections.

     2.2. Organization and Typography

     2.2.1. Outdated References

        1.  References to the BOOTPREQUEST packet.

        Confusion arises from the language of "Assigned Numbers" RFC 2131 Section 4.2.  A DHCP
        client "...MAY choose [STD 2, RFC 1700]
            should be changed 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' "Assigned Numbers" database
            maintained by IANA.  References are found in all
        subsequent messages, Tables 3 and 5,
            and in 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 "References" section.

        2.  References 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 "Interaction between DHCP and unspecified
        manufacturer's hardware identifier or a DNS name. BOOTP" RFC 2132 adds to the confusion by stating that the client identifier
        "...is expected to
            1534 should be unique for all clients in an administrative
        domain" without specifying what an "administrative domain" is.

        RFC 2132 continues by suggesting use integrated with the text of "...type-value pairs similar
        to the 'htype'/'chaddr' fields defined in..."  [RFC951], memo, and that a
        "...hardware type RFC
            1534 deprecated.

     2.2.2. Typographical Errors

        1.  Page 23, third paragraph of 0 (zero) section 4.1 -- "recieved" should
            be used when the value field
        contains an identifier other than a hardware address (e.g., a fully
        qualified domain name)."

        This suggestion "received."

        2.  Page 23, sixth paragraph of using type-value pairs has been widely adopted by
        DHCP client implementors, but the suggestion fails section 4.1 -- refers 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." 1533,
            not RFC 2131 SHOULD NOT have suggested the use of DNS names for the 2132.

        3.  Page 15, Figure 3.  Table misformatted.

        4.  Page 18, Figure 4.  Table misformatted.

        5.  Page 25, ninth paragraph of section 4.1 -- "uicast" should be
            "unicast."

        6.  Page 38, first paragraph after Table 5.  Orphaned sentence:
            "The DHCPREQUEST message contains the same 'xid' as the
            DHCPOFFER message."  No it doesn't.  Not only that, but this
            sentence makes no sense in its current location.  It should be
            removed.

        7.  Page 39, Last paragraph of 4.4.3 should be moved up as the
            last paragraph of 4.4.2.  When the text for DHCPINFORM was
            added, the text describing what a client should do if no
            DHCPACK is received was mistakenly pushed below it.

        8.  Apostrophes (') are used as single quotation marks, but
            outside of an enclosing quotation (") throughout the document.

        9.  Page 30, section 4.3.1, second from last bullet: "...client’s
            vendor class identifier and client's classes identified in the
            server".  This text makes no sense and should be deleted.

        10. Inconsistent style regarding placement of periods (.), commas
            (,) and semi-colons (;) with respect to quotation marks
            throughout the document.

        11. Quotation marks (single and double) are overused through the
            document.

     2.2.3. Omissions

        In several places there is missing or incomplete information,
        including:

        1.  Table 3, pages 27 and 28. .  The "options" entry for "DHCPNAK"
            in the "fields" portion of the table is missing.  All entries
            in this line should refer to the subsequent "options" table.

        2.  Page 33, Table 4, and Page 35, Figure 5, do not include the
            "DHCPINFORM" message.

        3.  Table 5, pages 37 and 38.  The "options" entry for
            "DHCPDECLINE, DHCPRELEASE" is missing.  All entries in this
            line should refer to the subsequent table.

     2.2.4. Tables

        1.  Table 3 (pages 28 and 29) and Table 5 (pages 37 and 38) should
            be separated into two tables each for readability.

        2.  Table 4 should be reorganized to show all messages (except
            DHCPRELEASE) that are sent from each client state.

        3.  The "Host Configuration Parameters" table now in an appendix
            should be omitted and described in a revised "DHCP Options"
            document (RFC 2132).

     2.2.5. Inconsistencies

        1.  Page 1, Abstract, "TCPIP" should be "TCP/IP" – as it is in the
            rest of the document.

        2.  Page 10, Table 3, description of 'htype' and 'hlen' fields does
            not capitalize "Ethernet."
        3.  Lack of consistency when describing "IP broadcast."  Sometimes it
            is "0xffffffff IP broadcast," elsewhere "limited broadcast," or
            "broadcast."  Suggest using the "255.255.255.255 IP broadcast
            address" form, as that is the most specific.  Specific references
            include:

               Page 19, third paragraph of section 3.2, List item #2

               Page 23, fifth paragraph of section 4.1 (twice)

               Page 25, thirteenth paragraph of section 4.1 (twice)

               Page 32, section 4.3.2, third bullet item

               Page 32, section 4.3.2, fifth bullet item

               Page 36, second paragraph of section 4.4.1

               Page 39, last paragraph of section 4.4.1

               Page 39, second paragraph of section 4.4.3

        4.  Lack of consistency when referring to the BROADCAST (B) flag:  it
            is also referred to as the "broadcast bit."

        5.  Table 3, "Fields and options used by DHCP servers," is
            problematic.  It indicates that we MUST fill in both the "Server
            Identifier" (and siaddr) in our DHCPACK (and DHCPNAK) response.
            That's a change from the same table in RFC 1541 that specifies
            this is a "MAY" (and which is consistent with RFC 2132 section
            9.7 and identical RFC 1533 section 9.5 wording).

     2.3. Policy issues

        There has in general been a certain amount of overlap in DHCP between
        protocol and policy.  The matters include lease times, whether
        servers are willing to extend leases, timeouts, and re-transmission.

        We SHOULD clarify what is dictated by the protocol and what is a
        policy decision at a given site.

        The DHC Working Group philosophy ought to be to constrain client
        behavior more closely than server behavior.  DHCP interactions are
        initiated (and continued) by clients:  clients outnumber servers by
        many tens of thousands to one; client implementers cannot be quite
        certain of all the environments in which their client may ultimately
        appear, whereas server implementations may be designed for very
        specific environments.  Policy is likely to be a matter of
        centralized control, whereas clients are not likely to enjoy a
        sufficient status to impose policy on servers.

        The previous paragraph implies that the WORKING GROUP should tighten
        the protocol with respect to such issues as retries and backoffs,
        whereas servers should not be constrained on issues such as how to
        uniquely identify clients, whether to offer or extend leases etc.

     2.4. The Client Hardware Address, "chaddr"

        The value of "chaddr" MUST NOT change from DHCPDISCOVER to
        DHCPREQUEST, although the wording in table 3 makes this point
        unclear.

        Further, the length of "chaddr" SHOULD be exactly specified by
        "hlen," which SHOULD match the address length for "htype."

     2.5. The DHCP Client Identifier

     2.5.1. Uniqueness

        DHCP servers must uniquely identify DHCP clients requesting services
        in order to correctly configure the client.  RFC 2131 provides two
        specific methods for identifying a client:  (1) the client identifier
        (DHCP Option 61) [RFC2132], and (2) the "chaddr" field of the
        BOOTPREQUEST packet.

        Confusion arises from the language of RFC 2131 Section 4.2.  A DHCP
        client "...MAY choose to explicitly provide the identifier through
        the 'client identifier' option.  If the client supplies a 'client
        identifier,' the client MUST use that same 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 alternatives for a
        unique identifier were given: an unspecified manufacturer's serial
        number 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.

        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 implementers, but the suggestion fails to heed the
        warning about uniqueness issues with "chaddr."

        RECOMMENDATIONS:

        o  RFC 2131 SHOULD have made required the "client identifier"
           either to be globally unique or, to be unique within an
           "administrative domain," and, in the latter case, defined
           "administrative domain."

        o  RFC 2131 SHOULD NOT have suggested the use of DNS names for the
           "client identifier" without also suggesting some mechanism mechanism for
           maintaining a consistent name-to-address mapping.

        o  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.

        o  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.5.2. Prohibition in DHCPOFFER and DHCPACK

        Table 3, in the "options" section, specifies that the server MUST NOT
        send the "client identifier" in the DHCPOFFER or DHCPACK messages,
        but MAY send it in a DHCPNAK message.  There is no very good reason
        why DHCPNAK should be treated differently, and there is considerable
        utility in returning the client identifier, as it allows clients
        further corroboration, beyond that implied by matching "xid’s" (see
        2.23), that they are the intended recipient.

        RECOMMENDATIONS:

        Change the text in Table 3, for all three message types, to read:
        "MAY -- if included, MUST BE the client identifier sent by the
        client".

     2.6. Address-in-Use Detection

        RFC 2131 Page 7, section 1.6, second set of bullet items, first
        bullet says that DHCP must: "Guarantee that any specific network
        address will not be in use by more than one client at a time," but
        the protocol as later described does not fulfill this requirement.

        Two mechanisms are presented: an ARP request generated by the client;
        and an ICMP echo request generated by the server:

        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

     2.6.1. Client-side ARP

        To meet the requirement of RFC 2131 page 7, a DHCP client MUST send
        an ARP request for the IP address contained in a DHCPACK before using
        it.  This is presently a SHOULD:

        o  Page 12, second paragraph of section 2.2:  "...  and the client
           SHOULD probe the newly received address, e.g., with ARP"

        There has been confusion on this topic because many clients are
        sending an ARP reply (after the DHCPACK).  This often has nothing to
        do with DHCP, and is triggered in many systems whenever an interface
        IP address changes.  (Without access to kernel code there is nothing
        one can do about it.)

        RECOMMENDATIONS:

        o  The Working Group should consider whether to make client ARP a
           MUST.

     2.6.2. Server side PING.

        ICMP is inherently unreliable.  Furthermore since success is "no
        response" it is an imprecise matter to decide how long to wait before
        one is certain that no response will ever occur.  A possible
        suggestion is a back off and retry for ping.

        In cable modem environments, PING is not helpful because it is the
        cable modem termination system (CMTS) that replies from its cache:  a
        cache which may not be perfectly reliable and which in many cases has
        been constructed by listening to the DHCP traffic in the first place!
        It is known that some network administrators try to block propagation
        of ICMP ECHO messages through internal routers, which removes one of
        the two address conflict detection mechanisms.

        RECOMMENDATIONS:

        o  Use of ICMP on the server should be a “MAY”, not a “SHOULD”.

     2.6.3. Other Mechanisms

        Both the ICMP ECHO (Ping) and Address Resolution Protocol (ARP)
        mechanisms are very lightweight by design, depending on clients with
        conflicting addresses to "defend" their address by responding to
        queries to show that an address is in use.  Is there a better
        alternative to ICMP ECHO and ARP that is backward-compatible with
        these two protocols?

     2.7. DHCP Relay Agents

     2.7.1. Relay Agent Source Addresses

        There should be some text that specifies what the relay agent should
        use for the IP source address of relayed packets.  Because relay
        agents change the payload ("giaddr" and relay agent option 82) their
        operation does not amount to IP forwarding.  The IP source address
        they use should be their own.  [Aside: for security purposes it might
        have been better than they retain the source IP address of the
        original packet, but it is too late to change all that.]

     2.7.2. Relay Agent Port Usage

        Relay agents should use port 67 as the source port number.  Relay
        agents always listen on port 67, but port 68 has sometimes been used
        as the source port number probably because it was copied from the
        source port of the incoming packet.

        Cable modem vendors would like to install filters blocking outgoing
        packets with source port 67.

        RECOMMENDATIONS:

        o  Relay agents MUST use 67 as their source port number.

        o  Relay agents MUST NOT forward packets with non-zero giaddr
           unless the source port number on the packet is 67.

     2.8. Host Name, Domain Name, and FQDNs

        A fully qualified domain name (FQDN) consists of two conceptual
        parts:  the host name portion and the domain name portion.  Host
        names consist of one or more non-null parts separated by the ISO
        period (.) character ("separator") while domain names consist of two
        or more non-null parts delimited by the separator, one of which must
        be a valid top-level domain (TLD) name.  DHCP options exist for
        hostname (option 12) and domain name (option 15), and are proposed
        for FQDN (draft-ietf-dhc-fqdn-option-05.txt) but the FQDN option is
        not required to be a concatenation of hostname and domain name.

        Should RFC 2131 explicitly state that the client FQDN MUST be the
        host name (option 12) concatenated with the domain name (option 15)?

     2.9. Overloading of DHCPREQUEST

        The client sends a DHCPREQUEST message from several different states:
        INIT, INIT-REBOOT, REBINDING, and RENEWING.  Differentiation among
        the states is done according to the context of other message fields
        and option values.  At this point there probably can be no change in
        this usage, but the content of other message fields and option values
        should be carefully reviewed to ensure consistency

     2.10. DHCPINFORM

        The intent of DHCPINFORM messages is to allow clients to query
        servers for configuration information WHETHER OR NOT their IP address
        has been assigned by DHCP.

        Section 3.4 Para 2 Page 21 states: "The server SHOULD check the
        network address in a DHCPINFORM message for consistency."  What the
        server should be checking is a mystery.  Possibly the intent was that
        servers should verify that the source IP address in the packet is
        identical to the "ciaddr."  Since the server should reply to
        "ciaddr," this affords some measure of security, preventing third
        parties from discovering configuration information pertaining to
        other clients.  Whether that is desirable, or whether instead
        DHCPINFORM should be available to third parties, such as proxies, has
        never been resolved.

        Section 4.4.4 Para 1, "Use of broadcast and unicast," hints that
        clients may be able to broadcast DHCPINFORM messages to servers: "The
        DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST and DHCPINFORM
        messages, unless the client knows the address of a DHCP server."

        This text suggests that a DHCP client may choose to broadcast a
        DHCPINFORM request for whatever reason, and points out the need for
        clarification of all text concerning multiple server responses and
        consistency of returned options.

        RECOMMENDATIONS:

        o  DHCPINFORM messages should be included in Table 4 to summarize
           the fields and options usage with this message type.

        o  The Working Group should consider the ramifications of
           permitting third party DHCPINFORMs, that is, DHCPINFORM
           messages NOT sent by the DHCP client, but by other processes
           having access to the ports.

        o  Section 4.3.1, "DHCPDISCOVER Message," and section 4.3.2,
           "DHCPREQUEST Message" briefly mention consistency and uniform
           responses from multiple servers:  this text SHOULD be clarified
           to state what consistency is expected or required of the
           server, and what a client should do if a server supplies
           inconsistent data.

     2.11. Unicast of DHCPDISCOVER

        Section 4.4.4 Para 1, "Use of broadcast and unicast," hints that
        clients may be able to unicast DHCPDISCOVER messages to servers: "The
        DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST and DHCPINFORM
        messages, unless the client knows the address of a DHCP server."

        This would be pointless unless "ciaddr" were non-zero, because the
        server would not know how to respond.  Neither does table 4 admit the
        possibility.

        We believe it is common practice for
        maintaining BOOTP Relay Agents to only fill-
        in "giaddr" for broadcast packets.  This requires investigation:
        such behavior would restrict the use of unicast DHCPDISCOVER messages
        to the same subnet on which the server resides -- a consistent name-to-address mapping. very restricted
        condition.

        One circumstance in which this might make sense is for proxies
        gathering IP addresses on behalf of other clients.  In that case the
        proxy could put its own IP address in "ciaddr" and perhaps use
        multiple different client identifiers in multiple transmissions.
        Table 5, however, asserts that ciaddr must be zero.

        RECOMMENDATIONS:

        o  The Working Group should consider whether to allow this kind of
           proxy usage, and what changes that might imply to RFC 2132 2131.

        o  Tables 4 and 5 SHOULD NOT have suggested using be updated to reflect the "htype"  and "chaddr"
        fields as a type-value pair because possibility of
           unicast DHCPDISCOVER messages.

        o  Figure 5 SHOULD be updated to reflect the warning uses of unicast and
           broadcast packets

     2.12. DHCPRELEASE

        There are several MUST NOT entries in the "options" portion of RFC
        2131
        Section 4.2 about potential problems using "chaddr" table 5 specifying the inclusion of options in the DHCPRELEASE.
        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 the "fields" portion of table 5 there is the word "unused" for the
        "sname" and "file" fields of a DHCPRELEASE message, while "options"
        for the purpose.

        RFC 2132 SHOULD NOT have used DHCPRELEASE was left blank.

        A DHCPRELEASE message SHOULD be subject to some verification criteria
        to reduce the chance of a bogus release.  Two possible changes to
        these tables are:

        1.  In the "fields" portion of table 5, change the word "should"  when suggesting "xid" from
            "selected by client" to "xid from server DHCPACK message."

        2.  In the
        use "options" portion of type-value pairs table 5, change the entry for
            "client identifier"  with a type of 0
        (zero) when from "MAY" to "client identifier used in
            the value is anything other than a hardware address.

     2.2. Address-in-Use Detection

     2.3. DHCPDISCOVER message."

     2.13. Client state diagram

        Section 4.3.1 and Figure 5 do not accurately describe DHCP Relay Agents

        (To be added)

     2.4. Host Name, Domain Name, client
        behavior:  DHCP clients send messages to servers from the INIT, INIT-
        REBOOT, SELECTING, REQUESTING, and FQDNs

        (To be added)

     2.5. Conflicts with Host Requirements [RFC1123]

        (To be added)

     2.6. What Are Default Values?

        (To be added)
     2.7. Overloading BOUND states, not from RENEWING or
        REBINDING.

        o  Change the text of DHCPREQUEST

        The DHCPREQUEST message is sent by section 4.3.1 and it's schematic
           representation in Figure 5 to correctly represent the client states,
           transitions, triggering events, and messages sent.

     2.14. Options

        The language in several different
        states:  INIT, INIT-REBOOT, REBINDING, RFC 2131 concerning whether and RENEWING.  Differentiation
        among which options to
        return to the states client is done according convoluted and apparently contradictory.

     2.14.1. Which Options to Return?

        There are two opposing philosophies regarding which options servers
        should return to clients:  to return every option with values within
        the context client’s scope, or to return only those options specifically
        requested by a client and within scope.  The following arguments have
        been cited:

        Supporting the return of every option:

        o  Consistency.  A network administrator wants all of other packet
        fileds.

     2.8. DHCPRELEASE

        There were several MUST NOT entries in the table that specifies
           configured options to show up on each client on the
        inclusion network,
           regardless of client vendor.

        o  A DHCP client is likely only to request the options in it
           supports.  However, many application layer options are not used
           by the DHCPRELEASE. DHCP client but are useful to applications.

        o  A bogus DHCPRELEASE should
        not be allowed DHCP client would either need to release a lease I set about be configured or updated 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. new options.  The vendor said
        that their reading whole idea of the RFC allows such an option DHCP is to be included.

        In a table just above keep
           configuration on the table that specifies "all others" as MUST
        NOT there is server, not on the word "unused" for "options" for client, which is
           pointed out in:  Page 7, second and third bullets of section
           1.6.

        Supporting the DHCPRELEASE.
        Could return only of requested options:

        o  Some DHCP clients may reject packets containing options that be what
           they did not request especially if they are ignorant of their
           semantics; therefore a DHCP server should only return the vendor was thinking?

        What is appropriate here?  It
           options requested.

        o  The DHCP packet size is also unclear why these MUST NOT's
        exist.

     2.9. Which limited.  Options are often configured
           on a per-network rather than a per-client basis, and to Return?

        There is some question about return
           unwanted options risks exhausting the intent of space available while
           options remain which the client needs.

        RFC 2131 with regard does little to resolve the client options to send.  In Section matter.  Two different sections
        are relevant: section 3.5 there is no mention of a
        minimum set of parameters to be sent describes mechanisms to a requesting client, nor any
        mention limit the number of which parameters
        options sent, while section 4.3.1 subsequently presents an apparently
        conflicting description of how to send if select values for options requested
        by the client does not request
        any. client.

        RFC 2131, Section 3.5:

           "First, most parameters have defaults defined in the Host
           Requirements RFCs; if the client receives no parameters from
           the server that override the defaults, a client uses those
           default values."
        The list of parameters with a cross-reference to the defining RFC is
        given in Appendix A of RFC 2131.

        Several sources contend that there is no parameter virtually none of the parameters in the
        list for
        which have a viable meaningful default value exists, value, which raises the issue of
        viability of the technique described in this section for reducing
        total server response message size.

        Even if the option has a default value defined in [RFC1122], RFC 2131
        is silent on the question of whether or not the server MUST, SHOULD,
        or MAY choose not to send an that option if when its value is the same as
        the default.

        RFC 2131, Section 4.3.:

           "IF the server has been explicitly configured with a default
           value for the parameter, the server MUST include that value in
           an appropriate option in the 'option' field, ELSE

           "IF the server recognizes the parameter as a parameter defined
           in the Host Requirements Document, the server MUST include the
           default per value for that parameter as given in the Host Requirements.

        Section 3.5 of RFC 2131 describes two mechanisms
           Requirements Document in an appropriate option in the 'option'
           field, ELSE

           "The server MUST NOT return a value for that parameter."

        The word "default" in the first statement seems misplaced.  The
        second statement seems contrary to limit the number intent of options sent, but offers minimizing the
        amount of data sent by the server:  if the scope of the Host
        Requirements RFCs applies to all Internet-connected hosts, then a
        DHCP server SHOULD NOT have to supply these values -- they should
        already be assumed by the client as the default for the requested
        option.

        There is no mention of a minimum set of parameters to be sent to a
        requesting client, nor any mention of which parameters to send if the
        client does not request any not any guidance for what to do when
        there is more data than will fit in a response packet.  Can the options be
        somehow prioritized? Could additional options be obtained using the
        DHCPINFORM mechanism?

        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 response packet.  Can the parameter,
        options be somehow prioritized?  Could additional options be obtained
        using the server MUST include that value in DHCPINFORM mechanism?  Should an appropriate option additional bit in the 'option' field, ELSE

           "IF the server recognizes the parameter
        "flags" field be defined as a parameter defined
           in the Host Requirements Document, the server "packet overflow" bit?

        RECOMMENDATIONS:

        o  Clients MUST include the
           default value for that same parameter as given in the Host
           Requirements Document request list on all
           messages.

        o  Clients MUST be prepared to receive responses containing
           options they did not request and/or whose semantics are
           unknown.  They MAY choose silently to ignore such options.

        o  Language implying that parameters in an appropriate option "Requirements for Internet
           Hosts" have defaults should be removed.

     2.14.2. Multiple Instances of Options

        Page 24, seventh paragraph, section 4.1:  "Options may appear only
        once, unless otherwise specified in the 'option'
           field, ELSE

           "The server MUST NOT return options document.  The client
        concatenates the values of multiple instances of the same option into
        a value single parameter list for that parameter" configuration."  The first sentence
        should start out "Options MUST appear only once, unless...."  The
        second of these statements seems contrary to sentence belongs in the intent options memo [RFC2132] for options
        where there can be multiple instances.  Together, these two sentences
        are confusing.

     2.14.3. Option Ordering

        A number of
        minimizing clients require that the amount of data sent by DHCP message type be the server:  if first
        option (after the scope magic cookie).

        RECOMMENDATIONS:

        o  With the exception of option 82, which must be last (save
           option 255 which acts as a terminator), the Host Requirements RFCs applies client MUST NOT
           make any assumption about the ordering of options.

     2.14.4.                             Options 66 and 67

        Options 66 (TFTP server name) and 67 (bootfile name) were introduced
        as an alternative to all Internet-connected hosts,
        then the fixed fields "sname" and "file" in BOOTP.
        As discussed elsewhere, space is at a DHCP server SHOULD NOT have premium in DHCP, and reserving
        64 octets ("sname") and 128 octets ("file") to supply these contain values -- they
        should already be assumed by are
        that potentially, and commonly, much shorter is wasteful.
        Furthermore, the existence of these options allows the client as to
        either request those values from the default server or not, according to
        need.

        At present, servers are at liberty to return values for these options
        in either the
        requested fixed fields, or encapsulated like any other DHCP
        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  Clients have sometimes assumed only the former.  RFC 2131 where
        should address this issue.

        RECOMMENDATIONS:

        o  Using "sname" and "file" for these options SHOULD be
           deprecated.

        o  Clients MUST be prepared, at least for the intended meaning
        is unclear.

     2.13.1. time being, for
           either method of delivery.

     2.15. 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 is nothing new about it.  Should this section be
        referring to User classing?

     2.13.2. Option Selection

        Should a DHCP server return all options that

     2.15.1. Character set

        Some new clients 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 spaces in their identifier, which options should
        be returned:  always return every option configured broke some
        implementations with configuration file records delimited by
        whitespace.

     2.15.2. Form of the network
        administrator, name space

        An early suggestion (RFC 1541 time-frame), expressed symbolically,
        was the form "Stock symbol/Organization...." e.g., "SUNW.class-
        1.class-2" or only return those options specifically requested by
        a client.

        A DHCP server should always return options that "CMU.edu.class-1.class-2".  This would 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 had the network, regardless of
            client vendor.

        2.  A DHCP client
        advantage of preventing collisions between vendors.  This was not
        adopted, and it is likely only going probably too late to request the resurrect it.

     2.15.3. Relationship to vendor options it
            supports.  However, there

        Text is needed describing how each unique vendor class identifier
        implies a 254 unique encapsulated option name space.  There are many application layer 254,
        because even within the vendor space options 0 and 255 retain their
        meaning as the pad value and terminator, respectively.  An occasional
        misconception is that
            are not used there is only a single unique encapsulated 254
        option name space shared by all vendors, with the DHCP client but are useful effect that the
        same values being returned to applications.

        3.  A DHCP *any* client would either need to be configured or updated to
            request new options.  The whole idea regardless of DHCP is vendor class
        identifier.  Obviously, we should include text 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, clarify the argument was made that some DHCP clients would
        break if they received new options,
        relationship between Vendor Class identifier and therefore a DHCP server
        should only return the options encapsulated
        Vendor option.

     2.15.4. Multiplicity.

        How many vendor class identifiers can 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 have?  One only,
        because the
           client, according client is unique to a specific vendor.  If the following rules:"

        o  Page 36, first paragraph of section 4.4.1
     2.13.3. Client / Server retransmission

        Because DHCP servers are the passive participants and DHCP clients
        are the active participants, client
        were to send more than one vendor class option it would be impossible
        for the DHCP protocol is susceptible server to
        poorly behaved clients (retransmit too fast).  However, there decide which set of encapsulated vendor options to
        select.

        Here is no some more text describing this susceptibility.  Furthermore, regarding vendor options from a note from Mike
        Carney regarding the use of vendor class / encapsulated options:

           Vendor class support requires the
        power-of-2 retransmission algorithm is ability to configure a SHOULD/MAY.  This probably
        should be DHCP
           server to support a MUST.  If we need different retransmission algorithms for
        different media, new vendor class by associating that vendor
           class identifier with 254 options whose types can 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 be
           defined by following the DHCP client's documentation.  Each
           group of list item 5, section 3.1

        2.  Page 24, eighth paragraph 254 options has the "scope" of section 4.1

        3.  Page 36, first paragraph that vendor.  For
           example, suppose we have the following two clients:

           Vendor Class "SunBeam.Toaster.2slots"

           Options for this class:

           Code  Len  Data

             1    2   Darkness setting   ( a 2 byte integer)

           Vendor Class "Voxpopulis.Answering.Machine"

           Options for this class:

           Code  Len  Data   (X bytes ASCCI string, of section 4.4.1

     2.13.4. Transmission the answer message)

             1    X   Outgoing message

        Both clients are on the same network ("Kitchen"), and are clients of DHCP NAKs

        DHCP NAKs MUST be broadcast.  However,
        the text describing same DHCP server.  Note that both use encapsulated option code 1.
        Looks like a server's
        behavior when conflict, but it isn't.

        In 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 syntax of section 4.1

        3.  Page 32, Last paragraph the DHCP server's configuration table, one
        configures two new options, each which has the "scope" 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 vendor
        class.

        What this means is that when the broadcast bit in order for toaster boots, the relay agent to
        properly broadcast DHCP server only
        returns vendor class options associated with the DHCPNAK.  We just need to either refer to it
        in
        "SunBeam.Toaster.2slots" class.  When the first two references or duplicate answering machine boots, it there.

     2.13.5. Minimum size
        only sees vendor class options associated with the
        "GE.Answering.Machine" class.  Clients 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 vendor classes not
        currently configured on this point, but RFC 2131 just refers to RFC 951.  We
        SHOULD add a line stating that the minimum size of a server don't see any encapsulated vendor
        options.

     2.16. Client/Server Retransmission

        Because DHCP frame is
        300 bytes in reference:

           Page 10, first paragraph after Table 1, section 2

        After all, servers are the passive participants and DHCP clients
        are the active participants, the DHCP protocol is intended susceptible to be backward compatible with BOOTP.

     2.13.6. Use of ciaddr

        RFC 951 -
        poorly behaved clients (retransmitting too fast, for example).
        However, there is no text describing this susceptibility.
        Furthermore, the use ciaddr when they've received an IP address from
        a source outside of BOOTP, and thus the power-of-2 retransmission algorithm is a
        SHOULD/MAY.  This probably should be able to respond to
        ARPs.

        The text a MUST.  If we need different
        retransmission algorithms for different media, then we should
        develop/document them in RFC 2131 table form.  The specification as it stands
        is mostly supportive too loose and does cause inter-operability problems:

        1.  Page 16, section 3.1, last sentence of this point with the
        following exception: list item 3.1.

        2.  Page 21, 17, third paragraph of list item 5, section 3.1

        3.  Page 24, eighth paragraph of section 4.1

        4.  Page 36, first sentence paragraph of last para, section 3.4:  "The server
           SHOULD check the network address in a DHCPINFORM message for
           consistency, but 4.4.1

     2.17. Transmission of DHCPNAKs

        DHCPNAKs 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 broadcast or unicast to at the link level because
        the DHCPREQUEST"

     2.13.7. Duplicate client has no valid IP address detection address.  The specification specifies same comment applies to
        DHCPOFFERs but with one significant difference: a DHCPOFFER has a
        valid "yiaddr" which a relay agent can use as the requirement that DHCP guarantee that
        an destination IP address
        address.  It 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 clear that any specific network address whatever mechanism relay agents are
        using to transmit offers 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 work when "yiaddr" is 0.0.0.0.
        Therefore, for safety’s sake, the DHCP client.  To meet this
        requirement, I think a DHCP client servers MUST validate set the IP address
        contained broadcast bit
        in DHCPNAK packets.  The text describing a DHCPACK before using it, and that a DHCP server MAY
        validate an IP address using an ICMP echo request before OFFERing it
        to server's behavior when the
        client is accessible through a client.  Right now, both mechanisms are SHOULD's.  Relevant
        references:

        o BOOTP relay agent does not do this:

        1.  Page 12, second 19, last paragraph of section 2.2, last sentence

        o  Page 13, list item 2, section 3.1

        o 3.2

        2.  Page 38, first 23, fifth paragraph after Table 5, of section 4.4.1
     2.13.8. Clarify use 4.1

        3.  Page 32, Last paragraph 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 "DHCPREQUEST generated during INIT-
            REBOOT state," bullet, section 4.3.2.

        This last describes the form of behavior that's required -- a server MUST set
        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 broadcast bit 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 order for the
        same values relay agent to *any* client returning *any* vendor class identifier.
        Obviously, we properly broadcast
        the DHCPNAK.

        RECOMMENDATION
        o  Items (1) and (2) above should include either duplicate the text of
           (3), or should reference section 4.3.2.

     2.18. Use of ciaddr

        According to clarify the relationship between
        Vendor Class identifier RFC 951 and the encapsulated Vendor option.

        How many Vendor class identifiers can RFC 1542, clients use "ciaddr" when they've
        received an IP address from a client have?

        Only one, as there source outside of BOOTP/DHCP, and can
        respond to ARPs.

        The text in RFC 2131 is only one mostly supportive of this point with the
        following exception:

           Page 32, "DHCPREQUEST generated during REBINDING state:"
           section 4.3.2:  "The DHCP client vendor.  It is impossible server SHOULD check 'ciaddr' for
           correctness before replying to have more than one, since there would the DHCPREQUEST."

        This line should be no way to know which
        encapsulated option went with which Vendor Class.

        Here is some more text regarding vendor options from a note struck from Mike
        Carney regarding the use document.  Servers trust
        "ciaddr," period.

     2.19. Size of Vendor class / encapsulated options:

        "Successful Vendor class support requires the ability a BOOTP/DHCP frame

        The description in RFC 2131 relating to configure the size constraints of DHCP
        packets (Page 10, first paragraph after Table 1, section 2) is
        inadequate.

     2.19.1. Minimum size.

        RFC 951 states that a minimum BOOTP frame is 300 octets in length.
        Some BOOTP relay agents have been known to drop frames of less than
        300 octets.  RFC 951 is explicit on this point, but RFC 2131 just
        refers to RFC 951.  Since DHCP server is intended to support a new vendor class by associating that vendor
        class identifier be backward compatible
        with 253 options whose types can then BOOTP, the protocol should continue to observe this lower bound.

        RECOMMENDATIONS:

        o  Text should be defined by
        following added stating explicitly that the DHCP client's documentation.  Each group minimum size
           of 253 options a DHCP frame is 300 octets.

     2.19.2. Maximum Size, MTU, and Message Size option

        It has the "scope" been thought necessary to avoid fragmentation of the IP
        packets in DHCP/BOOTP due to concerns that Vendor.  For example, let's say we have some clients would be
        unable to reassemble fragments before the
        following two clients:

           Vendor Class "SunBeam.Toaster.2slots"

           Options for this class:

           Code  Len   Data

             1    2    Darkness setting

           Darkness setting IP stack is a 2 byte integer.

           Vendor Class "GE.Answering.Machine"

           Options for this class:

           Code  Len   Data

             1    X    Outgoing message

           Outgoing message properly
        configured.  RFC 951 states "For simplicity it is an ASCII string, X bytes long, consisting
           of assumed that the text
        BOOTP packet is never fragmented". Regardless of the answer message.

        Both clients are on the same network "Kitchen," and theoretical
        limitations in IP stack implementations, it is certain that there are clients
        several DHCP/BOOTP implementations, at both ends of the same DHCP server.  Note protocol,
        which will not reassemble.

        Various comments in the WORKING GROUP imply that both use Encapsulated option code 1.
        Looks like a conflict, but it isn't.

        In fragmentation could
        be avoided were the syntax client consistently to include the MTU of the DHCP server's configuration table, I configure
        two new options, each
        link layer interface. But clients cannot be expected to be omniscient
        about other media over which has packets travel en route to servers.
        Servers that must be endowed with this knowledge, which they MUST use
        to avoid packet fragmentation.

        Once the "scope" of IP stack is configured, and the vendor class.

        What this means IP stack is that when fully
        configured, the toaster boots, aforementioned limitation ceases to exist, and later
        stages of the DHCP server only
        returns vendor class options associated with protocol could allow larger packets (up to the
        "SunBeam.Toaster.2slots"  class.  When UDP
        limit).  DHCPINFORMs, especially, could benefit from this relaxation.
        There probably should be explicit text to allow larger packets
        (presumably up to the answering machine boots,
        it only seens vendor class options associated with maximum PDU size) for later stages of the
        "GE.Answering.Machine"  class.  Clients
        protocol.

        A number of vendor classes not
        currently configured on clients send small packets with the server don't see assumption that
        servers will not return a packet that is any encapsulated vendor
        options, since larger than the server hasn't been configured to support that
        vendor class. one
        received from the client.  The DHCP server can client MUST NOT 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 assumption.
        If the client's class identifier.

     2.13.9. DHCP MTU client cannot process a response larger than a certain size,
        the client MUST use the message size 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 inform servers of this
        size. Note that this is NOT the BOOTP header which same option as the MTU.

        RECOMMENDATIONS:

        o  Servers and relay agent needs to deliver agents MUST ensure that IP datagram
           fragmentation does not occur at any stage in the DHCP
        response).  As such, protocol
           before the client IP stack is fully configured.

        o  Clients really SHOULD communicate their link-
        layer link-layer frame size to the
           DHCP server via the DHCP MTU option.  We
        should clarify this point both in

        o  Clients MUST NOT assume that servers will return a packet no
           larger than the DHCP and BOOTP specifications.

        We should consider changing SHOULD to one they send. If the client has a limit on the
           size of the packet that it can process it MUST convey that
           limit to the server in this case. the "maximum message size" option (57)

        o  Page 21, second para, paragraph, section 3.5
     2.13.10. SHOULDs that should be MUSTs

        There are many SHOULDs and 3.5, the first sentence
           SHOULD NOTs that should be converted into
        MUSTs or MUST NOTs.  Too many changed to list, but here's a few:

        4.  Page 12, second paragraph of section 2.2:  "...  and the "The client SHOULD probe include the 'maximum
           DHCP message size' option to let the newly received address, e.g.  with ARP"  (MUST)

        5.  Page 16, item 4, section 3.1 "The server SHOULD NOT check know how large the
            offered network address at
           server may make its DHCP messages, and the value of this point."  (MUST NOT)

        6.  Page 16, item 5, section 3.1 "The client option
           SHOULD perform a final
            check on be the parameters..."  (MUST)

        7.  Page 17, item 5, section 3.1 "The client MTU of the [client] network interface being
           configured."

        o  The WORKING GROUP SHOULD wait consider whether to allow
           fragmentation of packets after the client is fully configured,
           and how servers can divine this fact (e.g. a minimum non-zero
           "ciaddr").

     2.20. Use of
            ten seconds..."  (MUST)

        8. giaddr

        Page 18, item 2, 23, fifth paragraph, section 3.2 "Servers SHOULD NOT check that 4.1:  "If the
            client's network address 'giaddr’ field is already
        zero and the 'ciaddr' field is nonzero, then the server unicasts
        DHCPOFFER and DHCPACK messages to the address in use;..."  (MUST NOT)

        9. 'ciaddr.'"  True for
        DHCPACK, false for DHCPOFFER (a DHCPDISCOVER will never have anything
        but 0 as "ciaddr.")

     2.21. Address Selection

        Page 19, item 2, second para, 27, third paragraph, section 3.2 "...servers SHOULD
            respond 4.3.1:  "Note that, in some network
        architectures (e.g., internets with a DHCPNAK message more than on IP subnet assigned
        to a physical network segment), it may be the client"  (MUST) The
            following sentences are rather dubious case that the DHCP
        client should be assigned an address from a different subnet than the
        address recording in 'giaddr.'"

        There are two differing view of this paragraph as well.

        10. Page 21, first para, section 3.4 "The servers SHOULD unicast sentence:

           There is considerable detail in the
            DHCPACK replay rest of RFC 2131 trying to
           get the address given int he 'ciaddr' field 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
            DHCPINFORM message"  (MUST)

        11. Page 22, last para, same
           wire should be either described in detail in its own section 3.5 "If a server receives
           (with caveats) or as a DHCP
            request message with an invalid 'requested IP address', separate informational RFC.  Otherwise,
           the
            server SHOULD respond use of "giaddr" is unclear.

        Alternatively:

           Additional supporting text should be added to RFC 2131 to the client
           effect that servers having knowledge of network topology MAY
           choose to offer an address inconsistent with a DHCPNAK message..."
            (MUST)

        and so on.  We should review "giaddr" but
           consistent with that topology.  Furthermore, the MAY/SHOULD/MUST (NOT)s in address
           offered may differ depending upon the spec, contents of the vendor
           class, user class, and tighten up those we can.  SHOULDs should list even the valid
        exceptions (some do; most don't).

     2.13.11. Just wrong

        Page 23, fifth para, section 4.1:  "If client identifier.  All of
           these things are policy matters for the 'giaddr server.

     2.22. Use of "secs" field is zero and
        the 'ciaddr'

        The "secs" field is nonzero, then the server unicasts DHCPOFFER has not been discussed much:  many clients simply
        leave its value as zero, and
        DHCPACK messages to the address in 'ciaddr'".  True for DHCPACK,
        false for DHCPOFFER (a DHCPDISCOVER will never few if any servers 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. used its value
        to modify their behavior. These practices seem acceptable.  The client
        concatenates the values of multiple instances value
        of "secs" SHOULD be the same option into elapsed time (in seconds) since the client
        began trying to acquire or extend a single parameter list for configuration"  The first sentence should
        start out "Options MUST appear only once, unless...".  The second
        sentence belongs in lease on an IP address.  A
        sixteen bit field, its maximum value is 65536.  It is conceivable
        that due to server or network failure that a client may have been
        waiting longer than this.

        RECOMMENDATIONS:

        o  A client MAY choose to leave to ignore the options draft for options where there can secs field.  If so
           its value MUST 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 set to zero. If the server.."?

        Page 16, last sentence of list item 3, section 3.1 "The client times
        out and retransmits chooses to insert
           a value, the DHCPDISCOVER message if value SHOULD be time elapsed since the client receives
        no DHCPOFFER messages."  How long should
           began negotiating for an IP address.  If the client wait?

     2.14. Inconsistencies

        1.  Page 1, Abstract, "TCPIP" should has been
           waiting longer than 65536 seconds its value SHOULD be "TCP/IP" -- like it is in the
            rest of the document.

        2.  Lack 65536.
           The value SHOULD NOT wrap around to zero.

     2.23. Use 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, "htype" and "hlen" fields

        At least one vendor has used chaddr as a place holder for a value
        that is was not in fact a link-layer (hardware) address, while at 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
        same type using an htype of section 4.4.1

        10. Page 39, second paragraph 1 (meant to be Ethernet) but an hlen of section 4.4.3

        11. Page 40, first paragraph
        16 (instead of 4.4.4

        12. Page 40, second paragraph 6).  Many servers will reject a packet with this kind
        of 4.4.4

        13. Page 41, fifth paragraph inconsistency between the htype and hlen fields.

        Values of 4.4.5
     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 htype not equal to zero MUST correspond to a physical network segment), it may be the case that link-level
        medium to which the DHCP client should is attached according to IANA’s
        Assigned Numbers database.

        RECOMMENDATIONS:

        o  The value of hlen MUST be assigned an address from a different subnet than consistent with the length of a link-
           level address recording in 'giaddr.'"  We go through great detail in the
        rest implied by htype.

        o  An htype of the draft trying zero SHOULD be used to get the use mean that chaddr is an
           identifier unrelated to a specific link-level medium.

     2.24. Use of giaddr clear as it relates xid field

        This field exists to BOOTP relay agents (RFC 951 and allow clients to match replies to requests.  In
        two places RFC 1542), then this sentence
        basically "undoes" this work.  Serving multiple IP networks on 2131 erroneously states that the
        same wire client should be either described in detail use the
        "xid" in its own section
        (with caveats) or the server’s DHCPOFFER 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 value in its follow up request

        o  Table 5.  Orphaned sentence:  "The 5 DHCPREQUEST message contains column

        o  Section 4.4.1 Para 5

        In principle the same 'xid' as 32 bits of "xid" should be sufficient to make the DHCPOFFER
            message"  No
        chance of collisions almost nil, provided that it doesn't.  Not only that, but this sentence makes
            no sense is randomly
        generated as 2131 suggests in its current location.  It should be removed.

        8.  Page 39, Last section 4.4.1 paragraph of 4.4.3 should 3.  However,
        some vendors have admitted to generating "xid" which may not be moved up
        sufficiently uniformly distributed.

        The randomness requirement on "xid" is not as stringent as would be
        required, say, in selecting a cryptographic key.  It is quite
        permissible that the last
            paragraph initial key be predictable given sufficient
        knowledge of 4.4.2.  When the text for DHCPINFORM was added, the
            text describing what client, but clients MUST ensure that these
        identifiers are generated in such a client should do if no DHCPACK is received
            was mistakenly pushed below it.

     2.17. Use of "secs" field
     2.18. Use way that the chance of "htype" and "hlen" fields.

        This is directed at vendors who try to support their certain products
        by creating chaddr's collision
        with an htype other clients in the DHCP administrative domain is what one
        should expect from a truly random number.

        Permitting the use of 1 (meant to be Ethernet) but an
        hlen the same "xid" on a re-transmission might
        marginally improve the efficiency of 16.  We should have language the protocol.  Server responses
        to suggest that an htype of zero
        should the first transmission, which arrived after the timeout and
        retransmission would be used in this case.

     2.19. accepted, and might avoid yet another client
        timeout.

     2.25. Options in DHCPOFFER and DHCPACK

        RFC 2131 says that the options delivered in these two cases should
        not be in conflict.  It does not say what "conflict" means in that
        case.  This SHOULD be clarified as follows: clarified.

        RECOMMENDATIONS:

        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 and 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 message, the lease time offered MUST be *at at least
           as long* 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 differ from
           those in a DHCPOFFER.  The motivation for this is that some  Some DHCP servers attempt to balance the
           load for other services by permuting lists.  Thus  For instance, 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 some
           servers to deliver an identical OFFER and ACK (it implies
           keeping state.)

     2.20.

        o  If a particularly long option list must be delivered to the
           client, it might not be possible to fit all options in the DHCP
           payload of a UDP packet.  RFC 2131 appears to permit a long
           list of options to be sent partly in the DHCPOFFER message and
           partly in the DHCPACK message.

     2.26. Lease times.

        RFC 2131 has some rather woolly language (section 4.3.1) which that might be interpreted
        as constraining the duration of a lease that can be offered based on
        past history or what the client wants.  This SHOULD be rewritten to
        make clear that in a DHCPOFFER a server can offer whatever lease time
        that local policy finds acceptable, without regard to what the client
        requests, or what was offered last time around.

        Also, for  If a server offers a
        longer lease than the client requested, the client can simply enter
        the RENEWING or REBINDING states, or send a DHCPRELEASE message
        according to its desired [earlier] times.

        For RENEWALS, it the text should be made clear that servers are not
        obligated to extend leases merely because the client wishes an
        extension (see [see also general comment below about policy.) policy.]

        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).
        (T0/2).  If it also returns T1 in the options, it should ensure that
        T1 is adjusted from the original value of for otherwise else the new ACK will have T0
        and T1 identical.

     2.21. Option ordering

        A number of clients exist that require

     2.27. Miscellaneous

        There are many SHOULDs and SHOULD NOTs that the DHCP message type should perhaps be
        converted into MUSTs or MUST NOTs.  Here is a summary:

        1.  Page 16, item 4, section 3.1 "The server SHOULD NOT check the first option (after the magic cookie).  We
            offered network address at this point."  (MUST NOT)

        2.  Page 16, item 5, section 3.1 "The client SHOULD restate that perform a
            final check on the parameters..."  (MUST)

        3.  Page 17, item 5, section 3.1 "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 SHOULD wait a fragmented UDP
        packet before minimum
            of ten seconds..."  (MUST)

        4.  Page 18, item 2, section 3.2 "Servers SHOULD NOT check that
            the IP stack is properly configured.  That client's network address is the
        underlying logic behind the BOOTP packet size limitation.  But already in use..."  (MUST NOT)

        5.  Page 19, item 2, second paragraph, section 3.2 "...servers
            SHOULD respond with a
        DHCPINFORM, or any other transfer when the client is fully
        configured, there is no such limitation.  There probably should be
        explicit text DHCPNAK message to allow larger packets (presumably up the client"  (MUST).
            The following sentences are rather dubious in this paragraph
            as well.

        6.  Page 21, first paragraph, section 3.4 "The servers SHOULD
            unicast the DHCPACK replay to the maximum
        PDU size) for later stages address given in the
            'ciaddr' field of the protocol.

     2.23. Policy issues

        There has in general been DHCPINFORM message"  (MUST)

        7.  Page 22, last paragraph, section 3.5 "If a server receives 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 request message with an invalid 'requested IP address',
            the server SHOULD clarify what is dictated by respond to the protocol and what is a
        policy decision at client with a given site.

     3. Suggested Changes to RFC 2131

        This section contains specific wording changes to DHCPNAK
            message..."  (MUST)

        RECOMMENDATIONS:

        o  The WORKING GROUP should review the MAY/SHOULD/MUST (NOT)s in
           RFC 2131, based on 2131. Those SHOULDs that remain should list the identified issues.

     4. valid
           exceptions (some do; most don't).

     3. Intellectual Property

        The IETF takes no position regarding the validity or scope of any
        intellectual property or other rights that might 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 claimed required to
        pertain practice
        this standard.  Please address the information to the implementation or IETF Executive
        Director.

     4. Notes

        This section will be removed when this memo goes to Working Group
        Last Call.

     4.1. Issues

        Open, unresolved issues about RFC 2131 include:

        1.  What is the correct use of client identifier in DHCPOFFER and
            DHCPACK messages?

        2.  Are there any effective alternatives to ICMP ECHO and ARP for
            address-in-use detection?
        3.  What is the technology described definition of a Fully Qualified Domain Name?

        4.  Should DHCPINFORM messages be allowed from client proxies?

        5.  Should client proxies, in
        this document general, be allowed, and how does a
            client proxy know the IP address of a DHCP server?

        6.  Should a DHCP server send only options requested by a client,
            or should a server send all options for which it is configured
            with a value?

        7.  Should required usage of "xid" and "client identifier" be
            changed to support server verification of DHCPRELEASE
            messages?

        8.  What is the extent correct statement about selecting an IP address to which any license under such rights
        might or might not
            offer a client when the offered address is on a different
            subnet than the client's "giaddr?"

        9.  Should a new flags bit to signify "more options data
            available" be available; neither does it represent added?

        10. Do we need a new "Maximum Relay MTU Size" option to ensure
            that all reply packets sent by a server will pass without
            fragmenting or dropping packets?

        11. Would it
        has made any effort help to identify any such rights.  Information on the
        IETF's procedures with respect set a sort of "more to rights come" option,
            indicating that more options will follow in standards-track and
        standards-related documentation can be found a consecutive
            DHCPACK, where the subsequent DHCPACKs would have a
            "additional information" option indicating that the message
            contains only new options data similar to a DHCPACK in BCP-11.

        Copies of claims of rights made available for publication and any
        assurances of licenses
            response to be made available, or a DHCPINFORM message?

        12. Are unicast DHCPDISCOVER messages permitted?  What are the result
            requirements for specific message fields and options in this
            case?

        13. What level of an
        attempt made to obtain consistency is required among responses from
            multiple servers?

     4.2. Changes from Prior Drafts

        The "-01" revision contains substantial changes following a general license or permission for the use detailed
        review of
        such proprietary rights DHC Working Group mailing list discussions on RFC 2131
        clarification issues, consideration of several directed questions,
        and comments received by implementers or users the authors.  Changes include:

        o  Reorganization of this
        specification can be obtained from the IETF Secretariat.

        The IETF invites any interested party to bring document to its attention any
        copyrights, patents or patent applications, group all typographical
           errors together, separate from protocol or other proprietary
        rights that may cover technology that may be required to practice
        this standard.  Please address policy issues.

        o  Elimination of "Interaction with DNS" and "Client and Server
           Administration" sections because the information authors saw no clear
           resolution 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 topics.

        o  Creation of these an issues have been resolved.  Some may become items
        for future study, while some will probably be dropped.

     5.2. Changes from Prior Drafts list in section 4.1.

        The "-00" revision is was the initial version of this memo, submitted to
        the Internet-Drafts editor on 23 February 2003.

     6.

     5. 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 Microsystems, Steve Tulloh
        of Shadow Support.

     7. Support, Bernie Volz, Ted Lemon of Nominum, Simon Vogl,
        Edward Mascarenhas of SGI, Andre Kostur of Incognito, Bud Millwood of
        Weird Solutions, Patrick Guélat of ImproWare Network Services, and
        Swamy Narasimha of Nokia.

     6. IANA Considerations

        This memo contains no values requiring IANA attention.

     8.

     7. 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.

     8. References

       [STD 2] Reynolds, J., and J.  Postel, "Assigned Numbers,"  STD 2, RFC
          1700, July 1992.

     [RFC951] Croft, W., and J. Gilmore, J., "Bootstrap Protocol," RFC 951,
        September 1985.

     [RFC1123] R. Braden, "Requirements for Internet Hosts -- Application
        and Support,"  RFC 1123, October 1989.

     [RFC1542] W. Wimer, "Clarifications and Extensions for the Bootstrap
        Protocol" RFC 1542, October 1993

     [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

     [RFC3203] T'Joens, Y., Hublet, Peter C., and De Schrijver, P., "The DHCP
        Reconfigure Extension," July 2001.

       <draft-ietf-dhc-leasequery-04.txt> Rich Woundy

     <draft-ietf-dhc-leasequery-05.txt> Woundy, R., and Kim Kinnear, K., "DHCP
        Lease Query," March 2003.

     <draft-ietf-dhc-fqdn-option-05.txt>, Stapp, M., and Rekhter, Y., "The
        DHCP Client FQDN Option," November 2002.

     10.

     <draft-swamy-dhc-client-id-00.txt>, Narasimha, S., "Client Identifier
        option in server replies," July 2003.

     9. 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
     11.

        Rob Stevens
        308 Arthur Ave
        Aptos California 95003-5202
        USA

        Phone:+1-(831)-688-9722
        E-mail:  robs@cruzio.com

     10. Full Copyright Statement

        Copyright (C) The Internet Society, 2003.  All Rights Reserved.

        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, 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.

     APPENDIX A:  List of Vendors

     ------------------------------------------------------------------------
     |Vendor            |Product          |E-mail Address                   |
     ------------------------------------------------------------------------
     |2Wire             |HomePortal       |support@2Wire.com                |
     |3Com              |Home Gateway     |                                 |
     |3e Technologies   |                 |                                 |
     | International    |Magnum           |info@3eti.com                    |
     |3K Group          |Turbo Cell       |info@3kgroup.com                 |
     |Accelerated       |                 |                                 |
     | Technology       |Nucleus          |support@acceleratedtechnology.com|
     |ActionTec         |                 |                                 |
     | Electronics      |                 |                                 |
     |ADTRAN            |Netvanta 2100    |                                 |
     |Agere Systems     |Orinoco RG-1000  |                                 |
     |Apple Computer    |                 |cheshire@apple.com               |
     |Appliansys        |DNSBox 300       |                                 |
     |Argus             |                 |                                 |
     | Technologies     |EtherAccess 2000 |info@arguscorp.com               |
     |Ateonix Networks  |NASAS-2040       |tech@ateonix.com                 |
     |Avaya             |WAP              |                                 |
     |Barbed Wire       |                 |                                 |
     | Technologies     |                 |                                 |
     |Broadband         |                 |                                 |
     | Gateways         |Evolo            |                                 |
     |Caldera/SCO       |Open Linux       |                                 |
     |                  |   Eserver       |info@sco.com                     |
     |Cayman Systems    |                 |                                 |
     |CheckPoint        |                 |                                 |
     |   Software       |                 |                                 |
     |Cisco Systems     |Network          |                                 |
     |                  |Registrar        |kkinnear@cisco.com               |
     |Cisco Systems     |AIR-AP3000       |                                 |
     |Clavister         |                 |                                 |
     |CLinux            |                 |                                 |
     |Compaq            |Connection Point |                                 |
     |vCoNet            |                 |                                 |
     |   Communications |XpressIP 8550    |                                 |
     |Cygsoft           |                 |support@cygsoft.com              |
     |D-Link            |DI-700           |                                 |
     |Efficient         |                 |                                 |
     |   Networks       |                 |                                 |
     |Esoft             |Redphish         |                                 |
     |Filanet           |Interjak         |                                 |
     ------------------------------------------------------------------------
     ------------------------------------------------------------------------
     |Vendor            |Product          |E-mail Address                   |
     ------------------------------------------------------------------------
     |FTP Software      |                 |                                 |
     |Helios            |PCShare          |                                 |
     |Incognito         |                 |                                 |
     |   Software       |Address Commander|support@incognito.com            |
     |InfoBlox          |DNS One          |support@infoblox.com             |
     |Internet Software |                 |                                 |
     |   Consortium     |DHCPD            |Ted.Lemon@nominum.com            |
     |AttachNet         |Internet Pro SOHO|support@attachnet.com            |
     |InterNiche        |Portable DHCP    |                                 |
     |   Techologies    |Server           |support@iniche.com               |
     |JH Software       |Simple DNSPlus   |support@jhsoft.com               |
     |Leviton           |Internet Gateway |                                 |
     |Lightning         |MultiCOM         |                                 |
     |LinkSys           |WAP-11           |                                 |
     |Lucent            |                 |                                 |
     |   Technologies   |VitalQIP         |                                 |
     |Matrox Electronic |                 |                                 |
     |   Systems        |iSwitch          |networks.techsupport@matrox.com  |
     |UMax Technologies |UGate-3300       |support@umaxcare.com             |
     |MDL Corporation   |FileZerver NAS   |help@mdlcorp.com                 |
     |Microsoft         |                 |                                 |
     |   Corporation    |Windows Server   |                                 |
     |MobiWave          |Spyroz           |support@mobiwave.com             |
     |Multi-Tech        |                 |                                 |
     |   Systems        |RouteFinder VPN  |support@multitech.com            |
     |N3K               |VitalQIP         |info@n3k.co.uk                   |
     |Net Integration   |                 |                                 |
     |   Technologies   |Net Integrator   |support@net-itech.com            |
     |Netgear           |RP334            |                                 |
     |NetWinder         |                 |                                 |
     |Network           |                 |                                 |
     |   TeleSystems    |                 |suppport@shadowsupport.com       |
     |Nokia             |IP30             |internetapac@nokia.com           |
     |Nominum, Inc.     |DCS              |Eric.Luce@nominum.com            |
     |Nortel            |Net ID           |gww@nortelnetworks.com           |
     |Novell            |                 |                                 |
     |On Technology     |IP Track         |support@on.com                   |
     |Panasonic         |KX-HGW200        |                                 |
     |Paul Smith        |                 |                                 |
     |   Computer Svcs  |vDHCP            |support@pscs.co.uk               |
     |PGP               |PGP-5            |                                 |
     |Phoenix           |                 |                                 |
     |   Technologies   |ViewPoint        |                                 |
     ------------------------------------------------------------------------
     ------------------------------------------------------------------------
     |Vendor            |Product          |E-mail Address                   |
     ------------------------------------------------------------------------
     |Powerwallz        |ProShield        |                                 |
     |PresiNET Systems  |                 |                                 |
     |Proxim            |Skyline          |                                 |
     |Rapidstream       |Rapidstream 500  |                                 |
     |Siemens           |                 |                                 |
     |SnapGear          |                 |support@snapgear.com             |
     |Sonic Wall        |SOHO             |                                 |
     |Sun Microsystems  |                 |                                 |
     |Symantec          |VPN-100          |                                 |
     |Teneo             |NetScreen        |                                 |
     |Threshold         |                 |                                 |
     |   Networks       |Edge             |                                 |
     |Trellis Network   |                 |                                 |
     |   Services       |DNS ONE          |                                 |
     |Weird Solutions   |DHCP Turbo       |                                 |
     ------------------------------------------------------------------------