Last Modified: 2004-01-22
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)
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 |
RFC | Status | Title |
---|---|---|
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 |
RFC2489 | BCP | Procedure 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 |
RFC2939 | BCP | Procedure 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 |
RFC3646 | Standard | DNS Configuration Options for DHCPv6 |
RFC3633 | Standard | IPv6 Prefix Options for DHCPv6 |
RFC3634 | Standard | KDC Server Address Sub-option |
RFC3679 | I | Unused DHCP Option Codes |
|
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"' 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. |
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" 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. |