2.3.2 Dynamic Host Configuration (dhc)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC 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: 2004-09-29

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://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)

Internet-Drafts:

  • draft-ietf-dhc-server-mib-10.txt
  • draft-ietf-dhc-fqdn-option-07.txt
  • draft-ietf-dhc-ddns-resolution-08.txt
  • draft-ietf-dhc-leasequery-07.txt
  • draft-ietf-dhc-vpn-option-03.txt
  • draft-ietf-dhc-agentopt-radius-08.txt
  • draft-ietf-dhc-isnsoption-12.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-01.txt
  • draft-ietf-dhc-v4-threat-analysis-02.txt
  • draft-ietf-dhc-dna-ipv4-09.txt
  • draft-ietf-dhc-relay-agent-ipsec-01.txt
  • draft-ietf-dhc-3315id-for-v4-03.txt
  • draft-ietf-dhc-dhcpv6-opt-sntp-01.txt
  • draft-ietf-dhc-rapid-commit-opt-05.txt
  • draft-ietf-dhc-reclassify-options-01.txt
  • draft-ietf-dhc-proxyserver-opt-02.txt
  • draft-ietf-dhc-dual-stack-02.txt
  • draft-ietf-dhc-lifetime-02.txt
  • draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt
  • draft-ietf-dhc-vendor-suboption-00.txt
  • draft-ietf-dhc-dhcpv6-fqdn-00.txt
  • draft-ietf-dhc-dhcpv6-clarify-auth-00.txt

    Request For Comments:

    RFCStatusTitle
    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

    Current Meeting Report

    DHC
    IETF-61


    Administrivia Ralph Droms

    Droms asked about interest in DHCP server MIB, draft-ietf-dhc-server-mib. The specification has been reviewed by the IESG and is close to being done. However, one author is not interested in continuing to work on the specification and the other wants to confirm that there is sufficient interest before committing to more work on the document. Ted Lemon expressed interest in seeing a server MIB (although not necessarily this one). Droms will work with Glen Waters (document co-author) to complete the specification.


    Reclassifying DHCPv4 Options Bernie Volz

    draft-ietf-dhc-reclassify-options is about to be published as an RFC. Volz described the process for broadcasting notification of the process specified in the document, and asked for assistance in identifying all vendors whose use of option codes will be affected by this specification.


    DNS zone suffix option for DHCPv6 Renxiang Yan
    draft-yan-dhc-dhcpv6-opt-dnszone

    Yan gave a presentation about draft-yan-dhc-dhcpv6-opt-dnszone. The key idea is to send the DNS domain from which a host should form its FQDN to the host. Ted Lemon noted that the mechanism in this specification supposes that the host will then use DDNS to update its DNS information. This use of DDNS will require management of authorization information for individual hosts, which won't scale. The RA-based mechanism in draft-jeong-ipv6-ra-dns-autoconf has similar issues of scale. Further discussion will take place on the WG mailing list before coming to a decision about taking this draft on as a WG work item.


    Vendor-Specific Information Suboption Mark Stapp
    draft-stapp-dhc-vendor-suboption

    There was consensus in the room to take this draft to WG last call. Droms will confirm consensus on the WG mailing list.


    DHCP Authentication via EAP Mark Stapp

    Stapp presented summary of idea to use EAP for DHCP authentication (no document, yet). The premise of this work is that requiring the use of another set of keys around just to do DHCP is a non-starter and DNSSEC is not ready, so Stapp suggests using credentials already provisioned for 802.1x for DHCP authentication. There was some discussion about where in the authentication system (AAA server?) session keys might be generated. Stapp will write a draft based on his ideas for WG review.


    Information Refresh Time Option for DHCPv6 Stig Venaas
    draft-ietf-dhc-lifetime

    Venaas gave an update about the draft, which has been previously discussed by the WG. The title of the specification has been changed to "Information Refresh Time Option for DHCPv6" as the option controls when a client contacts the DHCP server, but does not cause previously obtained information to expire in any way. Some minor issues were raised about max and min values for lifetime which will be discussed on WG mailing list. Pending that discussion, there was consensus in room to go to WG last call. Consensus to be confirmed on WG mailing list.


    Multicast Reconfig. Protocol for Stateless DHCPv6 Daniel Park
    draft-vijay-dhc-dhcpv6-mcast-reconf

    Park gave a summary of the draft. Droms asked why the protocol uses Relay-reply message to notify router (through relay) to toggle 'M'/'O' bits; isn't CLI sufficient? Greg Daley suggested SNMP might be appropriate to cause router to toggle 'M'/'O' bits. Some additional discussion about whether this mechanism is needed if "Information Refresh Time Option for DHCPv6" is accepted for standards track. Volz pointed out that "multicast reconfig" is useful for unplanned renumbering. Park was requested to provide more detail; further discussion will take place on the WG mailing list before coming to a decision about taking this draft on as a WG work item.


    Anycast Address Assignment using DHCPv6 Syam Madanapalli
    draft-madanapalli-dhcpv6-anycast

    Madanapalli presented summary of the draft. Ted Lemon pointed out that the slides were somewhat different from the text in "draft-madanapalli-dhcpv6-anycast", and that the second part of the specification (in which the services are classified) begins to look a lot like SLP. Droms suggested the draft might be spit into two pieces: one for assignment and one for service classification. There was consensus in the room to accept the draft as a WG work item; the consensus will be confirmed on WG mailing list.


    Source Address Selection Policy option for DHCPv6 T. Fujisaki
    draft-hirotaka-dhc-source-address-selection-opt

    This draft provides a protocol for distribution of address selection policy, where those policies are described in RFC 3484. The draft is related to other drafts about distribution of policy currently before the ipv6 and multi6 WGs. John Schnizlein asked if this draft is really solving a routing problem. Ted Lemon asked if this is for reasonably stable and static multi-homed networks' authors agreed that this is for source address selection policy, not routing information. Further discussion will take place on the WG mailing list before coming to a decision about taking this draft on as a WG work item.


    DHCPv6 Relay Agent Information Option Wing Cheong Lau
    draft-droms-dhc-v6-relayopt

    The consensus in the room was to accept the draft as a WG work item; consensus will be confirmed on WG mailing list.


    Clarifications on DHCPv6 Authentication T. Jinmei
    draft-ietf-dhc-dhcpv6-clarify-auth

    Jinmei-san presented a list of changes to the draft in the most recent revision and a couple of outstanding issues:
    * draft recommends treating multiple exchanges as a single "session", which requires additional state in the server
    * should this draft be published independently or rolled into a revision of RFC 3315?
    Jinmei-san will initiate discussion of a couple of outstanding issues and then the draft will be ready for WG last call.


    DHCP Relay Agent Opt for MIPv6 bootstrapping Kuntal Chowdhury
    draft-chowdhury-dhc-mip6-agentop

    J. Bharatia presented a summary of the draft, which provides a mechanism through which a remote AAA server can pass the address of a MIP6 home agent to a roaming MIP6 host for initial configuration/bootstrapping. Mark Stapp objected to the relay agent modifying the DHCP message rather than inserting information in the relay option wrapper. It was mentioned that a similar draft that accomplishes the same objective without DHCP is under consideration in the mip6 WG. The author was requested to revise the draft to avoid modification of the DHCP message by the relay and the WG will consider the revised draft.


    DHCP-DNS interaction Bernie Volz
    draft-ietf-dhc-dhcpv6-fqdn
    draft-ietf-dhc-fqdn-option
    draft-ietf-dhc-ddns-resolution

    Volz presented a status report: these drafts along with draft-ietf-dhc-3315id-for-v4 and draft-ietf-dnsext-dhcid-rr will go to the IESG as a package. draft-ietf-dnsext-dhcid-rr is through WG last call (dnsext). The consensus in the room was to go to WG last call on draft-ietf-dhc-fqdn-option; consensus will be confirmed on the WG mailing list.

    Slides

    Agenda
    Reclassifying DHCPv4 Options
    DNS zone suffix option for DHCPv6
    DHCP Authentication Using EAP
    Information Refresh Time Option for DHCPv6
    Multicast Reconfiguration Protocol for Stateless DHCPv6
    Anycast Address Assignment Using DHCPv6
    Source Address Selection Policy option for DHCPv6
    DHCP Relay Agent Option to Support Mobile IPv6 bootstrapping
    Clarifications on DHCPv6 Authentication
    DHCPv6 Relay Agent Information Option and RADIUS Attributes Sub-option
    DHCP-DNS Interaction