Current Meeting Report
Jabber Logs

2.3.3 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: -- Additional DHC Page
NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 05/24/2002

Ralph Droms <>
Internet Area Director(s):
Thomas Narten <>
Erik Nordmark <>
Internet Area Advisor:
Thomas Narten <>
Mailing Lists:
General Discussion:
To Subscribe:
Description of Working Group:
Other Lists:

A separate mailing list is used for discussing the IPv6 version of dhcp:

This working group has developed DHCP for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. DHCP is currently a "Draft Standard" (RFC2131, RFC2132). The working group now has four main objectives:

* Revise and submit the DHCP specification for acceptance as a Full Standard

* Develop a roadmap for the review and acceptance of new options, define a new option syntax, develop an accurate list of assigned option codes and identify option codes that can be safely reassigned

* Develop a specification for DHCP for IPv6

* Develop an inter-server communication for coordination of multiple servers

* Review new options for DHCP, as deemed appropriate by the working group chair and/or the Internet area directors; specific options currently under review in the working group include:

o Mechanisms for the authentication of clients and servers

o Interaction between DHCP and DNS dynamic update protocol

o Definition of a DHCP MIB for management of DHCP servers through SNMP

o Definition of an LDAP schema to provide a standardized format for the storage and retrieval of DHCP information, primarily configuration and lease data; this schema will be developed in coordination with the Policy Frameworks Working Group as appropriate.

o Options through which DHCP relay agents can pass information to DHCP servers

o Other options: user class, server selection, domain search

Goals and Milestones:
JUN 99  Submit Internet-Draft on subnet selection option in time for Oslo IETF
JUN 99  Submit Internet-Draft on DAP schema for DHCP in time for Oslo IETF
JUN 99  Submit Internet-Draft on DHCP authentication in time for Oslo IETF
JUN 99  Submit Internet-Draft on failover protocol in time for Oslo IETF
JUN 99  Submit Internet-Draft on relay agent options in time for Oslo IETF
JUN 99  Submit Internet-Draft on DHCP-DNS interaction in time for Oslo IETF
JUL 99  Submit Internet-Draft on DHCP authentication for WG last call
JUL 99  Develop plan for review of DHCP specification and acceptance as Internet Standard.
SEP 99  Submit DHCP server MIB specification for WG last call
SEP 99  Submit subnet selection option specification for WG Last Call
NOV 99  Submit DHCP server MIB specification for IESG consideration as a Proposed Standard
NOV 99  Submit LDAP schema specification for WG last call
MAR 00  Submit LDAP schema specification to IESG for consideration as a Proposed Standard.
  • - draft-ietf-dhc-dhcpv6-26.txt
  • - draft-ietf-dhc-failover-10.txt
  • - draft-ietf-dhc-server-mib-06.txt
  • - draft-ietf-dhc-csr-07.txt
  • - draft-ietf-dhc-packetcable-02.txt
  • - draft-ietf-dhc-fqdn-option-04.txt
  • - draft-ietf-dhc-ddns-resolution-04.txt
  • - draft-ietf-dhc-leasequery-03.txt
  • - draft-ietf-dhc-concat-04.txt
  • - draft-ietf-dhc-agent-vpn-id-01.txt
  • - draft-ietf-dhc-agent-subnet-selection-03.txt
  • - draft-ietf-dhc-dhcpv6-opt-dstm-01.txt
  • - draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt
  • - draft-ietf-dhc-agentopt-radius-00.txt
  • - draft-ietf-dhc-dhcpv6-loadb-02.txt
  • - draft-ietf-dhc-dhcpv6-opt-dstm-ports-01.txt
  • - draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt
  • - draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt
  • - draft-ietf-dhc-host-option-considerations-00.txt
  • - draft-ietf-dhc-isnsoption-01.txt
  • - draft-ietf-dhc-dhcpv6-opt-cliprefprefix-00.txt
  • - draft-ietf-dhc-auth-suboption-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
    RFC2132 DS DHCP Options and BOOTP Vendor Extensions
    RFC2131 DS Dynamic Host Configuration Protocol
    RFC2242 PS Netware/IP Domain Name and Information
    RFC2241 PS DHCP Options for Novell Directory Services
    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
    RFC3011 PS The Subnet Selection Option for DHCP
    RFC3004 PS The User Class 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

    Current Meeting Report

    DHC WG Meeting minutes
    IETF 55, Atlanta, 11/2002
    Administrivia, agenda bashing, Ralph Droms
    CableLabs Client Configuration option draft is in IETF last call.  So far, 
    the last call has elicited comments requiring some editorial and minor 
    specification changes.
    DHCPv6 specification has been reviewed by IESG, and requires small edits to 
    text describing relay agent security.  Droms will post summary of 
    changes to WG mailing list.
    Use of IPsec for Securing DHCPv4 Messages Exchanged Between Relay Agents and 
    Servers, Ralph Droms
    draft-droms-dhcp-relay-agent-ipsec-00.txt describes use of IPsec for 
    securing messages between relay agents and servers.  Carl Smith asked if it 
    is different than the mechanism in the DHCPv6 draft; answer: no.  Narten 
    asked for comparison with Stapp's 
    draft-ietf-dhc-auth-suboption-01.txt.   Droms noted IPsec mechanism is 
    hop-by-hop while authentication options covers entire path; IPsec 
    mechanism incurs extra complexity if there are multiple relay agents in the 
    path to the server.  The WG agreed to take the document on as a WG 
    The Authentication Suboption for the DHCP Relay Agent Option, Mark Stapp
    draft-ietf-dhc-auth-suboption-01.txt specifies a DHCP-specific 
    mechanism, based on a relay agent suboption that contains a message 
    digest for checking message integrity.  This mechanism uses shared keys and 
    includes an identifier mechanism to accommodate edge devices that don't use 
    giaddr.  With additional changes, this mechanism can accommodate 
    multiple, nested relay agents.
    The WG was asked what to do with the two proposals: advance both, adopt 
    one?  Does the WG have a clear understanding of the two proposals?  Ted 
    Lemon asked how we might weight the pros and cons.  Thomas Narten and 
    Stuart Cheshie asked if there is any data on whether IPsec 
    implementations are available to relay agents today.  Mark Stapp asked 
    about potential computational complexity issues.  Stapp, Lemon and John 
    Schnizlein all asked what the perceived customer requirements are.  Droms 
    expressed concern about interoperability if both proposals are 
    advanced.  Erik Nordmark asked how relay agents would be configured to use 
    IPsec or with the keys for the relay agent option.  Droms pointed out that 
    reuse of IPsec technology implies the availability of future IPsec 
    enhancements.  Schnizlein volunteered to organize discussion of pros and 
    cons of both proposals on the WG mailing list.
    DHCP Option for SNMP Notifications, Mark Bakke
    draft-bakke-dhc-snmp-trap-01.txt was developed to address 
    requirements for systems using diskless boot to obtain a list of IP 
    addresses to which to send SNMP traps.  Narten asked which WG is best for 
    discussion of this option - in theory, details should be discussed in an 
    SNMP WG with final review of syntax and compatibility in the dhc WG.  
    Narten will coordinate review of the document with MIB groups in the IETF, 
    and the document will ultimately be a dhc WG work item, as there are no 
    appropriate active SNMP WGs.  There was a question about whether the 
    option should be expanded with multiple sub-options for different trap 
    Subnet Allocation using DHCP, Richard Johnson
    This proposal describes a mechanism through which a DHCP server can 
    delegate a block of addresses (IPv4), collect usage data on the 
    delegated addresses and deprecate use of addresses.  It is similar to the 
    prefix delegation mechanism for DHCPv6.  Ted Lemon pointed out that this 
    proposal would require a major revision to existing server, and he 
    suggested that the authors review previous, related work by Walt Lazear.  
    The WG agreed to take on this document as a WG work item.
    DHCP Server-ID Override Suboption, Richard Johnson
    Some DHCP client messages, such as DHCPRENEW, are unicast directly to the 
    DHCP server and not received by a relay agent.  Thus, relay agents are 
    unable to add relay agent options to those messages.  This proposal 
    provides a mechanism through which the DHCP server can configure the 
    client to respond to the relay agent rather than directly to the server.  
    Narten asked if continued expansion of relay agent options is a good 
    thing.  WG consensus is that relay agent options have been found to 
    provide function that cannot be provided in other ways, and the full range of 
    application for relay agent options is still being explored.  Stapp 
    suggested revisiting the relay agent option specification, RFC3046, as a WG 
    charter item.  The WG agreed to take on this document as a WG work item.
    Considerations for the use of the Host Name option, Carl Smith
    Carl had one question for the WG: how can a client request that its 
    name/address association be removed from DNS?  Can we use the FQDN to 
    accomplish this result?  Kim Kinnear and Ted Lemon asked what customer 
    requires this result.  Bernie Volz suggested revisiting this question 
    after the DHCPv6 FQDN model is completed.
    Load Balancing for DHCPv6, Bernie Volz
    Any more changes needed in this draft?  No; so this document is ready for WG 
    last call after DHCPv6 spec has advanced.
    Other DHCPv6 options, Ralph Droms
    draft-ietf-dhc-dhcpv6-opt-prefix-delegation-00.txt has folded prefix 
    delegation into identity associations; the document is also under 
    discussion in the ipv6 WG.
    draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt are all ready for WG last call as 
    soon as DHCPv6 advances.
    draft-ietf-dhc-dhcpv6-opt-dstm-01.txt and 
    draft-ietf-dhc-dhcpv6-opt-dstm-ports-01.txt are to be synced up with v6ops 
    Lemon, Volz and Narten all asked about the requirement for the 
    mechanism proposed in 
    draft-ietf-dhc-dhcpv6-opt-cliprefprefix-00.txt.  A K Vijayabhaskar 
    (author) to clarify motivation and requirements in the 
    A Guide to Implementing Stateless DHCPv6 Service, Ralph Droms
    Droms asked the WG about the best way to specify the parts of DHCPv6 
    required for stateless DHCPv6 operation ("DHCPv6-lite") - for example, for 
    providing DNS server configuration without address assignment.  Stuart 
    Cheshire asked if the document should be informational or 
    standards-track.  Another possibility would be BCP.  The WG asked that the 
    Reconfigure message be added to 
    draft-droms-dhcpv6-stateless-guide-01.txt and accepted the document as a dhc 
    WG work item.
    Revised DHC WG charter and milestones, Ralph Droms
    Droms reported that the revised charter and milestones have been 
    submitted to the IESG.  The IESG suggested adding a separate charter item to 
    develop a mechanism through which a client can authenticate a server 
    without authentication of the client by the server.  Droms will add the 
    relay agent charter item suggested by Stapp (see above).
    Carl Smith, Bernie Volz and Barr Hibbs volunteered to be a design team that 
    will follow up on the charter item to review RFC3118; they will develop a 
    threat model and analysis of the authentication provided by RFC3118.  Barr 
    Hibbs volunteered to coordinate and act as editor for a review of the 
    DHCPv4 specification.
    Recycling option codes, Ralph Droms
    There are more than 15 options codes that have been assigned but never 
    used.  Droms will publish an Internet Draft identifying these option codes 
    and asking for feedback from the Internet community about whether these 
    option codes can be returned to IANA for reassignment.  After the 
    Internet Draft has been reviewed by the dhc WG and by the IESG, it will be 
    submitted to IANA.
    DHCP Lease Query, Kim Kinnear
    The WG last call on 
    draft-ietf-dhc-leasequery-05.txt has completed.  Based on input from the 
    last call, Kinnear has changed the draft to use a new option rather than 
    overloading the requested address option, and has made other editorial 
    changes.  The document is now ready for submission to the IESG.
    Link Selection sub-option for the Relay Agent Information Option, Kim 
    Last call on 
    draft-ietf-dhc-agent-subnet-selection-04.txt has completed.  This 
    document is waiting for authentication of relay agent messages to be 
    DHCP Subscriber ID Suboption for the DHCP Relay Agent Option, Richard 
    This option, in 
    draft-johnson-dhc-subscriber-id-00.txt, is motivated by a 
    requirement to identify a subscriber in a relay agent option, 
    regardless of the port to which the subscriber is attached.  The WG 
    agreed to take on this document as a WG work item.
    DHCP Option for Geographic Location, John Schnizlein
    This option, in 
    draft-polk-dhcp-geo-loc-option-00.txt, passes location information about a 
    DHCP client from the server to the client.  The immediate purpose is to 
    provide location information to IP phones.  The geopriv WG will own the 
    semantics, while the dhc WG will own the protocol and the syntax of the 
    The DHCP Client FQDN Option, Mark Stapp
    DDNS-DHCP conflict resolution, Mark Stapp
    Stapp reported on 
    draft-ietf-dnsext-dhcid-rr-05.txt.  There are no deployed 
    implementations of these drafts.  Cisco and two others have 
    (non-interoperable) implementation that use TXT RRs, waiting for 
    approval of DHCID RR.  Droms asked for a summary of changes to the 
    current drafts.  Stapp will post summaries to WG mailing list.  
    Gudmundsson asked if the DHSID RR should become a more general RR type.  WG 
    consensus was no, as that would delay progress of these drafts and there is 
    no specific requirement for other, similar RR types.  Gudmundsson and 
    Droms agreed documents are ready for dnsext and dhc WG last call.


    DHCP Option for SNMP Notifications
    Subnet Allocation Option
    Server ID Override sub-option
    DHCP Leasequery Messages
    Link Selection sub-option
    Subscriber-ID Relay Sub-option
    GeoLoc Option format
    The Relay-Agent Authentication Suboption