2.3.3 Dynamic Host Configuration (dhc)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. 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-06-27

Chair(s):

Ralph Droms <rdroms@cisco.com>
Stig Venaas <sv@ecs.soton.ac.uk>

Internet Area Director(s):

Mark Townsley <townsley@cisco.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-10.txt
  • draft-ietf-dhc-ddns-resolution-09.txt
  • draft-ietf-dhc-leasequery-08.txt
  • draft-ietf-dhc-agent-vpn-id-03.txt
  • draft-ietf-dhc-vpn-option-05.txt
  • draft-ietf-dhc-isnsoption-13.txt
  • draft-ietf-dhc-server-override-02.txt
  • draft-ietf-dhc-subnet-alloc-03.txt
  • draft-ietf-dhc-dna-ipv4-13.txt
  • draft-ietf-dhc-relay-agent-ipsec-02.txt
  • draft-ietf-dhc-pxe-options-01.txt
  • draft-ietf-dhc-3315id-for-v4-05.txt
  • draft-ietf-dhc-proxyserver-opt-04.txt
  • draft-ietf-dhc-dual-stack-03.txt
  • draft-ietf-dhc-lifetime-03.txt
  • draft-ietf-dhc-vendor-suboption-00.txt
  • draft-ietf-dhc-dhcpv6-fqdn-02.txt
  • draft-ietf-dhc-soa-option-00.txt
  • draft-ietf-dhc-v6-relay-radius-00.txt
  • draft-ietf-dhc-bcmc-options-02.txt
  • draft-ietf-dhc-dhcpv6-subid-00.txt
  • draft-ietf-dhc-dhcpv6-remoteid-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
    RFC3942 Standard Reclassifying DHCPv4 Options
    RFC3993 Standard DHCP Subscriber ID Suboption for the DHCP Relay Agent Option
    RFC4014 Standard RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option
    RFC4030 Standard The Authentication Suboption for the DHCP Relay Agent Option
    RFC4039 Standard Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4)
    RFC4075 Standard Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6
    RFC4076 I Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

    Current Meeting Report

    Minutes from dhc WG meeting at IETF-63
    --------------------------------------
    
    Thanks to John Schnizlein for taking notes and "Struk" for acting as
    Jabber scribe.  Their input contributed to these minutes.
    
    Administrivia from the chairs
    -----------------------------
    
    A revision of draft-ietf-geopriv-dhcp-civil-06 will be published soon
    that gives details about "security concerns related to using DHCP to
    update the database."  Members of the WG are asked to review the
    changes in the new revision, relative to
    draft-ietf-geopriv-dhcp-civil-04, which was reviewed in a dhc WG last
    call.
    
    The chairs asked for volunteers to restart two initiatives: DHCP
    threat analysis, DHCP implementation experience.
    
    The chairs are reviewing draft-ietf-dhc-failover-12.txt prior to
    submission to the IESG.
    
    The WG discussed the status of draft-ietf-dhc-bcmc-options-02.txt.
    There are some IESG Discuss issues outstanding.  Ted Lemon said that
    he had commented during the WG last call that he would prefer that the
    BCMC option specify only IP addresses and not FQDNs.  Elwyn Davies
    reviewed issues raised by the General Area review team.  Stig Venaas
    will post a summary of outstanding issues to the WG mailing list.  The
    authors will publish a revision that addresses the outstanding issues.
    
    
    DHCP Option for Proxy Server Configuration
      
    ------------------------------------------
    
    Michael Alexander presented and raised a couple of issues: use RDF or
    XML encoding; push or pull Javascript?  Ted Lemon noted that XML
    encoding may be too large to fit in a DHCP message.  David Hankins
    said he is satisfied with the responses to his earlier comments about
    the draft.  Mark Stapp asked if there are any expected uses of this
    option.  Hankins respnded that the RedHat "network manager" would
    likely use it.  The WG came to consensus use a URI that could be used
    to obtain additional configuration information.  The authors will
    revise the draft to specify the use of URIs.
    
    
    Merging of data from DHCP4 and DHCPv6
      
    -------------------------------------
    
    Stig Venaas presented and explained that this draft gives solutions to
    some of the issues raised in draft-ietf-dhc-dual-stack-03.  Examples
    of solutions include using FQDNs in options (returning both IPv4 and
    IPv6 addresses) and depend on implementation of address selection
    rules (RFC 3484) for selection between IPv4 and IPv6.  Alain Durand
    noted that there is some urgency in coming to a solution, and that the
    client's DUID might be useful to a merged DHCP server to correlate the
    DHCPv4 and DHCPv6 clients from the same host.  Tim Chown responded
    that a solution is needed quickly, but the WG must be sure to review
    all possible solutions.  Another suggestion was to use IPv4-mapped
    addresses in IPv6 options.  Ted Lemon said that the draft doesn't
    actually say what's going on before talking about how to solve the
    problem.  There was unanimous consensus at the WG meeting to accept
    the draft as a WG work item.  WG consensus will be confirmed on the WG
    mailing list.
    
    
    DHCPv6 Default Address Selection Policy option
      
    ----------------------------------------------
    
    T. Fujisaki presented.  The WG discussed which WG should be
    responsible for this draft.  Ted Lemon asked why we are waiting if we
    are addressing control of a mechanism that is already specified in an
    RFC?  Margaret Wasserman said there needs to be a demonstrated
    requirement, and the option should be developed with those
    requirements in mind.  The ipv6 WG discussed RFC 3484; specifically,
    should RFC 3484 be revised because some text is obsolete (e.g., text
    referring to site-local addresses) and is the address selection
    mechanism is useful.  There are some scenarios in which centralized
    control of address selection would be useful: if RFC 3484bis defaults
    are not appropriate; shim6 WG would find centralized control useful.
    Greg Daley suggested the selection mechanism could also be controlled
    through router advertiesements.  The dhc WG decided to defer
    consideration of the draft until the ipv6 WG decides (a) what to do
    about RFC 3484; (b) is centralized control of address selection useful
    and (c) should it be controlled through a DHCP option.
    
    
    Zone Suffix Option for DHCPv6
      
    -------------------------------------------
    
    R. Yan presented.  This option addresses the deployment scenario in
    which hosts need to learn about domain suffix (not "zone suffix") in a
    network that has acquired IPv6 addresses through prefix delegation.
    Ted Lemon asked that text restricted use to a particular deployment
    scenario be deleted, as the option may have broader application.
    There was consensus at the WG meeting to accept the draft as a WG work
    item.  WG consensus will be confirmed on the WG mailing list.
    
    
    DHCP Option for CLF/NASS
      
    ------------------------------------------
    
    Spencer Dawkins presented.  This option addresses configuration of
    NGN terminals (TE) with a network identifer.  The identifier may be an
    IPv4 address, an FQDN or a string (for networks that don't tie
    identification to IP).  Dawkins said that there is no need for an IPv6
    encoding today. Ted Lemon said the draft uses many undefined
    acronyms.
    
    The WG then discussed the problem of data encoding in DHCP options.
    Various DHCP server implementers came to consensus that representing
    different data encodings as sub-options would be the easiest to
    implement.
    
    There was insufficient WG review and response to take the draft on as
    a WG work item.  The WG will review the next revision and reconsider
    its status.
    
    
    TAHI DHCPv6 test tool
    ---------------------
    
    Nobumichi Ozoe presented.  TAHI expects to have a beta release of
    DHCPv6 test tools available October 2005, and 1.0 release April 2006.
    Announcements of availability will be posted to the dhcwg@ietf.org
    mailing list.  Also watch www.tahi.org/dhcpv6.
    
    
    DHCPv6 client
    -------------
    
    Ted Lemon announced that he has been developing a DHCPv6 client based
    on the ISC DHCPv4 client.  The protocol work is done and he is now
    working on stack integration.  Rob Austein said that ISC is interested
    in the client.
    
    
    Status report on option code registration
    -----------------------------------------
    
    Bernie Volz reported on option code registration as specified by RFC
    3942.  He has discovered many clashes; details available at iana.org.
    18 options have been described as "tentatively assigned" in 128-223
    space; 10 of those options have multiple uses.  The good news is that
    78 out of the possible 96 option codes have not been claimed and are
    available for assignment to new DHCP options.  Those claiming usage of
    options will be asked to document that usage in an Informational RFC.
    
    DHCPv4 option for PANA Authentication Agents
      
    ----------------------------------------
    
    Suraj Kumar presented.  Mark Stapp pointed out that this option also
    uses multiple encodings (see earlier discussion) and should be
    redefined to use sub-options.  Greg daley noted that the DNS name
    might not be useful because a host cannot use DNS if it is not
    authenticated.  There was unanimous consensus at the WG meeting to
    accept the draft as a WG work item.  WG consensus will be confirmed on
    the WG mailing list.
    
    
    Review of RA M/O bits discussion
    --------------------------------
    S. D. Park presented a summary of the discussion about the ND RA M/O
    bits that has been on the ipv6 mailing list and at the ipv6 WG meeting
    at IETF 63.  The ipv6 WG has three requirements (from
    http://www1.ietf.org/mail-archive/web/dhcwg/current/msg05255.html): 
    
    1) Ability to indicate to a host "DHCP is not available on this link",
       with the expectation that the host won't send any DHCP messages
    
    2) Ability for a host to get all desired and available DHCP
       configuration with a single DHCP message exchange
    
    3) Ability to do DHCP without having to configure routers
      (e.g., by ignoring RA with M=0 and/or O=0 and invoking HCB and/or
      ICB anyway)
    
    Requirement 1 is acceptable, the dhc WG will need to investigate
    requirement 2 and requirement 3 is not suitable.  Mark Stapp pointed
    out that the use of the M/O bits should be to indicate availability of
    a service.
    
    
    DHCPv6<->DNA interaction
    ------------------------
    
    Brett Pentland presented work from the dna WG that may have an impact
    on DHCPv6.  DNA would eliminate the need for DHCPv6 Confirm/Reply
    message exchange (which is itself a form of "DNA").  There will be a
    discussion on the dhc WG mailing list about whether DNA would require
    a chnage to RFC 3315.
    
    
    Route Injection for DHCPv6 Prefix Delegation
    --------------------------------------------
    
    Ralph Droms summarized a discussion about injecting routes for
    delegated prefixes when the delegating router (DR) and requesting
    router (RR) are not on the same link.  Alternatives:
    
    1. RR injects the route (generic routing protocol)
    2. Relay agent injects the route
    2a. Relay agent learns about delegated prefix through relay agent
        option 
    2b. Relay agent learns about delegated prefix by snooping messages to
        clients
    2c. Network element on which relay agent resides (that must perofrm
        route injection) learns about route through some out-of-band
        mechanism (some other configuration protocol)
    3. DR (really, DHCPv6 server) injects the route
    
    Option 1 involves trusting the RR: authenticate its identity,
    authenticate the contents of the update message, confirm the RR has
    the right to advertise the prefix.  Options 2 require something like
    leasequery so the relay agent cna recover state.  Option 3 is probably
    not viable.  The WG will continue discussion on the mailing list.
    
    
    
    

    Slides

    Introduction, Agenda, Administrivia
    DHCP Option for Proxy Server Configuration
    Dual-stack clients and merging of data from DHCPv4 and DHCPv6
    Zone Suffix Option for DHCPv6
    DHCP Option for CLF/NASS
    DHCPv4 option for PANA Authentication Agents
    TAHI DHCPv6 test tool
    Status repon on option code registration
    DHCPv6-DNA interaction
    Route Injection for DHCPv6 Prefix Delegation