RFC 3315
Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
Pages: 101
Obsoleted by: 8415
Updated by: 4361 5494 6221 6422 6644 7083 7227 7283 7550
Obsoleted by: 8415
Updated by: 4361 5494 6221 6422 6644 7083 7227 7283 7550
Part 1 of 5 – Pages 1 to 16
Network Working Group R. Droms, Ed. Request for Comments: 3315 Cisco Category: Standards Track J. Bound Hewlett Packard B. Volz Ericsson T. Lemon Nominum C. Perkins Nokia Research Center M. Carney Sun Microsystems July 2003 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved.Abstract
The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP servers to pass configuration parameters such as IPv6 network addresses to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol is a stateful counterpart to "IPv6 Stateless Address Autoconfiguration" (RFC 2462), and can be used separately or concurrently with the latter to obtain configuration parameters.
Table of Contents
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 5 1.1. Protocols and Addressing . . . . . . . . . . . . . . . 6 1.2. Client-server Exchanges Involving Two Messages . . . . 6 1.3. Client-server Exchanges Involving Four Messages. . . . 7 2. Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Background. . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . 9 4.2. DHCP Terminology . . . . . . . . . . . . . . . . . . . 10 5. DHCP Constants. . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Multicast Addresses. . . . . . . . . . . . . . . . . . 13 5.2. UDP Ports. . . . . . . . . . . . . . . . . . . . . . . 13 5.3. DHCP Message Types . . . . . . . . . . . . . . . . . . 13 5.4. Status Codes . . . . . . . . . . . . . . . . . . . . . 15 5.5. Transmission and Retransmission Parameters . . . . . . 16 5.6 Representation of time values and "Infinity" as a time value. . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Client/Server Message Formats . . . . . . . . . . . . . . . . 16 7. Relay Agent/Server Message Formats. . . . . . . . . . . . . . 17 7.1. Relay-forward Message. . . . . . . . . . . . . . . . . 18 7.2. Relay-reply Message. . . . . . . . . . . . . . . . . . 19 8. Representation and Use of Domain Names. . . . . . . . . . . . 19 9. DHCP Unique Identifier (DUID) . . . . . . . . . . . . . . . . 19 9.1. DUID Contents. . . . . . . . . . . . . . . . . . . . . 20 9.2. DUID Based on Link-layer Address Plus Time [DUID-LLT]. 20 9.3. DUID Assigned by Vendor Based on Enterprise Number [DUID-EN]. . . . . . . . . . . . . . . . . . . . . . . 22 9.4. DUID Based on Link-layer Address [DUID-LL] . . . . . . 22 10. Identity Association. . . . . . . . . . . . . . . . . . . . . 23 11. Selecting Addresses for Assignment to an IA . . . . . . . . . 24 12. Management of Temporary Addresses . . . . . . . . . . . . . . 25 13. Transmission of Messages by a Client. . . . . . . . . . . . . 25 14. Reliability of Client Initiated Message Exchanges . . . . . . 26 15. Message Validation. . . . . . . . . . . . . . . . . . . . . . 27 15.1. Use of Transaction IDs . . . . . . . . . . . . . . . . 28 15.2. Solicit Message. . . . . . . . . . . . . . . . . . . . 28 15.3. Advertise Message. . . . . . . . . . . . . . . . . . . 28 15.4. Request Message. . . . . . . . . . . . . . . . . . . . 29 15.5. Confirm Message. . . . . . . . . . . . . . . . . . . . 29 15.6. Renew Message. . . . . . . . . . . . . . . . . . . . . 29 15.7. Rebind Message . . . . . . . . . . . . . . . . . . . . 29 15.8. Decline Messages . . . . . . . . . . . . . . . . . . . 30 15.9. Release Message. . . . . . . . . . . . . . . . . . . . 30 15.10. Reply Message. . . . . . . . . . . . . . . . . . . . . 30 15.11. Reconfigure Message. . . . . . . . . . . . . . . . . . 31 15.12. Information-request Message. . . . . . . . . . . . . . 31
15.13. Relay-forward Message. . . . . . . . . . . . . . . . . 31
15.14. Relay-reply Message. . . . . . . . . . . . . . . . . . 31
16. Client Source Address and Interface Selection . . . . . . . . 32
17. DHCP Server Solicitation. . . . . . . . . . . . . . . . . . . 32
17.1. Client Behavior. . . . . . . . . . . . . . . . . . . . 32
17.1.1. Creation of Solicit Messages . . . . . . . . . 32
17.1.2. Transmission of Solicit Messages . . . . . . . 33
17.1.3. Receipt of Advertise Messages. . . . . . . . . 35
17.1.4. Receipt of Reply Message . . . . . . . . . . . 35
17.2. Server Behavior. . . . . . . . . . . . . . . . . . . . 36
17.2.1. Receipt of Solicit Messages . . . . . . . . . 36
17.2.2. Creation and Transmission of Advertise Messages 36
17.2.3. Creation and Transmission of Reply Messages. . 38
18. DHCP Client-Initiated Configuration Exchange. . . . . . . . . 38
18.1. Client Behavior. . . . . . . . . . . . . . . . . . . . 39
18.1.1. Creation and Transmission of Request Messages. 39
18.1.2. Creation and Transmission of Confirm Messages. 40
18.1.3. Creation and Transmission of Renew Messages. . 41
18.1.4. Creation and Transmission of Rebind Messages . 43
18.1.5. Creation and Transmission of Information-
request Messages . . .. . . . . . . . . . . . 44
18.1.6. Creation and Transmission of Release Messages. 44
18.1.7. Creation and Transmission of Decline Messages. 46
18.1.8. Receipt of Reply Messages. . . . . . . . . . . 46
18.2. Server Behavior. . . . . . . . . . . . . . . . . . . . 48
18.2.1. Receipt of Request Messages. . . . . . . . . . 49
18.2.2. Receipt of Confirm Messages. . . . . . . . . . 50
18.2.3. Receipt of Renew Messages. . . . . . . . . . . 51
18.2.4. Receipt of Rebind Messages . . . . . . . . . . 51
18.2.5. Receipt of Information-request Messages. . . . 52
18.2.6. Receipt of Release Messages. . . . . . . . . . 53
18.2.7. Receipt of Decline Messages. . . . . . . . . . 53
18.2.8. Transmission of Reply Messages . . . . . . . . 54
19. DHCP Server-Initiated Configuration Exchange. . . . . . . . . 54
19.1. Server Behavior. . . . . . . . . . . . . . . . . . . . 55
19.1.1. Creation and Transmission of Reconfigure
Messages . . . . . . . . . . . . . . . . . . . 55
19.1.2. Time Out and Retransmission of Reconfigure
Messages . . . . . . . . . . . . . . . . . . . 56
19.2. Receipt of Renew Messages. . . . . . . . . . . . . . . 56
19.3. Receipt of Information-request Messages. . . . . . . . 56
19.4. Client Behavior. . . . . . . . . . . . . . . . . . . . 57
19.4.1. Receipt of Reconfigure Messages. . . . . . . . 57
19.4.2. Creation and Transmission of Renew Messages. . 58
19.4.3. Creation and Transmission of Information-
request Messages . . . . . . . . . . . . . . . 58
19.4.4. Time Out and Retransmission of Renew or
Information-request Messages . . . . . . . . . 58
19.4.5. Receipt of Reply Messages. . . . . . . . . . . 58
20. Relay Agent Behavior. . . . . . . . . . . . . . . . . . . . . 58
20.1. Relaying a Client Message or a Relay-forward Message . 59
20.1.1. Relaying a Message from a Client . . . . . . . 59
20.1.2. Relaying a Message from a Relay Agent. . . . . 59
20.2. Relaying a Relay-reply Message . . . . . . . . . . . . 60
20.3. Construction of Relay-reply Messages . . . . . . . . . 60
21. Authentication of DHCP Messages . . . . . . . . . . . . . . . 61
21.1. Security of Messages Sent Between Servers and Relay
Agents . . . . . . . . . . . . . . . . . . . . . . . 61
21.2. Summary of DHCP Authentication . . . . . . . . . . . . 63
21.3. Replay Detection . . . . . . . . . . . . . . . . . . . 63
21.4. Delayed Authentication Protocol. . . . . . . . . . . . 63
21.4.1. Use of the Authentication Option in the Delayed
Authentication Protocol. . . . . . . . . . . . 64
21.4.2. Message Validation . . . . . . . . . . . . . . 65
21.4.3. Key Utilization . . . . . . . . . . . . . . . 65
21.4.4. Client Considerations for Delayed Authentication
Protocol . . . . . . . . . . . . . . . . . . . 66
21.4.5. Server Considerations for Delayed Authentication
Protocol . . . . . . . . . . . . . . . . . . . 67
21.5. Reconfigure Key Authentication Protocol. . . . . . . . 68
21.5.1. Use of the Authentication Option in the
Reconfigure Key Authentication Protocol. . . . 69
21.5.2. Server considerations for Reconfigure Key
protocol . . . . . . . . . . . . . . . . . . . 69
21.5.3. Client considerations for Reconfigure Key
protocol . . . . . . . . . . . . . . . . . . . 70
22. DHCP Options. . . . . . . . . . . . . . . . . . . . . . . . . 70
22.1. Format of DHCP Options . . . . . . . . . . . . . . . . 71
22.2. Client Identifier Option . . . . . . . . . . . . . . . 71
22.3. Server Identifier Option . . . . . . . . . . . . . . . 72
22.4. Identity Association for Non-temporary Addresses Option 72
22.5. Identity Association for Temporary Addresses Option. . 75
22.6. IA Address Option. . . . . . . . . . . . . . . . . . . 76
22.7. Option Request Option. . . . . . . . . . . . . . . . . 78
22.8. Preference Option. . . . . . . . . . . . . . . . . . . 79
22.9. Elapsed Time Option. . . . . . . . . . . . . . . . . . 79
22.10. Relay Message Option . . . . . . . . . . . . . . . . . 80
22.11. Authentication Option. . . . . . . . . . . . . . . . . 81
22.12. Server Unicast Option. . . . . . . . . . . . . . . . . 82
22.13. Status Code Option . . . . . . . . . . . . . . . . . . 82
22.14. Rapid Commit Option. . . . . . . . . . . . . . . . . . 83
22.15. User Class Option. . . . . . . . . . . . . . . . . . . 84
22.16. Vendor Class Option. . . . . . . . . . . . . . . . . . 85
22.17. Vendor-specific Information Option . . . . . . . . . . 86
22.18. Interface-Id Option. . . . . . . . . . . . . . . . . . 87
22.19. Reconfigure Message Option . . . . . . . . . . . . . . 88
22.20. Reconfigure Accept Option. . . . . . . . . . . . . . . 89
23. Security Considerations . . . . . . . . . . . . . . . . . . . 89
24. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 91
24.1. Multicast Addresses. . . . . . . . . . . . . . . . . . 92
24.2. DHCP Message Types . . . . . . . . . . . . . . . . . . 93
24.3. DHCP Options . . . . . . . . . . . . . . . . . . . . . 94
24.4. Status Codes . . . . . . . . . . . . . . . . . . . . . 95
24.5. DUID . . . . . . . . . . . . . . . . . . . . . . . . . 95
25. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 95
26. References. . . . . . . . . . . . . . . . . . . . . . . . . . 96
26.1. Normative References . . . . . . . . . . . . . . . . . 96
26.2. Informative References . . . . . . . . . . . . . . . . 97
A. Appearance of Options in Message Types . . . . . . . . . . . . 98
B. Appearance of Options in the Options Field of DHCP Options . . 99
Chair's Address . . . . . . . . . . . . . . . . . . . . . . . . . 99
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 100
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 101
1. Introduction and Overview
This document describes DHCP for IPv6 (DHCP), a client/server
protocol that provides managed configuration of devices.
DHCP can provide a device with addresses assigned by a DHCP server
and other configuration information, which are carried in options.
DHCP can be extended through the definition of new options to carry
configuration information not specified in this document.
DHCP is the "stateful address autoconfiguration protocol" and the
"stateful autoconfiguration protocol" referred to in "IPv6 Stateless
Address Autoconfiguration" [17].
The operational models and relevant configuration information for
DHCPv4 [18][19] and DHCPv6 are sufficiently different that
integration between the two services is not included in this
document. If there is sufficient interest and demand, integration
can be specified in a document that extends DHCPv6 to carry IPv4
addresses and configuration information.
The remainder of this introduction summarizes DHCP, explaining the
message exchange mechanisms and example message flows. The message
flows in sections 1.2 and 1.3 are intended as illustrations of DHCP
operation rather than an exhaustive list of all possible
client-server interactions. Sections 17, 18, and 19 explain client
and server operation in detail.
1.1. Protocols and Addressing
Clients and servers exchange DHCP messages using UDP [15]. The client uses a link-local address or addresses determined through other mechanisms for transmitting and receiving DHCP messages. DHCP servers receive messages from clients using a reserved, link-scoped multicast address. A DHCP client transmits most messages to this reserved multicast address, so that the client need not be configured with the address or addresses of DHCP servers. To allow a DHCP client to send a message to a DHCP server that is not attached to the same link, a DHCP relay agent on the client's link will relay messages between the client and server. The operation of the relay agent is transparent to the client and the discussion of message exchanges in the remainder of this section will omit the description of message relaying by relay agents. Once the client has determined the address of a server, it may under some circumstances send messages directly to the server using unicast.1.2. Client-server Exchanges Involving Two Messages
When a DHCP client does not need to have a DHCP server assign it IP addresses, the client can obtain configuration information such as a list of available DNS servers [20] or NTP servers [21] through a single message and reply exchanged with a DHCP server. To obtain configuration information the client first sends an Information-Request message to the All_DHCP_Relay_Agents_and_Servers multicast address. Servers respond with a Reply message containing the configuration information for the client. This message exchange assumes that the client requires only configuration information and does not require the assignment of any IPv6 addresses. When a server has IPv6 addresses and other configuration information committed to a client, the client and server may be able to complete the exchange using only two messages, instead of four messages as described in the next section. In this case, the client sends a Solicit message to the All_DHCP_Relay_Agents_and_Servers requesting the assignment of addresses and other configuration information. This message includes an indication that the client is willing to accept an immediate Reply message from the server. The server that is willing to commit the assignment of addresses to the client
immediately responds with a Reply message. The configuration information and the addresses in the Reply message are then immediately available for use by the client. Each address assigned to the client has associated preferred and valid lifetimes specified by the server. To request an extension of the lifetimes assigned to an address, the client sends a Renew message to the server. The server sends a Reply message to the client with the new lifetimes, allowing the client to continue to use the address without interruption.1.3. Client-server Exchanges Involving Four Messages
To request the assignment of one or more IPv6 addresses, a client first locates a DHCP server and then requests the assignment of addresses and other configuration information from the server. The client sends a Solicit message to the All_DHCP_Relay_Agents_and_Servers address to find available DHCP servers. Any server that can meet the client's requirements responds with an Advertise message. The client then chooses one of the servers and sends a Request message to the server asking for confirmed assignment of addresses and other configuration information. The server responds with a Reply message that contains the confirmed addresses and configuration. As described in the previous section, the client sends a Renew message to the server to extend the lifetimes associated with its addresses, allowing the client to continue to use those addresses without interruption.2. Requirements
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [1]. This document also makes use of internal conceptual variables to describe protocol behavior and external variables that an implementation must allow system administrators to change. The specific variable names, how their values change, and how their settings influence protocol behavior are provided to demonstrate protocol behavior. An implementation is not required to have them in the exact form described here, so long as its external behavior is consistent with that described in this document.
3. Background
The IPv6 Specification provides the base architecture and design of IPv6. Related work in IPv6 that would best serve an implementor to study includes the IPv6 Specification [3], the IPv6 Addressing Architecture [5], IPv6 Stateless Address Autoconfiguration [17], IPv6 Neighbor Discovery Processing [13], and Dynamic Updates to DNS [22]. These specifications enable DHCP to build upon the IPv6 work to provide both robust stateful autoconfiguration and autoregistration of DNS Host Names. The IPv6 Addressing Architecture specification [5] defines the address scope that can be used in an IPv6 implementation, and the various configuration architecture guidelines for network designers of the IPv6 address space. Two advantages of IPv6 are that support for multicast is required and nodes can create link-local addresses during initialization. The availability of these features means that a client can use its link-local address and a well-known multicast address to discover and communicate with DHCP servers or relay agents on its link. IPv6 Stateless Address Autoconfiguration [17] specifies procedures by which a node may autoconfigure addresses based on router advertisements [13], and the use of a valid lifetime to support renumbering of addresses on the Internet. In addition, the protocol interaction by which a node begins stateless or stateful autoconfiguration is specified. DHCP is one vehicle to perform stateful autoconfiguration. Compatibility with stateless address autoconfiguration is a design requirement of DHCP. IPv6 Neighbor Discovery [13] is the node discovery protocol in IPv6 which replaces and enhances functions of ARP [14]. To understand IPv6 and stateless address autoconfiguration, it is strongly recommended that implementors understand IPv6 Neighbor Discovery. Dynamic Updates to DNS [22] is a specification that supports the dynamic update of DNS records for both IPv4 and IPv6. DHCP can use the dynamic updates to DNS to integrate addresses and name space to not only support autoconfiguration, but also autoregistration in IPv6.4. Terminology
This sections defines terminology specific to IPv6 and DHCP used in this document.
4.1. IPv6 Terminology
IPv6 terminology relevant to this specification from the IPv6 Protocol [3], IPv6 Addressing Architecture [5], and IPv6 Stateless Address Autoconfiguration [17] is included below. address An IP layer identifier for an interface or a set of interfaces. host Any node that is not a router. IP Internet Protocol Version 6 (IPv6). The terms IPv4 and IPv6 are used only in contexts where it is necessary to avoid ambiguity. interface A node's attachment to a link. link A communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP. Examples are Ethernet (simple or bridged); Token Ring; PPP links, X.25, Frame Relay, or ATM networks; and Internet (or higher) layer "tunnels", such as tunnels over IPv4 or IPv6 itself. link-layer identifier A link-layer identifier for an interface. Examples include IEEE 802 addresses for Ethernet or Token Ring network interfaces, and E.164 addresses for ISDN links. link-local address An IPv6 address having a link-only scope, indicated by having the prefix (FE80::/10), that can be used to reach neighboring nodes attached to the same link. Every interface has a link-local address. multicast address An identifier for a set of interfaces (typically belonging to different nodes). A packet sent to a multicast address is delivered to all interfaces identified by that address. neighbor A node attached to the same link.
node A device that implements IP.
packet An IP header plus payload.
prefix The initial bits of an address, or a
set of IP addresses that share the same
initial bits.
prefix length The number of bits in a prefix.
router A node that forwards IP packets not
explicitly addressed to itself.
unicast address An identifier for a single interface.
A packet sent to a unicast address is
delivered to the interface identified by
that address.
4.2. DHCP Terminology
Terminology specific to DHCP can be found below.
appropriate to the link An address is "appropriate to the link"
when the address is consistent with the
DHCP server's knowledge of the network
topology, prefix assignment and address
assignment policies.
binding A binding (or, client binding) is a
group of server data records containing
the information the server has about
the addresses in an IA or configuration
information explicitly assigned to the
client. Configuration information that
has been returned to a client through a
policy - for example, the information
returned to all clients on the same
link - does not require a binding. A
binding containing information about
an IA is indexed by the tuple <DUID,
IA-type, IAID> (where IA-type is the
type of address in the IA; for example,
temporary). A binding containing
configuration information for a client
is indexed by <DUID>.
configuration parameter An element of the configuration
information set on the server and
delivered to the client using DHCP.
Such parameters may be used to carry
information to be used by a node to
configure its network subsystem and
enable communication on a link or
internetwork, for example.
DHCP Dynamic Host Configuration Protocol
for IPv6. The terms DHCPv4 and DHCPv6
are used only in contexts where it is
necessary to avoid ambiguity.
DHCP client (or client) A node that initiates requests on a link
to obtain configuration parameters from
one or more DHCP servers.
DHCP domain A set of links managed by DHCP and
operated by a single administrative
entity.
DHCP realm A name used to identify the DHCP
administrative domain from which a DHCP
authentication key was selected.
DHCP relay agent (or relay agent) A node that acts as an
intermediary to deliver DHCP messages
between clients and servers, and is on
the same link as the client.
DHCP server (or server) A node that responds to requests from
clients, and may or may not be on the
same link as the client(s).
DUID A DHCP Unique IDentifier for a DHCP
participant; each DHCP client and server
has exactly one DUID. See section 9 for
details of the ways in which a DUID may
be constructed.
Identity association (IA) A collection of addresses assigned to
a client. Each IA has an associated
IAID. A client may have more than one
IA assigned to it; for example, one for
each of its interfaces.
Each IA holds one type of address;
for example, an identity association
for temporary addresses (IA_TA) holds
temporary addresses (see "identity
association for temporary addresses").
Throughout this document, "IA" is used
to refer to an identity association
without identifying the type of
addresses in the IA.
Identity association identifier (IAID) An identifier for an IA,
chosen by the client. Each IA has an
IAID, which is chosen to be unique among
all IAIDs for IAs belonging to that
client.
Identity association for non-temporary addresses (IA_NA) An IA
that carries assigned addresses that are
not temporary addresses (see "identity
association for temporary addresses")
Identity association for temporary addresses (IA_TA) An IA that
carries temporary addresses (see RFC
3041 [12]).
message A unit of data carried as the payload
of a UDP datagram, exchanged among DHCP
servers, relay agents and clients.
Reconfigure key A key supplied to a client by a server
used to provide security for Reconfigure
messages.
relaying A DHCP relay agent relays DHCP messages
between DHCP participants.
transaction ID An opaque value used to match responses
with replies initiated either by a
client or server.
5. DHCP Constants
This section describes various program and networking constants used
by DHCP.
5.1. Multicast Addresses
DHCP makes use of the following multicast addresses: All_DHCP_Relay_Agents_and_Servers (FF02::1:2) A link-scoped multicast address used by a client to communicate with neighboring (i.e., on-link) relay agents and servers. All servers and relay agents are members of this multicast group. All_DHCP_Servers (FF05::1:3) A site-scoped multicast address used by a relay agent to communicate with servers, either because the relay agent wants to send messages to all servers or because it does not know the unicast addresses of the servers. Note that in order for a relay agent to use this address, it must have an address of sufficient scope to be reachable by the servers. All servers within the site are members of this multicast group.5.2. UDP Ports
Clients listen for DHCP messages on UDP port 546. Servers and relay agents listen for DHCP messages on UDP port 547.5.3. DHCP Message Types
DHCP defines the following message types. More detail on these message types can be found in sections 6 and 7. Message types not listed here are reserved for future use. The numeric encoding for each message type is shown in parentheses. SOLICIT (1) A client sends a Solicit message to locate servers. ADVERTISE (2) A server sends an Advertise message to indicate that it is available for DHCP service, in response to a Solicit message received from a client. REQUEST (3) A client sends a Request message to request configuration parameters, including IP addresses, from a specific server. CONFIRM (4) A client sends a Confirm message to any available server to determine whether the addresses it was assigned are still appropriate to the link to which the client is connected.
RENEW (5) A client sends a Renew message to the server
that originally provided the client's addresses
and configuration parameters to extend the
lifetimes on the addresses assigned to the
client and to update other configuration
parameters.
REBIND (6) A client sends a Rebind message to any
available server to extend the lifetimes on the
addresses assigned to the client and to update
other configuration parameters; this message is
sent after a client receives no response to a
Renew message.
REPLY (7) A server sends a Reply message containing
assigned addresses and configuration parameters
in response to a Solicit, Request, Renew,
Rebind message received from a client. A
server sends a Reply message containing
configuration parameters in response to an
Information-request message. A server sends a
Reply message in response to a Confirm message
confirming or denying that the addresses
assigned to the client are appropriate to the
link to which the client is connected. A
server sends a Reply message to acknowledge
receipt of a Release or Decline message.
RELEASE (8) A client sends a Release message to the server
that assigned addresses to the client to
indicate that the client will no longer use one
or more of the assigned addresses.
DECLINE (9) A client sends a Decline message to a server to
indicate that the client has determined that
one or more addresses assigned by the server
are already in use on the link to which the
client is connected.
RECONFIGURE (10) A server sends a Reconfigure message to a
client to inform the client that the server has
new or updated configuration parameters, and
that the client is to initiate a Renew/Reply
or Information-request/Reply transaction with
the server in order to receive the updated
information.
INFORMATION-REQUEST (11) A client sends an Information-request
message to a server to request configuration
parameters without the assignment of any IP
addresses to the client.
RELAY-FORW (12) A relay agent sends a Relay-forward message
to relay messages to servers, either directly
or through another relay agent. The received
message, either a client message or a
Relay-forward message from another relay
agent, is encapsulated in an option in the
Relay-forward message.
RELAY-REPL (13) A server sends a Relay-reply message to a relay
agent containing a message that the relay
agent delivers to a client. The Relay-reply
message may be relayed by other relay agents
for delivery to the destination relay agent.
The server encapsulates the client message as
an option in the Relay-reply message, which the
relay agent extracts and relays to the client.
5.4. Status Codes
DHCPv6 uses status codes to communicate the success or failure of
operations requested in messages from clients and servers, and to
provide additional information about the specific cause of the
failure of a message. The specific status codes are defined in
section 24.4.
5.5. Transmission and Retransmission Parameters
This section presents a table of values used to describe the message transmission behavior of clients and servers. Parameter Default Description ------------------------------------- SOL_MAX_DELAY 1 sec Max delay of first Solicit SOL_TIMEOUT 1 sec Initial Solicit timeout SOL_MAX_RT 120 secs Max Solicit timeout value REQ_TIMEOUT 1 sec Initial Request timeout REQ_MAX_RT 30 secs Max Request timeout value REQ_MAX_RC 10 Max Request retry attempts CNF_MAX_DELAY 1 sec Max delay of first Confirm CNF_TIMEOUT 1 sec Initial Confirm timeout CNF_MAX_RT 4 secs Max Confirm timeout CNF_MAX_RD 10 secs Max Confirm duration REN_TIMEOUT 10 secs Initial Renew timeout REN_MAX_RT 600 secs Max Renew timeout value REB_TIMEOUT 10 secs Initial Rebind timeout REB_MAX_RT 600 secs Max Rebind timeout value INF_MAX_DELAY 1 sec Max delay of first Information-request INF_TIMEOUT 1 sec Initial Information-request timeout INF_MAX_RT 120 secs Max Information-request timeout value REL_TIMEOUT 1 sec Initial Release timeout REL_MAX_RC 5 MAX Release attempts DEC_TIMEOUT 1 sec Initial Decline timeout DEC_MAX_RC 5 Max Decline attempts REC_TIMEOUT 2 secs Initial Reconfigure timeout REC_MAX_RC 8 Max Reconfigure attempts HOP_COUNT_LIMIT 32 Max hop count in a Relay-forward message5.6 Representation of time values and "Infinity" as a time value
All time values for lifetimes, T1 and T2 are unsigned integers. The value 0xffffffff is taken to mean "infinity" when used as a lifetime (as in RFC2461 [17]) or a value for T1 or T2.
(page 16 continued on part 2)