Last Modified: 2004-06-30
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:
* 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 DHCPFORCERENEW
- 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 RFC 2131, RFC 2132 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.
* Assess the requirements for a dual-stack host to use DHCP to obtain configuration settings for both IPv4 and IPv6. Hosts that include implementations of both IPv4 and IPv6 ("dual-stack hosts") may use DHCP to obtain configuration settings (including assigned addresses) for both IPv4 and IPv6. The DHCPv4 and DHCPv6 specifications (RFC 2131, RFC 2132, RFC 3315 and subsequent RFCs) do not explicitly explain how a dual-stack host uses DHCP to obtain configuration settings for both IP stacks. The DHC WG will evaluate solutions for configuration of dual-stack hosts through DHCP and select a solution that will be developed and published by the WG.
* Assess the requirements for informing DHCPv6 clients of changes in configuration information. The DHCPv6 specification in RFC 3315 includes a mechanism through which clients can obtain other configuration information without obtaining an address or addresses. This mechanisms is sometimes called "stateless DHCPv6" and is specified in RFC 3736. RFC 3315 includes no provision for notifying DHCPv6 clients using stateless DHCPv6 of changes in the configuration information supplied to the client or any recommendations as to when a client should obtain possibly updated information. The DHC WG will evaluate solutions for informing DHCPv6 clients of changes in configuration information and select a solution that will be developed and published by the WG.
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 | |
Done | Submit DHCP Options for Internet Storage Name Service to IESG (draft-ietf-dhc-isnsoption) | |
Done | Submit DNS Configuration options for DHCPv6 to IESG (draft-ietf-dhc-dhcpv6-opt-dnsconfig) | |
Done | Submit NIS Configuratio Options for DHCPv6 to IESG (draft-ietf-dhc-dhcpv6-opt-nisconfig) | |
Done | Submit IPv6 Prefix Options for DHCPv6 to IESG (draft-troan-dhcpv6-opt-prefix-delegation) | |
Jul 04 | Submit 'Detection of Network Attachment (DNA) in IPv4' to IESG (draft-ietf-dhc-dna-ipv4) | |
Jul 04 | Resolve IPR issues around 'Rapid Commit Option for DHCPv4' | |
Aug 04 | Publish report on dual-stack issues in DHCP (draft-ietf-dhc-dual-stack) | |
Aug 04 | Publish report on requirements for renumbering using stateless DHCPv6 (draft-ietf-dhc-stateless-dhcpv6-renumbering) | |
Sep 04 | Submit 'Lifetime Option for DHCPv6' to IESG (draft-ietf-dhc-lifetime) | |
Sep 04 | DHCPv4 authentication design team report completed, 'Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis' | |
Sep 04 | DHCPv4 specification review report completed | |
Sep 04 | Submit 'DHCP Failover Protocol' to IESG (draft-ietf-dhc-failover) | |
Sep 04 | Submit 'Rapid Commit Option for DHCPv4' to IESG (draft-ietf-dhc-rapid-commit-opt) | |
Dec 04 | Submit DDNS/DHCP documents to IESG | |
Dec 04 | Submit 'Node-Specific Client Identifiers for DHCPv4' to IESG (draft-ietf-dhc-3315id-for-v4) |
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 |
RFC3736 | Standard | Stateless DHCP Service for IPv6 |
Meeting Summary
dhc WG, IETF 60 2004-08-03, 0900 ---------------- Administrivia ------------- The chair gratefully acknowledges Kim Kinnear, John Schnizlein for providing notes and Tim Chown for acting as jabber scribe, which the chair used in preparing these minutes. The chair announced that Samung has published a zero-cost licensing IPR claim on draft-ietf-dhc-rapid-commit-opt-05.txt. There was no objection in the WG to moving the draft draft forward. The chair announced that there was no response from PacketFront to a request from the IETF for clarification of IPR claim and a request from the chair for a zero-cost licensing IPR claim on draft-ietf-dhc-subscriber-id-06.txt. The consensus of the WG was to move the draft forward despite the current IPR claim. The DHCPv6 Client FQDN Option <draft-volz-dhc-dhcpv6-fqdn> ---------------------------------------------------------- The author gave a short presentation on the draft and asked for comments. Kim Kinnear suggested that we spell out how to handle the case(s) where the client doesn't send in the FQDN option. One issue is, can the server reply with the FQDN to the client if the client doesn't send it in? The draft currently says no. Another issue is what to do if the client send in an FQDN option, and then doesn't for one time, what should the server do? Pekka Savloa asked what about a client that tries to update DNS itself, and what is the operational reasons for the DHCP server to do the update instead of the DHCP client. Bernie and Mark suggested that using the client FQDN option doesn't change the fact that you have opened up the DNS server to dynamic updates. Ted suggested that this DHCPv6 approach parallels the DHCPv4 approach, and that the questioner should perhaps review the DHCPv4 drafts on this subject to better understand how the entire approach operates. Ted Lemon asked if there is a potential explosion of sending lots of names back with a single request? Bernie said yes, the server might offer multiple names. Margaret Waasserman asked if review of this draft would this be coordinated with the dnsext WG? The chair answered yes along with the others in this package (see below for list) that are being coordinated. After some discussion of the technical details, the consensus of the WG at the meeting was to accept draft-volz-dhc-dhcpv6-fqdn as a WG work item. It will be part of a package of drafts to be submitted to the IESG: draft-volz-dhc-dhcpv6-fqdn draft-ietf-dhc-fqdn-option draft-ietf-dnsext-dhcid-rr-07.txt draft-ietf-dhc-ddns-resolution-07.txt draft-ietf-dhc-3315id-for-v4-03.txt The consensus to accept the draft will be confirmed on the WG mailing list. The DHCP Client FQDN Option <draft-ietf-dhc-fqdn-option> --------------------------------------------------------- The author summarized the editorial changes. The WG meeting consensus was that this draft is ready for WG last call. It will go to last call when other drafts in the package are ready. The consensus that the draft is ready for WG last call will be confirmed on the WG mailing list. DHCP Option for Configuring IPv6-over-IPv4 Tunnels <draft-daniel-dhc-ipv6in4-opt> Configured Tunnel End-Point Config. using DHCPv4 <draft-daniel-dhc-dhcpv4-tep-conf> ----------------------------------------------------------------------------------- Discussion focused on <draft-daniel-dhc-ipv6in4-opt>. Ted Lemon suggested that the draft specificaly require that this option only be sent when the client has requested the option. The WG meeting concensus was to table discussion until dhc and v6ops WG chairs discuss which WG should take on these drafts and how the drafts fit into the v6ops WG discussion of tunnel discovery methods. Vendor-Specific Information Suboption for RAIO <draft-stapp-dhc-vendor-suboption> --------------------------------------------------------------------------------- The WG meeting consensus was to accept this draft as a dhc WG work item. The consensus will be confirmed on the WG mailing list. Renumbering Requirements for Stateless DHCPv6 <draft-ietf-dhc-stateless-dhcpv6-renumbering> ------------------------------------------------------------------------------------------- The author summarized the changes since the draft was last discussed in Seoul. It is related to the renumbering draft by Baker, et al., in the v6ops WG. The WG meeting consensus was that the draft is to be submitted to the IESG independent of any specific solution, for publication as an Informational RFC. The WG meeting consensus was that draft is ready for WG last call (to be confirmed on the WG mailing list). Lifetime Option for DHCPv6 <draft-ietf-dhc-lifetime> ---------------------------------------------------- The author presented the updated draft and asked three questions: What if the client asks for option and doesn't get it from the server? Stig's answer is that if you get it once and don't get it again, it should be like it never came in. What should happen if the client can't renew information. Don't forget what you've got while you are waiting for the update. Should we support stateful DHCP? If you get this option when doing stateful along with a lease time, what should you do? If this time is different than the lease time, how does a DHCP client handle it. These questions will be taken to the WG mailing list. The WG meeting consensus was to accept this draft as the solution chosen by the WG to meet the requirements defined in draft-ietf-dhc-stateless-dhcpv6-renumbering. The author will publish a revision based on comments from the meeting and the WG mailing list before consideration for WG last call. DHCP Option for Home Agent Discovery in MIPv6 <draft-jang-dhc-haopt> -------------------------------------------------------------------- This draft addresses the MIPv6 bootstrapping problem - how does a mobile node learn the address of its home agent? The WG suggested that the draft should specificy use of RFC 1035 encoding when carrying an FQDN. The chair will have a discussion with the mip6 chairs to determine which WG should take on this draft. Is there interest in 3GPP2 to use this option as well? Issues in DHCPv6 authentication <draft-jinmei-dhc-dhcpv6-clarify-auth> ---------------------------------------------------------------------- The author presented a summary of the draft, which clarifies issues in DHCPv6 authentication based on implmenetation experience. The WG meeting consensus was to take on this draft as a WG work item, to be published as PS, updating RFC 3315. The contents will be merged with RFC 3315 for DS. IPv6 multicast address assignment with DHCPv6 <draft-jdurand-assign-addr-ipv6-multicast-dhcpv6> ----------------------------------------------------------------------------------------------- This draft describes multicast address management using DHCPv6, because the author considers MADCAP (RFC 2970), SAP (RFC 2974), random choice, GLOP and ZMAAP inadequate. The draft describes a new identity association, IA_MA, that carries multicast addresses. The scope option allows the request to specific scope for the assigned addresses. Some mailing list discussion issues: 1. Should it be split into two drafts? 2. Range for group-id usefullness. 3. Timers specified with a new DHCPv6 option? 4. Scope option mandatory? 5. DHCPv6 in userspace - not in kernel? Problems? 6. IPv4 multicast address assignment? Should this be considered? 7. Prefix delegation for IPv6 multicast addresses? Dave Thaler suggested MADCAP provides multicast address assignment, is there a need for a new mechanism? The author responded that MADCAP exists, but people haven't actually deployed it. Thaler asked if that is a reason to try to do this with DHCPv6, or should MADCAP be required? Dave also asked if we do this with DHCPv6, then what do we about IPv4 multicast? Chair to discuss this draft with mboned chairs to determine where the draft should be reviewed and how to move forward. DHCPv4 Opts. for B-cast and M-cast Control Servers <draft-chowdhury-dhc-bcmcv4-option> DHCPv6 Opts. for B-cast and M-cast Control Servers <draft-chowdhury-dhc-bcmcv6-option> -------------------------------------------------------------------------------------- These two drafts were discussed together. The chair will discuss these drafts with the Internet ADs and the 3GPP2 liaison to determine how to move the drafts forward. IPv4 and IPv6 Dual-Stack Issues for DHCPv6 <draft-ietf-dhc-dual-stack> ---------------------------------------------------------------------- The WG Meeting consensus was to choose separate servers as the solution to dual-stack DHCP service. Discussion of other questions will move to the WG mailing list. |