The IESG has approved the Internet-Draft 'Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)' <draft-ietf-dhc-dhcpv6-28.txt> as a
Proposed Standard. This document is the product of the Dynamic Host
Configuration Working Group. The IESG contact persons are Erik
Nordmark and Thomas Narten.
Technical Summary
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables
DHCP servers to pass configuration parameters such as IPv6 network
addresses to IPv6 nodes. It offers the capability of automatic
allocation of reusable network addresses and additional
configuration flexibility. This protocol is a stateful counterpart
to "IPv6 Stateless Address Autoconfiguration" (RFC2462) and can be
used separately or concurrently with the latter to obtain
configuration parameters.
DHCPv6 offers two modes of operation. In stateful mode, the DHC
server maintains per-client configuration information (e.g.,
addresses). In stateless mode, the DHC server stores no per-client
information. Stateless mode is used when the information provided
is the same regardless of who asks for it, or because the
appropriate configuration information to be returned to a client
can be determined idempotently based on the information on the
request (e.g., all clients connected to particular links are to use
the same set of DNS servers).
Working Group Summary
There was consensus for this in the WG and no significant issues were
raised during the IETF Last Call.
Protocol Quality
This protocol has been reviewed for the IESG by Thomas Narten.
RFC Editor Note:
In Section 21.1, delete the following sentence from the first
paragraph:
> Relay agents and servers MUST support manual configuration and
> installation of static keys.
In Section 21.1, change the item:
> Key management Because the relay agents and servers must be
> manually configured, no automated key management
> is required.
to
Key management Because the relay agents and servers are used
within an organization, public key schemes are
not necessary. Because the relay agents and
servers must be manually configured, manually
configured key management may suffice, but
doesn't provide defense against replayed
messages. Accordingly, IKE with preshared
secrets SHOULD be supported. IKE with public
keys MAY be supported.
In Section 23, Security Considerations, add the following new second
paragraph, immediately after the first one:
Use of manually configured preshared keys for IPsec between relay
agents and servers does not defend against replayed DHCP messages.
Replayed messages can represent a DOS attack through exhaustion
of processing resources, but not through mis-configuration or
exhaustion of other resources such as assignable addresses.
