draft-ietf-dhc-dhcpv6-04.txt   draft-ietf-dhc-dhcpv6-05.txt 
Internet Engineering Task Force J. Bound Internet Engineering Task Force J. Bound
INTERNET DRAFT Digital Equipment Corp. INTERNET DRAFT Digital Equipment Corp.
DHC Working Group C. Perkins DHC Working Group C. Perkins
Obsoletes: draft-ietf-dhc-dhcpv6-03.txt IBM Research Obsoletes: draft-ietf-dhc-dhcpv6-04.txt IBM Research
12 February 1996 12 June 1996
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
draft-ietf-dhc-dhcpv6-04.txt draft-ietf-dhc-dhcpv6-05.txt
Status of This Memo Status of This Memo
This document is a submission to the DHC Working Group of the This document is a submission to the DHC Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted Internet Engineering Task Force (IETF). Comments should be submitted
to the dhcp-v6@bucknell.edu mailing list. to the dhcp-v6@bucknell.edu mailing list.
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
skipping to change at page 1, line 39 skipping to change at page 1, line 39
``1id-abstracts.txt'' listing contained in the Internet- Drafts ``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
Distribution of this document is unlimited. Distribution of this document is unlimited.
Abstract Abstract
The Dynamic Host Configuration Protocol (DHCP) provides a framework The Dynamic Host Configuration Protocol (DHCP) provides a framework
for passing configuration information, via options, to IPv6 hosts. for passing configuration information, via extensions, to IPv6 hosts.
It offers the capability of automatic allocation of reusable network It offers the capability of automatic allocation of reusable network
addresses and additional configuration options. This protocol should addresses and additional configuration flexibility. This protocol
be considered a stateful counterpart to the IPv6 Stateless Address should be considered a stateful counterpart to the IPv6 Stateless
Autoconfiguration protocol specification. Address Autoconfiguration protocol specification.
Contents Contents
Status of This Memo i Status of This Memo i
Abstract i Abstract i
1. Introduction 1 1. Introduction 1
1.1. Specification Language . . . . . . . . . . . . . . . . . 1 1.1. Specification Language . . . . . . . . . . . . . . . . . 1
2. Terminology and Definitions 2 2. Terminology and Definitions 2
2.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 2 2.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 2
2.2. DHCPv6 Terminology . . . . . . . . . . . . . . . . . . . 4 2.2. DHCPv6 Terminology . . . . . . . . . . . . . . . . . . . 3
3. Protocol Design Model 5 3. Protocol Design Model 4
3.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Design Goals . . . . . . . . . . . . . . . . . . . . . . 5
3.2. DHCPv6 Messages . . . . . . . . . . . . . . . . . . . . . 6 3.2. DHCPv6 Messages . . . . . . . . . . . . . . . . . . . . . 6
3.3. Request/Response Processing Model . . . . . . . . . . . . 7 3.3. Request/Response Processing Model . . . . . . . . . . . . 7
4. DHCPv6 Message Formats and Field Definitions 8 4. DHCPv6 Message Formats and Field Definitions 7
4.1. UDP Ports used for DHCPv6 messages . . . . . . . . . . . 8 4.1. UDP Ports used for DHCPv6 messages . . . . . . . . . . . 7
4.2. DHCP Solicit Message Format . . . . . . . . . . . . . . . 8 4.2. DHCP Solicit Message Format . . . . . . . . . . . . . . . 8
4.3. DHCP Advertise Message Format . . . . . . . . . . . . . . 9 4.3. DHCP Advertise Message Format . . . . . . . . . . . . . . 8
4.4. DHCP Request Message Format . . . . . . . . . . . . . . . 10 4.4. DHCP Request Message Format . . . . . . . . . . . . . . . 10
4.5. DHCP Reply Message Format . . . . . . . . . . . . . . . . 12 4.5. DHCP Reply Message Format . . . . . . . . . . . . . . . . 11
4.6. DHCP Release Message Format . . . . . . . . . . . . . . . 13 4.6. DHCP Release Message Format . . . . . . . . . . . . . . . 12
4.7. DHCP Reconfigure Message Format . . . . . . . . . . . . . 14 4.7. DHCP Reconfigure Message Format . . . . . . . . . . . . . 14
5. DHCP Client Considerations 15 5. DHCP Client Considerations 15
5.1. DHCP Solicit Message Processing . . . . . . . . . . . . . 15 5.1. Sending DHCP Solicit Messages . . . . . . . . . . . . . . 15
5.2. DHCP Advertise Message Processing . . . . . . . . . . . . 15 5.2. Receiving DHCP Advertise Messages . . . . . . . . . . . . 15
5.3. DHCP Request Message Processing . . . . . . . . . . . . . 16 5.3. Sending DHCP Request Messages . . . . . . . . . . . . . . 16
5.4. DHCP Reply Message Processing . . . . . . . . . . . . . . 17 5.4. Receiving DHCP Reply Messages . . . . . . . . . . . . . . 17
5.5. DHCP Release Message Processing . . . . . . . . . . . . . 18 5.5. Sending DHCP Release Messages . . . . . . . . . . . . . . 18
5.6. DHCP Reconfigure Message Processing . . . . . . . . . . . 18 5.6. Receiving DHCP Reconfigure Messages . . . . . . . . . . . 18
6. DHCP Server Considerations 19 6. DHCP Server Considerations 19
6.1. DHCP Solicit and Advertise Message Processing . . . . . . 19 6.1. Receiving DHCP Solicit Messages . . . . . . . . . . . . . 19
6.2. DHCP Request and Reply Message Processing . . . . . . . . 19 6.2. Sending DHCP Advertise Messages . . . . . . . . . . . . . 19
6.3. DHCP Release Message Processing . . . . . . . . . . . . . 20 6.3. DHCP Request and Reply Messages . . . . . . . . . . . . . 20
6.4. DHCP Reconfigure Message Processing . . . . . . . . . . . 21 6.4. Receiving DHCP Release Messages . . . . . . . . . . . . . 21
6.5. Sending DHCP Reconfigure Messages . . . . . . . . . . . . 22
7. DHCP Relay Considerations 22 7. DHCP Relay Considerations 22
7.1. DHCP Solicit and DHCP Advertise Message Processing . . . 22 7.1. DHCP Solicit and DHCP Advertise Message Processing . . . 23
7.2. DHCP Request Message Processing . . . . . . . . . . . . . 23 7.2. DHCP Request Message Processing . . . . . . . . . . . . . 23
7.3. DHCP Reply Message Processing . . . . . . . . . . . . . . 23 7.3. DHCP Reply Message Processing . . . . . . . . . . . . . . 24
7.4. Retransmission and Configuation Variables . . . . . . . . 23 7.4. Retransmission and Configuration Variables . . . . . . . 24
8. Security Considerations 25 8. Security Considerations 26
9. Acknowledgements 25 9. Acknowledgements 27
A. Related Work in IPv6 26 A. Related Work in IPv6 27
B. Change History 27 B. Change History 29
B.1. Changes from November 95 to February 96 Drafts . . . . . 27 B.1. Changes from November 95 to February 96 Drafts . . . . . 29
B.2. Changes from February 96 to June 96 Drafts . . . . . . . 29
Chair's Address 29 C. Comparison between DHCPv4 and DHCPv6 29
Author's Address 29 Chair's Address 34
Author's Address 34
1. Introduction 1. Introduction
The Dynamic Host Configuration Protocol (DHCP) provides configuration The Dynamic Host Configuration Protocol (DHCP) provides configuration
parameters to Internet hosts. DHCP consists of a protocol for parameters to Internet hosts. DHCP consists of a protocol for
delivering host-specific configuration parameters from a DHCP server delivering host-specific configuration parameters from a DHCP server
to a host, and a mechanism for allocation of network addresses and to a host, and a mechanism for allocation of network addresses and
other related parameters to IPv6 hosts. other related parameters to IPv6 hosts.
DHCP is built on a client-server model, where designated DHCP DHCP is built on a client-server model, where designated DHCP
skipping to change at page 2, line 5 skipping to change at page 2, line 5
each message. Sections 5, 6, and 7 specify how clients, servers, each message. Sections 5, 6, and 7 specify how clients, servers,
and relays interact. Appendix A summarizes related work in IPv6 that and relays interact. Appendix A summarizes related work in IPv6 that
will provide helpful context; it is not part of this specification, will provide helpful context; it is not part of this specification,
but included for informational purposes. but included for informational purposes.
1.1. Specification Language 1.1. Specification Language
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. of the specification. These words are often capitalized.
MUST This word, or the adjective "required", means MUST This word, or the adjective "required", means that
that the definition is an absolute requirement the definition is an absolute requirement of the
of the specification. specification.
MUST NOT This phrase means that the definition is an MUST NOT This phrase means that the definition is an absolute
absolute prohibition of the specification. prohibition of the specification.
SHOULD This word, or the adjective "recommended", SHOULD This word, or the adjective "recommended", means
means that there may exist valid reasons in that there may exist valid reasons in particular
particular circumstances to ignore this item, circumstances to ignore this item, but the full
but the full implications must be understood implications must be understood and carefully
and carefully weighed before choosing a weighed before choosing a different course.
different course. Unexpected results may Unexpected results may result otherwise.
result otherwise.
MAY This word, or the adjective "optional", means MAY This word, or the adjective "optional", means that
that this item is one of an allowed set of this item is one of an allowed set of alternatives.
alternatives. An implementation which does An implementation which does not include this option
not include this option MUST be prepared to MUST be prepared to interoperate with another
interoperate with another implementation which implementation which does include the option.
does include the option.
silently discard The implementation discards the datagram silently discard
without further processing, and without The implementation discards the datagram without
indicating an error to the sender. The further processing, and without indicating an error
implementation SHOULD provide the capability of to the sender. The implementation SHOULD provide
logging the error, including the contents of the capability of logging the error, including the
the discarded datagram, and SHOULD record the contents of the discarded datagram, and SHOULD
event in a statistics counter. record the event in a statistics counter.
2. Terminology and Definitions 2. Terminology and Definitions
Relevant terminology from the IPv6 Protocol [2], IPv6 Addressing Relevant terminology from the IPv6 Protocol [2], IPv6 Addressing
Architecture, and IPv6 Stateless Address Autoconfiguration will be Architecture, and IPv6 Stateless Address Autoconfiguration will be
provided, and then the DHCPv6 terminology. provided, and then the DHCPv6 terminology.
2.1. IPv6 Terminology 2.1. IPv6 Terminology
IP IP Internet Protocol Version 6 (IPv6). The terms IPv4 and
IPv6 are used only in contexts where necessary to avoid
Internet Protocol Version 6 (IPv6). The terms IPv4 and IPv6 ambiguity.
are used only in contexts where necessary to avoid ambiguity.
node
A device that implements IPv6.
router
A node that forwards IPv6 datagrams not explicitly addressed to
itself.
host node A device that implements IPv6.
Any node that is not a router. router A node that forwards IPv6 datagrams not explicitly
addressed to itself.
link host Any node that is not a router.
A communication facility or medium over which nodes can link A communication facility or medium over which nodes
communicate at the link layer, i.e., the layer immediately can communicate at the link layer, i.e., the layer
below IPv6. Examples are Ethernet (simple or bridged); PPP immediately below IPv6. Examples are Ethernet (simple
links, X.25, Frame Relay, or ATM networks; and internet (or or bridged); PPP links, X.25, Frame Relay, or ATM
higher) layer "tunnels", such as tunnels over IPv4 or IPv6 networks; and internet (or higher) layer "tunnels",
itself. such as tunnels over IPv4 or IPv6 itself.
link-layer identifier link-layer identifier
a link-layer identifier for an interface. Examples
a link-layer identifier for an interface. Examples include include IEEE 802 addresses for Ethernet links, and
IEEE 802 addresses for Ethernet links, and E.164 addresses for E.164 addresses for ISDN links.
ISDN links.
link-local address link-local address
An address having link-only scope that can be used to
An address having link-only scope that can be used to reach reach neighboring nodes attached to the same link. All
neighboring nodes attached to the same link. All interfaces interfaces have a link-local address.
have a link-local address.
neighbors neighbors
Nodes attached to the same link. Nodes attached to the same link.
interface interface
A node's attachment to the link. A node's attachment to the link.
address address An IP layer identifier for an interface or a set of
interfaces.
An IP layer identifier for an interface or a set of interfaces.
message
The data exchanged between DHCP agents and clients; in this
specification, messages are delivered via IPv6 and UDP.
datagram message The data exchanged between DHCP agents and clients; in
this specification, messages are delivered via IPv6 and
UDP.
An IP header plus payload. datagram An IP header plus payload.
unicast address unicast address
An identifier for a single interface. A datagram sent
An identifier for a single interface. A datagram sent to a to a unicast address is delivered to the interface
unicast address is delivered to the interface identified by identified by that address.
that address.
multicast address multicast address
An identifier for a set of interfaces (typically
An identifier for a set of interfaces (typically belonging to belonging to different nodes). A datagram sent to
different nodes). A datagram sent to a multicast address is a multicast address is delivered to all interfaces
delivered to all interfaces identified by that address. identified by that address.
2.2. DHCPv6 Terminology 2.2. DHCPv6 Terminology
configuration parameter configuration parameter
Any parameter that can be used by a node to configure
its network environment and enable communication on a
link or internetwork.
Any parameter that can be used by a node to configure its client A host that initiates requests on a link to obtain
network environment and enable communication on a link or
internetwork.
client
A host that initiates requests on a link to obtain
configuration parameters.
server
A server is a node that responds to requests from clients on a
link to provide: addresses, dynamic updates to DNS, or other
configuration parameters. configuration parameters.
relay server A server is a node that responds to requests from
clients on a link to provide: addresses, dynamic
updates to DNS, or other configuration parameters.
A node that may advertise DHCP server addresses, or may act as relay A node that may advertise DHCP server addresses, or may
an intermediary to deliver DHCP messages between clients and act as an intermediary to deliver DHCP messages between
servers. clients and servers.
DHCP Agent DHCP Agent
Either a DHCPv6 server or a DHCPv6 relay. Either a DHCPv6 server or a DHCPv6 relay.
agent address agent address
The address of a neighboring DHCP relay or DHCP server
on the same link as the DHCP client.
The address of a neighboring DHCP relay or DHCP server on the msg-type The msg-type defines the DHCPv6 protocol type for a
same link as the DHCP client. message.
msg-type
The msg-type defines the DHCPv6 protocol type for a message.
transaction-ID transaction-ID
The transaction-ID is a monotonically increasing
The transaction-ID is a monotonically increasing integer integer identifier specified by the client and is used
identifier specified by the client and is used by the client to by the client to match a DHCP Reply to a pending DHCP
match a DHCP Reply to a pending DHCP Request. Request.
server address server address
The server address specifies the address for the server The server address specifies the address for the server
responding to a client. responding to a client.
binding binding A binding in DHCPv6 contains the data which a DHCPv6
server MUST maintain for each of its clients. An
A binding in DHCPv6 contains the data which a DHCPv6 server implementation MUST support bindings consisting of at
MUST maintain for each of its clients. An implementation least a client's link-local address, agent address,
MUST support bindings consisting of at least a client's preferred lifetime and valid lifetime [9] for each
link-local address, agent address, preferred lifetime and valid client address, and the transaction-ID.
lifetime [9] for each client address, and the transaction-ID.
3. Protocol Design Model 3. Protocol Design Model
This section is provided for implementors to understand the DHCPv6 This section is provided for implementors to understand the DHCPv6
protocol design model from an architectural perspective. The goals, protocol design model from an architectural perspective. The goals,
conceptual models and implementation examples presented in this conceptual models and implementation examples presented in this
section do not specify requirements of the DHCPv6 protocol. section do not specify requirements of the DHCPv6 protocol.
3.1. Design Goals 3.1. Design Goals
skipping to change at page 6, line 32 skipping to change at page 5, line 43
- DHCPv6 MUST be compatible with IPv6 Stateless Address - DHCPv6 MUST be compatible with IPv6 Stateless Address
Autoconfiguration. Autoconfiguration.
- DHCPv6 must support the requirements of automated renumbering of - DHCPv6 must support the requirements of automated renumbering of
IPv6 addresses [1]. IPv6 addresses [1].
- DHCPv6 servers should be able to support Dynamic Updates to - DHCPv6 servers should be able to support Dynamic Updates to
DNS [10]. DNS [10].
- DHCPv6 servers MUST be able to handle multiple IPv6 addresses for
each client.
- A DHCPv6 server to server protocol is NOT part of this DHCPv6 - A DHCPv6 server to server protocol is NOT part of this DHCPv6
specification. specification.
- It is NOT a design goal of DHCPv6 to specify how a server - It is NOT a design goal of DHCPv6 to specify how a server
configuration parameter database is maintained or determined. configuration parameter database is maintained or determined.
Methods for configuring DHCP servers are outside the scope of Methods for configuring DHCP servers are outside the scope of
this document. this document.
3.2. DHCPv6 Messages 3.2. DHCPv6 Messages
Each DHCPv6 message contains a type, which defines whether the Each DHCPv6 message contains a type, which defines their function
message originated from a DHCPv6 server or client. within the protocol. The message types are as follows:
The message types are as follows:
01 DHCP Solicit 01 DHCP Solicit
The DHCP Solicit message is a DHCPv6 multicast (or in special The DHCP Solicit message is a DHCPv6 multicast (or in special
circumstances unicast) message from a client to one or more circumstances unicast) message from a client to one or more
neighboring DHCPv6 Agents. neighboring DHCPv6 Agents.
02 DHCP Advertise 02 DHCP Advertise
The DHCP Advertise is an IPv6 unicast message from a DHCP Agent The DHCP Advertise is an IPv6 unicast message from a DHCP Agent
in response to a client DHCP Solicit. in response to a client DHCP Solicit message.
03 DHCP Request 03 DHCP Request
The DHCP Request is an IPv6 unicast message from a client to The DHCP Request is an IPv6 unicast message from a client to
a server, when the client knows the IPv6 unicast address of a a server, when the client knows the IPv6 unicast address of a
server, to request configuration parameters on a network. server, to request configuration parameters on a network.
04 DHCP Reply 04 DHCP Reply
The DHCP Reply is an IPv6 unicast message sent by a server to The DHCP Reply is an IPv6 unicast message sent by a server to
respond to a client's DHCP Request. Extensions [5] to the DHCP respond to a client's DHCP Request. Extensions [5] to the DHCP
Reply describe the resources that the DHCP Server has committed Reply describe the resources that the DHCP Server has committed
and allocated to the client, and may contain other information and allocated to the client, and may contain other information
for use by the client. for use by the client.
05 DHCP Release 05 DHCP Release
The DHCP Release message is used by a DHCPv6 client to inform The DHCP Release message is used by a DHCPv6 client to inform
the server that the client is releasing a particular address, the server that the client is releasing a particular address,
or set of addresses or resources, even though the addresses or or set of addresses or resources, so that the server may
resources may still be marked valid in the server's binding for subsequently mark the addresses or resources as invalid in the
the client. server's binding for the client.
06 DHCP Reconfigure 06 DHCP Reconfigure
The DHCP Reconfigure message is used by a DHCPv6 server The DHCP Reconfigure message is used by a DHCPv6 server
to inform the client that the server has new configuration to inform the client that the server has new configuration
information of importance to the client. The client is information of importance to the client. The client is
expected to initiate a new Request/Reply transaction. expected to initiate a new Request/Reply transaction.
3.3. Request/Response Processing Model 3.3. Request/Response Processing Model
Processing details for the DHCP messages listed above are specified Processing details for the DHCP messages listed above are specified
in Sections 5, 6, and 7. in Sections 5, 6, and 7.
The request/response processing for DHCPv6 is transaction based The request/response processing for DHCPv6 is transaction based
and uses a best-effort set of messages to guarantee a completed and uses a best-effort set of messages to guarantee a completed
transaction. The timeout and retransmission guidelines and transaction. The timeout and retransmission guidelines and
configuration variables are discussed in Section 7.4. configuration variables are discussed in Section 7.4.
The request/response set is always started by a client with a DHCP The request/response set is always started by a client with a DHCP
Request, which may be issued after the client knows the server's Request, which may be issued after the client knows the server's
address. The response message is from the server and is the DHCP address. The response message or messages (the DHCP Reply) are is
Reply. At this point in the flow all data has been received. To from the server (possibly via a DHCP Relay). At this point in the
flow all data has been transmitted and, hopefully, received. To
provide a method of recovery if either the client or server do not provide a method of recovery if either the client or server do not
receive the messages to complete the transaction, the client is receive the messages to complete the transaction, the client is
required to retransmit any DHCP Request message until it elicits a required to retransmit any DHCP Request message until it elicits a
DHCP Reply, or until it can be reasonably certain that the desired DHCP Reply, or until it can be reasonably certain that the desired
DHCP Server is unavailable. DHCP Server is unavailable.
4. DHCPv6 Message Formats and Field Definitions 4. DHCPv6 Message Formats and Field Definitions
All fields in DHCPv6 messages MUST be initialized to binary zeroes by All fields in DHCPv6 messages MUST be initialized to binary zeroes by
both the client and server unless otherwise noted. DHCPv6 message both the client and server unless otherwise noted. DHCPv6 message
types not defined here (msg-types 0 and 7-255) are reserved. types not defined here (msg-types 0 and 7-255) are reserved.
All DHCP Agents MUST join the DHCPv6 Server/Relay-Agent multicast All DHCP Agents MUST join the DHCPv6 Server/Relay-Agent multicast
group at the well-known multicast address FF02:0:0:0:0:0:1:0. group at the well-known multicast address FF02:0:0:0:0:0:1:0. All
DHCP Servers MUST join the DHCPv6 Server multicast group at the
well-known multicast address FF02:0:0:0:0:0:tbd.
Servers on the same link as the client MUST use the source address Servers on the same link as the client MUST use the source address
in the IPv6 header from the client as the destination address in the in the IPv6 header from the client as the destination address in the
server's response datagrams. server's response message.
4.1. UDP Ports used for DHCPv6 messages 4.1. UDP Ports used for DHCPv6 messages
DHCPv6 uses the UDP [7] protocol to communicate between clients DHCPv6 uses the UDP [7] protocol to communicate between clients
and servers. UDP is not reliable, but DHCPv6 must provide some and servers. UDP is not reliable, but DHCPv6 must provide some
reliability between clients and servers. If a response is not reliability between clients and servers. If a response is not
received after transmission of a DHCP message, the message MUST be received after transmission of a DHCP message, the message MUST be
retransmitted according to the rules specified in 7.4. retransmitted according to the rules specified in 7.4.
A Client MUST transmit all messages over UDP using UDP port 547 as A Client MUST transmit all messages over UDP using UDP port 547 as
skipping to change at page 9, line 12 skipping to change at page 8, line 28
advertise. If a DHCPv6 client does not know any DHCP Agent address, advertise. If a DHCPv6 client does not know any DHCP Agent address,
or wants to locate a new server to receive configuration parameters, or wants to locate a new server to receive configuration parameters,
the client SHOULD use, as the destination IP address, the DHCPv6 the client SHOULD use, as the destination IP address, the DHCPv6
Server/Relay-Agent multicast address FF02:0:0:0:0:0:1:0. Server/Relay-Agent multicast address FF02:0:0:0:0:0:1:0.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | msg-flags | RESERVED | | msg-type | msg-flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type 1 msg-type 1
msg-flags 0 msg-flags 0
RESERVED 0 RESERVED 0
extensions No extensions are defined at this time.
4.3. DHCP Advertise Message Format 4.3. DHCP Advertise Message Format
A DHCPv6 agent sends a DHCP Advertise message to inform a prospective A DHCPv6 agent sends a DHCP Advertise message to inform a prospective
client about the IPv6 address of a DHCP Agent to which a DHCP Request client about the IPv6 address of a DHCP Agent to which a DHCP Request
message may be sent. message may be sent.
A DHCPv6 agent MAY periodically transmit DHCP Advertise messages to A DHCPv6 agent MAY periodically transmit DHCP Advertise messages to
the All-DHCPv6 Clients multicast address, no more often than once per the All-DHCPv6 Clients multicast address, no more often than once per
second, and with TTL == 1. second, and with TTL == 1.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type |S| msg-flags | server-count | reserved | | msg-type |S| rsvd | server-count | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| agent address | | agent address |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server addresses | | server addresses |
| (16 octets each) | | (16 octets each) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) ... | extensions (variable number and length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type 2 msg-type 2
S If set, the agent address is also a server S If set, the agent address is also a server address.
address.
msg-flags 0 T If set, the advertisement contains a time interval
which is the lifetime of the advertisement.
server-count The number of addresses listed in the server rsvd 0
server-count
The number of addresses listed in the server
addresses field. addresses field.
RESERVED 0 reserved 0
agent address The IPv6 address of a neighboring DHCP Agent agent address
The IPv6 address of a neighboring DHCP Agent
interface interface
server addresses The IPv6 address(es) of the DHCPv6 server(s) server addresses
which the DHCP Agent has been configured to The IPv6 address(es) of the DHCPv6 server(s) which
advertise. the DHCP Agent has been configured to advertise.
extensions See [5]. extensions See [5].
Note that if a neighboring DHCPv6 server issues the DHCP Advertise, Note that if a neighboring DHCPv6 server issues the DHCP Advertise,
then the agent address will be the IPv6 address of one of the then the agent address will be the IPv6 address of one of the
server's interfaces, the 'S' bit will be set, the agent address will server's interfaces, the 'S' bit will be set, the agent address will
be an address of the server, and there may be zero server addresses be an address of the server, and there may be zero server addresses
sent in the DHCP Advertise message. It is an error for server-count sent in the DHCP Advertise message. It is an error for server-count
to be zero if the 'S' bit is not set. to be zero if the 'S' bit is not set.
4.4. DHCP Request Message Format 4.4. DHCP Request Message Format
In order to request parameters from a DHCP server, a client sends a In order to request parameters from a DHCP server, a client sends a
DHCP Request message and appends the extensions which are appropriate DHCP Request message and appends the appropriate extensions [5]. If
for obtaining the needed parameters [5]. If the client does not know the client does not know any DHCPv6 server address, it must first
any DHCPv6 server address, it must first obtain a server address by obtain a server address by multicasting a DHCP Solicit message (see
multicasting a DHCP Solicit message (see Section 4.2). If the client Section 4.2). If the client does not have a valid IPv6 address
does not have a valid IPv6 address which is reachable by the DHCPv6 which is reachable by the DHCPv6 server, the client MUST use the
server, the client MUST use the unicast IP address of a local DHCPv6 unicast IP address of a local DHCPv6 relay as the destination IP
relay as the destination IP address. Otherwise, the client MAY omit address. Otherwise, the client MAY omit the server address in the
the server address in the DHCP Request message; in this case, the DHCP Request message; in this case, the client MUST send the DHCP
client MUST send the DHCP Request message directly to the server just Request message directly to the server, using the server address as
as it would any other datagram destined for the server, using the the IPv6 destination address in the IPv6 header.
server address as the IPv6 destination address in the IPv6 header.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type |S|C| reserved | transaction-ID | | msg-type |S|C| reserved | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) | | (if present) |
| server address (16 octets) | | server address (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| agent address | | agent address |
skipping to change at page 11, line 28 skipping to change at page 10, line 42
| link-local address | | link-local address |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) .... | extensions (variable number and length) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type 3 msg-type 3
S If set, the server address is present S If set, the server address is present
C If set, the client requests the server to C If set, the client requests the server to clear all
clear all existing resources and bindings existing resources and bindings currently associated
currently associated with the client, with the client, deallocating as needed.
deallocating as needed.
reserved 0 reserved 0
transaction-ID A monotonically increasing number which the transaction-ID
client asks the server to copy into its DHCP A monotonically increasing number which the client asks
Reply, so that the client can match Replies the server to copy into its DHCP Reply, so that the
with pending Requests. client can match Replies with pending Requests.
server address If present, the IPv6 address of the DHCPv6 server address
server which should receive the client's DHCP If present, the IPv6 address of the DHCPv6 server which
Request message. should receive the client's DHCP Request message.
agent address The IPv6 address of the relay or server agent address
interface from which the client received the The IPv6 address of the relay or server interface from
DHCP Advertise message which the client received the DHCP Advertise message
link-local address
The IPv6 link-local address of the client interface
from which the the client issued the DHCP Request
message
link-local address The IPv6 link-local address of the client
interface from which the the client issued
the DHCP Request message
extensions See [5]. extensions See [5].
4.5. DHCP Reply Message Format 4.5. DHCP Reply Message Format
The server sends a DHCP Reply message in response to every DHCP The server sends at least one DHCP Reply message in response to
Request received. If the request comes with the 'S' bit set, the every DHCP Request received. If the request comes with the 'S' bit
client could not directly send the Request to the server and had to set, the client could not directly send the Request to the server
use a neighboring relay agent. In that case, the server sends back and had to use a neighboring relay agent. In that case, the server
the DHCP Reply with the 'L' bit set, and the DHCP Reply is addressed sends back the DHCP Reply with the 'L' bit set, and the DHCP Reply is
to the agent address found in the DHCP Request message. If the addressed to the agent address found in the DHCP Request message. If
'L' bit is set, then the client's link-local address will also be the 'L' bit is set, then the client's link-local address will also be
present. present.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | error code | transaction-ID | | msg-type |L| error code | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) | | (if present) |
| link-local address (16 octets) | | link-local address (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) .... | extensions (variable number and length) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type 3 msg-type 3
error code One of the following values: L If set, the link-local address is present
error code
One of the following values:
0 Success 0 Success
1 Failure, reason unspecified 16 Failure, reason unspecified
2 Authentication failed or nonexistent 17 Authentication failed or nonexistent
3 Poorly formed request 18 Poorly formed request
4 Resources unavailable 19 Resources unavailable
5 Client record unavailable 20 Client record unavailable
16 Wrong phase of moon 21 Invalid source address in Release
32 Dogbert didn't like it 22 Unable to honor mandatory request
24 Bad Hair Day
32 Insufficient Funds
64 Server unreachable (ICMP error) 64 Server unreachable (ICMP error)
transaction-ID Copied from the transaction-ID which the transaction-ID
DHCPv6 server received in the DHCP Request. Copied from the transaction-ID which the DHCPv6 server
to help the client match this reply with an received in the DHCP Request. to help the client match
outstanding Request. this reply with an outstanding Request.
L If set, the link-local address is present
RESERVED 0
link-local address If present, the IPv6 address of the client link-local address
interface which issued the corresponding DHCP If present, the IPv6 address of the client interface
Request message. which issued the corresponding DHCP Request message.
extensions See [5]. extensions
See [5].
If the 'L' bit is set, and thus the link-local address is present in If the 'L' bit is set, and thus the link-local address is present in
the Reply message, the Reply is sent by the server to the relay's the Reply message, the Reply is sent by the server to the relay's
address which was specified as the agent address in the DHCP Request address which was specified as the agent address in the DHCP Request
message, and the relay uses the link-local address to deliver the message, and the relay uses the link-local address to deliver the
Reply message to the client. Reply message to the client. Error Code 22 MUST be sent only in the
case that the Server could otherwise honor the requested resource,
if the client had not made the parameter values (included in the
relevant Extension requesting the resource) mandatory for the server
to obey.
4.6. DHCP Release Message Format 4.6. DHCP Release Message Format
The DHCP Release message is sent without the assistance of any DHCPv6 The DHCP Release message is sent without the assistance of any DHCPv6
relay. When a client sends a Release message, it is assumed to relay. When a client sends a Release message, it is assumed to
have a valid IPv6 address with sufficient scope to allow access to have a valid IPv6 address with sufficient scope to allow access to
the target server. Only the parameters which are specified in the the target server. Only the parameters which are specified in the
extensions are released. The DHCP server acknowledges the Release extensions are released. The DHCP server acknowledges the Release
message by sending a DHCP Reply (Section 6.2). message by sending a DHCP Reply (Section 6.3).
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type |D| msg-flags | transaction-ID | | msg-type |D| msg-flags | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| agent address | | agent address |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| link-local address | | link-local address |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) .... | extensions (variable number and length) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type 5 msg-type 5
D If the 'D' ("Direct") flag is set, the client D If the 'D' ("Direct") flag is set, the client instructs
instructs the server to send the DHCP Reply the server to send the DHCP Reply directly back to the
directly back to the client, instead of client, instead of using the given agent address and
using the given agent address and link-local link-local address to relay the Reply message.
address to relay the Reply message.
msg-flags 0 msg-flags 0
transaction-ID A monotonically increasing number which the
client asks the server to use in its DHCP
Reply, to help the client match Replies with
outstanding Releases.
agent address The IPv6 address of the agent interface to transaction-ID
which the client issued the DHCP Request A monotonically increasing number which the client asks
message the server to use in its DHCP Reply, to help the client
match Replies with outstanding Releases.
link-local address The IPv6 link-local address of the client agent address
interface from which the the client issued The IPv6 address of the agent interface to which the
the DHCP Request message client issued the DHCP Request message
link-local address
The IPv6 link-local address of the client interface
from which the the client issued the DHCP Request
message
extensions See [5] extensions See [5]
If the client knows that the address it uses as the source IP address Suppose that the client knows that the address it uses as the source
in its IPv6 header will still be valid after the server performs the IP address in its IPv6 header will still be valid after the server
operations requested in the extensions to the DHCP Release message, performs the operations requested in the extensions to the DHCP
the client can then specify the 'D' flag. When the 'D' flag is set, Release message. In that case, and only then, the client SHOULD then
the server MUST send the DHCP Reply back to the client's address specify the 'D' flag. When the 'D' flag is set, the server MUST send
as shown in the source address of the IPv6 header of the Release the DHCP Reply back to the client's address as shown in the source
message. Otherwise, when the 'D' bit is not set, the server MUST use address of the IPv6 header of the Release message. Otherwise, when
the agent address and link-local address in its DHCP Reply message to the 'D' bit is not set, the server MUST use the agent address and
forward the Reply message back to the releasing client. link-local address in its DHCP Reply message to forward the Reply
message back to the releasing client.
4.7. DHCP Reconfigure Message Format 4.7. DHCP Reconfigure Message Format
The DHCP Reconfigure message is sent without the assistance of any The DHCP Reconfigure message is sent without the assistance of any
DHCPv6 relay. When a server sends a Reconfigure message, the client DHCPv6 relay. When a server sends a Reconfigure message, the client
to which it is sent is assumed to have a valid IPv6 address with to which it is sent is assumed to have a valid IPv6 address with
sufficient scope to be accessible by the server. Only the parameters sufficient scope to be accessible by the server. Only the parameters
which are specified in the extensions to the Reconfigure message need which are specified in the extensions to the Reconfigure message need
be requested again by the client. be requested again by the client.
The client SHOULD listen at UDP port 546 to receive possible DHCP The client SHOULD listen at UDP port 546 to receive possible DHCP
Reconfigure messages. If the client does not listen for DHCP Reconfigure messages, except in cases where the client knows that
Reconfigure messages, it is possible that the client will not receive no Reconfigure message will ever be issued. If the client does not
notification that its DHCP server has deallocated the client's IPv6 listen for DHCP Reconfigure messages, it is possible that the client
address and/or other resources allocated to the client. will not receive notification that its DHCP server has deallocated
the client's IPv6 address and/or other resources allocated to the
client.
See discussion in 6.3. See discussion in 6.5.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | msg-flags | reserved | | msg-type |C| msg-flags | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) .... | extensions (variable number and length) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type 6 msg-type 6
msg-type If set, the DHCPv6 client requests that all servers
receiving the message deallocate the resources
associated with the client.
msg-flags 0 msg-flags 0
reserved 0 reserved 0
extensions See [5] extensions See [5]
5. DHCP Client Considerations 5. DHCP Client Considerations
A DHCPv6 client MUST silently discard any DHCP Solicit, DHCP Request, A DHCPv6 client MUST silently discard any DHCP Solicit, DHCP Request,
or DHCP Release message it receives. or DHCP Release message it receives.
A DHCPv6 client should retain its configured parameters and resources A DHCPv6 client should retain its configured parameters and resources
across client system reboots and DHCPv6 client program restarts. across client system reboots and DHCPv6 client program restarts.
However, in these circumstances a DHCPv6 client SHOULD also formulate However, in these circumstances a DHCPv6 client SHOULD also formulate
a DHCP Request message to verify that its configured parameters and a DHCP Request message to verify that its configured parameters and
resources are still valid. This Request message MUST have the 'C' resources are still valid. This Request message MUST have the 'C'
bit set, to clear client binding information at the server, of which bit set, to clear client binding information at the server, of which
the client may no longer have any record. the client may no longer have any record.
5.1. DHCP Solicit Message Processing 5.1. Sending DHCP Solicit Messages
If a node wishes to become a new DHCPv6 client, it must first locate If a node wishes to become a new DHCPv6 client, it must first locate
a neighboring DHCP Agent. The client does this by multcasting a neighboring DHCP Agent. The client does this by multcasting
a DHCP Solicit message to the well-known multicast address a DHCP Solicit message to the well-known multicast address
FF02:0:0:0:0:0:1:0, setting the TTL == 1. FF02:0:0:0:0:0:1:0 (All DHCP Agents Address), setting the TTL == 1.
5.2. DHCP Advertise Message Processing By setting the 'C' bit in the Solicitation, a DHCPv6 client requests
that all the DHCP Servers that receive the solicitation should
deallocate their client records that match its link-local address.
5.2. Receiving DHCP Advertise Messages
When a DHCPv6 client receives a DHCP Advertise message, it may When a DHCPv6 client receives a DHCP Advertise message, it may
formulate a DHCP Request message to receive configuration information formulate a DHCP Request message to receive configuration information
and resources from the DHCP servers listed in the advertisement. If and resources from the DHCP servers listed in the advertisement. If
the Advertise message has zero server addresses and does not have the the Advertise message has zero server addresses and does not have the
'S' bit set, the client MUST silently discard the message. 'S' bit set, the client MUST silently discard the message. If the
server's address is shown as a Multicast address, the advertisement
MUST be silently discarded.
If the 'S' bit is set, the DHCP Advertise message was transmitted If the 'S' bit is set, the DHCP Advertise message was transmitted by
by a DHCPv6 server. In this case, the Advertise message may a DHCPv6 server on the same link as the client. In this case, the
have Extensions; this might allow the DHCPv6 client to select client MUST use the agent address as the address of its server for
the configuration that best meets its needs from among several future DHCPv6 message transactions. Also in this case, the Advertise
prospective servers. Also in this case, the client MUST use the message may have Extensions; this might allow the DHCPv6 client to
agent address as the address of its server for future DHCPv6 message select the configuration that best meets its needs from among several
transactions. prospective servers.
5.3. DHCP Request Message Processing 5.3. Sending DHCP Request Messages
A DHCPv6 client obtains configuration information from a DHCPv6 A DHCPv6 client obtains configuration information from a DHCPv6
server by sending a DHCP Request message. The client must know the server by sending a DHCP Request message. The client must know the
server's address before sending the Request message. In addition, server's address before sending the Request message. In addition,
the client must have acquired a valid DHCP agent address. If the the client must have acquired a valid DHCP agent address. If the
client and server are on the same link, the agent address used by the client and server are on the same link, the agent address used by the
client MUST be the same as the DHCP server's address. client MUST be the same as the DHCP server's address. A DHCP Request
message MUST NOT be sent to any multicast address, since otherwise
multiple DHCP agents would possibly allocate resources to the client
in response to the same Request, and the client would have no way to
know which servers had made the allocations.
If the client has no valid IPv6 address and the DHCP server is If the client has no valid IPv6 address and the DHCP server is
off-link, then the client MUST include the server address in the off-link, then the client MUST include the server address in the
appropriate field of the DHCP Request message and set the 'S' bit. appropriate field of the DHCP Request message and set the 'S' bit.
In this case, the IPv6 destination address of the Request message In this case, the IPv6 destination address of the Request message
MUST be the agent address. MUST be the agent address.
Otherwise, if the client already has a valid IPv6 address and knows Otherwise, if the client already has a valid IPv6 address and knows
the IPv6 address of a candidate IPv6 server, it MUST send the Request the IPv6 address of a candidate IPv6 server, it MUST send the Request
message directly to the DHCPv6 server without requiring the services message directly to the DHCPv6 server without requiring the services
of the local DHCPv6 relay. of the local DHCPv6 relay.
If a client wishes to instruct a DHCP server to deallocate all If a client wishes to instruct a DHCP server to deallocate all
previous resources, configuration information, and bindings previous resources, configuration information, and bindings
associated with its agent address and link-local address, it sets the associated with its agent address and link-local address, it sets the
'C' bit in the DHCP Request. A client MAY send in such a Request 'C' bit in the DHCP Request. A client MAY send in such a Request
even when it is no longer attached to the link on which the relay even when it is no longer attached to the link on which the relay
address is attached. address is attached.
A client MAY maintain information about which relay address and A client MAY maintain information about which relay address and
server address it has been using for use after a reboot. When server address it has been using for use after a reboot. Even so,
the client has a pending DHCP Request and reboots before the after a reboot the client MUST issue its next DHCP Request with the
corresponding DHCP Reply is received, the client MUST issue its next 'C' bit set.
DHCP Request after rebooting with the 'C' bit set.
In any case, after choosing a transaction-ID which is numerically In any case, after choosing a transaction-ID which is numerically
greater than its previous transaction-ID, and filling in the greater than its previous transaction-ID, and filling in the
appropriate fields of the DHCP Request message, the client MAY append appropriate fields of the DHCP Request message, the client MAY append
various DHCPv6 Extensions to the message. These Extensions denote various DHCPv6 Extensions to the message. These Extensions denote
specific requests by the client; for example, a client may request specific requests by the client; for example, a client may request
a particular IP address, or request that the server send an update a particular IP address, or request that the server send an update
containing the client's new IP address to a Domain Name Server. When containing the client's new IP address to a Domain Name Server. When
all Extensions have been applied, the DHCPv6 client unicasts the DHCP all Extensions have been applied, the DHCPv6 client unicasts the DHCP
Request to the appropriate DHCP Agent. Request to the appropriate DHCP Agent.
skipping to change at page 17, line 19 skipping to change at page 17, line 13
following information: following information:
- The transaction-ID of the Request message, - The transaction-ID of the Request message,
- The server address, - The server address,
- The agent address, - The agent address,
- The time at which the next retransmission will be attempted, and - The time at which the next retransmission will be attempted, and
- All Extensions appended to the reply message. - All Extensions appended to the request message.
If a client does not receive a DHCP Reply message with the If a client does not receive all the relevant DHCP Reply messages
same transaction-ID as a pending DHCP Request message within with the same transaction-ID as a pending DHCP Request message within
REPLY_MSG_INITIAL_TIMEOUT seconds, it MUST retransmit the Request REPLY_MSG_INITIAL_TIMEOUT seconds, it MUST retransmit the Request
with the same transaction-ID and continue to retransmit according to with the same transaction-ID and continue to retransmit according to
the rules in Section 7.4. the rules in Section 7.4.
Note that if a client crashes while its DHCP Request is still 5.4. Receiving DHCP Reply Messages
pending, no state is maintained, and the client MUST reissue a DHCP
Request after it restarts.
5.4. DHCP Reply Message Processing
When a client receives a DHCP Reply message, it MUST check whether When a client receives a DHCP Reply message, it MUST check whether
the transaction-ID in the Reply message matches the transaction-ID the transaction-ID in the Reply message matches the transaction-ID
of a pending DHCP Request message. If no match is found, the Reply of a pending DHCP Request message. If no match is found, the Reply
message MUST be silently discarded, and an error SHOULD be logged. message MUST be silently discarded, and an error SHOULD be logged.
If the transaction-ID matches that of a pending Request, and the 'L' If the transaction-ID matches that of a pending Request, and the 'L'
bit is set, but the source address in the IPv6 header does not match bit is set, but the source address in the IPv6 header does not match
the pending agent address, the client MUST discard the message, and the pending agent address, the client MUST discard the message, and
SHOULD log the event. Likewise, if the transaction-ID matches that SHOULD log the event. Likewise, if the transaction-ID matches that
of a pending Request, and the 'L' bit is not set, but the source of a pending Request, and the 'L' bit is not set, but the source
address in the IPv6 header does not match the pending server address, address in the IPv6 header does not match the pending server address,
the client MUST discard the message, and SHOULD log the event. the client MUST discard the message, and SHOULD log the event.
If the Reply message is acceptable, the client processes each If the Reply message is acceptable, the client processes each
Extension [5], extracting the relevant configuration information and Extension [5], extracting the relevant configuration information
parameters for its network operation. and parameters for its network operation. The Error Code found in
the Reply message applies to all extensions found in the Reply. If
all expected extensions are not found in the same Reply message,
then they are likely to be located in another Reply, possibly
with a different Error Code, but with the same Transaction ID. The
DHCPv6 Client MUST continue processing DHCP Reply messages until all
requested extensions are accounted for. If some requested extensions
are not accounted for within DHCP Reply messages sent by the server,
the client MUST reissue the entire DHCPv6 Request again, with all
extensions, and the same Transaction ID.
Some configuration information extracted from the Extensions to the Some configuration information extracted from the Extensions to the
DHCP Reply message must remain associated with the DHCP server that DHCP Reply message must remain associated with the DHCP server that
sent the message. The particular extensions that require this extra sent the message. The particular extensions that require this extra
measure of association with the server are indicated in the DHCPv6 measure of association with the server are indicated in the DHCPv6
Extensions document [5]. These associations may be useful with DHCP Extensions document [5]. These associations may be useful with DHCP
Release messages. Release messages.
5.5. DHCP Release Message Processing 5.5. Sending DHCP Release Messages
If a DHCPv6 client determines that some of its network configuration If a DHCPv6 client determines that some of its network configuration
parameters are no longer valid, it may enable the DHCPv6 server to parameters are no longer needed, it may enable the DHCPv6 server to
release allocated resources which are no longer in use by sending a release allocated resources which are no longer in use by sending
DHCP Release message to the server. The client must consult its list a DHCP Release message to the server. The client must consult its
of resource-server associations in order to determine which server list of resource-server associations in order to determine which
should receive the desired Release message. If a client wishes to server should receive the desired Release message. If a client
ask the server to release all information and resources relevent to wishes to ask the server to release all information and resources
the client, the client specifies no Extensions. relevent to the client, the client specifies no Extensions; this is
preferable to sending a DHCP Request message with the 'C' bit set and
A client wishes to release resources which were granted to it at no extensions.
another link-local address. In that case, the client must instruct
the server to send the DHCP Reply directly back to the client,
instead of performing the default processing of sending the DHCP
Reply back through the agent-address included in the DHCP Release.
This is done by setting the 'D' bit in the DHCP Release message.
5.6. DHCP Reconfigure Message Processing Suppoase client wishes to release resources which were granted to
it at another link-local address. In that case, the client must
instruct the server to send the DHCP Reply directly back to the
client, instead of performing the default processing of sending
the DHCP Reply back through the agent-address included in the DHCP
Release. This is done by setting the 'D' bit in the DHCP Release
message. Note that it is an error to include within the DHCP Release
message an IPv6 address extension which has the IPv6 address used as
the source address of the datagram containing DHCP Release message.
DISCUSSION: On the one hand, clients REALLY SHOULD listen for 5.6. Receiving DHCP Reconfigure Messages
Reconfigure messages. On the other hand, some
implementors claim that requiring a client to
always listen at a port is asking too much. This
issue needs further discussion.
If a DHCPv6 client receives a DHCP Reconfigure message, it is If a DHCPv6 client receives a DHCP Reconfigure message, it is
a request for the client to initiate a new DHCP Request/Reply a request for the client to initiate a new DHCP Request/Reply
transaction with the server which sent the Reconfigure message. transaction with the server which sent the Reconfigure message.
The server sending the Reconfigure message MAY be different than The server sending the Reconfigure message MAY be different than
the server which sent a DHCP Reply message containing the original the server which sent a DHCP Reply message containing the original
configuration information. configuration information.
For each Extension which is present in the Reconfigure message, the For each Extension which is present in the Reconfigure message, the
client appends a matching Extension to its DHCP Request message client appends a matching Extension to its DHCP Request message
which it formulates to send to the DHCPv6 server which is found in which it formulates to send to the DHCPv6 server which is found in
the IP source address of the message. The client also selects a the IP source address of the message. The client also selects a
transaction-ID numerically greater than its last choice and inserts transaction-ID numerically greater than its last choice and inserts
it into the Request message. From then on, processing is the same as it into the Request message. From then on, processing is the same as
specified above in Section 5.3. specified above in Section 5.3.
Note that a client may be requested by its server to join a multicast
group for the purpose of receiving DHCP Reconfigure messages. When a
Reconfigure message is delivered to the client by way of the selected
multicast address, the client must delay its further response for
a random amount of time uniformly distributed within the interval
between RECONF_MSG_MIN_RESP and RECONF_MSG_MAX_RESP seconds. This
will minimize the likelihood that the server will be bombarded with
DHCP Request messages all at the same time.
6. DHCP Server Considerations 6. DHCP Server Considerations
A server MUST ignore any DHCP Advertise, DHCP Reply, or DHCP A server MUST ignore any DHCP Advertise, DHCP Reply, or DHCP
Reconfigure message it receives. Reconfigure message it receives.
A server uses the combination <link-local address, agent address> to A server uses the combination <link-local address, agent address> to
index into its records of client bindings. A DHCPv6 server should index into its client records. A client record (called a "client
retain its client's bindings across server reboots, and, whenever binding", or sometimes just a "binding") is used to store all the
relevant information, resources, and configuration data which will
be associated with the client. Each client binding is uniquely
identifiable by the ordered pair <link-local address, agent address>,
since the link-local address is guaranteed to be unique [9] on
the link identified by the agent address. A DHCPv6 server should
retain its clients' bindings across server reboots, and, whenever
possible, a DHCPv6 client should be assigned the same configuration possible, a DHCPv6 client should be assigned the same configuration
parameters despite server host system reboots and DHCPv6 server parameters despite server host system reboots and DHCPv6 server
program restarts. A DHCPv6 server MUST support fixed or permanent program restarts. A DHCPv6 server MUST support fixed or permanent
allocation of configuration parameters to specific hosts. allocation of configuration parameters to specific clients.
6.1. DHCP Solicit and Advertise Message Processing 6.1. Receiving DHCP Solicit Messages
Upon receiving a DHCP Solicit message from a client, a server If the DHCP Solicit message was received at the All-DHCP-Servers
constructs a DHCP Advertise message and transmits it to the multicast address, the DHCP Server MUST check to make sure that the
soliciting client on the same link as the solicitation was received source address is not a link-local address. If the source address is
from. The destination address of the advertisement MUST be the a link-local address, the server MUST silently discard the packet.
source address of the solicitation. The DHCP server must use a IPv6
address of the interface on which it received the client's DHCP
Solicit message as the source address field of the IPv6 header of the
message.
6.2. DHCP Request and Reply Message Processing 6.2. Sending DHCP Advertise Messages
Upon receiving and verifying the correctness of a DHCP Solicit
message, a server constructs a DHCP Advertise message and transmits
it on the same link as the solicitation was received from. The
destination address of the advertisement MUST be the source address
of the solicitation. The DHCP server must use a IPv6 address of the
interface on which it received the Solicit message as the source
address field of the IPv6 header of the message.
The DHCP server MAY append extensions to the Advertisement, in order
to offer the soliciting node the best possible information about
the services and resources which the server may be able to make
available, should the solicitor choose to subsequently send a DHCP
Request to the server.
6.3. DHCP Request and Reply Messages
The DHCPv6 server MUST check to ensure that a valid link-local The DHCPv6 server MUST check to ensure that a valid link-local
address is present in the client's link-local address field of the address is present in the client's link-local address field of the
Request message. If not, the message MUST be silently discarded. Request message. If not, the message MUST be silently discarded.
Otherwise, it checks for the presence of the 'S' bit. If the 'S' bit Otherwise, it checks for the presence of the 'S' bit. If the 'S' bit
is set, the server MUST check that the server address matches the is set, the server MUST check that the server address matches the
destination IPv6 address at which the Request message was received destination IPv6 address at which the Request message was received
by the server. If the server address does not match, the Request by the server. If the server address does not match, the Request
message MUST be silently discarded. message MUST be silently discarded.
If the message is accepted, the server extracts the client's If the received agent address and link-local address do not
link-local address and the agent address, and uses the information to correspond to any binding known to the server, then the server MAY
locate or create an appropriate client record (called a binding) used create a new binding for the previously unknown client; otherwise, it
to store all the relevant information, resources, and configuration SHOULD return a DHCP Reply with a error code of 5.
data which will be associated with the client. Each client record is
uniquely identifiable by the ordered pair <link-local address, agent
address>, since the link-local address is guaranteed to be unique [9]
on the link identified by the agent address. If the received agent
address and link-local address do not correspond to any binding known
to the server, then the server MAY create a new binding for the
previously unknown client; otherwise, it SHOULD return a DHCP Reply
with a error code of 5.
Before processing the Request, the server must determine whether or Before processing the Request, the server must determine whether
not the Request is a retransmission of an earlier DHCP Request from or not the Request is a retransmission of an earlier DHCP Request
the same client. This is done by comparing the transaction-ID to from the same client. This is done by comparing the transaction-ID
all those transaction-IDs received from the same client during the to all those transaction-IDs received from the same client during
previous TRANSACTION_ID_TIMEOUT seconds. If the transaction-ID is the previous XID_ID_TIMEOUT seconds. If the transaction-ID is the
the same as one received during that time, the server MUST take the same as one received during that time, the server MUST take the
same action (e.g., retransmit the same DHCP Reply to the client) same action (e.g., retransmit the same DHCP Reply to the client)
as it did after processing the previous DHCP Request with the same as it did after processing the previous DHCP Request with the same
transaction-ID. transaction-ID.
Otherwise (the transaction-ID has not been recently used), when the Otherwise (the transaction-ID has not been recently used), when the
server has identified and allocated all the relevant information, server has identified and allocated all the relevant information,
resources, and configuration data that is associated with the client, resources, and configuration data that is associated with the client,
it sends that information to its DHCPv6 client by constructing a it sends that information to its DHCPv6 client by constructing a
DHCP Reply message and including the client's information in DHCPv6 DHCP Reply message and including the client's information in DHCPv6
Extensions to the Reply message. The DHCP Reply message uses the Extensions to the Reply message. The DHCP Reply message uses the
same transaction-ID as found in the received DHCP Request message. same transaction-ID as found in the received DHCP Request message.
If the DHCP Request message has the 'S' bit set in the message If the DHCP Request message has the 'S' bit set in the message
header, the DHCPv6 server MUST send the corresponding DHCP Reply header, then the Request was sent to the server by a DHCP Relay. In
message to the agent address found in the Request. this case, the DHCPv6 server MUST send the corresponding DHCP Reply
message to the agent address found in the Request (see section 7.2).
The DHCP Request may contain Extensions, which are interpreted The DHCP Request may contain Extensions, which are interpreted
as advisory (or mandatory) information from the client about its (by default) as advisory information from the client about its
configuration preferences. For instance, if the IP Address Extension configuration preferences. For instance, if the IP Address Extension
is present, the DHCPv6 server SHOULD attempt to allocate or extend is present, the DHCPv6 server SHOULD attempt to allocate or extend
the lifetime of the address indicated by the Extension. the lifetime of the address indicated by the Extension. Some
Extensions may be marked by the client as Required.
6.3. DHCP Release Message Processing the DHCP server may accept some extensions for successful processing
and allocation, while still rejecting others, or the server may
reject various extensions for different reasons (and therefore
different Error Codes). The Error Code found in the Reply message
applies to all extensions found in the Reply. The DHCP server can
send multiple Reply messages in response to the same DHCP Request,
each possibly with a different Error Code, but all with the same
Transaction ID. The DHCPv6 server MUST send enough DHCP Reply
messages to account for all requested extensions. The DHCPv6 server
SHOULD attempt to put all the Extensions that were processed with the
same Error Code into the same DHCP Reply, in the order in which they
were received.
6.4. Receiving DHCP Release Messages
If the server receives a DHCP Release Message, it MUST verify that a If the server receives a DHCP Release Message, it MUST verify that a
valid link-local address is present in the link-local address field valid link-local address is present in the link-local address field
of the message. If not, the message MUST be silently discarded. of the message. If not, the message MUST be silently discarded.
In response to a DHCP Release Message with a valid link-local In response to a DHCP Release Message with a valid link-local
address, the DHCPv6 server formulates a DHCP Reply message that address, the DHCPv6 server formulates a DHCP Reply message that
will be sent back to the releasing client by way of the client's will be sent back to the releasing client by way of the client's
link-local address. A DHCP Reply message sent in response to a DHCP link-local address. A DHCP Reply message sent in response to a DHCP
Release message MUST be sent to the client's link-local address via Release message MUST be sent to the client's link-local address via
skipping to change at page 21, line 25 skipping to change at page 22, line 7
After performing the operations indicated in the DHCP Release After performing the operations indicated in the DHCP Release
message and its Extensions, the DHCPv6 server formulates a DHCP message and its Extensions, the DHCPv6 server formulates a DHCP
Reply message, copying the transaction-ID, from the DHCP Release Reply message, copying the transaction-ID, from the DHCP Release
message. For each Extension in the DHCP Release message successfully message. For each Extension in the DHCP Release message successfully
processed by the server, a matching Extension is appended to the DHCP processed by the server, a matching Extension is appended to the DHCP
Reply message. Extensions in the DHCP Release message which cannot Reply message. Extensions in the DHCP Release message which cannot
be successfully processed by the server MUST NOT correspond to any be successfully processed by the server MUST NOT correspond to any
Extension appended to the Reply by the server. Extension appended to the Reply by the server.
6.4. DHCP Reconfigure Message Processing 6.5. Sending DHCP Reconfigure Messages
If a DHCPv6 server needs to change the configuration associated If a DHCPv6 server needs to change the configuration associated
to any of its clients, it constructs a DHCP Reconfigure message to any of its clients, it constructs a DHCP Reconfigure message
and sends it to each such client. The Reconfigure message MUST and sends it to each such client. The Reconfigure message MUST
contain the particular Extensions which inform the client about which contain the particular Extensions which inform the client about which
configuration information needs to be changed. configuration information needs to be changed. The Reconfigure MAY
be sent to a multicast address chosen by the server and sent to each
DISCUSSION: Perhaps a DHCPv6 server should be allowed to of its clients.
multicast a DHCP Reconfigure message to its
clients. There are issues to be resolved here.
There is concern about encouraging servers to send
such messages to any DHCP-wide multicast address.
Perhaps a new extension should be defined so that
the server can ask (some of) its clients to join a
specific multicast group. Then the server could
efficiently multicast Reconfigure messages to
whatever group it wants.
This would have the additional advantage that
clients could receive Reconfigure messages without
listening to any specific UDP port.
If multiple clients can receive the same
Reconfigure message, some algorithm must be
specified so that the clients stagger their
responses (i.e., their DHCP Requests) so that
the server isn't deluged all at once with some
arbitrarily large number of client Requests.
7. DHCP Relay Considerations 7. DHCP Relay Considerations
The DHCPv6 protocol is constructed so that a relay does not have The DHCPv6 protocol is constructed so that a relay does not have
to maintain any state in order to facilitate DHCPv6 client/server to maintain any state in order to facilitate DHCPv6 client/server
interactions. interactions.
All relays MUST use the IPv6 address of the interface from which the All relays MUST use the IPv6 address of the interface from which the
DHCPv6 message is transmitted as the source address for the IP header DHCPv6 message is transmitted as the source address for the IP header
of that DHCPv6 message. of that DHCPv6 message.
The main purpose of the DHCP Relay is to assist clients and servers
to carry out DHCPv6 protocol transactions. This, naturally, requires
that the relay be able to discover the addresses of those DHCP
Servers whose services can be advertised to propective clients. In
addition, this discovery has to be able to happen without specific
configuration within the DHCP Relay. By default, the relay discovers
local DHCP Servers by use of multicasting DHCP solicitations to
the All-DHCP-Servers multicast address, but this behavior is fully
configurable. This solicitation occurs every RELAY_DISCOVERY_PERIOD
seconds, and the relay updates its list of available servers after
each solicitation, after waiting MAX_ADV_WAIT seconds to receive the
updated advertisements from the DHCP Servers.
The DHCP Relay MUST be able to be configured with additional DHCP
Server address information for its subsequent advertisements to
link-local DHCP solicitations. Such configured Server addresses
are NOT subject to updates by way of the abovementioned multicast
solicitions.
DISCUSSION: TODO: Make the DHCP Server able to include a
"advertisement lifetime" in the DHCP Advertisement
returned to the DHCP Relay multicast. TODO: Make
the DHCP Server able to specify that each Client
Solicitation is "passed through" the relay so that
the DHCP Server can append specific Extensions
to the Advertisement which is then returned to
that client by way of the link-local DHCP Relay.
This will be done soon, pending the outcome of
discussion within the DHC Working Group.
7.1. DHCP Solicit and DHCP Advertise Message Processing 7.1. DHCP Solicit and DHCP Advertise Message Processing
Upon receiving a DHCP Solicit message from a client, a relay Upon receiving a DHCP Solicit message from a client, a relay
constructs a DHCP Advertise message and transmits it to the constructs a DHCP Advertise message and transmits it to the
soliciting client on the same link as the solicitation was received soliciting client on the same link as the solicitation was received
from. The destination address of the advertisement MUST be the from. The destination address of the advertisement MUST be the
source address of the solicitation. source address of the solicitation.
DISCUSSION: If the Solicit is delivered to a server and DISCUSSION: If the Solicit is delivered to a server and
the server is allowed to send the corresponding the server is allowed to send the corresponding
skipping to change at page 22, line 42 skipping to change at page 23, line 35
client could pick the server with the best "terms". client could pick the server with the best "terms".
Presumably, this forwarding behavior should be a Presumably, this forwarding behavior should be a
matter of relay configuration instead of client matter of relay configuration instead of client
request. I'll assume that for now and try to make request. I'll assume that for now and try to make
the protocol reflect the ability of DHCP Advertise the protocol reflect the ability of DHCP Advertise
messages to contain Extensions and come from DHCP messages to contain Extensions and come from DHCP
servers off-link. That may take a little more servers off-link. That may take a little more
doing which isn't in the protocol right now, be doing which isn't in the protocol right now, be
patient. patient.
DISCUSSION: What about the 'C' bit in Advertisements?
When transmitting a DHCP Advertise message, a relay indicates how When transmitting a DHCP Advertise message, a relay indicates how
many server addresses which it was configured to advertise, and many server addresses are included in the advertisement, and includes
includes each address in the DHCP Advertise message. The DHCP each address in the DHCP Advertise message. The DHCP Advertise
Advertise message must use a routeable IPv6 address in the source message must use a routeable IPv6 address in the source address of
address of the IPv6 header of the message. In particular, the source the IPv6 header of the message. In particular, the source address
address of any DHCP Advertise message sent by a DHCPv6 relay MUST NOT of any DHCP Advertise message sent by a DHCPv6 relay MUST NOT be a
be a link-local address. link-local address.
7.2. DHCP Request Message Processing 7.2. DHCP Request Message Processing
When a relay receives a DHCP Request message, it MUST check that the When a relay receives a DHCP Request message, it MUST check that the
message is received from a link-local address, that the link-local message is received from a link-local address, that the link-local
address matches the link-local address field in the Request message address matches the link-local address field in the Request message
header, and that the agent address field of the message matches an header, and that the agent address field of the message matches an
IPv6 address associated to the interface from which the DHCP Request IPv6 address associated to the interface from which the DHCP Request
message was received. The relay MUST also check whether the 'S' message was received. The relay MUST also check whether the 'S'
bit is set in the message header. If any of these checks fail, the bit is set in the message header. If any of these checks fail, the
message is not acceptable and MUST be silently discarded. message is not acceptable and MUST be silently discarded.
If the received request message is acceptable, the relay then If the received request message is acceptable, the relay then
transmits the DHCP Request message to the DHCPv6 server found in the transmits the DHCP Request message to the DHCPv6 server found in the
Server Address field of the received DHCP Request message. All of Server Address field of the received DHCP Request message. All of
the fields of DHCP Request message header transmitted by the relay the fields of DHCP Request message header transmitted by the relay
are copied over unchanged from the DHCP Request received from the are copied over unchanged from the DHCP Request received from the
client. Only the fields in the IPv6 header will differ from the client. Only the fields in the IPv6 header will differ from the
datagram received from the client, not the payload. datagram received from the client, not the payload.
DISCUSSION: Would an error return be better?
DISCUSSION: How about ICMP Unreachable when the Request fails?
7.3. DHCP Reply Message Processing 7.3. DHCP Reply Message Processing
When the relay receives a DHCP Reply, it MUST check whether the When the relay receives a DHCP Reply, it MUST check whether the
message has the 'L' bit set. It must check whether the link-local message has the 'L' bit set. It must check whether the link-local
address field contains an IPv6 address that has prefix FE80::00 . address field contains an IPv6 address that has prefix FE80::00 .
If all the checks are satisfied, the relay MUST send a DHCP Reply If all the checks are satisfied, the relay MUST send a DHCP Reply
message to the link-local address listed in the received Reply message to the link-local address listed in the received Reply
message. Only the fields in the IPv6 header will differ from the message. Only the fields in the IPv6 header will differ from the
datagram received from the server, not the payload. datagram received from the server, not the payload.
7.4. Retransmission and Configuation Variables 7.4. Retransmission and Configuration Variables
When a DHCPv6 client does not receive a DHCP Reply in response to a When a DHCPv6 client does not receive a DHCP Reply in response to a
pending DHCP Request, the client MUST retransmit the identical DHCP pending DHCP Request, the client MUST retransmit the identical DHCP
Request to the same server again until it can be reasonably sure that Request to the same server again until it can be reasonably sure that
the DHCPv6 server is unavailable and an alternative can be chosen. the DHCPv6 server is unavailable and an alternative can be chosen.
It is important for the DHCP Server to be sure that its client has It is important for the DHCP Server to be sure that its client has
received the configuration information included with the Extensions received the configuration information included with the Extensions
to the DHCP Reply message. to the DHCP Reply message.
Likewise, but less commonly, when a DHCP server does not receive a Likewise, but less commonly, when a DHCP server does not receive a
skipping to change at page 24, line 20 skipping to change at page 25, line 20
The time in seconds that a DHCPv6 client waits to receive a The time in seconds that a DHCPv6 client waits to receive a
server's DHCP Reply before retransmitting a DHCP Request. server's DHCP Reply before retransmitting a DHCP Request.
Default: 2 seconds. Default: 2 seconds.
REPLY_MSG_MIN_RETRANS REPLY_MSG_MIN_RETRANS
The minimum number of DHCP Request transmissions that a DHCPv6 The minimum number of DHCP Request transmissions that a DHCPv6
client should retransmit, before aborting the request, possibly client should retransmit, before aborting the request, possibly
retrying the Request with another Server, and logging DHCPv6 retrying the Request with another Server, and logging a DHCPv6
System Error. System Error.
Default: 10 retransmissions. Default: 10 retransmissions.
REPLY_MSG_RETRANS_INTERVAL
The time between successive retransmissions of DHCP Request
messages.
Default: 2 seconds.
RECONF_MSG_INITIAL_TIMEOUT RECONF_MSG_INITIAL_TIMEOUT
The time in seconds that a DHCPv6 server waits to receive The time in seconds that a DHCPv6 server waits to receive
a client's DHCP Request before retransmitting its DHCP a client's DHCP Request before retransmitting its DHCP
Reconfigure. Reconfigure.
Default: 2 seconds. Default: 2 seconds.
RECONF_MSG_MIN_RETRANS RECONF_MSG_MIN_RETRANS
The minimum number of DHCP Reconfigure messages that a DHCPv6 The minimum number of DHCP Reconfigure messages that a DHCPv6
server should retransmit, before assuming the the client is server should retransmit, before assuming the the client is
unavailable and that the server can proceed with the needed unavailable and that the server can proceed with the needed
reconfiguration of that client's resources, and logging DHCPv6 reconfiguration of that client's resources, and logging a
System Error. DHCPv6 System Error.
Default: 10 retransmissions. Default: 10 retransmissions.
RECONF_MSG_RETRANS_INTERVAL
The time between successive retransmissions of DHCP Reconfigure
messages.
Default: 2 seconds.
RECONF_MSG_MIN_RESP
The minimum amount of time before a client can respond to a
DHCP Reconfigure message sent to a multicast address.
Default: 1 second.
RECONF_MSG_MAX_RESP
The maximum amount of time before a client MUST respond to a
DHCP Reconfigure message sent to a multicast address.
Default: 8 second.
RELAY_DISCOVERY_PERIOD
The period fo time between successive attempts by the DHCP
Relay to discovery available DHCP Servers.
Default: 3600 seconds (1 hour).
MAX_ADV_WAIT
The amount of time the relay waits to hear DHCP Advertisements
from DHCP Servers after the relay issues its periodic
solicitation to the All-DHCP Servers multicast address.
The following parameter specifies how long a DHCPv6 server has to The following parameter specifies how long a DHCPv6 server has to
keep track of client transaction-IDs in order to make sure that keep track of client transaction-IDs in order to make sure that
client retransmissions using the same transaction-ID are idempotent. client retransmissions using the same transaction-ID are idempotent.
TRANSACTION_IT_TIMEOUT XID_IT_TIMEOUT
Default: 10800 seconds Default: 10800 seconds
8. Security Considerations 8. Security Considerations
It may often be very important for DHCP clients and servers to be DHCP clients and servers must often be able to authenticate the
able to authenticate the messages they exchange. For instance, a messages they exchange. For instance, a DHCP server may wish to be
DHCP server may wish to be certain that a DHCP Request originated certain that a DHCP Request originated from the client identified by
from the client identified by the <link-local address, agent address> the <link-local address, agent address> fields included within the
fields included within the Request message header. Conversely, Request message header. Conversely, it is often essential for a DHCP
it is often essential for a DHCP client to be certain that the client to be certain that the configuration parameters and addresses
configuration parameters and addresses it has received were sent to it has received were sent to it by an authoritative DHCP server.
it by an authoritative DHCP server. Similarly, a DHCP server should Similarly, a DHCP server should only accept a DHCP Release message
only accept a DHCP Release message which seems to be from one of which seems to be from one of its clients, if it has some assurance
its clients, if it has some assurance that the client actually did that the client actually did transmit the Release message. At the
transmit the Release message. At the time of this writing, there time of this writing, there is no generally accepted mechanism useful
is no generally accepted mechanism useful with DHCPv4 that can be with DHCPv4 that can be extended for use with DHCPv6.
extended for use with DHCPv6.
There has been some discussion about the advisability and
desirability of using IPv6 Authentication to allow DHCPv6 clients
and servers to authenticate messages which they exchange. However,
in many circumstances a client has only a link-local address, and a
link-local address cannot be forwarded to a server which is off-link.
Thus, the DHCP relay _has_to be involved, for instance, with the DHCP
Request when the client has only a link-local address, and therefore
the DHCP Request (in this circumstance) MUST have the relay's address
in the IPv6 destination address field.
That means that the authentication (in this circumstance) CANNOT be
end-to-end. That means that IPsec cannot apply. Thus, in order to
authenticate DHCP Request messages in many circumstances will require
a more specialized technique for message authentication, as specified
in the DHCPv6 Extensions companion document [5].
One possibility is to allow relays to encapsulate the DHCP Request The IPv6 Authentication Header can provide security for DHCPv6
before delivery to the server. Then the client could apply messages when both endpoints have a suitable IPv6 address. However,
end-to-end authentication (such as afforded by IPSec) which would a client often has only a link-local address, and such an address
nevertheless remain untouched by the relay. The relay could, if is not sufficient for a DHCPv6 server which is off-link. In those
desired, apply its own authentication header to the encapsulated circumstances the DHCP relay must be involved, so that the DHCP
datagrams. message MUST have the relay's address in the IPv6 destination address
field, even though the client aims to deliver the message to the
DHCPv5 server. The DHCPv6 Client-Server Authentication Extension is
intended to be used in these circumstances.
9. Acknowledgements 9. Acknowledgements
Thanks to the DHC Working Group for their time and input into the Thanks to the DHC Working Group for their time and input into the
specification. A special thanks for the consistent input, ideas, specification. A special thanks for the consistent input, ideas,
and review by (in alphabetical order) Brian Carpenter, Ralph Droms, and review by (in alphabetical order) Brian Carpenter, Ralph Droms,
Thomas Narten, Jack McCann, Yakov Rekhter, Matt Thomas, Sue Thomson, Thomas Narten, Jack McCann, Yakov Rekhter, Matt Thomas, Sue Thomson,
and Phil Wells. and Phil Wells.
Thanks to Steve Deering and Bob Hinden, who have consistently Thanks to Steve Deering and Bob Hinden, who have consistently
skipping to change at page 26, line 39 skipping to change at page 28, line 21
prior to the UDP header in the datagram. But, IPv6 does not support prior to the UDP header in the datagram. But, IPv6 does not support
fragmentation at routers and fragmentation must take place end-to-end fragmentation at routers and fragmentation must take place end-to-end
between hosts. If a DHCPv6 implementation needs to send a datagram between hosts. If a DHCPv6 implementation needs to send a datagram
greater than 536 octets it can either fragment the UDP datagram greater than 536 octets it can either fragment the UDP datagram
in UDP or use Path MTU Discovery [2] to determine the size of the in UDP or use Path MTU Discovery [2] to determine the size of the
datagram that will traverse a network path. It is implementation datagram that will traverse a network path. It is implementation
defined how this is accomplished in DHCPv6. defined how this is accomplished in DHCPv6.
The IPv6 Addressing Architecture Specification provides the address The IPv6 Addressing Architecture Specification provides the address
scope that can be used in an IPv6 implementation, and the various scope that can be used in an IPv6 implementation, and the various
configuration architecture guidelines for network designers of configuration architecture guidelines for network designers of the
the IPv6 address space. Two advantages of IPv6 is that multicast IPv6 address space. Two advantages of IPv6 are that multicast
addressing is well defined and nodes can create link-local addresses addressing is well defined, and nodes can create link-local addresses
during initialization of the nodes environment. This means that a during initialization of the nodes environment. This means that a
host immediately can configure an IPv6 address at initialization host immediately can configure an IPv6 address at initialization
for an interface, before communicating in any manner on the link. for an interface, before communicating in any manner on the link.
The host can then use a well-known multicast address to begin The host can then use a well-known multicast address to begin
communications to discover neighbors on the link, or as was discussed communications to discover neighbors on the link, or to send a DHCP
in the specification to locate a DHCPv6 server or relay. Solicit and locate a DHCPv6 server or relay.
The IPv6 Stateless Address Autoconfiguration Specification [9] IPv6 Stateless Address Autoconfiguration [9] specifies procedures by
defines how a host can autoconfigure addresses based on neighbor which a host may autoconfigure addresses based on neighbor discovery
discovery router advertisements, and the use of a validation lifetime router advertisements, and the use of a validation lifetime to
to support renumbering of addresses on the Internet. In addition the support renumbering of addresses on the Internet. In addition the
addrconf specification defines the protocol interaction for a host to protocol interaction by which a host begins stateless or stateful
begin stateless or stateful autoconfiguration. DHCPv6 is one vehicle autoconfiguration is specified. DHCPv6 is one vehicle to perform
to perform stateful autoconfiguration. Compatibility with addrconf stateful autoconfiguration. Compatibility with addrconf is a design
is a design goal of DHCPv6. goal of DHCPv6.
IPv6 Neighbor Discovery (ND) [4] is the node discovery protocol in IPv6 Neighbor Discovery [4] is the node discovery protocol in
IPv6 (replaces and enhances functions of IPv4 ARP Model [6]). To IPv6 (replaces and enhances functions of IPv4 ARP Model [6]). To
truly understand IPv6 and addrconf it is strongly recommended that truly understand IPv6 and addrconf it is strongly recommended that
implementors understand IPv6 ND. implementors understand IPv6 Neighbor Discovery.
Dynamic Updates to DNS [10] is a specification that supports the Dynamic Updates to DNS [10] is a specification that supports the
dynamic update of DNS records for both IPv4 and IPv6. DHCPv6 can use dynamic update of DNS records for both IPv4 and IPv6. DHCPv6 can use
the dynamic updates to DNS to now integrate addresses and name space the dynamic updates to DNS to now integrate addresses and name space
to not only support autoconfiguration, but also autoregistration in to not only support autoconfiguration, but also autoregistration in
IPv6. IPv6.
B. Change History B. Change History
B.1. Changes from November 95 to February 96 Drafts B.1. Changes from November 95 to February 96 Drafts
skipping to change at page 28, line 5 skipping to change at page 29, line 30
Server commits after receiving DHCP Request, and optimistically Server commits after receiving DHCP Request, and optimistically
depends on client retransmissions as negative acknowledgement. depends on client retransmissions as negative acknowledgement.
Eliminated total-addrs. Eliminated total-addrs.
Eliminated all definitions and most fields related to allocating IPv6 Eliminated all definitions and most fields related to allocating IPv6
addresses (moved to the Extensions specification). addresses (moved to the Extensions specification).
Renamed "gateway address" to be "agent address". Renamed "gateway address" to be "agent address".
Added "Considerations" sections.
B.2. Changes from February 96 to June 96 Drafts
Added language referring to DHCP Client-Server Authentication
extension.
Moved the 'L' bit in the DHCP Reply Message format to save 32 bits.
Added language for multicast Reconfigure message handling.
In the process of adding capability for the DHCP Relay to multicast
and obtain DHCP Server addresses.
C. Comparison between DHCPv4 and DHCPv6
This appendix is provided for readers who will find it useful to see
a model and architecture comparison between DHCPv4 and DHCPv6. The
differences are because of three key reasons:
o IPv6 inherently supports a new model and architecture for
communications and autoconfiguration of addresses.
o DHCPv6 in its design was able to take advantage of the inherent
benefits of IPv6.
o New features were added to support the evolution and the
existence of mature Internet users in the industry.
IPv6 Architecuture/Model Changes:
o The link-local address permits a node to have an address
immediately when the node boots, which means all clients have a
source IP address at all times to locate a server or relay agent
on the local link.
o The need for bootp compatibility and broadcast flags are removed,
which permitted a great deal of freedom in designing the new
packet formats for the client and server interaction.
o Multicast and the scoping methods in IPv6 permitted the design of
discovery packets that would inherently define their range by the
multicast address for the function required.
o Stateful autoconfiguration must coexist and integrate with
stateless autoconfiguration supporting Duplicate Address
Detection and two lease times to facilitate the dynamic
renumbering of addresses and the management of those addresses.
o Multiple addresses per interface are inherently supported in
IPv6.
o Most DHCPv4 options are unnecessary now because the configuration
parameters are either obtained thru IPv6 Neighbor Discovery or
the Service Location protocol.
DHCPv6 Architecture/Model Changes:
o Message types are the first bytes in the packet.
o IPv6 Address allocations are now handled in a message extension
as opposed to the main header.
o Client/Server bindings are now mandatory and take advantage of
the client's link-local address to always permit communications
either directly from an on-link server, or from a remote server
through an on-link relay-agent.
o Servers are now discovered by a client solicit and server or
relay-agent advertisement model.
o The client will know if the server is on-link or off-link.
o The client after a solicit will be returned the addresses of
available servers either from an on-link server or from an
on-link relay-agent as agents providing the advertisements.
o The on-link relay-agent will obtain the location of remote server
addresses from system configuration or by the use of a site wide
DHCPv6 Multicast packet.
o The protocol is optimized and removes the use of ACKs and NAKs
once the client and server set-up is complete.
o The server uses client retransmits to indicate that the client
may have become invalid, which permits recovery in the case where
the network has faulted.
o DHCPINFORM is inherent in the new packet design; a client can
request configuration parameters other than IPv6 addresses in the
optional extension headers.
o Clients must listen to their UDP port for the new Reconfigure
message type from servers, unless they join the appropriate
multicast group as specified by the DHCP server.
o Dynamic Updates to DNS are supported in the IPv6 Address
extension.
o New extensions have been defined.
New Internet User Features:
o Configuration of Dynamic Updates to DNS to support multiple
implementation policy requirements.
o Configuration of what policy is enforced when addresses are
deprecated for dynamic renumbering can be implemented.
o Configuration of how relay-agents locate remote servers for a
link can be implemented.
o An Authentication extension has been added.
o Configuration of IPv6 Mobile Binding Updates and Anycast
Addresses can be facilitated and implemented to support
Multihomed nodes.
o Configuration of additional addresses for server applications can
be requested by a client in an implementation.
o Configuration of reclaiming infinite leases can be implemented
using the Reconfigure message type.
o Configuration of tightly coupled integration between stateless
and stateful address autoconfiguration can be implemented.
References References
[1] S. Bradner and A. Mankin. The Recommendation for the IP Next [1] S. Bradner and A. Mankin. The Recommendation for the IP Next
Generation Protocol. RFC 1752, January 1995. Generation Protocol. RFC 1752, January 1995.
[2] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) [2] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6)
Specification. RFC 1883, December 1995. Specification. RFC 1883, December 1995.
[3] R. Hinden and S. Deering. IP Version 6 Addressing Architecture. [3] R. Hinden and S. Deering. IP Version 6 Addressing Architecture.
RFC 1883, December 1995. RFC 1883, December 1995.
[4] T. Narten, E. Nordmark, and W. Simpson. IPv6 Neighbor [4] T. Narten, E. Nordmark, and W. Simpson. IPv6 Neighbor
Discovery. draft-ietf-ipngwg-discovery-03.txt -- work in Discovery. draft-ietf-ipngwg-discovery-03.txt -- work in
progress, November 1995. progress, November 1995.
[5] C. Perkins. Extensions to DHCPv6. draft-ietf-dhc-dhcpv6ext-00.txt [5] C. Perkins. Extensions to DHCPv6. draft-ietf-dhc-dhcpv6ext-02.txt
-- work in progress, November 1995. -- work in progress, June 1996.
[6] David C. Plummer. An Ethernet Address Resolution Protocol: [6] David C. Plummer. An Ethernet Address Resolution Protocol:
Or Converting Network Protocol Addresses to 48.bit Ethernet Or Converting Network Protocol Addresses to 48.bit Ethernet
Addresses for Transmission on Ethernet Hardware. RFC 826, Addresses for Transmission on Ethernet Hardware. RFC 826,
November 1982. November 1982.
[7] J. B. Postel. User Datagram Protocol. RFC 768, August 1980. [7] J. B. Postel. User Datagram Protocol. RFC 768, August 1980.
[8] J. B. Postel, editor. Internet Protocol. RFC 791, September [8] J. B. Postel, Editor. Internet Protocol. RFC 791, September
1981. 1981.
[9] S. Thomson and T. Narten. IPv6 Stateless Address [9] S. Thomson and T. Narten. IPv6 Stateless Address
Autoconfiguration. draft-ietf-addrconf-ipv6-auto-06.txt Autoconfiguration. draft-ietf-addrconf-ipv6-auto-06.txt
- work in progress, November 1995. - work in progress, November 1995.
[10] S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates in the [10] S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates in the
Domain Name System (DNS). draft-ietf-dnsind-dynDNS-06.txt -- Domain Name System (DNS). draft-ietf-dnsind-dynDNS-06.txt --
work in progress, February 1996. work in progress, February 1996.
skipping to change at page 29, line 25 skipping to change at page 34, line 25
Phone: (717) 524-1145 Phone: (717) 524-1145
E-mail: droms@bucknell.edu E-mail: droms@bucknell.edu
Author's Address Author's Address
Questions about this memo can be directed to: Questions about this memo can be directed to:
Jim Bound Charles Perkins Jim Bound Charles Perkins
Digital Equipment Corporation T. J. Watson Research Center Digital Equipment Corporation T. J. Watson Research Center
110 Spitbrook Road, ZKO3-3/U14 IBM Corporation 110 Spitbrook Road, ZKO3-3/U14 IBM Corporation
Nashua, NH 03062 30 Saw Mill River Rd., Rm J1-A25 Nashua, NH 03062 30 Saw Mill River Rd., Rm H3-D34
Hawthorne, NY 10532 Hawthorne, NY 10532
Phone: +1-603-881-0400 +1-914-784-7350 Phone: +1-603-881-0400 +1-914-784-7350
Fax: +1-914-784-6205 Fax: +1-914-784-6205
E-mail: bound@zk3.dec.com perk@watson.ibm.com E-mail: bound@zk3.dec.com perk@watson.ibm.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/