Tech-invite3GPPspecsSIPRFCs
898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 3315

Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

Pages: 101
Obsoleted by:  8415
Updated by:  436154946221642266447083722772837550
Part 1 of 5 – Pages 1 to 16
None   None   Next

ToP   noToC   RFC3315 - Page 1
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.
ToP   noToC   RFC3315 - Page 2

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
ToP   noToC   RFC3315 - Page 3
       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
ToP   noToC   RFC3315 - Page 4
              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
ToP   noToC   RFC3315 - Page 5
       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.
ToP   noToC   RFC3315 - Page 6

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
ToP   noToC   RFC3315 - Page 7
   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.
ToP   noToC   RFC3315 - Page 8

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.
ToP   noToC   RFC3315 - Page 9

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.
ToP   noToC   RFC3315 - Page 10
      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>.
ToP   noToC   RFC3315 - Page 11
      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.
ToP   noToC   RFC3315 - Page 12
                                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.
ToP   noToC   RFC3315 - Page 13

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.
ToP   noToC   RFC3315 - Page 14
      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.
ToP   noToC   RFC3315 - Page 15
      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.
ToP   noToC   RFC3315 - Page 16

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 message

5.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)

Next Section