WG Action: RECHARTER: Dynamic Host Configuration (dhc)

[The IESG <[e-mail]>]

The charter of the Dynamic Host Configuration (dhc) working group in the 
Internet Area of the IETF has been updated. For additional information, 
please contact the Area Directors or the working group Chairs.

Dynamic Host Configuration (dhc)
================================

Current Status: Active Working Group

Chair(s):
Ralph Droms <[e-mail]>

Internet Area Directors:
Thomas Narten <[e-mail]>
Margaret Wasserman <[e-mail]>

Internet Area Advisor:
Margaret Wasserman <[e-mail]>

Mailing Lists:
General Discussion: [e-mail]
To Subscribe: http://www.ietf.org/mailman/.istinfo/dhcwg
Archive: http://www.ietf.org/mail-archive/web/dhcwg/index.html

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 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 Configuration Options for DHCPv6" to IESG
(draft-ietf-dhc-dhcpv6-opt-nisconfig)
Done Submit "IPv6 Prefix Options for DHCPv6" to IESG
(draft-ietf-dhc-dhcpv6-opt-prefix-delegation)
Done Submit "Simple Network Time Protocol Configuration Option for
DHCPv6" to IESG (draft-ietf-dhc-dhcpv6-opt-sntp)
Jul04 Submit "Detection of Network Attachment (DNA) in IPv4" to IESG
(draft-ietf-dhc-dna-ipv4)
Jul04 Resolve IPR issues around "Rapid Commit Option for DHCPv4"
Aug04 Publish report on dual-stack issues in DHCP (draft-ietf-dhc-dual-stack)
Aug04 Publish report on requirements for renumbering using stateless
DHCPv6 (draft-ietf-dhc-stateless-dhcpv6-renumbering)
Sep04 Submit "Lifetime Option for DHCPv6" to IESG (draft-ietf-dhc-lifetime)
Sep04 DHCPv4 authentication design team report completed, "Dynamic
Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis"
Sep04 DHCPv4 specification review report completed
Sep04 Submit "DHCP Failover Protocol" to IESG (draft-ietf-dhc-failover)
Sep04 Submit "Rapid Commit Option for DHCPv4" to IESG
(draft-ietf-dhc-rapid-commit-opt)
Dec04 Submit DDNS/DHCP documents to IESG
Dec04 Submit "Node-Specific Client Identifiers for DHCPv4" to IESG
(draft-ietf-dhc-3315id-for-v4)



_______________________________________________
IETF-Announce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf-announce