Interim Meeting 2/23/04
Interim Meeting 2/25/04


2.3.1 Dynamic Host Configuration (dhc)


In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       http://www.dhcp.org -- Additional DHC Page
NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-01-22

Chair(s):
Ralph Droms <rdroms@cisco.com>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret@thingmagic.com>
Internet Area Advisor:
Margaret Wasserman <margaret@thingmagic.com>
Mailing Lists:
General Discussion: dhcwg@ietf.org
To Subscribe: http://www1.ietf.org/mailman/listinfo/dhcwg
Archive: http://www1.ietf.org/mailman/listinfo/dhcwg
Description of Working Group:
Other Lists:

The dhc working group (DHC WG) has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCP is currently a "Draft Standard". The base protocol is documented in RFC2131 and RFC2132 (DHCP for IPv4) and RFCxxxx (DHCP for IPv6). Additional options are documented in subsequent RFCs.

The DHC WG is responsible for reviewing (and sometimes developing) DHCP options or other extensions (for both IPv4 and IPv6). The DHC WG is expected to review all proposed extensions to DHCP to ensure that they are consistent with the DHCP specification and other option formats, that they do not duplicate existing mechanisms, etc. The DHC WG will not (generally) be responsible for evaluating the semantic content of proposed options. The DHC WG will not adopt new proposals for extensions to DHCP as working group documents without first coordinating with other relevant working groups and determining who has the responsibility for reviewing the semantic content of an option.

The DHC WG has the following main objectives:

The DHC WG will address security in DHCP

o Develop and document security requirements for DHCP. RFC 3118 defines current security mechanisms for DHCPv4. Unfortunately, RFC 3118 has neither been implemented nor deployed to date. Specific issues to be considered include:

- Improved key management and scalability

- Security for messages passed between relay agents and servers

- Threats of DoS attacks through FORCERENEW

- The increased usage of DHC on unsecured (e.g., wireless) and public LANs

- The need for clients to be able to authenticate servers, without simultaneously requiring client authentication by the server.

o Develop and document a roadmap of any new documents or protocols needed to meet the security requirements for DHCP

Write an analysis of the DHCP specification, including RFC2131, RFC2132 and other RFCs defining additional options, which identifies ambiguities, contradictory specifications and other obstacles to development of interoperable implementations. Recommend a process for resolving identified problems and incorporating the resolutions into the DHCP specification.

Complete or abandon work on DHCPv6 options that are currently work in progress:

o IPv6 Prefix Options for DHCPv6 (draft-troan-dhcpv6-opt-prefix-delegation-02.txt)

o DNS Configuration options for DHCPv6 (draft-ietf-dhc-dhcpv6-opt-dnsconfig-01.txt)

o Load Balancing for DHCPv6 (draft-ietf-dhc-dhcpv6-loadb-02.txt)

o NIS Configuration Options for DHCPv6 (draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt)

o Time Configuration Options for DHCPv6 (draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt)

o Client Preferred Prefix option for DHCPv6 (draft-ietf-dhc-dhcpv6-opt-cliprefprefix-00.txt)

o A Guide to Implementing Stateless DHCPv6 Service (draft-droms-dhcpv6-stateless-guide-00.txt)

o DSTM Options for DHCPv6 (draft-ietf-dhc-dhcpv6-opt-dstm-01.txt)

o DSTM Ports Option for DHCPv6 (draft-ietf-dhc-dhcpv6-opt-dstm-ports-01.txt)

Complete or abandon work on DHCP extensions and options that are currently work in progress:

o Failover protocol (draft-ietf-dhc-failover-11.txt)

o The DHCP Client FQDN Option (draft-ietf-dhc-fqdn-option-04.txt) o Resolution of DNS Name Conflicts Among DHCP Clients (draft-ietf-dhc-ddns-resolution-04.txt)

o DHCP Server MIB (draft-ietf-dhc-server-mib-07.txt)

o Considerations for the use of the Host Name option (draft-ietf-dhc-host-option-considerations-01.txt)

o DHCP Lease Query (draft-ietf-dhc-leasequery-04.txt)

o DHCP Options for Internet Storage Name Service (draft-ietf-dhc-isnsoption-03.txt)

o Dynamic Host Configuration Protocol (DHCP) Server MIB (draft-ietf-dhc-server-mib-07.txt)

o DHCP Option for Mobile IP Mobility Agents (draft-ietf-dhc-mipadvert-opt-00.txt)

o DHCP VPN Information Option (draft-ietf-dhc-vpn-option-02.txt)

o KDC Server Address Sub-option (draft-ietf-dhc-suboptions-kdc-serveraddress-00.txt)

o The Authentication Suboption for the DHCP Relay Agent Option (draft-ietf-dhc-auth-suboption-00.txt)

o Link Selection sub-option for the Relay Agent Information Option (draft-ietf-dhc-agent-subnet-selection-03.txt)

o VPN Identifier sub-option for the Relay Agent Information Option (draft-ietf-dhc-agent-vpn-id-02.txt)

o RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option (draft-ietf-dhc-agentopt-radius-02.txt)

o DHCP Subscriber ID Suboption for the DHCP Relay Agent Option (draft-ietf-dhc-subscriber-id-00.txt)

Goals and Milestones:
Done  WG Last Call on DHCP Options for Internet Storage Name Service (draft-ietf-dhc-isnsoption-03.txt)
Done  WG Last Call on Load Balancing for DHCPv6 (draft-ietf-dhc-dhcpv6-loadb-02.txt)
Done  WG Last Call on Time Configuration Options for DHCPv6 (draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt)
Done  WG Last Call on IPv6 Prefix Options for DHCPv6 (draft-troan-dhcpv6-opt-prefix-delegation-02.txt)
Done  WG Last Call on DNS Configuration options for DHCPv6 (draft-ietf-dhc-dhcpv6-opt-dnsconfig-01.txt)
Done  WG Last Call on NIS Configuration Options for DHCPv6 (draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt)
Done  Resubmit draft-ietf-dhc-dhcpv6-28.txt to IESG
Done  Identify DHCPv4 authentication design team
Done  Identify DHCPv4 specification review design team
Done  Identify DHCPv4 relay agent message authentication design team
Feb 03  Submit DHCP Options for Internet Storage Name Service to IESG (draft-ietf-dhc-isnsoption-03.txt)
Feb 03  Submit DNS Configuration options for DHCPv6 to IESG (draft-ietf-dhc-dhcpv6-opt-dnsconfig-01.txt)
Feb 03  Submit NIS Configuration Options for DHCPv6 to IESG (draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt)
Feb 03  Submit Time Configuration Options for DHCPv6 to IESG (draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt)
Mar 03  Submit IPv6 Prefix Options for DHCPv6 to IESG (draft-troan-dhcpv6-opt-prefix-delegation-02.txt)
Mar 03  Submit Load Balancing for DHCPv6 to IESG (draft-ietf-dhc-dhcpv6-loadb-02.txt)
Apr 03  Update milestones to include all WG documents
Jun 03  DHCPv4 authentication design team report completed
Jun 03  DHCPv4 specification review report completed
Jun 03  Select DHCPv4 relay agent message authentication mechanism
Internet-Drafts:
  • - draft-ietf-dhc-failover-12.txt
  • - draft-ietf-dhc-server-mib-10.txt
  • - draft-ietf-dhc-fqdn-option-06.txt
  • - draft-ietf-dhc-ddns-resolution-06.txt
  • - draft-ietf-dhc-leasequery-06.txt
  • - draft-ietf-dhc-agentopt-radius-04.txt
  • - draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt
  • - draft-ietf-dhc-dhcpv6-opt-timeconfig-03.txt
  • - draft-ietf-dhc-isnsoption-10.txt
  • - draft-ietf-dhc-auth-suboption-03.txt
  • - draft-ietf-dhc-mipadvert-opt-02.txt
  • - draft-ietf-dhc-subscriber-id-05.txt
  • - draft-ietf-dhc-implementation-01.txt
  • - draft-ietf-dhc-dhcpv6-stateless-04.txt
  • - draft-ietf-dhc-dna-ipv4-05.txt
  • - draft-ietf-dhc-relay-agent-ipsec-01.txt
  • - draft-ietf-dhc-pxe-options-00.txt
  • - draft-ietf-dhc-vendor-01.txt
  • - draft-ietf-dhc-3315id-for-v4-02.txt
  • - draft-ietf-dhc-dhcpv6-opt-nss-00.txt
  • - draft-ietf-dhc-dhcpv6-opt-tz-00.txt
  • - draft-ietf-dhc-dhcpv6-opt-sntp-00.txt
  • - draft-ietf-dhc-rapid-commit-opt-00.txt
  • - draft-ietf-dhc-reclassify-options-00.txt
  • - draft-ietf-dhc-client-id-00.txt
  • - draft-ietf-dhc-proxyserver-opt-00.txt
  • - draft-ietf-dhc-dhcpv6-ctep-opt-00.txt
  • - draft-ietf-dhc-dhcpv6-opt-rboot-00.txt
  • - draft-ietf-dhc-opt-extrboot-00.txt
  • Request For Comments:
    RFCStatusTitle
    RFC1531 PS Dynamic Host Configuration Protocol
    RFC1532 PS Clarifications and Extensions for the Bootstrap Protocol
    RFC1534 DS Interoperation Between DHCP and BOOTP
    RFC1533 PS DHCP Options and BOOTP Vendor Extensions
    RFC1542 DS Clarifications and Extensions for the Bootstrap Protocol
    RFC1541 PS Dynamic Host Configuration Protocol
    RFC2131 DS Dynamic Host Configuration Protocol
    RFC2132 DS DHCP Options and BOOTP Vendor Extensions
    RFC2241 PS DHCP Options for Novell Directory Services
    RFC2242 PS Netware/IP Domain Name and Information
    RFC2485 PS DHCP Option for The Open Group's User Authentication Protocol
    RFC2489BCPProcedure for Defining New DHCP Options
    RFC2563 PS DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients
    RFC2610 PS DHCP Options for Service Location Protocol
    RFC2939BCPProcedure for Defining New DHCP Options and Message Types
    RFC2937 PS The Name Service Search Option for DHCP
    RFC3004 PS The User Class Option for DHCP
    RFC3011 PS The Subnet Selection Option for DHCP
    RFC3046 PS DHCP Relay Agent Information Option
    RFC3074 PS DHC load balancing algorithm
    RFC3118 PS Authentication for DHCP Messages
    RFC3203 PS DHCP reconfigure extension
    RFC3256 PS The DOCSIS Device Class DHCP Relay Agent Information Sub-option
    RFC3396 PS Encoding Long Options in DHCPv4
    RFC3442 PS The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4
    RFC3495 PS Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration
    RFC3527 PS Link Selection sub-option for the Relay Agent Information Option for DHCPv4
    RFC3315 PS Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
    RFC3594 PS PacketCable Security Ticket Control Sub-option for the the DHCP CableLabs Client Configuration (CCC)Option
    RFC3646StandardDNS Configuration Options for DHCPv6
    RFC3633StandardIPv6 Prefix Options for DHCPv6
    RFC3634StandardKDC Server Address Sub-option
    RFC3679 I Unused DHCP Option Codes

    Current Meeting Report

    dhc WG Minutes Seoul - March, 2004 Review of agenda. No changes. DHCP Option for Proxy Server Configuration <draft-ietf-dhc-proxyserver-opt-00> Technical discussion; ready for WG last call? Vijay gave a short review of his draft: this option sends a list of proxy servers and ports to a client. ~8 WG members had read the draft. The chair asked about the difference between this option and existing DHCP options for carrying lists of servers; for example, WWW and NNTP. Vijay justified proxy server option because it provides port number as well as proxy server address. The WG expressed consensus for WGLC (which will be confirmed on the WG mailing list). Ted Lemon will publish editorial comments during WGLC. The Extended Remote Boot Option for DHCPv4 <draft-ietf-dhc-opt-extrboot-00> Technical discussion; ready for WG last call? Vijay gave a short review of his draft: this option gives a list of TFTP servers along with a list of files for each server. ~7 WG members had read the draft. There was discussion that this draft specifies multiple copies of the same option, with different semantics from those specified in RFC3396. Also, the list of servers needs to differentiate between IP addresses or FQDNs. There was a suggestion that the servers just be specified as IP addresses, and a suggestion that the file name be specified as a length followed by name string. Another question: what are the semantics of the list of servers in case of an error? Does the client skip to the next server, retry the file, or what? Vijay will revise the draft to eliminate requirement for sub-options and address other comments. There will be no WGLC at this time. Vendor-Identifying Vendor Options for DHCPv4 <draft-ietf-dhc-vendor-01> Technical discussion; ready for WG last call? The author has revised the draft based on discussion at last WG meeting. ~8 WG members have read the draft. There was one question about the vendor identifier, which was eventually recalled to be the enterprise number. There was WG consensus for WGLC (which will be confirmed on the mailing list). Node-Specific Client Identifiers for DHCPv4 <draft-ietf-dhc-3315id-for-v4-01> Technical discussion; ready for WG last call? The author has revised the draft to simplify the generation of the DHCPv4 client identifier to match the DHCPv6 mechanism exactly. There was WG consensus for WGLC (which will be confirmed on the mailing list). Rapid Commit Option for DHCPv4 <draft-ietf-dhc-rapid-commit-opt-00> Technical discussion; ready for WG last call? The author gave a short presentation about this mechanism, which allows two message exchange in DHCPv4 (modeled on two message exchange in DHCPv6). No comments from WG. WG consensus for WGLC (which will be confirmed on the mailing list). Ted Lemon to publish editorial comments during WGLC. DHCPv6 Support for Remote Boot <draft-ietf-dhc-dhcpv6-opt-rboot-00> Technical discussion; ready for WG last call? The author gave a short presentation about this draft. This option may be impacted by dual-stack problem resolution. This option will not be affected by the multiple copies issue in the DHCPv4 option. Author to revise for editorial issues and for consistency (where possible) with similar DHCPv4 option. No WGLC at this time. Configured Tunnel End Point Option for DHCPv6 <draft-ietf-dhc-dhcpv6-ctep-opt-01> Technical discussion; ready for WG last call? The author gave a short introduction to this option. The WG expressed consensus that this option is intended for configuring routers, which is out-of-scope. The Internet Draft will be dropped as WG work item (which will be confirmed on the mailing list). Reclassifying DHCPv4 Options <draft-ietf-dhc-reclassify-options-00> Technical discussion; ready for WG last call? There was no comment from WG and the WG expressed consensus for WGLC (which will be confirmed on the mailing list). DHCPv4 Support for Conf. IPv6-in-IPv4 Tunnels <draft-daniel-dhc-ipv6in4-tunnels-00> Accept as WG work item? The author gave a short presentation about the option. ~8 WG members had read this draft. There was some discussion of the draft on the mailing list prior to the WG meeting. The author will publish a revised draft based on those comments. The draft will be reviewed by the v6ops WG; the chair will contact the v6ops WG chairs to determine how to proceed. The WG also needs to confirm it fits in dhc WG charter. The draft was not accepted as WG work item at this time. Micro-block IP Addr. Alloc. With DHCP Proxy Server <draft-shen-dhc-block-alloc-01> Accept as WG work item? The author gave a short presentation about the option. It fits in dhc WG charter under "address assignment". The chair will arrange for a discussion to reconcile this option with DHCPv6 prefix delegation and earlier ODAP work. The draft was not accepted as WG work item at this time. Vendor-Specific Suboption for the DHCP RAIO <draft-stapp-dhc-vendor-suboption-00> Ted Lemon expressed concern that this option will lead to unstandardized RAIO sub-options. The WG expressed consensus to accept as WG work item at this time (which will be confirmed on the mailing list). Renumbering Requirements for Stateless DHCPv6 <draft-chown-dhc-stateless-dhcpv6-renumbering-00> This draft defines requirements for updating configuration information obtained through the Information-Request message ("stateless DHCPv6"). There was a comment that the security section could be clearer. The WG charter needs to be updated before the WG takes on this work. The WG expressed consensus to accept this draft as a WG work item (pending charter update; will be confirmed on mailing list). Lifetime Option for DHCPv6 <draft-venaas-dhc-lifetime-01> The author gave a short presentation about the draft. This option is a solution for the renumbering problem. The chair asked if other conditions under which a host performs an Information-Request under other conditions like getting a new prefix in an RA. The WG charter needs to be updated before the WG takes on this work. The WG expressed consensus to accept this draft as a WG work item (pending charter update; will be confirmed on mailing list). Multicast Reconf. Protocol for Stateless DHCPv6 <draft-vijay-dhc-dhcpv6-mcast-reconf-00> Accept as WG work item? The author gave a short presentation about the draft. This option is another solution for the renumbering problem, which is especially applicable to unplanned changes. The chair confirmed that there are two components: one that describes how hosts respond to the reconfigure message and one that describes how to trigger the router to send the reconfigure messages. Margaret Wassserman will take some concerns to the dhcwg mailing list. The WG compared this draft with the previous (lifetime option) draft; the WG consensus was that the two options are sufficiently different that they attack different problems. The WG charter needs to be updated before the WG takes on this work. The WG is very interested in this work, but ID was not accepted as WG work item. (restart at 2:05hrs in) IPv4 and IPv6 Dual-Stack Issues for DHCPv6 <draft-chown-dhc-dual-stack-00> Stig Venaas gave an introduction to the problem based on draft-chown-dhc-dual-stack-00; this document also proposes some solutions. kre remarked that title is all wrong; the draft really discusses problem of accepting configuration from multiple interfaces. An alternative viewpoint is that information from two separate interfaces is different from having to make two answers to get all the information required. It may be possible to solve the dual-stack problem without solving the more general problem of getting information from multiple sources. The WG expressed consensus to accept this document as a WG work item (pending charter update; will confirm on mailing list). Update of dhc WG charter "Par. n" refers to the nth paragraph in the current dhc WG charter. Par. 1 - OK Par. 2 - OK Par. 3 - work in progress (security); Droms to ask design team about progress Par. 4 - work in progress; design team (Hibbs, chair) reviewing RFC 2131 The WG agreed that the list of drafts will be dropped from the charter; inactive IDs to be explicitly dropped from WG work items New charter items: * Stateless DHCPv6 renumbering (<draft-chown-dhc-stateless-dhcpv6-renumbering-00>) * Dual stack issues <draft-chown-dhc-dual-stack-00> * DHCP proxy architecture - Narten to discuss with WG chair before adding to charter The WG chair will write up text for each of the three items and the WG will discuss the text on the mailing list Update on IPR issue with two drafts This agenda item was overtaken events; WG to review three new RFCs: RFC 3667, RFC 3668, RFC 3669: and discuss IPR issues on dhcwg mailing list.

    Slides

    Agenda
    DHCP Option for Proxy Server
    Rapid Commit Option for DHCPv4
    DHCP Option for Configuring IPv6-in-IPv4 Tunnels
    Renumbering Requirements for Stateless DHCPv6
    Lifetime Option for DHCPv6
    IPv4 and IPv6 Dual-Stack Issues for DHCPv6

    Mon 2/23/04 Interim Meeting Report

    Minutes from conf call on RFC2131 implementation issues
    Mon 2/23/04
    -------------------------------------------------------

    Participants:	Vijayabhaskar A Kalusivalingam (vijayak@india.hp.com)
    		Ralph Droms (rdroms@cisco.com)
    		Barr Hibbs (rbhibbs@pacbell.net)
    		Kim Kinnear (kkineear@cisco.com)
    		Andre Kostur (Andre@incognito.com)
    		Bud Millwood (budm@weird-solutions.com)
    		Kevin Noll (kevin.noll@perfectorder.com)
    		Rob Stevens (robs@cruzio.com)
    		Bernie Volz (volz@cisco.com)
    

    1. Do we have sufficient response from the community to proceed?

    The review team has gotten good response and discussion about 'Implementation Issues with RFC 2131, "Dynamic Host Configuration Protocol"' . This draft will be published as Informational and used as the basis for publishing RFC2131bis, which will be considered for advancement as a Full Standard.

    2. Accept or reject typographic corrections

    The state machine in RFC2131 will be retained. Although the DHCPINFORM message is not included in the state machine, it has no impact on the client state and will not be added to the state machine diagram. There was some discussion about whether some messages were sent BEFORE or AFTER transitioning from one state to the other, with no clear consensus; Barr Hibbs offered to supply an updated version of the client state transition diagram for discussion based on a consistent interpretation of when messages are sent relative to transitions.

    RFC2131bis (and the included state machine) will be published in ASCII format (no PDF, PS, etc.) Otherwise, all typographic corrections are accepted.

    3. Policy issues: any proposed wording changes?

    The design team expressed consensus that client timeouts are sufficiently specified and the specification should be careful to avoid over-specifying client behavior.

    4. Invariability of 'chaddr'

    The discussion went to the requirement level for 'chaddr' and 'client identifier'. RFC2131bis will require that a client MUST send both 'chaddr' and 'client identifier', while a server must be prepared to receive a message with only 'chaddr'.

    5. Clarification of the Client Identifier (eliminate suggested format)

    RFC2131bis (as well as RFC2132bis) will specify that the 'client identifier' is an opaque string, with one suggestion that the client can construct the 'client identifier' as an htype/address pair. The server MUST NOT try to interpret the contents of the 'client identifier'; in particular, the server will not try to determine if the length of the address matches the hardware type.

    There was also discussion about 'chaddr' and 'htype'. The consensus was that the server SHOULD check that the length of 'chaddr' match the expected length from 'htype'. Note that if 'chaddr' is incorrect or invalid, the server (or relay agent) will not be able to deliver responses to the client.

    No consensus was reached for a requirement that a client identifier be globally unique. RFC2132bis will include suggestions for forming globally unique client identifiers.

    6. Address in use detection: can we improve it?

    The mechanisms suggested in RFC2131 - ICMP echo from the server, ARP from the client - will be specified as SHOULD in RFC2131bis.

    If another document is available that more completely specifies duplicate address detection for IPv4, a citation of that document will be substituted for the text in section 2.2 (and elsewhere) that describes the use of ARP and ICMP Echo for duplicate address detection.

    7. Relay agent source addresses and port usage

    The relay agent MUST send the relayed message with an address from one of its interface (preferably from the interface through which the relayed message is sent) as the source address.

    Port usage is an RFC1542 issue.

    8. Can we eliminate the 'sname' and 'file' fields of the BOOTP packet?

    Because this topic touches on significant changes to the DHCP specification, it will be the subject of a separate document.

    Currently, 'siaddr' carries the address of one boot server, while 'sname' and the TFTP server name option (66) carry a DNS name. Is there a requirement for an option that carries a list of addresses of boot servers? draft-vijay-dhc-opt-extrboot-00.txt defines a new option with a list of servers and associated file names.

    9. Accept, reject, or further study SHOULD v. MUST changes

    draft-hibbs-dhc-changes-00.txt will be discussed in detail in the next conf call.

    10. Review of other issues as time permits

    (time did not permit)

    11. Schedule follow-on review of unresolved issues

    Next conf call scheduled for 2/25/04

    12. Identify RFC2131bis editors
    13. Identify interest and initial reviewers for RFC2132

    RFC2131 and RFC2132 must be updated in parallel. Editors will be identified after further revision to draft-hibbs-dhc-changes-00.txt. Review team will work on RFC2132 issues after completing review of RFC2131 issues.

    Wed 2/25/04 Interim Meeting Report

    Minutes from conf call on RFC2131 implementation issues
    Wed 2/25/04
    -------------------------------------------------------

    Participants: Ralph Droms (rdroms@cisco.com)
                  Barr Hibbs (rbhibbs@pacbell.net)
                  Kim Kinnear (kkineear@cisco.com)
                  Andre Kostur (Andre@incognito.com)
                  Rob Stevens (robs@cruzio.com)
    

    Inclusion of DHCPINFORM in specifications
    -----------------------------------------

    The design team affirmed the previous decision not to add DHCPINFORM to the state machine in RFC2131. There may be a need to revisit the definition of when to use DHCPINFORM, based on work elsewhere on "detecting network attachment" (DNA) and recognizing that applications may use DHCPINFORM to obtain specific configuration information.

    Consideration of parallel work on DHCP specification
    ----------------------------------------------------

    Work from other Internet Drafts that affects the DHCP specification will be integrated into RFC2131bis.

    XID consistency
    ---------------

    Clients MUST use the same XID for retransmitted messages. Otherwise, there are no restrictions on the XID supplied by the client. In particular, the client is not required to use the same XID in a DHCPDISCOVER and subsequent DHCPREQUEST.

    Server responding with client identifier
    ----------------------------------------

    Servers will be required to include the client identifier in all responses.

    (The following text discusses sections from draft-ietf-dhc-implementation-01.txt; text not explicitly discussed is implicitly accepted.)

    Section 2.11: Unicast of DHCPDISCOVER
    -------------------------------------

    The discussion of proxies (e.g., NAS, RAS) will be moved to a different document.

    Section 2.12; DHCPRELEASE
    -------------------------

    The following changes will be made to table 5 of RFC 2131 for the DHCPDECLINE and DHCPRELEASE messages:

    * the 'sname' and 'file' fields will be marked "unused" (rather than "MAY"; note that table 5 is inconsistent in its description of the use of the 'sname' and 'file' fields)
    * The 'message' option will be permitted
    * The 'message type' option is required (table 5 has the 'options' field as "(unused)")

    Section 2.13: Client state diagram
    ----------------------------------

    The state transition diagram and associated text will be checked for correctness and consistency. The text describing the diagram will clarify that the client first sends the associated message and then transitions to the next state.

    Section 2.14.1; Which options to return?
    ----------------------------------------

    The server should return options according to the following priority order:

    * return required fields (lease time, message type, subnet mask, client ID)
    * return options client requested
    * return additional options that an admin wants (SHOULD be configurable to do so)

    A client MUST be prepared to accept options that it did not request, and MUST gracefully discard any options that it does not recognize.

    The text from the 'long options' RFC will be folded into RFC2131bis.

    Section 2.14.3: Option ordering
    -------------------------------

    The client MUST NOT make any assumptions about the order of options in a DHCP message.

    Section 2.14.4: Options 66 and 67
    ---------------------------------

    Because this section addresses a fundamental change to the DHCP protocol message format, it will be moved to another document.

    Section 2.15: Vendor Classes
    ----------------------------

    Section 1.1 of RFC2131 will be discarded from RFC2131bis.

    Section 2.15.1: Character set
    -----------------------------

    The design team was unable to reach consensus on whether the vendor class identifier should be considered an opaque value, a printable string, or some other alternative. Also, there was no consensus about use of NVT ASCII or allowing the inclusion of whitespace characters. The question will be forwarded to the dhc WG mailing list.

    The text from 'Vendor-Identifying Vendor Options for DHCPv4" should be considered for inclusion in RFC2131bis.

    Section 2.16: Client/Server Retransmission
    ------------------------------------------

    The text on retransmission timing from RFC3315 should be reviewed for use in RFC2131bis. The issue will be posted to the dhc WG mailing list.

    Section 2.17: Transmission of DHCPNAKs
    --------------------------------------

    DHCPNAKs SHOULD be broadcast unless the server knows definitively that a unicast will get to the client (e.g., client has valid address in 'yiaddr'; server is disallowing further use of that address). Various sections of RFC2131bis should be reworded for correctness and clarity.

    Section 2.18: Use of ciaddr
    ---------------------------

    The last sentence in this section, "Servers trust 'ciaddr,' period.", is incorrect. Servers SHOULD check 'ciaddr' for correctness.

    Section 2.19: Size of a BOOTP/DHCP frame
    ----------------------------------------

    RFC2131bis should explicitly mention 300 octet lower bound for DHCP messages. Other issues - maximum size, MTU, use of fragmentation and message size options - will be discussed on the dhc WG mailing list.