2.3.3 Dynamic Host Configuration (dhc)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional DHC Page

Last Modified: 2005-01-20


Ralph Droms <rdroms@cisco.com>
Stig Venaas <venaas@uninett.no>

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

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

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-10.txt
  • draft-ietf-dhc-ddns-resolution-08.txt
  • draft-ietf-dhc-leasequery-08.txt
  • draft-ietf-dhc-agent-vpn-id-03.txt
  • draft-ietf-dhc-vpn-option-04.txt
  • draft-ietf-dhc-isnsoption-13.txt
  • draft-ietf-dhc-auth-suboption-05.txt
  • draft-ietf-dhc-subscriber-id-07.txt
  • draft-ietf-dhc-server-override-01.txt
  • draft-ietf-dhc-subnet-alloc-02.txt
  • draft-ietf-dhc-dna-ipv4-09.txt
  • draft-ietf-dhc-relay-agent-ipsec-01.txt
  • draft-ietf-dhc-pxe-options-01.txt
  • draft-ietf-dhc-3315id-for-v4-04.txt
  • draft-ietf-dhc-dhcpv6-opt-sntp-01.txt
  • draft-ietf-dhc-rapid-commit-opt-05.txt
  • draft-ietf-dhc-proxyserver-opt-02.txt
  • draft-ietf-dhc-dual-stack-02.txt
  • draft-ietf-dhc-lifetime-03.txt
  • draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt
  • draft-ietf-dhc-vendor-suboption-00.txt
  • draft-ietf-dhc-dhcpv6-fqdn-02.txt
  • draft-ietf-dhc-dhcpv6-clarify-auth-00.txt
  • draft-ietf-dhc-bcmcv4-option-00.txt
  • draft-ietf-dhc-bcmcv6-option-00.txt
  • draft-ietf-dhc-soa-option-00.txt
  • draft-ietf-dhc-v6-relay-radius-00.txt

    Request For Comments:

    RFC1531 PS Dynamic Host Configuration Protocol
    RFC1532 PS Clarifications and Extensions for the Bootstrap Protocol
    RFC1533 PS DHCP Options and BOOTP Vendor Extensions
    RFC1534 DS Interoperation Between DHCP and BOOTP
    RFC1541 PS Dynamic Host Configuration Protocol
    RFC1542 DS Clarifications and Extensions for the Bootstrap 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
    RFC2937 PS The Name Service Search Option for DHCP
    RFC2939 BCP Procedure for Defining New DHCP Options and Message Types
    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
    RFC3315 PS Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
    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
    RFC3594 PS PacketCable Security Ticket Control Sub-option for the the DHCP CableLabs Client Configuration (CCC)Option
    RFC3633 Standard IPv6 Prefix Options for DHCPv6
    RFC3634 Standard KDC Server Address Sub-option
    RFC3646 Standard DNS Configuration Options for DHCPv6
    RFC3679 I Unused DHCP Option Codes
    RFC3736 Standard Stateless DHCP Service for IPv6
    RFC3898 Standard NIS Configuration Options for DHCPv6
    RFC3925 Standard Vendor-Identifying Vendor Options for DHCPv4
    RFC3942 Standard Reclassifying DHCPv4 Options
    RFC4014 Standard RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option

    Current Meeting Report

    Minutes from dhc WG meeting at IETF 62.

    Thanks to John Schnizlein and the anonymous Jabber scribe for taking
    notes from which these minutes were composed.

    3315id-for-v4 as requirement for other WG specifications? Ted Lemon
    Ted Lemon asked that the WG discuss the use of the client-identifier option, as defined in draft-ietf-dhc-3315id-for-v4-04.txt, in future specifications that involve DHCP. In particular, the specification for DHCP for IP-over-infiniband, draft-ietf-ipoib-dhcp-over-infiniband-09.txt, explicitly references the definitions for the client-identifier option from RFC 2132, rather than the new format defined in draft-ietf-dhc-3315id-for-v4-04.txt.

    Because draft-ietf-dhc-3315id-for-v4-04.txt formally updates the DHCP specification and deprecates other formats for the client-identifier, there is no need for the dhc WG to take any specific action. The dhc WG chairs will go the ipoib WG to insist that the deprecated formats for the client-identifier not be mentioned in draft-ietf-ipoib-dhcp-over-infiniband-09.txt.

    SMTP Option for DHCPv6 Martin Stiemerling
    draft-cadar-dhc-dhcpv6-opt-smtp-00.txt defines the equivalent of the DHCPv4 SMTP server option for DHCPv6. Ted Lemon said that the DHCPv4 option is unused and can be used to mount a denial of service attack. Stig Venaas said there is no evidence any e-mail clients use the DHCPv4 option. Ted said that it's not likely to be a good idea for a host to use the local SMTP server when roaming. Mark Andrews expressed that the option sounds like a good idea but the security issues need to be addressed.

    Christian will ask on an SMTP-related mailing list about whether the SMTP option is useful. The WG will then reconsider whether to take on the draft as a WG work item.

    Source Address Selection Policy option for DHCPv6 T. Fujisaki
    Fujisaki gave a short presentation about the option in
    draft-hirotaka-dhc-source-address-selection-opt-01.txt, which configurees the policy table for address selection in RFC 3484. Stig said the option looks useful and might even be extended to destination address selection. Alain Durand said that a policy global to the host won't be adequate because it may be application-dependent. Margaret Wasserman said that RFC 3484 says the table should be configurable, and it makes sense to carry thin-s configuration in DHCP, but the work on the option should be in the ipv6 WG.

    Fujisaki will rewrite
    draft-hirotaka-dhc-source-address-selection-opt-01.txt to define the option to carry only the RFC 3484 table configuration bits; a pointer to RFC 3484 will motivate need for selection table and this option. Fujisaki will take the edited draft to the ipv6 WG for review.

    DHCPv6 Relay agent RADIUS Attribute Option Wing Cheong Lau
    Thomas Narten asked the WG to consider the criteria for RADIUS attributes that may be carried in the relay agent option defined in

    DHCPv6 Options for Fast Handovers Takeshi Ogawa
    The author presented this draft at the mobopts IRTF WG, but there was no time for discussion. Consensus is that this draft should belong to a MIP-related WG.

    Service-Oriented Address Assignment using DHCP Syam Madanapalli
    Madanapalli summarized the mechanism in
    draft-ietf-dhc-soa-option-00.txt and
    draft-syam-dhc-soav4-option-00.txt as automating the process of assigning anycast addresses to services. The mechanism is based on the premise that some services will be provided through an anycast address. These addresses would be assigned dynamically on demand from the providing server, rather than using a well-known address.

    Ralph Droms asked how different kinds and types of services would be defined. Madanapalli responded that a draft defining the service descriptions needs to be written. Stig Venaas said that anycast wouldn't work when a client needs to choose a specific web server. Also, anycast has routing implications; how would anycast routing information be injected into the routing protocols?

    Margaret Wasserman found these options and the concepts confusing: addresses are assigned to interfaces, not services. Ralph responded that the mechanism in these drafts enables application services to be assigned an anycast address for the anycast-enabled service; the concept is similar to MADCAP assignment of multicast addresses.

    Thomas Narten asked who is the customer for these options? Droms asked if there is a document that describes the anycast service framework in more detail to provide a context for these options. Alain Durand said that this is a very complex area; how does the server know its role in asking for an anycast address?

    The WG consensus is to wait for an overall framework paper and specific customers before proceeding.

    Relay Agent Options Bernie Volz
    Bernie Volz described draft-volz-dhc-dhcpv6-remoteid-00.txt and draft-volz-dhc-dhcpv6-subid-00.txt as IPv6 version of the equivalent DHCPv4 relay agent option sub-options. The WG consensus was to accept these two drafts as WG work items.

    The WG then discussed forwarding DHCPv6 prefix delegation (DHCPv6-PD) through relay agents. The key issue is injecting routing information about delegated prefixes if the delegation is not done at the router to which the requesting router is attached. A couple of alternatives were discussed: edge router acts as DHCPv6-PD requesting router to internal DHCP server and then acts as delegating router to customer requesting router; new relay agent option allows delegating server to inform edge router of delegation in message carrying delegation to requesting router. Ted Lemon asked what happens if the edge router reboots and loses the information about delegated prefixes. Someone answered that the link to the CPE requesting router would flap and it would re-request the prefix delegation. David Hankins expressed a preference for using a real routing protocol like BGP. Discussion to continue on the WG mailing list.

    Zone Suffix Option for DHCPv6 Renxiang Yan
    Renxiang Yan was unable to attend the WG meeting. Droms presented some slides from an updated draft and explained that the server sends a domain to which the client prepends its host name to form an FQDN. No WG action taken at this time.

    DHCP: IPv4 and IPv6 Dual-Stack Issues
    Droms asked for WG consensus that draft-ietf-dhc-dual-stack-02.txt is ready for WG last call. Alain Durand said that the more general problem is really a multi-homed host problem rather than just IPv4-IPv6. The WG agreed that there is a multi-homed host problem, but there may be simplifying assumptions in the IPv4-IPv6 case so that considering this draft is a way to make progress. Consensus at the meeting was that the draft is ready for WG last call.

    Resolving the IPv4 and IPv6 Dual-Stack Issues Tim Chown
    WG was asked what are the next steps in resolving the dual stack issues listed in draft-ietf-dhc-dual-stack-02.txt. One conclusion from draft-ietf-dhc-dual-stack-02.txt is that IPv4 configuration should not be added to DHCPv6; rather, DHCPv4 and DHCPv6 should be kept separate, with the assumption that a single admin can keep the servers in sync.

    Droms asked what the scope of the next document might be. Ted Lemon said that he doesn't think there is a protocol solution. Another comment was that how to handle configuration of merging is a hard problem. Tim Chown suggested limiting the scope of a next document to the scenario in which both the DHCPv4 and DHCPv6 services are managed in the same admin domain. Dave Thaler said that there are two separate problems: (1) in absence of external input, how should information from different DHCP services be merged? (2) how does the DHCP service administrator resolve loss of information. The WG can help with (2). Alain Durand said that the first step is to determine if the information comes from the same domain and is, therefore, mergeable. Margaret Wasserman said that merging the list of DNS server is not as easy as it might seem - think about a client where one of its interfaces is in a split-DNS environment. The WG will continue to work on this issue.

    RFC3118 Delayed DHCP Authentication Using EAP Alper Yegin
    Alper Yegin gave a presentation on
    draft-yegin-eap-boot-rfc3118-01.txt, which uses RFC 3118 authentication with a shared key derived from the EAP authentication step. This mechanism would use a new relay agent suboption to push the key to the DHCP server, and a new option in authentication mechanisms (PANA, AVP; 802.1x TBD) to push the key to the client. draft-yegin-eap-boot-rfc3118-01.txt is a derivative of an earlier EAP-DHCP authentication by Yegin, which was not picked up as a WG work item because of technical concerns. Yegin will rewrite draft-yegin-eap-boot-rfc3118-01.txt to describe DHCP authentication independent of PANA, PPP or 802.1x, and include an appendix showing a specific implementation (preferably 802.1x).


    SMTP Option in DHCPv6
    Source Address Selection Policy option for DHCPv6
    DHCPv6 Relay Agent RADIUS Attributes Option
    HCP-based Fast Handover protocol
    Service-Oriented Address Assignment Using DHCP
    DNS Zone Suffix Option for DHCPv6