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 60th IETF Meeting in San Diego, California USA. It may now be out-of-date.

Last Modified: 2004-06-30

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://www.ietf.org/mail-archive/web/dhcwg/index.html
Description of Working Group:
The dhc working group (DHC WG) has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCPv4 is currently a "Draft Standard" and is documented in RFC 2131 and RFC 2132. DHCPv6 is currently a "Proposed Standard" and is documented in RFC 3315. Subsequent RFCs document additional options and other enhancements to the specifications.

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.

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
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)
  • - draft-ietf-dhc-server-mib-10.txt
  • - draft-ietf-dhc-fqdn-option-07.txt
  • - draft-ietf-dhc-ddns-resolution-07.txt
  • - draft-ietf-dhc-leasequery-07.txt
  • - draft-ietf-dhc-agentopt-radius-07.txt
  • - draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt
  • - draft-ietf-dhc-isnsoption-12.txt
  • - draft-ietf-dhc-auth-suboption-04.txt
  • - draft-ietf-dhc-mipadvert-opt-02.txt
  • - draft-ietf-dhc-subscriber-id-06.txt
  • - draft-ietf-dhc-v4-threat-analysis-02.txt
  • - draft-ietf-dhc-dna-ipv4-08.txt
  • - draft-ietf-dhc-relay-agent-ipsec-01.txt
  • - draft-ietf-dhc-vendor-03.txt
  • - draft-ietf-dhc-3315id-for-v4-03.txt
  • - draft-ietf-dhc-dhcpv6-opt-sntp-00.txt
  • - draft-ietf-dhc-rapid-commit-opt-05.txt
  • - draft-ietf-dhc-reclassify-options-01.txt
  • - draft-ietf-dhc-client-id-00.txt
  • - draft-ietf-dhc-proxyserver-opt-01.txt
  • - draft-ietf-dhc-dhcpv6-ctep-opt-01.txt
  • - draft-ietf-dhc-dhcpv6-opt-rboot-00.txt
  • - draft-ietf-dhc-opt-extrboot-00.txt
  • - draft-ietf-dhc-dual-stack-01.txt
  • - draft-ietf-dhc-lifetime-01.txt
  • - draft-ietf-dhc-stateless-dhcpv6-renumbering-01.txt
  • Request For Comments:
    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
    RFC3736StandardStateless DHCP Service for IPv6

    Current Meeting Report

    Meeting Summary
    dhc WG, IETF 60
    2004-08-03, 0900


    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:


    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.


    Clarifications on DHCPv6 Authentication
    Broadcast-Multicast Service Controller Discovery via DHCP-Option-Codes
    Client FQDN Options