Internet Engineering Task Force                                 J. Bound
INTERNET DRAFT                                                     Nokia                                                    Compaq
DHC Working Group                                              M. Carney
Obsoletes:  draft-ietf-dhc-dhcpv6-18.txt           Sun Microsystems, Inc
                                                              C. Perkins
                                                   Nokia Research Center
                                                           R. Droms(ed.)
                                                           Cisco Systems
                                                           15 April
                                                            30 June 2001

         Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
                      draft-ietf-dhc-dhcpv6-18.txt
                      draft-ietf-dhc-dhcpv6-19.txt

Status of This Memo

   This document is a submission by the Dynamic Host Configuration
   Working Group of the Internet Engineering Task Force (IETF). Comments
   should be submitted to the dhcp-v6@bucknell.edu mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at
   any time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

    The list of current Internet-Drafts can be accessed at:
         http://www.ietf.org/ietf/1id-abstracts.txt
    The list of Internet-Draft Shadow Directories can be accessed at:
         http://www.ietf.org/shadow.html.

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" [13], [20], and can be used separately
   or concurrently with the latter to obtain configuration parameters.

                                Contents

Status of This Memo                                                    i

Abstract                                                               i

 1. Introduction                                                       1

 2. Requirements                                                       1

 3. Background                                                         1

 4. Design Goals                                                       3

 5. Non-Goals                                                          3

 6. Terminology                                                        4
     6.1. IPv6 Terminology  . . . . . . . . . . . . . . . . . . . .    4
     6.2. DHCP Terminology  . . . . . . . . . . . . . . . . . . . .    5

 7. DHCP Constants                                                     6
     7.1. Multicast Addresses . . . . . . . . . . . . . . . . . . .    7    6
     7.2. UDP ports . . . . . . . . . . . . . . . . . . . . . . . .    7
     7.3. DHCP message types  . . . . . . . . . . . . . . . . . . .    7
     7.4. Error Values  . . . . . . . . . . . . . . . . . . . . . .    9
           7.4.1. Generic Error Values  . . . . . . . . . . . . . .    9
           7.4.2. Server-specific Error Values  . . . . . . . . . .    9
     7.5. Configuration Variables . . . . . . . . . . . . . . . . .   10    9

 8. Overview                                                          10
     8.1. How does a node know to use DHCP? . . . . . . . . . . . .   10
     8.2. What if the client and server(s) are on different links?    10
     8.3. How does a client request configuration parameters from
             servers? . . . . . . . . . . . . . . . . . . . . . . .   11
     8.4. How do clients and servers identify and manage addresses?   12   11
     8.5. Can a client release its assigned addresses before the lease
             expires? . . . . . . . . . . . . . . . . . . . . . . .   12
     8.6. What if the client determines one or more of its assigned
             addresses are already being used by another client?  .   12
     8.7. How are clients notified of server configuration changes?   12

 9. Message Formats                                                   13                                                   12
     9.1. DHCP Solicit Message Format . . . . . . . . . . . . . . .   13
     9.2. DHCP Advertise Message Format . . . . . . . . . . . . . .   14   13
     9.3. DHCP Request Message Format . . . . . . . . . . . . . . .   14
     9.4. DHCP Confirm Message Format . . . . . . . . . . . . . . .   15   14
     9.5. DHCP Renew Message Format . . . . . . . . . . . . . . . .   15
     9.6. DHCP Rebind Message Format  . . . . . . . . . . . . . . .   15
     9.7. DHCP Reply Message Format . . . . . . . . . . . . . . . .   16   15
     9.8. DHCP Release Message Format . . . . . . . . . . . . . . .   16
     9.9. DHCP Decline Message Format . . . . . . . . . . . . . . .   17   16
    9.10. DHCP Reconfigure-init Message Format  . . . . . . . . . .   17

10. Relay messages                                                    17
    10.1. Relay-forward message . . . . . . . . . . . . . . . . . .   18   17
    10.2. Relay-reply message . . . . . . . . . . . . . . . . . . .   18

11. DHCP unique identifier (DUID)                                     18

12. Identity association                                              19

12.                                              18

13. DHCP Server Solicitation                                          19
    12.1.
    13.1. Solicit Message Validation  . . . . . . . . . . . . . . .   19
    12.2.
    13.2. Advertise Message Validation  . . . . . . . . . . . . . .   19
    12.3.
    13.3. Client Behavior . . . . . . . . . . . . . . . . . . . . .   19
          12.3.1.
          13.3.1. Creation and sending of the Solicit message . . .   20
          12.3.2.   19
          13.3.2. Time out and retransmission of Solicit Messages .   20
          12.3.3.
          13.3.3. Receipt of Advertise messages . . . . . . . . . .   20
    12.4.
    13.4. Server Behavior . . . . . . . . . . . . . . . . . . . . .   21
          12.4.1.
          13.4.1. Receipt of Solicit messages . . . . . . . . . . .   21
          12.4.2.
          13.4.2. Creation and sending of Advertise messages  . . .   21

13.

14. DHCP Client-Initiated Configuration Exchange                      22
    13.1.
    14.1. Client Message Validation . . . . . . . . . . . . . . . .   23
    13.2.
    14.2. Server Message Validation . . . . . . . . . . . . . . . .   23
    13.3.
    14.3. Client Behavior . . . . . . . . . . . . . . . . . . . . .   24
          13.3.1.
          14.3.1. Creation and sending of Request messages  . . . .   24
          13.3.2.
          14.3.2. Creation and sending of Confirm messages  . . . .   25
          13.3.3.
          14.3.3. Creation and sending of Renew messages  . . . . .   26
          13.3.4.
          14.3.4. Creation and sending of Rebind messages . . . . .   27
          13.3.5.
          14.3.5. Receipt of Reply message in response to a Reply, Request,
                          Confirm, Renew or Rebind message . . . . .  28
          13.3.6.
          14.3.6. Creation and sending of Release messages  . . . .   30
          13.3.7.   29
          14.3.7. Time out and retransmission of Release Messages .   30
          13.3.8.
          14.3.8. Receipt of Reply message in response to a Release
                          message  . . . . . . . . . . . . . . . . .  30
          14.3.9. Creation and sending of Decline messages  . . . .   30
          13.3.9.
         14.3.10. Time out and retransmission of Decline Messages .   31
         13.3.10.
         14.3.11. Receipt of Reply message in response to a Release
                          message  . . . . . . . . . . . . . . . . .  31
    13.4.
    14.4. Server Behavior . . . . . . . . . . . . . . . . . . . . .   31
          13.4.1.
          14.4.1. Receipt of Request messages . . . . . . . . . . .   32
          13.4.2.
          14.4.2. Receipt of Confirm messages . . . . . . . . . . .   32
          13.4.3.
          14.4.3. Receipt of Renew messages . . . . . . . . . . . .   33
          13.4.4.
          14.4.4. Receipt of Rebind messages  . . . . . . . . . . .   34
          13.4.5.
          14.4.5. Receipt of Release messages . . . . . . . . . . .   35
          13.4.6.
          14.4.6. Sending of Reply messages . . . . . . . . . . . .   35

14.   36

15. DHCP Server-Initiated Configuration Exchange                      36
    14.1.
    15.1. Reconfigure-init Message Validation . . . . . . . . . . .   36
    14.2.
    15.2. Server Behavior . . . . . . . . . . . . . . . . . . . . .   36
          14.2.1.
          15.2.1. Creation and sending of Reconfigure-init messages   36
          14.2.2.
          15.2.2. Time out and retransmission of unicast Reconfigure-init
                          messages . . . . . . . .  37
          14.2.3. Time out and retransmission of multicast
                          Reconfigure-init messages . . . . . . . .  38
          14.2.4. .  37
          15.2.3. Receipt of Request messages . . . . . . . . . . .   38
    14.3.   37
    15.3. Client Behavior . . . . . . . . . . . . . . . . . . . . .   38
          14.3.1.
          15.3.1. Receipt of Reconfigure-init messages  . . . . . .   38
          14.3.2.
          15.3.2. Creation and sending of Request messages  . . . .   38
          14.3.3.   39
          15.3.3. Time out and retransmission of Request messages .   39
          14.3.4.
          15.3.4. Receipt of Reply messages . . . . . . . . . . . .   39

15.

16. Relay Behavior                                                    39
    15.1.
    16.1. Relaying of client messages . . . . . . . . . . . . . . .   39
    15.2.
    16.2. Relaying of server messages . . . . . . . . . . . . . . .   40

16.

17. Authentication of DHCP options messages                                   40
    16.1. Format of
    17.1. DHCP options  . . threat model . . . . . . . . . . . . . . .   40
    16.2. Identity association option . . . . .   40
    17.2. Summary of DHCP authentication  . . . . . . . . . .   41
    16.3. Option request option . . .   41
    17.3. Replay detection  . . . . . . . . . . . . . . .   43
    16.4. Client message option . . . . .   41
    17.4. Configuration token protocol  . . . . . . . . . . . . .   43
    16.5. Server message option .   42
    17.5. Delayed authentication protocol . . . . . . . . . . . . .   42
          17.5.1. Management issues in the delayed authentication
                          protocol . . . .   44
    16.6. Retransmission parameter option . . . . . . . . . . . . .   44
    16.7. Reconfigure-delay  42
          17.5.2. Use of the Authentication option in the delayed
                          authentication protocol  . . . . . . . . .  43
          17.5.3. Message validation  . . . . . . .   44
    16.8. DSTM Global IPv4 Address Option . . . . . . . . .   44
          17.5.4. Key utilization . . . .   45
    16.9. Authentication option . . . . . . . . . . . . .   44
          17.5.5. Client considerations for delayed authentication
                          protocol . . . . .   46

17. DHCP Client Implementor Notes                                     46
    17.1. Primary Interface . . . . . . . . . . . .  44
          17.5.6. Receiving Advertise messages  . . . . . . . .   46
    17.2. Advertise Message and Configuration Parameter Caching . .   46
    17.3. Time out and retransmission variables   45
          17.5.7. Server considerations for delayed authentication
                          protocol . . . . . . . . . .   47
    17.4. Server Preference . . . . . . .  46

18. DHCP options                                                      46
    18.1. Format of DHCP options  . . . . . . . . . . . . . . . . .   47

18.
    18.2. DHCP Server Implementor Notes                                     47
    18.1. Client Bindings unique identifier option . . . . . . . . . . . . . .   47
    18.3. Identity association option . . . . . . .   47
    18.2. Reconfigure-init Considerations . . . . . . . .   47
    18.4. Option request option . . . . .   47
          18.2.1. Reliable transmission of multicast Reconfigure-init
                          messages . . . . . . . . . . . . .   50
    18.5. Client message option . . . .  48
    18.3. Server Preference . . . . . . . . . . . . . .   50
    18.6. Server message option . . . . . .   48
    18.4. Request Message Transaction-ID Cache . . . . . . . . . .   48

19. DHCP Relay Implementor Notes                                      48

20. Open Issues for Working Group Discussion                          49
    20.1. Authentication . .   51
    18.7. Retransmission parameter option . . . . . . . . . . . . .   51
    18.8. DSTM Global IPv4 Address Option . . . . . .   49
    20.2. Identification of IAs by servers . . . . . . .   51
    18.9. Authentication option . . . . .   49
    20.3. DHCP-DNS interaction . . . . . . . . . . . . .   52
   18.10. Server unicast option . . . . .   49
    20.4. Temporary addresses . . . . . . . . . . . . .   53
   18.11. Domain Search Option  . . . . . .   49
    20.5. Use of term "agent" . . . . . . . . . . . .   53
   18.12. Domain Name Server Option . . . . . . .   49
    20.6. Client behavior when response to Rebind is not received .   49
    20.7. Additional options . . . . . . . .   54

19. DHCP Client Implementor Notes                                     55
    19.1. Primary Interface . . . . . . . . . . .   50
    20.8. Operational parameters . . . . . . . . .   55
    19.2. Advertise Message and Configuration Parameter Caching . .   55
    19.3. Time out and retransmission variables . . . . . .   50

21. Security                                                          50

22. Year 2000 considerations                                          50

23. IANA Considerations                                               50

24. Acknowledgments                                                   51

 A. Comparison between DHCPv4 and DHCPv6                              51

 B. Full Copyright Statement                                          53

 C. Changes in this draft                                             53
     C.1. New messages for confirming addresses and extending the lease
             on an IA . . . .   55
    19.4. Server Preference . . . . . . . . . . . . . . . . . . .   54
     C.2. New message formats .   56

20. DHCP Server Implementor Notes                                     56
    20.1. Client Bindings . . . . . . . . . . . . . . . . . .   54
     C.3. Renamed Server-forward message . . .   56
    20.2. Reconfigure-init Considerations . . . . . . . . . .   54
     C.4. Clarified relay forwarding of messages . . .   56
    20.3. Server Preference . . . . . .   54
     C.5. Addresses and options in Advertise messages . . . . . . .   54
     C.6. Clarification of IA option format . . . . . . .   56
    20.4. Request Message Transaction-ID Cache  . . . . .   54
     C.7. Specification of transaction ID in Solicit message . . .   54
     C.8. Edits to definitions . .   57

21. DHCP Relay Implementor Notes                                      57

22. Security                                                          57

23. Year 2000 considerations                                          57

24. IANA Considerations                                               57
    24.1. DHCPv6 options  . . . . . . . . . . . . . . . .   55
     C.9. Relay agent messages . . . . .   57
    24.2. Multicast addresses . . . . . . . . . . . . .   55
    C.10. Relay agent behavior . . . . . .   58
    24.3. Status codes  . . . . . . . . . . . .   55
    C.11. Transmission of all client messages through relays . . .   55
    C.12. . . . . . . .   58
    24.4. Retransmission parameter option . . . . . . . . . . . . .   58
    24.5. Authentication option . . . . . . . . . . . . . . . . . .   58

25. Acknowledgments                                                   59

 A. Comparison between DHCPv4 and DHCPv6                              59

 B. Full Copyright Statement                                          61

 C. Changes in this draft                                             61
     C.1. Reconfigure-init messages  . . . . . . . . . . . . . . . .   55
    C.13. Ordering . . . .   62
     C.2. Authentication  . . . . . . . . . . . . . . . . . . . . .   62
     C.3. Confirm message . . . . . . . . . . . . . . . . . . . . .   62
     C.4. Failure of sections Rebind message . . . . . . . . . . . . . . . .   63
     C.5. Server behavior in response to Release message  . . . . .   63
     C.6. Client behavior when sending a Release message  .   55
    C.14. . . . .   63
     C.7. IA option . . . . . . . . . . . . . . . . . . . . . . . .   63
     C.8. DSTM option . . . . . . . . . . . . . . . . . . . . . . .   55
    C.15. Message and   63
     C.9. Server unicast option numbering . . . . . . . . . . . . . .   55
    C.16. Inclusion of IAs in Solicit message by client . . . .   64
    C.10. Domain search option  . .   56
    C.17. Clarification of destination of client messages . . . . .   56
    C.18. Clarification of client use of Confirm messages . . . . .   56

Chair's Address                                                       58

Author's . . . . . .   64
    C.11. DNS servers option  . . . . . . . . . . . . . . . . . . .   64
    C.12. DUID and IAID . . . . . . . . . . . . . . . . . . . . . .   64
    C.13. Continuing to poll with Solicit . . . . . . . . . . . . .   64
    C.14. Using DHCPv6 without address assignment . . . . . . . . .   64
    C.15. Potential crossing in flight of Request and Reconfigure-init
             messages . . . . . . . . . . . . . . . . . . . . . . .   64

 D. Open Issues for Working Group Discussion                          64
     D.1. Generation and use of DUID and IAID . . . . . . . . . . .   65
     D.2. Address                                                      58

1. Introduction registration  . . . . . . . . . . . . . . . . . .   65
     D.3. Prefix advertisement  . . . . . . . . . . . . . . . . . .   65
     D.4. DHCP-DNS interaction  . . . . . . . . . . . . . . . . . .   65
     D.5. Use of term "agent" . . . . . . . . . . . . . . . . . . .   65
     D.6. Additional options  . . . . . . . . . . . . . . . . . . .   65
     D.7. Operational parameters  . . . . . . . . . . . . . . . . .   65

Chair's Address                                                       68

Author's Address                                                      68

1. Introduction

   This document describes DHCP for IPv6 (DHCP), a UDP [18]
   client/server protocol designed to reduce the cost of management
   of IPv6 nodes in environments where network managers require more
   control over the allocation of IPv6 addresses and configuration
   of network stack parameters than that offered by "IPv6 Stateless
   Autoconfiguration" [20].  DHCP is a stateful counterpart to
   stateless autoconfiguration.  Note that both stateful and stateless
   autoconfiguration can be used concurrently in the same environment,
   leveraging the strengths of both mechanisms in order to reduce the
   cost of ownership and management of network nodes.

   DHCP reduces the cost of ownership by centralizing the management
   of network resources such as IP addresses, routing information, OS
   installation information, directory service information, and other
   such information on a few DHCP servers, rather than distributing such
   information in local configuration files among each network node.
   DHCP is designed to be easily extended to carry new configuration
   parameters through the addition of new DHCP "options" defined to
   carry this information.

   Those readers familiar with DHCP for IPv4 [7] will find DHCP for IPv6
   provides a superset of features, and benefits from the additional
   features of IPv6 and freedom from BOOTP [5]-backward compatibility
   constraints.  For more information about the differences between DHCP
   for IPv6 and DHCP for IPv4, see Appendix A.

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 [3].

   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

   Related work in IPv6 that would best serve an implementor to study
   is the IPv6 Specification [6], the IPv6 Addressing Architecture [9],
   IPv6 Stateless Address Autoconfiguration [20], IPv6 Neighbor
   Discovery Processing [16], 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 Specification provides the base architecture and design of
   IPv6.  A key point for DHCP implementors to understand is that IPv6
   requires that every link in the Internet have an MTU of 1280 octets
   or greater (in IPv4 the requirement is 68 octets).  This means that
   a UDP packet of 536 octets will always pass through an internetwork
   (less 40 octets for the IPv6 header), as long as there are no IP
   options prior to the UDP header in the packet.  But, IPv6 does not
   support fragmentation at routers, so that fragmentation takes place
   end-to-end between hosts.  If a DHCP implementation needs to send a
   packet greater than 1500 octets it can either fragment the UDP packet
   into fragments of 1500 octets or less, or use Path MTU Discovery [11]
   to determine the size of the packet that will traverse a network
   path.

   DHCP clients use Path MTU discovery when they have an address of
   sufficient scope to reach the DHCP server.  If a DHCP client does not
   have such an address, that client MUST fragment its packets if the
   resultant message size is greater than the minimum 1280 octets.

   Path MTU Discovery for IPv6 is supported for both UDP and TCP and
   can cause end-to-end fragmentation when the PMTU changes for a
   destination.

   The IPv6 Addressing Architecture specification [9] 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.  This means that a client can immediately use
   its link-local address and a well-known multicast address to begin
   communications to discover neighbors on the link.  For instance, a
   client can send a Solicit message and locate a server or relay.

   IPv6 Stateless Address Autoconfiguration [20] (Addrconf) specifies
   procedures by which a node may autoconfigure addresses based on
   router advertisements [16], 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 addrconf is a design
   requirement of DHCP (see Section 4).

   IPv6 Neighbor Discovery [16] is the node discovery protocol in IPv6
   which replaces and enhances functions of ARP [17].  To understand
   IPv6 and Addrconf 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. Design Goals

    -  DHCP is a mechanism rather than a policy.  Network administrators
       set their administrative policies through the configuration
       parameters they place upon the DHCP servers in the DHCP domain
       they're managing.  DHCP is simply used to deliver parameters
       according to that policy to each of the DHCP clients within the
       domain.

    -  DHCP is compatible with IPv6 stateless autoconf [20].

    -  DHCP does not require manual configuration of network parameters
       on DHCP clients, except in cases where such configuration is
       needed for security reasons.  A node configuring itself using
       DHCP should require no user intervention.

    -  DHCP does not require a server on each link.  To allow for scale
       and economy, DHCP must work across DHCP relays.

    -  DHCP coexists with statically configured, non-participating nodes
       and with existing network protocol implementations.

    -  DHCP clients can operate on a link without IPv6 routers present.

    -  DHCP will provide the ability to renumber network(s) when
       required by network administrators [4].

    -  A DHCP client can make multiple, different requests for
       configuration parameters when necessary from one or more DHCP
       servers at any time.

    -  DHCP will contain the appropriate time out and retransmission
       mechanisms to efficiently operate in environments with high
       latency and low bandwidth characteristics.

5. Non-Goals

   This document describes specification explicitly does not cover the following:

    -  Specification of a DHCP for IPv6 (DHCP), server to server protocol.

    -  How a UDP [12]
   client/server protocol designed DHCP server stores its DHCP data.

    -  How to reduce manage a DHCP domain or DHCP server.

    -  How a DHCP relay is configured or what sort of information it may
       log.

6. Terminology

6.1. IPv6 Terminology

   IPv6 terminology relevant to this specification from the cost IPv6
   Protocol [6], IPv6 Addressing Architecture [9], and IPv6 Stateless
   Address Autoconfiguration [20] is included below.

      address                 An IP layer identifier for an interface or
                              a set of management interfaces.

      unicast address         An identifier for a single interface.
                              A packet sent to a unicast address is
                              delivered to the interface identified by
                              that 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.

      host                    Any node that is not a router.

      IP                      Internet Protocol Version 6 (IPv6).  The
                              terms IPv4 and IPv6 nodes are used only in environments
                              contexts where network managers require more
   control 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 allocation of 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 and configuration
   of for
                              Ethernet or Token Ring network stack parameters than that offered interfaces,
                              and E.164 addresses for ISDN links.

      link-local address      An IP address having link-only
                              scope, indicated by "IPv6 Stateless
   Autoconfiguration" [13].  DHCP is a stateful counterpart to
   stateless autoconfiguration.  Note having the prefix
                              (FE80::0000/64), that both stateful and stateless
   autoconfiguration can be used concurrently in to reach
                              neighboring nodes attached to the same environment,
   leveraging the strengths
                              link.  Every interface has a link-local
                              address.

      message                 A unit of both mechanisms data carried in order a packet,
                              exchanged between DHCP agents and clients.

      neighbor                A node attached to reduce the
   cost of ownership and management same link.

      node                    A device that implements IP.

      packet                  An IP header plus payload.

      prefix                  The initial bits of network nodes.

   DHCP reduces the cost an address, or a set
                              of ownership by centralizing IP address that share the management same initial
                              bits.

      prefix length           The number of network resources such as IP addresses, routing information, OS
   installation information, directory service information, and other
   such information on a few DHCP servers, rather than distributing such
   information bits in local configuration files among each network node. a prefix.

      router                  A node that forwards IP packets not
                              explicitly addressed to itself.

6.2. DHCP is designed Terminology

   Terminology specific to DHCP can be easily extended found below.

      abort status              A status value returned to carry new configuration
   parameters through the addition of new DHCP "options" defined to
   carry this information.

   Those readers familiar with
                                application that has invoked a DHCP for IPv4 [6] will find
                                client operation, indicating anything
                                other than success.

      agent address             The address of a neighboring DHCP for IPv6
   provides Agent
                                on the same link as the DHCP client.

      binding                   A binding (or, client binding) is a superset
                                group of features, and benefits from server data records containing
                                the additional
   features of IPv6 and freedom from BOOTP [4]-backward compatibility
   constraints.  For more server's information about the differences between DHCP
   for IPv6 and DHCP for IPv4, see Appendix A.

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
                                addresses in [2].

   This document also makes use of internal conceptual variables
   to describe protocol behavior and external variables that an
   implementation must allow system administrators IA and any other
                                configuration information assigned to change.
                                the client.  A binding is indexed by the
                                tuple <DUID, IAID>.

      DHCP                      Dynamic Host Configuration Protocol
                                for IPv6.  The
   specific variable names, how their values change, terms DHCPv4 and how their
   settings influence protocol behavior DHCPv6
                                are provided to demonstrate
   protocol behavior.  An implementation is not required to have them used only in
   the exact form described here, so long as its external behavior contexts where it is
   consistent with that described in this document.

3. Background

   Related work in IPv6 that would best serve an implementor
                                necessary to study
   is avoid ambiguity.

      configuration parameter   An element of the IPv6 Specification [5], configuration
                                information set on the IPv6 Addressing Architecture [7],
   IPv6 Stateless Address Autoconfiguration [13], IPv6 Neighbor
   Discovery Processing [10], server and Dynamic Updates to DNS [15].  These
   specifications enable DHCP
                                delivered to build upon the IPv6 work client using DHCP.
                                Such parameters may be used to carry
                                information to be used by a node to provide
   both robust stateful autoconfiguration and autoregistration of DNS
   Host Names.

   The IPv6 Specification provides the base architecture
                                configure its network subsystem and design of
   IPv6.  A key point
                                enable communication on a link or
                                internetwork, for example.

      DHCP implementors to understand is that IPv6
   requires client (or client)   A node that every initiates requests on a link in the Internet have an MTU of 1280 octets
                                to obtain configuration parameters from
                                one or greater (in IPv4 the requirement more DHCP servers.

      DHCP domain               A set of links managed by DHCP and
                                operated by a single administrative
                                entity.

      DHCP server (or server)   A server is 68 octets).  This means that a UDP packet of 536 octets will always pass through an internetwork
   (less 40 octets for the IPv6 header), as long as there are no IP
   options prior node that responds to
                                requests from clients, and may or
                                may not be on the UDP header in same link as the packet.  But, IPv6 does not
   support fragmentation at routers, so
                                client(s).

      DHCP relay (or relay)     A node that fragmentation takes place
   end-to-end acts as an intermediary to
                                deliver DHCP messages between hosts.  If clients
                                and servers, and is on the same link as
                                a client.

      DHCP implementation needs to send agent (or agent)     Either a
   packet greater than 1500 octets it can either fragment DHCP server on the UDP packet
   into fragments of 1500 octets or less, same link as
                                a client, or use Path MTU Discovery [8]
   to determine the size of the packet that will traverse a network
   path. DHCP clients use Path MTU discovery when they have an address relay.

      DUID                      A DHCP unique identifier for a client.

      Identity association (IA) A collection of
   sufficient scope addresses assigned to reach the DHCP server.  If
                                a DHCP client does not client.  Each IA has an associated
                                IAID. An IA may have such 0 or more addresses
                                associated with it.

      Identity association identifier (IAID) An identifier for an address, that client MUST fragment its packets if the
   resultant message size is greater than IA,
                                chosen by the minimum 1280 octets.

   Path MTU Discovery for IPv6 client.  Each IA has an
                                IAID, which is supported for both UDP and TCP and
   can cause end-to-end fragmentation when the PMTU changes chosen to be unique among
                                all IAIDs for a
   destination.

   The IPv6 Addressing Architecture specification [7] defines the
   address scope IAs belonging to that can be used in an IPv6 implementation, and the
                                client.

      transaction-ID            An unsigned integer to match responses
                                with replies initiated either by a
                                client or server.

7. DHCP Constants

   This section describes various configuration architecture guidelines for network designers program and networking constants used
   by DHCP.

7.1. Multicast Addresses

   DHCP makes use of the IPv6 address space.  Two advantages of IPv6 are that support
   for following multicast is required, and nodes can create link-local addresses
   during initialization. addresses:

      All DHCP Agents address:  FF02::1:2 This means that a client can immediately use
   its link-local link-scoped multicast
                 address is used by clients to communicate with the
                 on-link agent(s) when they do not know those agents'
                 link-local address(es).  All agents (servers and a well-known
                 relays) are members of this multicast group.

      All DHCP Servers address:  FF05::1:3 This site-scoped multicast
                 address is used by clients or relays to communicate
                 with server(s), either because they want to begin
   communications send
                 messages to discover neighbors on all servers or because they do not know
                 the link.  For instance, server(s) unicast address(es).  Note that in order
                 for a client can send a Solicit message and locate a server or relay.

   IPv6 Stateless Address Autoconfiguration [13] (Addrconf) specifies
   procedures by which a node may autoconfigure addresses based on
   router advertisements [10], and the to use this address, it must have an
                 address of a valid lifetime sufficient scope to
   support renumbering of addresses on be reachable by the Internet.  In addition
                 server(s).  All servers within the
   protocol interaction by which a node begins stateless or stateful
   autoconfiguration is specified. site are members of
                 this multicast group.

7.2. UDP ports

   DHCP is one vehicle to perform
   stateful autoconfiguration.  Compatibility with addrconf is uses the following destination UDP [18] port numbers.  While
   source ports MAY be arbitrary, client implementations SHOULD permit
   their specification through a design
   requirement local configuration parameter to
   facilitate the use of DHCP (see Section 4).

   IPv6 Neighbor Discovery [10] is through firewalls.

      546        Client port.  Used by servers as the node discovery protocol in IPv6
   which replaces and enhances functions of ARP [11].  To understand
   IPv6 destination port
                 for messages sent to clients and Addrconf it is strongly recommended that implementors
   understand IPv6 Neighbor Discovery.

   Dynamic Updates relays.  Used by relay
                 agents as the destination port for messages sent to DNS [15] is a specification that supports
                 clients.

      547        Agent port.  Used as the
   dynamic update of DNS records destination port by clients
                 for both IPv4 and IPv6. messages sent to agents.  Used as the destination
                 port by relays for messages sent to servers.

7.3. DHCP can use message types

   DHCP defines the dynamic updates to DNS to integrate addresses and name space to
   not only support autoconfiguration, but also autoregistration following message types.  More detail on these
   message types can be found in
   IPv6.

4. Design Goals

    -  DHCP Section 9.  Message types 0 and
   TBD--255 are reserved and MUST be silently ignored.  The message code
   for each message type is a mechanism rather than a policy.  Network administrators
       set their administrative policies through the configuration
       parameters they place upon shown with the message name.

      SOLICIT (1)          The DHCP servers in the Solicit (or Solicit) message is used
                           by clients to locate servers.

      ADVERTISE (2)        The DHCP domain
       they're managing. Advertise (or Advertise) message is
                           used by servers responding to Solicits.

      REQUEST (3)          The DHCP Request (or Request) message is simply
                           used by clients to deliver request configuration
                           parameters
       according from servers.

      CONFIRM (4)          The DHCP Confirm (or Confirm) message is used
                           by clients to confirm that policy the addresses
                           assigned to each of an IA and the DHCP clients within lifetimes for
                           those addresses, as well as the
       domain.

    -  DHCP is compatible with IPv6 stateless autoconf [13].

    -  DHCP does not require manual current
                           configuration of network parameters
       on DHCP clients, except in cases where such configuration is
       needed for security reasons.  A node configuring itself using
       DHCP should require no user intervention.

    -  DHCP does not require a assigned by the
                           server on each link.  To allow for scale
       and economy, DHCP must work across DHCP relays.

    -  DHCP coexists with statically configured, non-participating nodes
       and with existing network protocol implementations.

    - to the client are still valid.

      RENEW (5)            The DHCP Renew (or Renew) message is used by
                           clients can operate on a link without IPv6 routers present.

    -  DHCP will provide to obtain the ability addresses assigned to renumber network(s) when
       required by network administrators [3].

    -  A DHCP client can make multiple, different requests
                           an IA and the lifetimes for those addresses,
                           as well as the current configuration
                           parameters when necessary from one or more DHCP
       servers at any time.

    -  DHCP will contain assigned by the appropriate time out and retransmission
       mechanisms server to efficiently operate in environments with high
       latency and low bandwidth characteristics.

5. Non-Goals

   This specification explicitly does not cover the following:

    -  Specification of
                           client.  A client sends a DHCP server Renew message to
                           the server protocol.

    -  How a DHCP server stores its DHCP data.

    -  How that originally assigned the IA
                           when the lease on an IA is about to manage a DHCP domain or DHCP server.

    -  How a expire.

      REBIND (6)           The DHCP relay Rebind (or Rebind) message is configured or what sort of information it may
       log.

6. Terminology

6.1. IPv6 Terminology

   IPv6 terminology relevant
                           used by clients to this specification from obtain the IPv6
   Protocol [5], IPv6 Addressing Architecture [7], and IPv6 Stateless
   Address Autoconfiguration [13] is included below.

      address                 An IP layer identifier for an interface or
                              a set of interfaces.

      unicast address         An identifier for a single interface.
                              A packet sent to a unicast address is
                              delivered addresses
                           assigned to an IA and the interface identified by
                              that address.

      multicast address       An identifier lifetimes for a set of interfaces
                              (typically belonging
                           those addresses, as well as the current
                           configuration parameters assigned by the
                           server to different nodes). the client.  A packet sent to clients sends a multicast address is
                              delivered
                           Rebind message to all interfaces identified by
                              that address.

      host                    Any node that available DHCP servers
                           when the lease on an IA is not a router.

      IP                      Internet Protocol Version 6 (IPv6). about to expire.

      REPLY (7)            The
                              terms IPv4 and IPv6 are used only in
                              contexts where it DHCP Reply (or Reply) message is necessary used
                           by servers responding to avoid
                              ambiguity.

      interface               A node's attachment Request, Confirm,
                           Renew, Rebind, Release and Decline messages.
                           In the case of responding to a link.

      link                    A communication facility Request,
                           Confirm, Renew or medium over
                              which nodes can communicate at Rebind message, the link
                              layer, i.e., Reply
                           contains configuration parameters destined
                           for the layer immediately below
                              IP. Examples are Ethernet (simple or
                              bridged); Token Ring; PPP links, X.25,
                              Frame Relay, or ATM networks; and Internet client.

      RELEASE (8)          The DHCP Release (or higher) layer "tunnels", such as
                              tunnels over IPv4 Release) message is used
                           by clients to return one or IPv6 itself.

      link-layer identifier   A link-layer identifier for an interface.
                              Examples include IEEE 802 more IP addresses for
                              Ethernet
                           to servers.

      DECLINE (9)          The DHCP Decline (or Decline) message is used
                           by clients to indicate that the client has
                           determined that one or Token Ring network interfaces,
                              and E.164 more addresses for ISDN links.

      link-local address      An IP address having link-only
                              scope, indicated by having in an
                           IA are already in use on the prefix
                              (FE80::0000/64), link to which
                           the client is connected.

      RECONFIG-INIT (10)   The DHCP Reconfigure-init (or
                           Reconfigure-init) message is sent by
                           server(s) to inform client(s) that the
                           server(s) has new or updated configuration
                           parameters, and that can be the client(s) are to
                           initiate a Request/Reply transaction with the
                           server(s) in order to receive the updated
                           information.

      RELAY-FORW (11)      The DHCP Relay-forward (or Relay-forward)
                           message is used by relays to reach
                              neighboring nodes attached forward
                           client messages to servers.  The client
                           message is encapsulated in an option in the same
                              link.  Every interface has
                           Relay-forward message.

      RELAY-REPL (12)      The DHCP Relay-reply (or Relay-reply)
                           message is used by servers to send messages
                           to clients through a link-local
                              address. relay.  The server
                           encapsulates the client message                 A unit of data carried as an option
                           in a packet, the Relay-reply message, which the relay
                           extracts and forwards to the client.

7.4. Error Values

   This section describes error values exchanged between DHCP agents
   implementations.

7.4.1. Generic Error Values

   The following symbolic names are used between client and clients.

      neighbor                A node attached server
   implementations to the same link.

      node                    A device that implements IP.

      packet                  An IP header plus payload.

      prefix convey error conditions.  The initial bits of an address, or a set
                              of IP address following table
   contains the actual numeric values for each name.  Note that share the same initial
                              bits.

      prefix length
   numeric values do not start at 1, nor are they consecutive.  The number of bits
   errors are organized in a prefix.

      router                  A node that forwards IP packets not
                              explicitly addressed to itself.

6.2. DHCP Terminology

   Terminology specific to DHCP can be found below.

      abort status              A status value returned logical groups.

   _______________________________________________________________
   |Error_Name___|Error_ID|_Description_________________________|_
   |Success______|00______|_Success_____________________________|_
   |UnspecFail___|16______|_Failure,_reason_unspecified_________|_
   |AuthFailed___|17______|_Authentication_failed_or_nonexistent|_
   |PoorlyFormed_|18______|_Poorly_formed_message_______________|_
   |Unavail______|19______|_Addresses_unavailable_______________|_

7.4.2. Server-specific Error Values

   The following symbolic names are used by server implementations to the
                                application that has invoked a DHCP
                                client operation, indicating anything
                                other than success.

      agent address
   convey error conditions to clients.  The address of a neighboring DHCP Agent
                                on the same link as following table contains the DHCP client.

      binding                   A binding (or, client binding) is
   actual numeric values for each name.
   _______________________________________________________________
   |Error_Name____|Error_ID|_Description________________________|_
   |NoBinding_____|20______|_Client_record_(binding)_unavailable|_
   |ConfNoMatch___|21______|_Client_record_Confirm_not_match_IA_|_

   |RenwNoMatch___|22______|_Client_record_Renew_not_match_IA___|_
   |RebdNoMatch___|23______|_Client_record_Rebind_not_match_IA__|_
   |InvalidSource_|24______|_Invalid_Client_IP_address__________|_
   |NoServer______|25______|_Relay_cannot_find_Server_Address___|_
   |ICMPError_____|64______|_Server_unreachable_(ICMP_error)____|_

7.5. Configuration Variables

   This section presents a
                                group table of client and server data records containing configuration
   variables and the server's information about default or initial values for these variables.  The
   client-specific variables MAY be configured on the
                                addresses in an IA server and any other
                                configuration information assigned MAY be
   delivered to the client.  A binding is indexed by the
                                tuple <prefix, DUID>, where client through the 'prefix'
                                is "DHCP Retransmission Parameter
   Option" in a prefix assigned to Reply message.

   _________________________________________________________________________
   |Parameter__________|Default|_Description______________________________|_
   |MIN_SOL_DELAY______|1______|_MIN_(secs)_to_delay_1st_mesg_____________|_
   |MAX_SOL_DELAY______|5______|_MAX_(secs)_to_delay_1st_mesg_____________|_
   |ADV_MSG_TIMEOUT____|500____|_SOL_Retrans_timer_(msecs)________________|_
   |ADV_MSG_MAX________|30_____|_MAX_timer_value_(secs)___________________|_
   |SOL_MAX_ATTEMPTS___|-1_____|_MAX_attempts_(-1_=_infinite)_____________|_
   |REP_MSG_TIMEOUT____|250____|_Retrans_timer_(msecs)_for_Reply__________|_
   |QRY_MSG_ATTEMPTS___|10_____|_MAX_Request/Confirm/Renew/Rebind_attempts|_
   |REL_MSG_ATTEMPTS___|5______|_MAX_Release/Decline_attempts_____________|_
   |RECREP_MSG_TIMEOUT_|2000___|_Retrans_timer_(msecs)____________________|_
   |REC_MSG_ATTEMPTS___|10_____|_Reconfigure_attempts_____________________|_
   |REC_THRESHOLD______|100____|_%_of_required_clients____________________|_
   |SRVR_PREF_WAIT_____|2______|_Advertise_Collect_timer_(secs)___________|_

8. Overview

   This section provides a general overview of the link to
                                which interaction between
   the client functional entities of DHCP. The overview is attached organized as a
   series of questions and 'DUID'
                                is the DUID from the IA in the binding.

                                DISCUSSION:

                                   The indexing answers.  Details of an IA by <prefix,
                                   DUID> is still under discussion. DHCP                      Dynamic Host Configuration Protocol
                                for IPv6.  The terms DHCPv4 such as message
   formats and DHCPv6
                                are used only retransmissions can be found in contexts where later sections of this
   document.

8.1. How does a node know to use DHCP?

   An unconfigured node determines that it is
                                necessary to avoid ambiguity. use DHCP for
   configuration parameter   An element of an interface by detecting the configuration
                                information set presence (or absence)
   of routers on the server and
                                delivered link.  If router(s) are present, the node examines
   router advertisements to the client using DHCP.
                                Such parameters may determine if DHCP should be used to carry
                                information to be used by a
   configure the interface.  If there are no routers present, then
   the node MUST use DHCP to configure its network subsystem the interface.  Details of
   this process can be found in neighbor discovery [16] and
                                enable communication on a link or
                                internetwork, for example.

      DHCP stateless
   autoconfiguration [20].

8.2. What if the client (or client)   A node that initiates requests and server(s) are on a link
                                to obtain configuration parameters from different links?

   Use of DHCP in such environments requires one or more DHCP servers.

      DHCP domain               A relays
   be set of links managed by DHCP and
                                operated by up on the client's link, because a single administrative
                                entity. client may only have a
   link-local address.  Relays receive messages from the client and
   forward them to some set of servers within the DHCP server (or server)   A server domain.  The
   client message is a node that responds forwarded verbatim as an option in the message
   from the relay to
                                requests the server.  A relay will include one of its own
   addresses (of sufficient scope) from clients, and may or
                                may not be the interface on the same link
   as the
                                client(s).

      DHCP relay (or relay)     A node that acts client, as an intermediary well as the prefix length of that address, in its
   message to
                                deliver DHCP the server.  Servers receiving the forwarded traffic
   use this information to aid in selecting configuration parameters
   appropriate to the client's link.

   Servers use relays to forward messages between clients
                                and servers, and is on to clients.  The message
   intended for the same link client is carried as
                                a client.

      DHCP agent (or agent)     Either a DHCP server on an option in the message to the same link as
                                a client, or a DHCP
   relay.

      DUID                      A DHCP unique identifier for a client.

                                DISCUSSION:

                                   Rules for choosing a DUID are TBD.

      Identity association (IA) A collection of addresses assigned  The relay extracts the message from the option and forwards
   it to
                                a the client.  Each IA has an associated
                                DUID. An IA may have 0 or more addresses
                                associated with it.

      transaction-ID            An unsigned integer  Servers use the relay's address as the destination
   to match responses
                                with replies initiated either forward client-destined messages for final delivery by a the relay.

   Relays forward client or server.

7. DHCP Constants

   This section describes various program and networking constants used
   by DHCP.

7.1. Multicast Addresses

   DHCP makes use messages to servers using some combination
   of the following multicast addresses: All DHCP Agents address:  FF02::1:2 This link-scoped Servers site-local multicast
                 address is used by clients to communicate with the
                 on-link agent(s) when they do not know those agents'
                 link-local address(es).  All agents (servers and
                 relays) are members address, some other
   (perhaps a combination) of this site-local multicast group.

      All addresses set up
   within the DHCP Servers address:  FF05::1:3 This site-scoped multicast
                 address is used by clients or relays to communicate
                 with server(s), either because they want to send
                 messages domain to all include the servers in that domain, or because they do not know
                 the server(s) a
   list of unicast address(es). addresses for servers.  The network administrator
   makes relay configuration decisions based upon the topological
   requirements (scope) of the DHCP domain they are managing.  Note
   that in order if the DHCP domain spans more than the site-local scope, then
   the relays MUST be configured with global addresses for a client to use this address, it must have an
                 address of sufficient scope the client's
   link so as to be reachable by the
                 server(s).  All servers within outside the site are members of
                 this multicast group.

   DISCUSSION:

      Is there relays' site-local
   environment.

8.3. How does a requirement for client request configuration parameters from servers?

   To request configuration parameters, the client forms a site-scoped "All DHCP Clients"
      multicast address, Request
   message, and sends it to be used the server either directly (the server is
   on the same link as the default in sending
      Reconfigure messages.

7.2. UDP ports

   DHCP uses client) or indirectly (through the following destination UDP [12] port numbers.  While
   source ports MAY be arbitrary, on-link
   relay).  The client implementations SHOULD permit
   their specification through MAY include a local configuration parameter Option Request Option 18.4 (ORO)
   along with other options to
   facilitate request specific information from the use of DHCP through firewalls.

      546        Client port.  Used by servers as
   server.  Note that the destination port
                 for client MAY form multiple Request messages sent to clients
   and relays.  Used by relay
                 agents as the destination port for messages sent send each of them to
                 clients.

      547        Agent port.  Used as different servers to request potentially
   different information (perhaps based upon what was advertised) in
   order to satisfy its needs.  As a client's needs may change over time
   (perhaps based upon an application's requirements), the destination port by clients
                 for client may
   form additional Request messages sent to agents.  Used request additional information as the destination
                 port by relays for
   it is needed.

   The server(s) respond with Reply messages sent to servers.

7.3. DHCP message types

   DHCP defines containing the following message types.  More detail on these
   message types requested
   configuration parameters, which can be found in Section 9.  Message types 0 and
   TBD--255 are reserved and MUST be silently ignored.  The message code
   for each message type is shown with include status information
   regarding the message name.

      SOLICIT (1)     The DHCP Solicit (or Solicit) message is used information requested by
                      clients to locate servers.

      ADVERTISE (2) the client.  The DHCP Advertise (or Advertise) message Reply MAY
   also include additional information.

8.4. How do clients and servers identify and manage addresses?

   Servers and clients manage addresses in groups called "identity
   associations." Each identity association (IA) is used
                      by identified using
   a unique identifier.  An identity association may contain one or
   more IPv6 addresses.  DHCP servers responding assign addresses to Solicits.

      REQUEST (3)     The identity
   associations.  DHCP Request (or Request) message is used by clients use the addresses in an identity
   association to request configuration parameters from
                      servers.

      CONFIRM (4)     The DHCP Confirm (or Confirm) message configure interfaces.  There is used by
                      clients to confirm always at least one
   identity association per interface that the addresses assigned a client wishes to configure.
   Each address in an IA has its own preferred and valid lifetime.  Over
   time, the lifetimes for those addresses,
                      as well as server may change the current configuration parameters
                      assigned characteristics of the addresses in
   an IA; for example, by changing the preferred or valid lifetime for
   an address in the IA. The server may also add or delete addresses
   from an IA; for example, deleting old addresses and adding new
   addresses to the renumber a client.  A client are still
                      valid.

      RENEW (5)       The DHCP Renew (or Renew) message is used by
                      clients to obtain can request the current
   list of addresses assigned to an IA
                      and the lifetimes for those addresses, as well as
                      the current configuration parameters assigned by
                      the from a server to through an exchange
   of protocol messages.

8.5. Can a client release its assigned addresses before the client. lease
   expires?

   A client sends forms a Renew
                      message to the server that originally assigned the
                      IA when Release message, including options identifying
   the lease on an IA is about to expire.

      REBIND (6) be released.  The DHCP Rebind (or Rebind) message is used by
                      clients to obtain client sends the addresses assigned Release to an IA
                      and the lifetimes for those addresses, as well
                      as the current configuration parameters server
   which assigned
                      by the server addresses to the client.  A clients sends client initially.  If that
   server cannot be reached after a
                      Rebind message to all available DHCP servers when certain number of attempts (see
   section 7.5), the client can abandon the lease on an IA is about to expire.

      REPLY (7)       The DHCP Reply (or Reply) message is used by
                      servers responding to Request, Confirm, Renew,
                      Rebind, Release and Decline messages. attempt.  In this
   case, the case
                      of responding to a Request, Confirm, Renew or
                      Rebind message, the Reply contains configuration
                      parameters destined for address(es) in the client.

      RELEASE (8)     The DHCP Release (or Release) message is used by
                      clients to return one or more IP addresses to
                      servers.

      DECLINE (9)     The DHCP Decline (or Decline) message is used IA will be reclaimed by
                      clients to indicate that the server(s)
   when the lifetimes on the addresses expire.

8.6. What if the client has determined
                      that determines one or more of its assigned addresses in an IA
   are already being used by another client?

   If the client determines through a mechanism like Duplicate Address
   Detection [20] that the address it was assigned by the server is
   already in use on the link to which by another client, the client is connected.

      RECONFIG (10)   The DHCP Reconfigure-init (or Reconfigure-init) will send a Decline
   message is sent by server(s) to inform
                      client(s) that the server(s) has server.

8.7. How are clients notified of server configuration changes?

   There are two possibilities.  Either the clients discover the new
   information when they revisit the server(s) to request additional
   configuration information/extend the lifetime on an address.  or updated
   through a server-initiated event known as a reconfigure event.

   The reconfiguration feature of DHCP offers network administrators
   the opportunity to update configuration parameters, and that information on DHCP clients
   whenever necessary.  To signal the need for client reconfiguration,
   the server will unicast a Reconfigure-init message to each client
   individually.  A Reconfigure-init is a trigger which will cause the
   client(s)
                      are to initiate a standard Request/Reply transaction exchange with the server(s)
   server in order to receive acquire the new or updated
                      information.

      RELAY-FORW (11) The addresses.

9. Message Formats

   Each DHCP Relay-forward (or Relay-forward) message
                      is used by relays to forward client has an identical fixed format header; some messages to
                      servers.  The client message
   also allow a variable format area for options.  Not all fields in
   the header are used in every message.  In this section, every field
   is encapsulated described for every message and fields that are not used in an
                      option a
   message are marked as "unused".  All unused fields in a message MUST
   be transmitted as zeroes and ignored by the receiver of the Relay-forward message.

      RELAY-REPL (12)

   The DHCP Relay-reply (or Relay-reply) message
                      is used header:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    msg-type   |  preference   |         transaction-ID        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                   client-link-local-address                   |
     |                          (16 octets)                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         server-address                        |
     |                          (16 octets)                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                                                               .
     .                            options                            .
     |                          (variable)                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

9.1. DHCP Solicit Message Format

      msg-type                    SOLICIT

      preference                  (unused) MUST be 0

      transaction-ID              An unsigned integer generated by servers to send messages to clients
                      through a relay.  The server encapsulates the
                                  client message as an option in the Relay-reply
                      message, which the relay extracts and forwards to
                      the client.

7.4. Error Values

   This section describes error values exchanged between DHCP
   implementations.

7.4.1. Generic Error Values

   The following symbolic names are used between client and server
   implementations to convey error conditions. identify this Solicit
                                  message.

      client-link-local-address   The following table
   contains link-local address of the actual numeric values
                                  interface for each name.  Note that which the
   numeric values do not start at 1, nor are they consecutive.  The
   errors are organized in logical groups.

   _______________________________________________________________
   |Error_Name___|Error_ID|_Description_________________________|_
   |Success______|00______|_Success_____________________________|_
   |UnspecFail___|16______|_Failure,_reason_unspecified_________|_
   |AuthFailed___|17______|_Authentication_failed_or_nonexistent|_
   |PoorlyFormed_|18______|_Poorly_formed_message_______________|_
   |Unavail______|19______|_Addresses_unavailable_______________|_

7.4.2. Server-specific Error Values

   The following symbolic names are used by server implementations client is
                                  using DHCP.

      server-address              (unused) MUST be 0

      options                     See section 18.

9.2. DHCP Advertise Message Format

      msg-type                    ADVERTISE

      preference                  An unsigned integer indicating a
                                  server's willingness to
   convey error conditions provide
                                  service to clients.  The following table contains the
   actual numeric values for each name.
   _______________________________________________________________
   |Error_Name____|Error_ID|_Description________________________|_
   |NoBinding_____|20______|_Client_record_(binding)_unavailable|_
   |ConfNoMatch___|21______|_Client_record_Confirm_not_match_IA_|_

   |RenwNoMatch___|22______|_Client_record_Renew_not_match_IA___|_
   |RebdNoMatch___|23______|_Client_record_Rebind_not_match_IA__|_
   |InvalidSource_|24______|_Invalid_Client_IP_address__________|_
   |NoServer______|25______|_Relay_cannot_find_Server_Address___|_
   |ICMPError_____|64______|_Server_unreachable_(ICMP_error)____|_

7.5. Configuration Variables

   This section presents a table client.

      transaction-ID              An unsigned integer used to identify
                                  this Advertise message.  Copied from
                                  the client's Solicit message.

      client-link-local-address   The IP link-local address of the
                                  client and server configuration
   variables and interface from which the default or initial values for these variables. client
                                  issued the Solicit message.

      server-address              The
   client-specific variables MAY be configured on IP address of the server and MAY that
                                  generated this message.  If the DHCP
                                  domain crosses site boundaries, then
                                  this address MUST be
   delivered to globally-scoped.

      options                     See section 18.

9.3. DHCP Request Message Format

      msg-type                    REQUEST

      preference                  (unused) MUST be 0

      transaction-ID              An unsigned integer generated by the
                                  client through the "DHCP Retransmission Parameter
   Option" in a Reply used to identify this Request
                                  message.

   _________________________________________________________________________
   |Parameter__________|Default|_Description______________________________|_
   |MIN_SOL_DELAY______|1______|_MIN_(secs)_to_delay_1st_mesg_____________|_
   |MAX_SOL_DELAY______|5______|_MAX_(secs)_to_delay_1st_mesg_____________|_
   |ADV_MSG_TIMEOUT____|500____|_SOL_Retrans_timer_(msecs)________________|_
   |ADV_MSG_MAX________|30_____|_MAX_timer_value_(secs)___________________|_
   |SOL_MAX_ATTEMPTS___|-1_____|_MAX_attempts_(-1_=_infinite)_____________|_
   |REP_MSG_TIMEOUT____|250____|_Retrans_timer_(msecs)_for_Reply__________|_
   |QRY_MSG_ATTEMPTS___|10_____|_MAX_Request/Confirm/Renew/Rebind_attempts|_
   |REL_MSG_ATTEMPTS___|5______|_MAX_Release/Decline_attempts_____________|_
   |RECREP_MSG_TIMEOUT_|2000___|_Retrans_timer_(msecs)____________________|_
   |REC_MSG_ATTEMPTS___|10_____|_Reconfigure_attempts_____________________|_
   |REC_REP_MIN________|5______|_Minimum_pause_interval_(secs)____________|_
   |REC_REP_MAX________|7200___|_Maximum_pause_interval_(secs)____________|_
   |REC_THRESHOLD______|100____|_%_of_required_clients____________________|_
   |SRVR_PREF_WAIT_____|2______|_Advertise_Collect_timer_(secs)___________|_

8. Overview

   This section provides a general overview

      client-link-local-address   The link-local address of the interaction between client
                                  interface from which the functional entities of DHCP. client will
                                  issue the Request message.

      server-address              The overview is organized as a
   series of questions and answers.  Details of DHCP such as message
   formats and retransmissions can be found in later sections IP address of this
   document.

8.1. How does a node know the server to use DHCP?

   An unconfigured node determines that it which
                                  the this message is to use DHCP for
   configuration of directed, copied
                                  from an interface Advertise message.

      options                     See section 18.

9.4. DHCP Confirm Message Format

      msg-type                    CONFIRM

      preference                  (unused) MUST be 0

      transaction-ID              An unsigned integer generated by detecting the presence (or absence)
                                  client used to identify this Confirm
                                  message.

      client-link-local-address   The link-local address of routers on the link.  If router(s) are present, client
                                  interface from which the node examines
   router advertisements to determine if client will
                                  issue the Confirm message.

      server-address              MUST be zero.

      options                     See section 18.

9.5. DHCP should Renew Message Format

      msg-type                    RENEW

      preference                  (unused) MUST be 0

      transaction-ID              An unsigned integer generated by the
                                  client used to
   configure identify this Renew
                                  message.

      client-link-local-address   The link-local address of the interface.  If there are no routers present, then client
                                  interface from which the node MUST use DHCP to configure client will
                                  issue the interface.  Detail on Renew message.

      server-address              The IP address of the server to which
                                  this process can Renew message is directed, which
                                  MUST be found in neighbor discovery [10] and stateless
   autoconfiguration [13].

8.2. What if the client and server(s) are on different links?

   Use address of DHCP the server from
                                  which the IAs in such environments requires one or more this message were
                                  originally assigned.

      options                     See section 18.

9.6. DHCP relays Rebind Message Format

      msg-type                    REBIND

      preference                  (unused) MUST be set up on 0

      transaction-ID              An unsigned integer generated by the client's link, because a
                                  client may only have a used to identify this Rebind
                                  message.

      client-link-local-address   The link-local address.  Relays receive messages from address of the client and
   forward them to some set of servers within
                                  interface from which the DHCP domain.  The client message is forwarded verbatim as an option in will
                                  issue the message
   from Rebind message.

      server-address              MUST be zero.

      options                     See section 18.

9.7. DHCP Reply Message Format

      msg-type                    REPLY

      preference                  An unsigned integer indicating a
                                  server's willingness to provide
                                  service to the relay client.

      transaction-ID              An unsigned integer used to identify
                                  this Reply message.  Copied from the server.  A relay will include one
                                  client's Request, Confirm, Renew or
                                  Rebind message.

      client-link-local-address   The link-local address of its own
   addresses (of sufficient scope) from the
                                  interface on the same link
   as the client, as well as for which the prefix length client is
                                  using DHCP.

      server-address              The IP address of that address, in its
   message to the server.  Servers receiving
                                  If the forwarded traffic
   use DHCP domain crosses site
                                  boundaries, then this information to aid in selecting configuration parameters
   appropriate to the client's link.

   Servers use relays to forward messages to clients.  The message
   intended for address MUST be
                                  globally-scoped.

      options                     See section 18.

9.8. DHCP Release Message Format

      msg-type                    RELEASE

      preference                  (unused) MUST be 0

      transaction-ID              An unsigned integer generated by the
                                  client is carried as an option in the message used to the
   relay. identify this Release
                                  message.

      client-link-local-address   The relay extracts client's link-local address for
                                  the message interface from which the optin and forwards it
   to the client.  Servers use client
                                  will send the relay's Release message.

      server-address              The IP address as of the destination to
   forward client-destined messages for final delivery server that
                                  assigned the IA.

      options                     See section 18.

9.9. DHCP Decline Message Format

      msg-type                    DECLINE

      preference                  (unused) MUST be 0

      transaction-ID              An unsigned integer generated by the relay.

   Relays forward
                                  client messages used to servers using some combination
   of the All DHCP Servers site-local multicast address, some other
   (perhaps a combination) of site-local multicast addresses set up
   within identify this Decline
                                  message.

      client-link-local-address   The client's link-local address for
                                  the DHCP domain to include interface from which the servers in that domain, or a
   list of unicast addresses for servers.  The network administrator
   makes relay configuration decisions based upon client
                                  will send the topological
   requirements (scope) Decline message.

      server-address              The IP address of the DHCP domain they are managing.  Note server that if
                                  assigned the addresses.

      options                     See section 18.

9.10. DHCP domain spans more than Reconfigure-init Message Format

      msg-type                    RECONFIG-INIT

      preference                  (unused) MUST be 0

      transaction-ID              (unused) MUST be 0

      client-link-local-address   (unused) MUST be 0

      server-address              The IP address of the site-local scope, then DHCP server
                                  issuing the relays Reconfigure-init message.
                                  MUST be configured with global addresses for the client's
   link so as of sufficient scope to be
                                  reachable by all clients.

      options                     See section 18.

10. Relay messages

   Relay agents exchange messages with servers outside the relays' site-local
   environment.

8.3. How does a client request configuration parameters from servers?

   To request configuration parameters, the client forms a Request
   message, to forward messages
   between clients and sends it servers that are not connected to the server either directly (the server is
   on the same link as the client) or indirectly (through the on-link
   relay).  The client MAY include a Option Request Option 16.3 (ORO)
   along with other options to request specific information from the
   server.  Note that the client MAY form multiple Request messages link.

10.1. Relay-forward message

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    msg-type   | prefix length |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                         relay-address                         |
     |                                                               |
     |                               |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |            options (variable number and send each length)   ....        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      msg-type        RELAY-FORW

      prefix-length   The length of them to different servers to request potentially
   different information (perhaps based upon what was advertised) the prefix in
   order to satisfy its needs.  As a client's needs may change over time
   (perhaps based upon an application's requirements), the client may
   form additional Request messages address in the
                      "relay-address" field.

      relay-address   An address assigned to request additional information as
   it is needed.

   The server(s) respond with Reply messages containing the requested
   configuration parameters, interface through which can include status information
   regarding
                      the information requested by message from the client.  The Reply MAY
   also client was received.

      options         MUST include additional information, such as a reconfiguration event
   multicast group for the client to join to monitor reconfiguration
   events, as described in "Client message option"; see
                      section 8.7.

8.4. How do clients and servers identify and manage addresses?

   Servers 18.5.

10.2. Relay-reply message

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    msg-type   | prefix length |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                         relay-address                         |
     |                                                               |
     |                               |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |            options (variable number and clients manage addresses length)   ....        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      msg-type        RELAY-REPL

      prefix-length   The length of the prefix in groups called "identity
   associations." Each identity associations is identified using the address in the
                      "relay-address" field.

      relay-address   An address identifying the interface through which
                      the message from the server should be forwarded;
                      copied from the "relay-forward" message.

      options         MUST include a "Server message option"; see
                      section 18.6.

11. DHCP unique identifier.  An identity association may contain one or
   more IPv6 addresses. identifier (DUID)

   Each DHCP client has a DUID. DHCP servers assign addresses use DUIDs to identity
   associations.  DHCP identify
   clients use for the addresses in an identity
   association to configure interfaces.  There is always at least one
   identity association per interface that a client wishes to configure.
   Each address in an IA has its own preferred selection of configuration parameters and valid lifetime.  Over
   time, the server may change in
   the characteristics association of IAs with clients.  See section 18.2 for the addresses
   representation of a DUID in
   an IA; a DHCP message.

   DISCUSSION:

      The syntax, rules for example, by changing the preferred or valid lifetime selecting and requirements for
   an address gloabl
      uniqueness in the IA. DUIDs are TBD.

      The server may also add or delete addresses
   from DUID is carried in an IA; for example, deleting old addresses option because it may be variable
      length and because it is not required in all DHCP options
      (e.g., messages sent by servers need not include a DUID).

12. Identity association

   An "identity-association" (IA) is a construct through which a server
   and adding new
   addresses to renumber a client.  A client can request the current
   list identify, group and manage IPv6 addresses.  Each IA
   consists of addresses assigned to an IA from IAID and a server through an exchange list of protocol messages.

8.5. Can a client release its assigned associated IPv6 addresses before the lease
   expires? (the list
   may be empty).  A client forms a Release message, including options identifying associates an IA with one of its interfaces
   and uses the IA to be released.  The client sends the Release to the server
   which assigned the obtain IPv6 addresses to the client initially.  If for that
   server cannot be reached after interface from a certain number of attempts (see
   server.

   See section 7.5), the client can abandon the Release attempt.  In this
   case, the address(es) in 18.3 for the representation of an IA will be reclaimed by the server(s)
   when the lifetimes on the addresses expire.

8.6. What if the in a DHCP message.

13. DHCP Server Solicitation

   This section describes how a client determines one or more locates servers.  The behavior
   of its assigned addresses
   are already being used by another client?

   If the client determines through a mechanism like Duplicate Address
   Detection [13] that the address it was assigned by the and server implementations is
   already in use by another client, the client will form a Decline
   message, including discussed, along with the option carrying
   messages they use.

13.1. Solicit Message Validation

   Clients MUST silently discard any received Solicit messages.

   Agents MUST silently discard any received Solicit messages if the in-use
   "client-link-local-address" field does not contain a valid link-local
   address.

13.2. Advertise Message Validation

   Servers MUST discard any received Advertise messages.

   Clients MUST discard any Advertise messages that meet any of the
   following criteria:

     o The
   option's status "Transaction-ID" field MUST be set to value does not match the value reflecting the "in
   use" status of
       client used in its Solicit message.

     o The "client-link-local-address" field value does not match the address.

8.7. How are clients notified
       link-local address of server configuration changes?

   There are two possibilities.  Either the clients interface upon which the client sent
       the Solicit message.

13.3. Client Behavior

   Clients use the Solicit message to discover the new
   information when they revisit the server(s) DHCP servers configured
   to request additional
   configuration information/extend the lifetime serve addresses on an address.  or
   through a server-initiated event known as a reconfigure event.

   The reconfiguration feature of DHCP offers network administrators the opportunity link to update configuration information on DHCP clients
   whenever necessary.  To signal which the need for client reconfiguration, is attached.

13.3.1. Creation and sending of the server will unicast a Reconfigure-init Solicit message to each
   client individually.

   The server may use multicast client sets the "msg-type" field to signal SOLICIT, and places the
   reconfiguration
   link-local address of the interface it wishes to multiple clients simultaneously.  (Note that
   there is no mechanism defined configure in the protocol to guarantee that
   every
   "client-link-local-address" field.

   The client actually performs generates a reconfiguration transaction ID inserts this value in response to a
   multicast reconfigure-init message.)  A Reconfigure-init is the
   "transaction-ID" field.

   The client includes a trigger
   which will cause DUID option to identify itself to the client(s) server.
   The client MUST include options for any IAs to initiate a standard Request/Reply
   exchange with which the server in order client is
   expecting to acquire have the new or updated server assign addresses.

9. Message Formats

   Each DHCP message has an identical fixed format header; some messages
   also allow  Because the client
   does not have any IAs with addresses when sending a variable format area for options.  Not Solicit message,
   all fields in of the header are used IAs MUST be empty.  The client MAY include an Option
   Request Option in every the Solicit message.  In this section, every field
   is described for every message and fields that are not used in a
   message are marked  The client MUST NOT include
   any other options except those specifically allowed as "unused". defined by
   specific options.

   The client sends the Solicit message to the All unused fields in DHCP Agents
   multicast address, destination port 547.  The source port selection
   can be arbitrary, although it SHOULD be possible using a client
   configuration facility to set a specific source port value.

13.3.2. Time out and retransmission of Solicit Messages

   The client's first Solicit message on the interface MUST be transmitted as zeroes and ignored delayed
   by a random amount of time between the receiver interval of MIN_SOL_DELAY and
   MAX_SOL_DELAY. This random delay desynchronizes clients which start
   at the message. same time (e.g., after a power outage).

   The DHCP message header:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    msg-type   |  preference   |         transaction-ID        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                   client-link-local-address                   |
     |                          (16 octets)                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         server-address                        |
     |                          (16 octets)                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                                                               .
     .                            options                            .
     |                          (variable)                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

9.1. DHCP Solicit Message Format

      msg-type                    SOLICIT

      preference                  (unused) MUST be 0

      transaction-ID              An unsigned integer generated by client waits ADV_MSG_TIMEOUT, collecting Advertise messages.
   If no Advertise messages are received, the client used to identify this Solicit
                                  message.

      client-link-local-address   The link-local address of retransmits
   the
                                  interface for Solicit, and doubles the ADV_MSG_TIMEOUT value.  This process
   continues until either one or more Advertise messages are received or
   ADV_MSG_TIMEOUT reaches the ADV_MSG_MAX value.  Thereafter, Solicits
   are retransmitted every ADV_MSG_MAX until SOL_MAX_ATTEMPTS have been
   made, at which time the client is
                                  using DHCP.

      server-address              (unused) MUST be 0

      options                     See section 16.

9.2. DHCP Advertise Message Format

      msg-type                    ADVERTISE

      preference                  An unsigned integer indicating a
                                  server's willingness MAY choose to provide
                                  service stop trying to DHCP
   configure the client.

      transaction-ID interface.  An unsigned integer used event external to identify
                                  this Advertise message.  Copied from
                                  the client's Solicit message.

      client-link-local-address   The IP link-local address of the
                                  client interface from which the client
                                  issued the Solicit message.

      server-address              The IP address of the server that
                                  generated this message.  If DHCP is required
   to restart the DHCP
                                  domain crosses site boundaries, then
                                  this address MUST be globally-scoped.

      options                     See section 16.

9.3. configuration process.  A DHCP Request Message Format

      msg-type                    REQUEST

      preference                  (unused) MUST be 0

      transaction-ID              An unsigned integer generated by the client used MAY,
   alternatively, choose to identify this Request
                                  message.

      client-link-local-address   The link-local address of continue sending Solicit messages at the client
                                  interface from which
   ADV_MSG_MAX interval.

   Default and initial values for MIN_SOL_DELAY, MAX_SOL_DELAY,
   ADV_MSG_TIMEOUT, AND ADV_MSG_MAX are documented in section 7.5.

13.3.3. Receipt of Advertise messages

   Upon receipt of one or more validated Advertise messages, the client will
                                  issue
   selects one or more Advertise messages based upon the Request message.

      server-address              The IP address of following
   criteria.

    -  Those Advertise messages with the highest server to which
                                  the this message is directed, copied
                                  from an Advertise message.

      options                     See section 16.

9.4. DHCP Confirm Message Format

      msg-type                    CONFIRM preference                  (unused) MUST be 0

      transaction-ID              An unsigned integer generated by the
                                  client used to identify this Confirm
                                  message.

      client-link-local-address   The link-local address
       value (see section 19.4) are preferred over all other Advertise
       messages.

    -  Within a group of Advertise messages with the same server
       preference value, a client
                                  interface from which the client will
                                  issue MAY select those servers whose
       Advertise messages advertise information of interest to
       the Confirm message.

      server-address              MUST be zero.

      options                     See section 16.

9.5. DHCP Renew Message Format

      msg-type                    RENEW

      preference                  (unused) MUST client.  For example, one server may be 0

      transaction-ID              An unsigned integer generated by advertising the
                                  client used to identify this Renew
                                  message.

      client-link-local-address   The link-local
       availability of IP addresses which have an address scope of
       interest to the client.

   Once a client
                                  interface from which has selected Advertise message(s), the client will
                                  issue the Renew message.

      server-address              The IP address of the
   typically store information about each server, such as server to which
                                  this Renew message is directed, which
                                  MUST be
   preference value, addresses advertised, when the address advertisement was
   received, and so on.  Depending on the requirements of the server from
                                  which client's
   invoking user, the IAs in client MAY initiate a configuration exchange with
   the server(s) immediately, or MAY defer this message were
                                  originally assigned.

      options                     See section 16.

9.6. DHCP Rebind Message Format

      msg-type                    REBIND

      preference                  (unused) MUST be 0

      transaction-ID              An unsigned integer generated by exchange until later.

   If the client used needs to identify this Rebind
                                  message.

      client-link-local-address   The link-local address of select an alternate server in the client
                                  interface from which case that a
   chosen server does not respond, the client will
                                  issue the Rebind message.

      server-address              MUST be zero.

      options                     See section 16.

9.7. DHCP Reply Message Format

      msg-type                    REPLY

      preference                  An unsigned integer indicating a
                                  server's willingness to provide
                                  service to chooses the client.

      transaction-ID              An unsigned integer used to identify
                                  this Reply message.  Copied from server with
   the
                                  client's Request, Confirm, Renew or
                                  Rebind message.

      client-link-local-address next highest preference value.

   The link-local address client MAY choose a less-preferred server if that server has a
   better set of advertised parameters, such as the
                                  interface for which available addresses
   advertised in IAs.

13.4. Server Behavior

   For this discussion, the client server is
                                  using DHCP.

      server-address              The IP address assumed to have been configured in
   an implementation specific manner.  This configuration is assumed to
   contain all network topology information for the DHCP domain, as well
   as any necessary authentication information.

13.4.1. Receipt of Solicit messages

   If the server receives a Solicit message, the client must be on the
   same link as the server.  If the DHCP domain crosses site
                                  boundaries, then this address MUST be
                                  globally-scoped.

      options                     See section 16.

9.8. DHCP Release Message Format

      msg-type                    RELEASE

      preference                  (unused) MUST be 0

      transaction-ID              An unsigned integer generated by server receives a Relay-forward
   message containing a Solicit message, the client used to identify this Release
                                  message.

      client-link-local-address   The client's link-local address for must be on the interface from
   link to which the client
                                  will send prefix identified by the Release message.

      server-address              The IP address of "relay-address" and
   "prefix-length" fields in the Relay-forward message is assigned.
   The server that
                                  assigned records the IA.

      options                     See section 16.

9.9. DHCP Decline Message Format

      msg-type                    DECLINE

      preference                  (unused) MUST be 0

      transaction-ID              An unsigned integer generated by "relay-address" field from the
                                  client used to identify this Decline
                                  message.

      client-link-local-address   The client's link-local address for Relay-forward
   message and extracts the interface solicit message from which the "client-message"
   option.

   If administrative policy permits the server to respond to a client on
   that link, the server will generate and send an Advertise message to
   the Decline message.

      server-address              The IP address client.

13.4.2. Creation and sending of the Advertise messages

   The server that
                                  assigned sets the addresses.

      options                     See section 16.

9.10. DHCP Reconfigure-init Message Format

      preference                  (unused) MUST be 0

      transaction-ID              An unsigned integer generated
                                  by "msg-type" field to ADVERTISE and copies the server
   values of the following fields from the client's Solicit to identify this
                                  Reconfigure-init message the
   Advertise message:

     o transaction-ID

     o client-link-local-address   (unused) MUST be 0

      server-address
   The server places one of its IP address addresses (determined through
   administrator setting) in the "server-address" field of the DHCP Advertise
   message.  The server
                                  issuing sets the Reconfigure-init message.
                                  MUST be of sufficient scope "preference" field according to be
                                  reachable by all clients.

      options its
   configuration information.  See section 16.

10. Relay messages

   Relay agents exchange messages with servers 20.3 for a description of
   server preference.

   The server MUST include options to forward messages
   between clients and servers the Advertise message containing
   any addresses that are not connected would be assigned to IAs contained in the same link.

10.1. Relay-forward Solicit
   message

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    msg-type   | prefix length |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                         relay-address                         |
     |                                                               |
     |                               |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     | from the client.  The server MAY include other options (variable number and length)   ....        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      msg-type        RELAY-FORW

      prefix-length the
   server will return to the client in a subsequent Reply message.
   The length information in these options will be used by the client in the
   selection of a server if the prefix client receives more than one Advertise
   message.

   If the Solicit message was received in a Relay-forward message, the
   server constructs a Relay-reply message with the Advertise message in
   the payload of a "server-message" option.  The server unicasts the
   Relay-reply message to the address in the "relay-address" field.

      relay-address   An address assigned field from
   the Relay-forward message.

   If the Solicit message was received directly by the server, the
   server unicasts the Advertise message directly to the interface client using
   the "client-link-local-address" field value as the destination
   address.  The Advertise message MUST be unicast through the interface
   on which the Solicit message from the client was received.

      options         MUST include

14. DHCP Client-Initiated Configuration Exchange

   A client initiates a "Client message option"; see
                      section 16.4.

10.2. Relay-reply message

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    msg-type   | prefix length |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                         relay-address                         |
     |                                                               |
     |                               |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |            options (variable number and length)   ....        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      msg-type        RELAY-REPL

      prefix-length exchange with a server or servers to
   acquire or update configuration information of interest.  The length client
   may initiate the configuration exchange as part of the prefix in operating
   system configuration process or when requested to do so by the address
   application layer.

   The client uses the following messages to initiate a configuration
   event:

      Request   Obtain initial configuration information (from a server
                identified in a previously received Advertise message)
                when the
                      "relay-address" field.

      relay-address   An address identifying client has no assigned addresses

      Confirm   Confirm the interface validity of assigned addresses and other
                configuration changes through which the message server from which the server should
                configuration information was obtained when the client's
                assigned addresses may not be forwarded;
                      copied from valid; for example, when
                the "client-forward" message.

      options         MUST include a "Server message option"; see
                      section 16.5.

11. Identity association

   An "identity-association" (IA) is client reboots or loses its connection to a construct link

      Renew     Extend the lease on an IA through which a the server
   and a client can identify, group and manage IPv6 addresses.  Each that
                originally assigned the IA

      Rebind    Extend the lease on an IA through any server willing to
                extend the lease
      Release   Release the lease on an IA
   consists of a DUID and a list release all of associated IPv6 the
                addresses (the list
   may be empty). contained in the IA,

      Decline   Decline the assignment of one or more addresses in an
                IA.

   A client associates an IA with one of its interfaces
   and uses the IA Release/Reply message exchange to obtain IPv6 addresses for indicate to the
   DHCP server that interface from a
   server.

   See section 16.2 for the representation of an IA client will no longer be using the addresses in a DHCP message.

12. DHCP Server Solicitation

   This section describes how a
   the released IA.

   A client locates servers.  The behavior
   of uses the Decline/Reply message exchange to indicate to the
   DHCP server that the client and has detected that one or more addresses
   assigned by the server implementations is discussed, along with already in use on the
   messages they use.

12.1. Solicit client's link.

14.1. Client Message Validation

   Clients MUST silently discard any received Solicit messages. client messages (Request,
   Confirm, Renew, Rebind, Release or Decline messages).

   Agents MUST silently discard any received Solicit client messages if in which the
   "client-link-local-address" field does not contain a valid link-local
   address.

12.2. Advertise

   Servers MUST discard any received client messages in which the
   "options" field contains an authentication option, and the server
   cannot successfully authenticate the client.

   Servers MUST discard any received Request, Renew, Release or Decline
   message in which the "server-address" field value does not match any
   of the server's addresses.

14.2. Server Message Validation

   Servers MUST silently discard any received Advertise messages. server messages
   (Advertise, Reply or Reconfigure-init messages).

   Clients MUST discard any Advertise server messages that meet any of the
   following criteria:

     o The "Transaction-ID" "transaction-ID" field value in the server message does
       not match the value the client used used in its Request or Release
       message.

     o The "client-link-local-address" field value in the server message
       does not match the link-local address of the interface from which
       the client sent in its Request, Confirm, Renew, Rebind, Release
       or Decline message.

     o The server message contains an authentication option, and the
       client's attempt to authenticate the message fails.

   Relays MUST discard any Relay-reply message in which the
   "client-link-local-address" in the encapsulated Reply message does
   not contain a valid link-local address.

14.3. Client Behavior

   A client will use Request, Confirm, Renew and Rebind messages to
   acquire and confirm the validity of configuration information.  A
   client may initiate such an exchange automatically in order to
   acquire the necessary network parameters to communicate with nodes
   off-link.  The client uses the server address information from
   previous Advertise message(s) for use in constructing Request and
   Renew message(s).  Note that a client may request configuration
   information from one or more servers at any time.

   A client uses the Release message in its Solicit message.

     o The "client-link-local-address" field value does not match the
       link-local address management of the interface upon which IAs when
   the client sent has been instructed to release the Solicit message.

12.3. Client Behavior

   Clients use IA prior to the Solicit IA
   expiration time since it is no longer needed.

   A client uses the Decline message to discover DHCP servers configured
   to serve when the client has determined
   through DAD or some other method that one or more of the addresses on
   assigned by the link to which server in the client IA is attached.

12.3.1. already in use by a different
   client.

14.3.1. Creation and sending of the Solicit Request messages

   If a client has no valid IPv6 addresses of sufficient scope to
   communicate with a DHCP server, it may send a Request message to
   obtain new addresses.  The client includes one or more IAs in the
   Request message, to which the server assigns new addresses.  The
   server then returns IA(s) to the client in a Reply message.

   The client sets the "msg-type" field to SOLICIT, REQUEST, and places
   the link-local address of the interface it wishes to configure acquire
   configuration information for in the "client-link-local-address"
   field.

   The client generates a transaction ID inserts this value in the
   "transaction-ID" field.

   The client MUST include options for any IAs to which places the client is
   expecting to have address of the destination server assign addresses.  Because in the
   "server-address" field.

   The client
   does not have any IAs with addresses when sending adds a Solicit message,
   all of DUID option to identify itself to the IAs MUST be empty. server.  The
   client MAY include an Option
   Request Option in adds any other approppriate options, including one or more IA
   options (if the Solicit message. client is requesting that the server assign it some
   network addresses).  The list of addresses in each included IA MUST
   be empty.  If the client MUST NOT include is not requesting that the server assign it
   any other options except those specifically allowed as defined by
   specific options. addresses, the client omits the IA option.

   The client sends the Solicit Request message to the All DHCP Agents
   multicast address, destination port 547.  The source port selection
   can be arbitrary, although it SHOULD be possible using a client
   configuration facility to set a specific source port value.

12.3.2. Time out and retransmission of Solicit Messages

   The client's first Solicit message on the interface MUST be delayed
   by a random amount of time between the interval of MIN_SOL_DELAY and
   MAX_SOL_DELAY. This random delay desynchronizes clients which start
   at server will respond to the same time (e.g., after Request message with a power outage).

   The client waits ADV_MSG_TIMEOUT, collecting Advertise messages. Reply
   message.  If no Advertise messages are received, Reply message is received within REP_MSG_TIMEOUT
   milliseconds, the client retransmits the Solicit, Request with the same
   transaction-ID, and doubles the ADV_MSG_TIMEOUT value.  This process REP_MSG_TIMEOUT value, and waits
   again.  The client continues this process until either one or more Advertise messages are a Reply is received
   or
   ADV_MSG_TIMEOUT reaches the ADV_MSG_MAX value.  Thereafter, Solicits
   are retransmitted every ADV_MSG_MAX until SOL_MAX_ATTEMPTS REQUEST_MSG_ATTEMPTS unsuccessful attempts have been made, at
   which time the client stops trying MUST abort the configuration attempt.  The
   client SHOULD report the abort status to DHCP configure the
   interface.  An event external application layer.

   Default and initial values for REP_MSG_TIMEOUT and REQ_MSG_ATTEMPTS
   are documented in section 7.5.

14.3.2. Creation and sending of Confirm messages

   Whenever a client may have moved to DHCP a new link, its IPv6 addresses
   may no longer be valid.  Examples of times when a client may have
   moved to a new link include:

     o The client reboots

     o The client is required physically disconnected from a wired connection

     o The client returns from sleep mode

     o The client using a wireless technology changes cells

   In any situation when a client may have moved to restart the DHCP
   configuration process.

   Default and initial values for MIN_SOL_DELAY, MAX_SOL_DELAY,
   ADV_MSG_TIMEOUT, AND ADV_MSG_MAX are documented in section 7.5.

12.3.3. Receipt of Advertise messages

   Upon receipt of one or more validated Advertise messages, a new link, the
   client
   selects one or more Advertise messages based upon the following
   criteria.

    -  Those Advertise messages with the highest server preference
       value (see section 17.4) are preferred over all other Advertise
       messages.

    -  Within MUST initiate a group of Advertise messages Confirm/Reply message exchange.  The client
   includes any IAs, along with the same server
       preference value, a client MAY select addresses associated with those IAs,
   in its Confirm message.  Any responding servers whose
       Advertise messages advertise information will indicate the
   acceptability of interest the addresses with the status in the IA it returns
   to the client.  For example, one server may be advertising

   The client sets the
       availability of IP addresses which have an "msg-type" field to CONFIRM, and places
   the link-local address scope of
       interest the interface it wishes to acquire
   configuration information for in the client.

   Once "client-link-local-address"
   field.

   The client generates a transaction ID inserts this value in the
   "transaction-ID" field.

   The client has selected Advertise message(s), sets the "server-address" field to 0.

   The client will
   typically store information about each server, such as adds a DUID option to identify itself to the server.  The
   client adds any appropriate options, including one or more IA options
   (if the client is requesting that the server
   preference value, addresses advertised, when confirm the advertisement was
   received, and so on.  Depending on validity of
   some network addresses).  If the client does include any IA options,
   it MUST include the requirements list of the client's
   invoking user, addresses the client MAY initiate a configuration exchange currently has
   associated with that IA.

   The client sends the server(s) immediately, or MAY defer this exchange until later.

   If Confirm message to the All DHCP Agents
   multicast address, destination port 547.  The source port selection
   can be arbitrary, although it SHOULD be possible using a client needs
   configuration facility to set a specific source port value.

   Servers will respond to select an alternate server in the case that Confirm message with a
   chosen server does not respond, Reply message.  If
   no Confirm message is received within REP_MSG_TIMEOUT milliseconds,
   the client chooses retransmits the server Confirm with the next highest preference value. same transaction-ID,
   and doubles the REP_MSG_TIMEOUT value, and waits again.  The client MAY choose a less-preferred server if that server has a
   better set of advertised parameters, such as the available addresses
   advertised in IAs.

12.4. Server Behavior

   For
   continues this discussion, the server process until a Reply is assumed to received or QRY_MSG_ATTEMPTS
   unsuccessful attempts have been configured in
   an implementation specific manner.  This made, at which time the client MUST
   abort the configuration is assumed attempt.  The client SHOULD report the abort
   status to
   contain all network topology information the application layer.

   Default and initial values for REP_MSG_TIMEOUT and QRY_MSG_ATTEMPTS
   are documented in section 7.5.

   If the client receives no response to its Confirm message, it MAY
   restart the configuration process by locating a DHCP domain, as well server with an
   Advertise message and sending a Request to that server, as any necessary authentication information.

12.4.1. Receipt described
   in section 14.3.1.

14.3.3. Creation and sending of Solicit Renew messages

   If the server receives

   IPv6 addresses assigned to a Solicit message, the client must be on through an IA use the same link
   preferred and valid lifetimes as the server.  If the IPv6 addresses obtained through
   stateless autoconfiguration.  The server receives a Relay-forward
   message containing a Solicit message, assigns preferred and valid
   lifetimes to the client must be on IPv6 addresses it assigns to an IA. To extend those
   lifetimes, the
   link client sends a Request to which the prefix identified by server containing an
   "IA option" for the "relay-address" IA and
   "prefix-length" fields its associated addresses.  The server
   determines new lifetimes for the addresses in the Relay-forward message is assigned. IA according to
   the server's administrative configuration.  The server records may also add
   new addresses to the "relay-address" field IA. The server remove addresses from the Relay-forward
   message IA by
   setting the preferred and extracts valid lifetimes of those addresses to zero.

   The server controls the solicit message from time at which the "client-message"
   option. client contacts the server
   to extend the lifetimes on assigned addresses through the T1 and
   T2 parameters assigned to an IA. If administrative policy permits the server does not assign an
   explicit value to respond T1 or T2 for an IA, T1 defaults to a 0.5 times the
   shortest preferred lifetime of any address assigned to the IA and
   T2 defaults to 0.875 times the shortest preferred lifetime of any
   address assigned to the IA.

   At time T1 for an IA, the client initiates a Request/Reply message
   exchange to extend the lifetimes on
   that link, any addresses in the server will generate and send IA. The
   client includes an Advertise IA option with all addresses currently assigned to
   the IA in its Request message.  The client sends this Request message
   to the client.

12.4.2. Creation and sending of Advertise messages All DHCP Agents multicast address.

   The server client sets the "msg-type" field to ADVERTISE RENEW, and copies the
   values of the following fields from the client's Solicit to the
   Advertise message:

     o transaction-ID

     o client-link-local-address

   The server places one of its IP addresses (determined through
   administrator setting) in
   the "server-address" field link-local address of the Advertise
   message.  The server sets the "preference" field according interface it wishes to its acquire
   configuration information.  See section 18.3 information for a description of
   server preference.

   The server MUST include options to the Advertise message containing
   any addresses that would be assigned to IAs contained in the Solicit
   message from the client. "client-link-local-address"
   field.

   The server MAY include other options the
   server will return to the client in generates a subsequent Reply message.
   The information transaction ID inserts this value in these options will be used by the
   "transaction-ID" field.

   The client in places the
   selection address of a server if the client receives more than one Advertise
   message.

   If the Solicit message was received in a Relay-forward message, the destination server constructs a Relay-reply message with the Advertise message in the payload of a "server-message" option.
   "server-address" field.

   The server unicasts the
   Relay-reply message client adds a DUID option to the address in the "relay-address" field from
   the Relay-forward message.

   If the Solicit message was received directly by the server, the
   server unicasts the Advertise message directly identify itself to the client using
   the "client-link-local-address" field value as the destination
   address. server.  The Advertise message MUST be unicast through the interface
   on which
   client adds any appropriate options, including one or more IA options
   (if the Solicit message was received.

13. DHCP Client-Initiated Configuration Exchange

   A client initiates a message exchange with a is requesting that the server or servers to
   acquire or update configuration information of interest.  The extend the lease on some
   IAs; note that the client may initiate check the configuration exchange as part status of the operating
   system other configuration process or when requested to do so by
   parameters without asking for lease extensions).  If the
   application layer. client does
   include any IA options, it MUST include the list of addresses the
   client currently has associated with that IA.

   The client uses sends the following messages Renew message to initiate a configuration
   event with the All DHCP Agents multicast
   address, destination port 547.  The source port selection can
   be arbitrary, although it SHOULD be possible using a server or servers:

      Request   Obtain initial client
   configuration information (from facility to set a specific source port value.

   The server
                identified in will respond to the Renew message with a previously Reply message.
   If no Reply message is received Advertise message)
                when within REP_MSG_TIMEOUT milliseconds,
   the client has no assigned addresses

      Confirm   Confirm the validity of assigned addresses and other
                configuration changes through the server from which retransmits the
                configuration information was obtained when Renew with the client's
                assigned addresses may not be valid; for example, when same transaction-ID, and
   doubles the REP_MSG_TIMEOUT value, and waits again.  The client reboots or loses its connection to
   continues this process until a link
      Renew     Extend the lease on an IA through the server that
                originally assigned the IA Reply is received or until time T2 is
   reached (see section 14.3.4).

   Default and initial values for REP_MSG_TIMEOUT are documented in
   section 7.5.

14.3.4. Creation and sending of Rebind    Extend the lease on messages

   At time T2 for an IA through any (which will only be reached if the server willing to
                extend the lease

   A client uses
   which the Release/Reply Renew message exchange to indicate to the
   DHCP server that the client will no longer be using the addresses in was sent at time T1 has not responded),
   the released IA.

   A client uses the Decline/Reply initiates a Rebind/Reply message exchange to indicate to the
   DHCP server that the exchange.  The client has detected that one or more
   includes an IA option with all addresses currently assigned by to the server is already IA
   in use on the client's link.

13.1. Client Message Validation

   Clients MUST silently discard any received client messages (Request,
   Confirm, Renew, Rebind, Release or Decline messages).

   Agents MUST discard any received its Rebind message.  The client messages in which sends this message to the
   "client-link-local-address" field does not contain a valid link-local All DHCP
   Agents multicast address.

   Servers MUST discard any received

   The client messages in which sets the
   "options" "msg-type" field contains an authentication option, to REBIND, and places
   the server
   cannot successfully authenticate link-local address of the client.

   Servers MUST discard any received Request, Renew, Release or Decline
   message interface it wishes to acquire
   configuration information for in which the "server-address" field "client-link-local-address"
   field.

   The client generates a transaction ID inserts this value does not match any
   of in the server's addresses.

13.2. Server Message Validation

   Servers MUST silently discard any received server messages (Reply or
   Reconfigure-init messages).

   Clients MUST discard any server messages that meet any of
   "transaction-ID" field.

   The client sets the
   following criteria:

     o "server-address" field to 0.

   The client adds a DUID option to identify itself to the server.
   The "transaction-ID" field value in client adds any appropriate options, including one or more IA
   options.  If the server message client does
       not match the value include any IA options (if the client used in its Request or Release
       message.

     o The "client-link-local-address" field value in is
   requesting that the server message
       does not match extend the link-local address lease on some IAs; note that
   the client may check the status of other configuration parameters
   without asking for lease extensions), it MUST include the interface from which list of
   addresses the client sent in its Request, Confirm, Renew, Rebind, Release
       or Decline message.

     o currently has associated with that IA.

   The server message contains an authentication option, and the
       client's attempt to authenticate client sends the Rebind message fails.

   Relays MUST discard any Relay-reply message in which the
   "client-link-local-address" in to the encapsulated Reply message does
   not contain All DHCP Agents multicast
   address, destination port 547.  The source port selection can
   be arbitrary, although it SHOULD be possible using a valid link-local address.

13.3. Client Behavior

   A client
   configuration facility to set a specific source port value.

   The server will use Request, Confirm, Renew and Rebind messages respond to
   acquire and confirm the validity of configuration information.  A Rebind message with a Reply message.
   If no Reply message is received within REP_MSG_TIMEOUT milliseconds,
   the client may initiate such an exchange automatically in order to
   acquire retransmits the necessary network parameters to communicate Rebind with nodes
   off-link. the same transaction-ID, and
   doubles the REP_MSG_TIMEOUT value, and waits again.  The client uses the server address information from
   previous Advertise message(s)
   continues this process until a Reply is received.

   Default and initial values for use REP_MSG_TIMEOUT are documented in constructing Request and
   Renew message(s).  Note that a
   section 7.5.

   The client may request configuration
   information has several alternatives to choose from one or more servers at any time.

   A client uses if it receives no
   response to its Rebind message.

    -  When the Release message in lease on the management of IAs when IA expires, the client has been instructed may choose to release use a
       Solicit message to locate a new DHCP server and send a Request
       for the expired IA prior to the new server

    -  Some addresses in the IA
   expiration time since it is no longer needed.

   A client uses may have lifetimes that extend beyond
       the Decline message when lease of the IA, so the client has determined
   through DAD or some other method that one or more may choose to continue to use
       those addresses; once all of the addresses
   assigned by the server in have expired, the IA is already in use by a different
   client.

13.3.1. Creation and sending of Request messages

   If a
       client has no valid IPv6 addresses of sufficient scope to
   communicate with a DHCP server, it may send a Request message choose to
   obtain locate a new addresses. DHCP server

    -  The client includes one or more IAs may have other addresses in other IAs, so the
   Request message, client
       may choose to which discard the server assigns new addresses.  The
   server then returns IA(s) to expired IA and use the client addresses in a Reply message.

   The client sets the "msg-type" field
       other IAs

14.3.5. Receipt of Reply message in response to REQUEST, and places a Request, Confirm,
   Renew or Rebind message

   Upon the receipt of a valid Reply message in response to a
   Request, Confirm, Renew or Rebind message, the link-local address of client extracts the interface it wishes to acquire
   configuration information for contained in the "client-link-local-address"
   field.

   The client generates Reply.  If the "status"
   field contains a transaction ID inserts this value in non-zero value, the
   "transaction-ID" field.

   The client places reports the address of error status
   to the destination server application layer.

   The client records the T1 and T2 times for each IA in the
   "server-address" field. Reply
   message.  The client adds records any appropriate options, including one or more IA
   options (if addresses included with IAs in
   the Reply message.  The client is requesting that updates the preferred and valid
   lifetimes for the server assign it some
   network addresses).  The list of addresses in each included the IA MUST
   be empty.

   The client sends from the Request message to lifetime information
   in the All DHCP Agents
   multicast address, destination port 547. IA option.  The source port selection
   can be arbitrary, although it SHOULD be possible using a client
   configuration facility to set a specific source port value.

   The server will respond to the Request message with a Reply
   message.  If no Reply message is received within REP_MSG_TIMEOUT
   milliseconds, leaves any addresses that the client retransmits the Request
   has associated with the same
   transaction-ID, and doubles the REP_MSG_TIMEOUT value, and waits
   again.  The client continues this process until a Reply is received
   or REQUEST_MSG_ATTEMPTS unsuccessful attempts have been made, at
   which time IA that are not included in the client MUST abort IA option
   unchanged.

   Management of the specific configuration attempt.  The
   client SHOULD report the abort status to information is detailed in
   the application layer.

   Default and initial values for REP_MSG_TIMEOUT and REQ_MSG_ATTEMPTS
   are documented definition of each option, in section 7.5.

13.3.2. Creation and sending of Confirm messages

   Whenever a 18.

   When the client may have moved to a new link, its IPv6 addresses
   may no longer be valid.  Examples of times when receives an Unavail error status in an IA from the
   server for a Request message the client may will have
   moved to find a new link include:

     o The client reboots

     o The
   server to create an IA.

   When the client is physically disconnected from receives a wired connection

     o The client returns NoBinding error status in an IA from sleep mode

     o The client using a wireless technology changes cells

   In any situation when the
   server for a Confirm message the client may have moved can assume it needs to send a new link,
   Request to reestablish an IA with the server.

   When the client MUST initiate receives a Confirm/Reply Conf_NoMatch error status in an IA from
   the server for a Confirm message exchange.  The the client
   includes any IAs, along with can send a Renew message
   to the addresses associated with those IAs,
   in its Confirm message.  The server will indicate to extend the acceptability
   of lease for the addresses with addresses.

   When the client receives a NoBinding error status in the an IA it returns to from the client.

   DISCUSSION:

      This section used
   server for a Renew message the client can assume it needs to allow servers send a
   Request to change reestablish an IA with the addresses server.

   When the client receives a Renw_NoMatch error status in an IA. Without some additional mechanism, servers
      responding IA from
   the server for a Renew message the client can assume it needs to Confirm messages can't change safely
      change send
   a Request to reestablish an IA with the addresses in IAs (although they can change server.

   When the lifetimes), because servers may send back different
      addresses.

   The client sets the "msg-type" field to CONFIRM, and places receives an Unavail error status in an IA from the link-local address of
   server for a Renew message the interface client can assume it wishes needs to acquire
   configuration information for in send a
   Request to reestablish an IA with the server.

   When the "client-link-local-address"
   field.

   The client generates receives a transaction ID inserts this value NoBinding error status in an IA from the
   "transaction-ID" field.

   The client sets
   server for a Rebind message the "server-address" field to 0.

   The client adds any appropriate options, including one or more can assume it needs to send a
   Request to reestablish an IA
   options (if the client is requesting that with the server confirm the
   validity of some network addresses).  If or try another server.

   When the client does include
   any receives a Rebd_NoMatch error status in an IA options, it MUST include from
   the list of addresses server for a Rebind message the client
   currently has associated can assume it needs to
   send a Request to reestablish an IA with that IA.

   The the server or try another
   server.

   When the client sends receives an Unavail error status in an IA from the Confirm
   server for a Rebind message to the All DHCP Agents
   multicast address, destination port 547.  The source port selection client can be arbitrary, although assume it SHOULD be possible using a client
   configuration facility needs to set send a specific source port value.

   Servers will respond
   Request to reestablish an IA with the server or try another server.

14.3.6. Creation and sending of Release messages

   The client sets the "msg-type" field to RELEASE, and places the Confirm message
   link-local address of the interface associated with the configuration
   information it wishes to release in the "client-link-local-address"
   field.

   The client generates a Reply message.  If
   no Confirm message is received within REP_MSG_TIMEOUT milliseconds, transaction ID and places this value in the
   "transaction-ID" field.

   The client retransmits places the Confirm with IP address of the same transaction-ID,
   and doubles server that allocated the REP_MSG_TIMEOUT value, and waits again.
   address(es) in the "server-address" field.

   The client
   continues this process until adds a Reply is received or QRY_MSG_ATTEMPTS
   unsuccessful attempts have been made, at which time DUID option to identify itself to the server.  The
   client includes options containing the IAs it is releasing in the
   "options" field.  The addresses to be released MUST
   abort be included in
   the configuration attempt. IAs.  The client SHOULD report appropriate "status" field in the abort
   status options MUST be set
   to indicate the application layer.

   Default and initial values reason for REP_MSG_TIMEOUT and QRY_MSG_ATTEMPTS
   are documented in section 7.5. the release.

   If the client receives no response is configured to its Confirm message, it MAY
   restart use authentication, the configuration process by locating a DHCP server with an
   Advertise message and sending a Request to that server, as described
   in section 13.3.1.

13.3.3. Creation and sending of Renew messages

   IPv6 addresses assigned to a client through an IA use
   generates the same
   preferred and valid lifetimes as IPv6 addresses obtained through
   stateless autoconfiguration.  The server assigns preferred appropriate authentication option, and valid
   lifetimes adds this option
   to the IPv6 addresses it assigns to an IA. To extend those
   lifetimes, "options" field.  Note that the authentication option MUST be
   the last option in the "options" field.  See section  18.9 for more
   details about the authentication option.

   The client sends a Request to the server containing an
   "IA option" for Release message to the IA All DHCP Agents multicast
   address.

14.3.7. Time out and its associated addresses.  The server
   determines new lifetimes retransmission of Release Messages

   A client MAY choose to wait for a Reply message from the addresses server in the IA according
   response to the server's administrative configuration.  The server may also add
   new addresses Release message.  If the client does wait for a
   Reply, the client MAY choose to retransmit the IA. The server remove addresses from Release message.

   If no Reply message is received within REP_MSG_TIMEOUT milliseconds,
   the IA by
   setting client retransmits the preferred Release, doubles the REP_MSG_TIMEOUT
   value, and valid lifetimes of those addresses to zero. waits again.  The server controls the time client continues this process until a
   Reply is received or REL_MSG_ATTEMPTS unsuccessful attempts have been
   made, at which time the client contacts the server
   to extend SHOULD abort the lifetimes on assigned addresses through release attempt.
   The client SHOULD return the T1 and
   T2 parameters assigned abort status to an IA. If the server does not assign an
   explicit value to T1 or T2 for application, if an IA, T1 defaults to 0.5 times the
   shortest preferred lifetime of any address assigned to
   application initiated the IA release.

   Default and
   T2 defaults to 0.875 times the shortest preferred lifetime of any
   address assigned to the IA.

   At time T1 initial values for an IA, REP_MSG_TIMEOUT and REL_MSG_ATTEMPTS
   are documented in section 7.5.

   Note that if the client initiates a Request/Reply message
   exchange fails to extend release the lifetimes on any addresses in IA, the IA. The
   client includes an IA option with all addresses currently
   assigned to the IA will be reclaimed by the server when the lease
   associated with it expires.

14.3.8. Receipt of Reply message in its Request message.  The client multicasts this Request response to a Release message

   Upon receipt of a valid Reply message, the client can consider the
   Release event successful, and SHOULD return the successful status to
   the All DHCP Agents multicast address. application layer, if an application initiated the release.

14.3.9. Creation and sending of Decline messages

   The client sets the "msg-type" field to RENEW, DECLINE, and places the
   link-local address of the interface associated with the configuration
   information it wishes to acquire
   configuration information for decline in the "client-link-local-address"
   field.

   The client generates a transaction ID inserts and places this value in the
   "transaction-ID" field.

   The client places the IP address of the destination server that allocated the
   address(es) in the "server-address" field.

   The client adds any appropriate options, including one or more IA
   options (if a DUID option to identify itself to the server.  The
   client includes options containing the IAs it is requesting that declining in the server extend
   "options" field.  The addresses to be released MUST be included in
   the lease
   on some IAs; note that IAs.  The appropriate "status" field in the client may check options MUST be set
   to indicate the status of other
   configuration parameters without asking reason for lease extensions). declining the address.

   If the client does include any IA options, it MUST include the list of
   addresses is configured to use authentication, the client currently has associated with that IA.

   The client sends
   generates the Renew message appropriate authentication option, and adds this option
   to the All DHCP Agents multicast
   address, destination port 547.  The source port selection can
   be arbitrary, although it SHOULD "options" field.  Note that the authentication option MUST be possible using a client
   configuration facility to set a specific source port value.
   the last option in the "options" field.  See section  18.9 for more
   details about the authentication option.

   The server will respond to client send the Renew Decline message with a Reply message. to the All DHCP Agents multicast
   address.

14.3.10. Time out and retransmission of Decline Messages

   If no Reply message is received within REP_MSG_TIMEOUT milliseconds,
   the client retransmits the Renew with the same transaction-ID, and Decline, doubles the REP_MSG_TIMEOUT
   value, and waits again.  The client continues this process until a
   Reply is received or until REL_MSG_ATTEMPTS unsuccessful attempts have
   been made, at which time T2 is
   reached (see section 13.3.4). the client SHOULD abort the attempt to
   decline the address.  The client SHOULD return the abort status to
   the application, if an application initiated the release.

   Default and initial values for REP_MSG_TIMEOUT and REL_MSG_ATTEMPTS
   are documented in section 7.5.

13.3.4. Creation and sending

14.3.11. Receipt of Rebind messages

   At time T2 for an IA (which will only be reached Reply message in response to a Release message

   Upon receipt of a valid Reply message, the client can consider the
   Release event successful, and SHOULD return the successful status to
   the application layer, if an application initiated the server release.

14.4. Server Behavior

   For this discussion, the Server is assumed to
   which have been configured in
   an implementation specific manner with configuration of interest to
   clients.

14.4.1. Receipt of Request messages

   Upon the Renew receipt of a valid Request message was sent at time T1 has not responded),
   the from a client initiates the server
   can respond to, (implementation-specific administrative policy
   satisfied) the server scans the options field.

   The server then constructs a Rebind/Reply Reply message exchange. and sends it to the
   client.

   The client
   includes an IA server SHOULD process each option with all addresses currently assigned to for the IA client in its Rebind message. an
   implementation-specific manner.  The client multicasts this server MUST construct a Reply
   message containing the following values:

      msg-type                    REPLY

      preference                  Enter the server's preference to
                                  provide services to the All
   DHCP Agents multicast address.

   The client sets client.

      transaction-ID              Enter the "msg-type" field to REBIND, and places transaction-ID from the link-local
                                  Request message.

      client-link-local address of   Enter the interface it wishes to acquire
   configuration information for in client-link-local address
                                  from the "client-link-local-address"
   field.

   The client generates a transaction ID inserts this value in Request message.

      server address              Enter the
   "transaction-ID" field.

   The client sets IP address of the "server-address" field to 0.

   The client adds any appropriate options, including one or more IA
   options.  If server.

   When the client does include any server receives a Request and IA options (if option is included the
   client is requesting that the configuration of a new IA by the server.
   The server extend MUST take the lease on some IAs; note clients IA and associate a binding for that
   the
   client may check in an implementation-specific manner within the status of other server's
   configuration parameters
   without asking parameter database for lease extensions), it MUST include DHCP clients.

   If the list of server cannot provide addresses to the client currently has associated with that IA.

   The it SHOULD send
   back an empty IA to the client sends with the Rebind message status field set to Unavail.

   If the All DHCP Agents multicast
   address, destination port 547.  The source port selection server can
   be arbitrary, although it SHOULD be possible using a provide addresses to the client
   configuration facility it MUST send back
   the IA to set the client with all fields entered and a specific source port value. status of Success,
   and add the IA as a new client binding.

   The server will respond adds options to the Reply message for any other
   configuration information to be assigned to the Rebind message with client.

14.4.2. Receipt of Confirm messages

   Upon the receipt of a Reply message.
   If no Reply valid Confirm message is received within REP_MSG_TIMEOUT milliseconds,
   the from a client retransmits the Rebind with server
   can respond to, (implementation-specific administrative policy
   satisfied) the same transaction-ID, and
   doubles server scans the REP_MSG_TIMEOUT value, and waits again. options field.

   The client
   continues this process until server then constructs a Reply is received.

   Default message and initial values sends it to the
   client.

   The server SHOULD process each option for REP_MSG_TIMEOUT are documented the client in
   section 7.5.

   DISCUSSION: an
   implementation-specific manner.  The client has several alternatives server MUST construct a Reply
   message containing the following values:

      msg-type                    REPLY

      preference                  Enter the server's preference to choose from if it
      receives no response
                                  provide services to its Rebind the client.

      transaction-ID              Enter the transaction-ID from the
                                  Confirm message.

       -  When

      client-link-local address   Enter the lease on client-link-local address
                                  from the IA expires, Confirm message.

      server address              Enter the server's address.

   When the client may choose
          to use a Solicit message to locate a new DHCP server and
          send receives a Request for the expired Confirm and an IA to option is included the
   client is requesting confirmation that the new server

       -  Some addresses in the IA may have lifetimes that extend
          beyond are
   valid.  The server SHOULD locate the lease of clients binding and verify the IA, so
   information in the IA from the client may choose
          to continue to use those addresses; once all of matches the
          addresses have expired, information stored
   for that client.

   If the server cannot find a client may choose entry for this IA the server
   SHOULD return an empty IA with status set to locate
          a new DHCP NoBinding.

   If the server

       -  The finds that the information for the client may have other addresses does not
   match what is in other IAs, so the server's records for that client may choose to discard the expired server
   should send back an empty IA and use with status set to Conf_NoMatch.

   If the
          addresses in server finds a match to the other IAs

13.3.5. Confirm then the server should
   send back the IA to the client with status set to success.

14.4.3. Receipt of Reply message in response to a Reply, Confirm, Renew
   or Rebind message messages

   Upon the receipt of a valid Renew message from a client the server
   can respond to, (implementation-specific administrative policy
   satisfied) the server scans the options field.

   The server then constructs a Reply message and sends it to the
   client.

   The server SHOULD process each option for the client in response an
   implementation-specific manner.  The server MUST construct a Reply
   message containing the following values:

      msg-type                    REPLY

      preference                  Enter the server's preference to
                                  provide services to the client.

      transaction-ID              Enter the transaction-ID from the
                                  Confirm message.

      client-link-local address   Enter the client-link-local address
                                  from the Confirm message.

      server address              Enter the server's address.

   When the server receives a
   Request, Confirm, Renew or Rebind message, the and IA option from a client extracts it
   SHOULD locate the clients binding and verify the
   configuration information contained in the Reply.
   IA from the client matches the information stored for that client.

   If the "status"
   field contains server cannot find a non-zero value, client entry for this IA the server
   SHOULD return an empty IA with status set to NoBinding.

   If the server finds that the addresses in the IA for the client reports do
   not match the error clients binding the server should return an empty IA
   with status set to Renw_NoMatch.

   If the application layer.

   The client records the T1 and T2 times server cannot Renew addresses for each the client it SHOULD send
   back an empty IA in to the Reply
   message.  The client records any addresses included with IAs in the Reply message.  The client updates status field set to Unavail.

   If the preferred and valid
   lifetimes for server finds the addresses in the IA from for the lifetime information
   in client then the
   server SHOULD send back the IA option.  The client leaves any addresses that to the client
   has associated with new lease times
   and T1/T2 times if the IA that are default is not included in the IA option
   unchanged.

   Management being used, and set status to
   Success.

14.4.4. Receipt of Rebind messages

   Upon the specific configuration information is detailed in
   the definition receipt of each option, in section 16.

   When the client receives an Unavail error status in an IA a valid Rebind message from a client the server for
   can respond to, (implementation-specific administrative policy
   satisfied) the server scans the options field.

   The server then constructs a Request Reply message the client will have and sends it to find a new the
   client.

   The server to create an IA.

   When SHOULD process each option for the client receives a NoBinding error status in an IA from the
   implementation-specific manner.  The server for MUST construct a Confirm Reply
   message containing the client can assume it needs following values:

      msg-type                    REPLY

      preference                  Enter the server's preference to send a
   Request
                                  provide services to reestablish an IA with the server.

   When client.

      transaction-ID              Enter the client receives a Conf_NoMatch error status in an IA transaction-ID from the server for a
                                  Confirm message message.

      client-link-local address   Enter the client can send a Renew message
   to client-link-local address
                                  from the Confirm message.

      server to extend the lease for address              Enter the addresses. server's address.

   When the client server receives a NoBinding error status in an Rebind and IA option from the
   server for a Renew message the client can assume it needs to send a
   Request to reestablish an IA with
   SHOULD locate the server.

   When clients binding and verify the client receives a Renw_NoMatch error status information in an the
   IA from the server client matches the information stored for a Renew message that client.

   If the client can assume it needs to send server cannot find a Request to reestablish client entry for this IA the server
   SHOULD return an empty IA with status set to NoBinding.

   If the server.

   When server finds that the client receives an Unavail error status addresses in the IA for the client do
   not match the clients binding the server should return an empty IA from
   with status set to Rebd_NoMatch.

   If the server cannot Rebind addresses for a Renew message the client can assume it needs to SHOULD send a
   Request to reestablish
   back an empty IA with the server.

   When to the client receives a NoBinding error with the status field set to Unavail.

   If the server finds the addresses in an the IA from for the client then the
   server for SHOULD send back the IA to the client with new lease times
   and T1/T2 times if the default is not being used, and set status to
   Success.

   DISCUSSION:

      There is a significant difference between Renew and Rebind
      messages:  Because the Rebind message is processed by a
      single server, the client respnding server can assume it needs actually change the
      addresses in the IA. However, because multiple servers may
      repsond to send a
   Request to reestablish an IA with Rebind, all they can safely do is update T1, T2
      (for the IA) and lifetimes (for individual addresses).

14.4.5. Receipt of Release messages

   Upon the receipt of a valid Release message, the server or try another server.

   When examines the client receives a Rebd_NoMatch error status
   IAs and the addresses in an IA from the server IAs for a Rebind validity.  If the IAs in the
   message are in a binding for the client can assume it needs to
   send a Request and the addresses in the IAs
   have been assigned by the server to reestablish an IA with those IA, the server or try another
   server.

   When deletes
   the client receives an Unavail error status in an IA addresses from the
   server for a Rebind message IAs and makes the client can assume it needs addresses available for
   assignment to send other clients.

   The server then generates a
   Request to reestablish an IA with Reply message.  If all of the server or try another server.

13.3.6. Creation IAs were
   valid and sending of Release messages

   The client the addresses successfully released,, the server sets the "msg-type"
   "status" field to RELEASE, and places "Success".  If any of the
   link-local address IAs were invalid or if
   any of the interface associated with addresses were not successfully released, the configuration
   information it wishes to release server
   releases none of the addresses in the "client-link-local-address"
   field.

   The client generates a transaction ID message and places this value in sets the
   "transaction-ID" field.

   The client places "status"
   field to "NoBinding"(section 7.4).

   If the IP address client successfully releases some but not all of the server that allocated the
   address(es) addresses
   in an IA, the "server-address" field.

   The IA continues to exist and holds the remaining,
   unreleased addresses.

   A client includes options can send an option containing the IAs it is releasing in the
   "options" field.  The an IA with no listed addresses
   to be released MUST be included in release implicitly all of the IAs.  The appropriate "status" field addresses in the options MUST be set IA.

   A server is not required to indicate the reason for (but may choose to as an implementation
   strategy) retain any record of an IA from which all of the release. addresses
   have been released.

14.4.6. Sending of Reply messages

   If the client is configured to use authentication, Request, Confirm, Renew, Rebind or Release message from
   the client
   generates was originally received by the appropriate authentication option, and adds this option
   to server, the "options" field.  Note that server
   unicasts the authentication option MUST be Reply message to the last option link-local address in the "options"
   "client-link-local-address" field.  See section  16.9 for more
   details about the authentication option.

   The client send the Release message to the All DHCP Agents multicast
   address.

13.3.7. Time out and retransmission of Release Messages

   If no Reply the message is was originally received within REP_MSG_TIMEOUT milliseconds,
   the client retransmits the Release, doubles the REP_MSG_TIMEOUT
   value, and waits again.  The client continues this process until in a
   Reply is received Forward-request or REL_MSG_ATTEMPTS unsuccessful attempts have been
   made, at which time
   Forward-release message from a relay, the client SHOULD abort server places the release attempt.
   The client SHOULD return Reply
   message in the abort status options field of a Response-reply message and unicasts
   the message to the application, if an
   application initiated relay's address from the release.

   Default and initial values for REP_MSG_TIMEOUT original message.

15. DHCP Server-Initiated Configuration Exchange

   A server initiates a configuration exchange to force DHCP clients
   to obtain new addresses and REL_MSG_ATTEMPTS
   are documented other configuration information.  For
   example, an administrator may use a server-initiated configuration
   exchange when links in section 7.5.

   Note that if the client fails to release the IA, the addresses
   assigned DHCP domain are to the IA will be reclaimed by renumbered.  Other
   examples include changes in the server when location of directory servers,
   addition of new services such as printing, and availability of new
   software (system or application).

15.1. Reconfigure-init Message Validation

   Agents MUST silently discard any received Reconfigure-init messages.

   Clients MUST discard any Reconfigure-init messages that do
   not contain an authentication option or that fail the lease
   associated client's
   authentication check.

15.2. Server Behavior

   A server sends a Reconfigure-init message to cause a client to
   initiate immediately a Request/Reply message exchange with it expires.

13.3.8. the
   server.

15.2.1. Creation and sending of Decline Reconfigure-init messages

   The client server sets the "msg-type" field to DECLINE, and places the
   link-local address of the interface associated with the configuration
   information it wishes to decline in the "client-link-local-address"
   field. RECONFIG-INIT. The client server
   generates a transaction ID transaction-ID and places this value inserts it in the "transaction-ID"
   field.  The client server places the IP its address of the server that allocated the
   address(es) (of appropriate scope) in the
   "server-address" field.

   The client includes options containing server MAY include an ORO option to inform the IAs it is declining in client of what
   information has been changed or new information that has been added.
   In particular, the
   "options" field.  The addresses to be released MUST be included in server specifies the IAs.  The appropriate "status" field IA option in the options MUST be set
   to indicate the reason for declining ORO if the address.

   If
   server wants the client is configured to use authentication, the client
   generates the appropriate obtain new address information.

   The server MUST include an authentication option, and adds this option
   to with the "options" field.  Note appropriate
   settings and add that the authentication option MUST be as the last option in the "options" field.  See section  16.9 for more
   details about
   field of the authentication option. Reconfigure-init message.

   The server MUST NOT include any other options in the Reconfigure-init
   except as specifically allowed in the definition of individual
   options.

   The server unicasts the Reconfigure-init message to one client.  The
   server may unicast Reconfigure-init messages to more than one client send
   concurrently; for example, to reliably reconfigure all known clients,
   the Decline server will unicast a Reconfigure-init message to each client.

   After the All DHCP Agents multicast
   address.

13.3.9. server sends the Reconfigure-init message, it waits for a
   Request message from those clients confirming that each client has
   received the Reconfigure-init and are thus initiating a Request/Reply
   transaction with the server.

15.2.2. Time out and retransmission of Decline Messages Reconfigure-init messages

   If no Reply the server does not receive a Request message is received within REP_MSG_TIMEOUT milliseconds, from the client
   in RECREP_MSG_TIMEOUT milliseconds, the server retransmits
   the Decline, Reconfigure-init message, doubles the REP_MSG_TIMEOUT
   value, RECREP_MSG_TIMEOUT
   value and waits again.  The client server continues this process until a
   Reply is received or REL_MSG_ATTEMPTS
   REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which time point
   the client server SHOULD abort the attempt reconfigure process.

   Default and initial values for RECREP_MSG_TIMEOUT and
   REC_MSG_ATTEMPTS are documented in section 7.5.

15.2.3. Receipt of Request messages

   The server generates and sends Reply message(s) to the client as
   described in section 14.4.6, including in the "options" field new
   values for configuration parameters.

   It is possible that the client may send a Request message after the
   server has sent a Reconfigure-init but before the Reconfigure-init is
   received by the client.  In this case, the client's Request message
   may not include all of the IAs and requests for parameters to be
   reconfigured by the server.  To accommodate this scenario, the server
   MAY choose to send a Reply with the IAs and other parameters to
   decline
   be reconfigured, even if those IAs and parameters were not in the address.  The client SHOULD return
   Request message from the abort status to client.

15.3. Client Behavior

   A client MUST always monitor UDP port 546 for Reconfigure-init
   messages on interfaces upon which it has acquired DHCP parameters.
   Since the application, if an results of a reconfiguration event may affect application initiated
   layer programs, the release.

   Default and initial values for REP_MSG_TIMEOUT client SHOULD log these events, and REL_MSG_ATTEMPTS
   are documented in section 7.5.

13.3.10. MAY notify
   these programs of the change through an implementation-specific
   interface.

15.3.1. Receipt of Reply message in response to a Release message Reconfigure-init messages

   Upon receipt of a valid Reply Reconfigure-init message, the client can consider the
   Release event successful, and SHOULD return the successful status to
   the application layer, if an application initiated
   initiates a Request/Reply transaction with the release.

13.4. Server Behavior

   For this discussion, server.  While
   the Server Request/Reply transaction is assumed to have been configured in
   an implementation specific manner with configuration of interest to
   clients.

13.4.1. Receipt of Request progress, the client silently
   discards any Reconfigure-init messages

   Upon it receives.

   DISCUSSION:

      The Reconfigure-init message acts as a trigger that signals
      the receipt of client to complete a valid Request successful Request/Reply message from
      exchange.  Once the client has received a Recongfigure-init,
      the client proceeds with the server
   can respond to, (implementation-specific administrative policy
   satisfied) Request/Reply message
      exchange (retransmitting the server scans Request if necessary); the options field.

   The server then constructs a Reply message and sends it to
      client ignores any additional Reconfigure-init messages
      (regardless of the
   client.

   The server SHOULD process each option for transaction ID in the Reconfigure-init
      message) until the Request/Reply exchange is complete.
      Subsequent Reconfigure-init messages (again independent
      of the transaction ID) cause the client in an
   implementation-specific manner.  The server MUST construct to initiate a Reply
   message containing new
      Request/Reply exchange.

      How does this mechanism work in the following values:

      msg-type                    REPLY

      preference                  Enter face of duplicated
      or retransmitted Reconfigure-init messages?  Duplicate
      messages will be ignored because the servers preference to
                                  provide services to client will begin
      the client.

      transaction-ID              Enter Request/Reply exchange after the transaction-ID from receipt of the
                                  Request message.

      client-link-local address   Enter
      first Reconfigure-init.  Retransmitted messages will
      either trigger the client-link-local address
                                  from Request/Reply exchange (if the Request message.

      server address              Enter first
      Reconfigure-init was not received by the IP address client) or will
      be ignored.  The server can discontinue retransmission of
      Reconfigure-init messages to the server.

   When client once the server
      receives the client's Request.

      It might be possible for a Request and IA option is included duplicate or retransmitted
      Reconfigure-init to be sufficiently delayed (and
      delivered out of order) to arrive at the client is requesting after
      the configuration of a new IA Request/Reply exchange (initiated by the server.
   The server MUST take original
      Reconfigure-init) has been completed.  In this case, the clients IA and associate a binding for
   that
      client in an implementation-specific manner within the servers
   configuration parameter database for DHCP clients.

   If the server cannot provide addresses would initiate a redundant Request/Reply exchange.
      The likelihood of delayed and out of order delivery is small
      enough to be ignored.  The consequence of the client it SHOULD send
   back an empty IA redundant
      exchange is inefficiency rather than incorrect operation.

15.3.2. Creation and sending of Request messages

   When responding to a Reconfigure-init, the client with creates and
   sends the status field set to Unavail.

   If Request message in exactly the server can provide addresses to same manner as outlined in
   section 14.3.1 with the following difference:

      IAs   The client it MUST send back includes IA options containing the IA to addresses the
            client with all fields entered currently has assigned to those IAs for the interface
            through which the Reconfigure-init message was received.

15.3.3. Time out and a status retransmission of Success,
   and add Request messages

   The client uses the IA same variables and retransmission algorithm as it
   does with Request messages generated as part of a new client binding.

   The server adds options to the Reply message for any other client-initiated
   configuration information to be assigned to the client.

13.4.2. exchange.  See section 14.3.1 for details.

15.3.4. Receipt of Confirm Reply messages

   Upon the receipt of a valid Confirm message from a client the server
   can respond to, (implementation-specific administrative policy
   satisfied) the server scans the options field.

   The server then constructs a Reply message and sends it to the
   client.

   The server SHOULD process each option for message, the client in an
   implementation-specific manner.  The server MUST construct a Reply
   message containing the following values:

      msg-type                    REPLY

      preference                  Enter the servers preference to
                                  provide services to the client.

      transaction-ID              Enter the transaction-ID from the
                                  Confirm message.

      client-link-local address   Enter the client-link-local address
                                  from the Confirm message.

      server address              Enter extracts the server's address.

   When
   contents of the server receives a Confirm "options" field, and an IA option is included the sets (or resets) configuration
   parameters appropriately.  The client is requesting confirmation that records and updates the
   lifetimes for any addresses specified in the IA are
   valid.  The server SHOULD locate the clients binding and verify the
   information IAs in the IA from Reply message.
   If the client matches configuration parameters changed were requested by the information stored
   for that client.

   If
   application layer, the server cannot find a client entry for this IA notifies the application layer of the server
   SHOULD return
   changes using an empty IA with status set to NoBinding.

   If implementation-specific interface.

   As discussed in section 15.2.3, the Reply from the server finds may include
   IAs and parameters that were not included in the information for Request message from
   the client.  The client does not
   match what is MUST configure itself with all of the IAs and
   parameters in the servers records for that client Reply from the server
   should send back an empty IA with status set to Conf_NoMatch.

   If server.

16. Relay Behavior

   For this discussion, the server finds a match Relay may be configured to use a list of
   server destination addresses, which may include unicast addresses,
   the Confirm then All DHCP Servers multicast address, or other multicast addresses
   selected by the server should
   send back network administrator.  If the IA to Relay has not been
   explicitly configured, it will use the client with status set to success.

13.4.3. Receipt of Renew messages

   Upon All DHCP Servers multicast
   address as the receipt default.

16.1. Relaying of client messages

   When a valid Renew message from Relay receives a valid client the server
   can respond to, (implementation-specific administrative policy
   satisfied) the server scans the options field.

   The server then message, it constructs
   a Reply Relay-forward message.  The relay places an address from
   the interface on which the client message was received in the
   "relay-address" field and sends it to the
   client.

   The server SHOULD process each option prefix length for the client that address in an
   implementation-specific manner.  The server MUST construct a Reply
   message containing the following values:

      msg-type                    REPLY

      preference                  Enter
   "prefix-length" field.  This address will be used by the servers preference to
                                  provide services server to
   identify the client.

      transaction-ID              Enter link to which the transaction-ID from client is connected and will be used
   by the
                                  Confirm message.

      client-link-local address   Enter relay to forward the client-link-local address Advertise message from the Confirm message. server address              Enter the server's address.

   When back to
   the server receives client.

   The relay constructs a Renew and IA "client-message" option 18.5 that contains
   the entire message from a the client it
   SHOULD locate in the clients binding and verify data field of the information
   option.  The relay places the "relay-message" option along with any
   "relay-specific" options in the
   IA from options field of the client matches Relay-forward
   message.  The Relay then sends the information stored for that client.

   If Relay-forward message to the list
   of server cannot find a client entry for this IA the destination addresses that it has been configured with.

16.2. Relaying of server
   SHOULD return an empty IA with status set to NoBinding.

   If messages

   When the relay receives a Relay-reply message, it extracts the server finds that
   message from the addresses in "server-message" option and forwards the IA for message
   to the client do
   not match address in the clients binding client-link-local-address field in the server should return an empty IA
   with status set to Renw_NoMatch.

   If
   message.  The relay forwards the server cannot Renew addresses for the client it SHOULD send
   back an empty IA to message through the client with interface
   identified in the status "relay-address" field set in the Relay-reply message.

17. Authentication of DHCP messages

   Some network administrators may wish to Unavail.

   If provide authentication of
   the server finds source and contents of DHCP messages.  For example, clients may
   be subject to denial of service attacks through the use of bogus
   DHCP servers, or may simply be misconfigured due to unintentionally
   instantiated DHCP servers.  Network administrators may wish to
   constrain the allocation of addresses to authorized hosts to avoid
   denial of service attacks in "hostile" environments where the IA for network
   medium is not physically secured, such as wireless networks or
   college residence halls.

   Because of the client then risk of denial of service attacks against DHCP
   clients, the use of authentication is mandated in Reconfigure-init
   messages.  A DHCP server SHOULD send back MUST include an authentication option in
   Reconfigure-init messages sent to clients.

   The DHCP authentication mechanism is based on the IA design of
   authentication for DHCP for IPv4 [8].

17.1. DHCP threat model

   The threat to DHCP is inherently an insider threat (assuming a
   properly configured network where DHCPv6 ports are blocked on
   the client with new lease times
   and T1/T2 times if enterprise's perimeter gateways.)  Regardless of the default is not being used, gateway
   configuration, however, the potential attacks by insiders and set status to
   Success.

13.4.4. Receipt of Rebind messages

   Upon
   outsiders are the receipt of a valid Rebind message from same.

   The attack specific to a DHCP client is the server
   can respond to, (implementation-specific administrative policy
   satisfied) possibility of the
   establishment of a "rogue" server scans with the options field.

   The server then constructs a Reply message and sends it intent of providing
   incorrect configuration information to the client.  The server SHOULD process each option motivation
   for doing so may be to establish a "man in the middle" attack or it
   may be for a "denial of service" attack.

   There is another threat to DHCP clients from mistakenly or
   accidentally configured DHCP servers that answer DHCP client in an
   implementation-specific manner. requests
   with unintentionally incorrect configuration parameters.

   The threat specific to a DHCP server MUST construct is an invalid client
   masquerading as a Reply
   message containing the following values:

      msg-type                    REPLY

      preference                  Enter the servers preference valid client.  The motivation for this may be for
   "theft of service", or to
                                  provide services circumvent auditing for any number of
   nefarious purposes.

   The threat common to both the client.

      transaction-ID              Enter client and the transaction-ID from server is the resource
   "denial of service" (DoS) attack.  These attacks typically involve
   the exhaustion of valid addresses, or the exhaustion of CPU or
   network bandwidth, and are present anytime there is a shared
   resource.  In current practice, redundancy mitigates DoS attacks the
                                  Confirm message.

      client-link-local address   Enter
   best.

17.2. Summary of DHCP authentication

   Authentication of DHCP messages is accomplished through the client-link-local address
                                  from use of
   the Confirm message.

      server address              Enter Authentication option.  The authentication information carried
   in the server's address.

   When Authentication option can be used to reliably identify the server receives
   source of a Rebind DHCP message and IA to confirm that the contents of the DHCP
   message have not been tampered with.

   The Authentication option from provides a client it
   SHOULD locate the clients binding and verify framework for multiple
   authentication protocols.  Two such protocols are defined here.
   Other protocols defined in the information future will be specified in separate
   documents.

   The protocol field in the
   IA from Authentication option identifies the client matches
   specific protocol used to generate the authentication information stored for that client.

   If
   carried in the server cannot find option.  The algorithm field identifies a client entry specific
   algorithm within the authentication protocol; for this IA example, the server
   SHOULD return an empty IA with status set
   algorithm field specifies the hash algorithm used to NoBinding.

   If generate the server finds that
   message authentication code (MAC) in the addresses authentication option.  The
   replay detection method (RDM) field specifies the type of replay
   detection used in the IA for replay detection field.

17.3. Replay detection

   The Replay Detection Method (RDM) field determines the client do
   not match type of replay
   detection used in the clients binding Replay Detection field.

   If the server should return an empty IA
   with status RDM field contains 0x00, the replay detection field MUST be
   set to Rebd_NoMatch.

   If the server cannot Rebind addresses for value of a monotonically increasing counter.  Using a
   counter value such as the client it SHOULD send
   back current time of day (e.g., an empty IA to NTP-format
   timestamp [12]) can reduce the danger of replay attacks.  This method
   MUST be supported by all protocols.

17.4. Configuration token protocol

   If the client with protocol field is 0, the status authentication information field set
   holds a simple configuration token.  The configuration token is an
   opaque, unencoded value known to Unavail.

   If both the server finds sender and receiver.  The
   sender inserts the addresses configuration token in the IA for DHCP message and the client then
   receiver matches the
   server SHOULD send back token from the IA message to the client with new lease times
   and T1/T2 times if shared token.  If
   the default configuration option is not being used, present and set status to
   Success.

13.4.5. Receipt of Release messages

   Upon the receipt of a valid Release message, token from the server examines message
   does not match the
   IAs and shared token, the addresses in receiver MUST discard the IAs
   message.

   Configuration token may be used to pass a plain-text configuration
   token and provides only weak entity authentication and no message
   authentication.  This protocol is only useful for validity. rudimentary
   protection against inadvertently instantiated DHCP servers.

   DISCUSSION:

      The intent here is to pass a constant, non-computed token
      such as a plain-text password.  Other types of entity
      authentication using computed tokens such as Kerberos
      tickets or one-time passwords will be defined as separate
      protocols.

17.5. Delayed authentication protocol

   If the IAs in protocol field is 1, the message are in a binding for is using the client and "delayed
   authentication" mechanism.  In delayed authentication, the addresses client
   requests authentication in its Solicit message and the IAs
   have been assigned server replies
   with an Advertise message that includes authentication information.
   This authentication information contains a nonce value generated by
   the server source as a message authentication code (MAC) to those IA, the server deletes
   the addresses from the IAs provide message
   authentication and makes the addresses available for
   assignment to other clients. entity authentication.

   The server then generates a Reply message.  If all use of a particular technique based on the IAs were
   valid and HMAC protocol [10]
   using the addresses successfully released,, MD5 hash [19] is defined here.

17.5.1. Management issues in the delayed authentication protocol

   The "delayed authentication" protocol does not attempt to address
   situations where a client may roam from one administrative domain
   to another, i.e.  interdomain roaming.  This protocol is focused on
   solving the server sets intradomain problem where the
   "status" field to "Success".  If any out-of-band exchange of the IAs were invalid or if
   any a
   shared secret is feasible.

17.5.2. Use of the addresses were not successfully released, Authentication option in the server
   releases none of delayed authentication
   protocol

   In a Solicit message, the addresses in Authentication option carries the message Protocol,
   Algorithm, RDM and sets Replay detection fields, but no Authentication
   information.

   In an Advertise, Request, Renew, Rebind or Confirm message, the "status"
   field to "NoBinding"(section 7.4).

   DISCUSSION:

      What is
   Authentication option carries the behavior Protocol, Algorithm, RDM and Replay
   detection fields and Authentication information.  The format of the server relative to a "partially
      released" IA; i.e., an IA for which some but not all
      addresses are released?

      Can a client send an empty IA to release all addresses
   Authentication information is:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Secret ID (32 bits)                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                     HMAC-MD5 (128 bits)                       |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The following definitions will be used in the IA?

      If description of the IA becomes empty - all addresses are released
   authentication information for delayed authentication, algorithm 1:

   Replay Detection  - can as defined by the server discard any record of RDM field
   K                 - a secret value shared between the IA?

13.4.6. Sending source and
                       destination of Reply messages

   If the Request, Confirm, Renew, Rebind or Release message from the client was originally received by message; each secret has a
                       unique identifier (secret ID)
   secret ID         - the server, unique identifier for the server
   unicasts secret value
                       used to generate the Reply MAC for this message to
   HMAC-MD5          - the link-local address in MAC generating function.

   The sender computes the
   "client-link-local-address" field.

   If MAC using the message was originally received in a Forward-request or
   Forward-release message from a relay, HMAC generation algorithm [10]
   and the server places MD5 hash function  [19].  The entire DHCP message (except
   as noted below), including the Reply DHCP message in header and the options
   field, is used as input to the HMAC-MD5 computation function.  The
   'secret ID' field MUST be set to the identifier of a Response-reply message and unicasts the message secret used to
   generate the relay's address from MAC.

   DISCUSSION:

      Algorithm 1 specifies the original message.

14. use of HMAC-MD5.  Use of a
      different technique, such as HMAC-SHA, will be specified as
      a separate protocol.

      Delayed authentication requires a shared secret key for each
      client on each DHCP Server-Initiated Configuration Exchange

   A server initiates a configuration exchange with which that client may wish
      to force use the DHCP clients protocol.  Each secret key has a unique
      identifier that can be used by a receiver to obtain new addresses and other configuration information.  For
   example, an administrator determine which
      secret was used to generate the MAC in the DHCP message.
      Therefore, delayed authentication may use not scale well in an
      architecture in which a server-initiated configuration
   exchange when links DHCP client connects to multiple
      administrative domains.

17.5.3. Message validation

   To validate an incoming message, the receiver first checks that
   the value in the DHCP domain are replay detection field is acceptable according
   to be renumbered.  Other
   examples include changes the replay detection method specified by the RDM field.  Next,
   the receiver computes the MAC as described in [10].  The receiver
   MUST set the location 'MAC' field of directory servers,
   addition the authentication option to all 0s for
   computation of new services such as printing, the MAC, and availability of new
   software (system or application).

14.1. Reconfigure-init Message Validation

   Agents MUST silently discard any received Reconfigure-init messages.

   Clients because a DHCP relay agent may alter
   the values of the 'giaddr' and 'hops' fields in the DHCP message,
   the contents of those two fields MUST discard any Reconfigure-init messages that do also be set to zero for the
   computation of the MAC. If the MAC computed by the receiver does not contain an authentication option or that fail
   match the MAC contained in the client's authentication check.

   Clients option, the receiver
   MUST discard the DHCP message.

17.5.4. Key utilization

   Each DHCP client has a key, K. The client uses its key to encode
   any Reconfigure-init messages that contain a
   transaction-ID that matches it sends to the transaction-ID in a Reconfigure-init
   message previously received server and to authenticate and verify
   any messages it receives from the same DHCP server.

14.2. Server Behavior

   A server sends a Reconfigure-init message  The client's key SHOULD
   be initially distributed to trigger a the client to
   initiate immediately a Request/Reply message exchange with through some out-of-band
   mechanism, and SHOULD be stored locally on the
   server.  A server may unicast a Reconfigure-init message directly
   to a single client or for use multicast to deliver in all
   authenticated DHCP messages.  Once the client has been given its key,
   it SHOULD use that key for all transactions even if the client's
   configuration changes; e.g., if the client is assigned a Reconfigure-init
   message new network
   address.

   Each DHCP server MUST know, or be able to multiple obtain in a secure manner,
   the keys for all authorized clients.

14.2.1. Creation  If all clients use the same
   key, clients can perform both entity and sending message authentication for
   all messages received from servers.  However, the sharing of Reconfigure-init keys
   is strongly discouraged as it allows for unauthorized clients to
   masquerade as authorized clients by obtaining a copy of the shared
   key.  To authenticate the identity of individual clients, each client
   MUST be configured with a unique key.

17.5.5. Client considerations for delayed authentication protocol

17.5.5.1. Sending Solicit messages

   The server sets

   When the "msg-type" field to RECONFIG. The server
   generates client sends a transaction-ID Solicit message and inserts wishes to use
   authentication, it in includes an Authentication option with the "transaction-ID"
   field. desired
   protocol, algorithm, RDM and replay detection field as described
   in section 17.5.  The server places its address (of appropriate scope) client does not include any authentication
   information in the
   "server-address" field. Authentication option.

17.5.6. Receiving Advertise messages

   The server MAY include client validates any Advertise messages containing an ORO
   Authentication option to inform specifying the client of what delayed authentication protocol
   using the validation test described in section 17.5.3.

   Client behavior if no Advertise messages include authentication
   information has been changed or new information pass the validation test is controlled by local policy
   on the client.  According to client policy, the client MAY choose to
   respond to a Advertise message that has not been added. authenticated.

   The server MUST include an authentication option decision to set local policy to accept unauthenticated messages
   should be made with care.  Accepting an unauthenticated Advertise
   message can make the appropriate
   settings client vulnerable to spoofing and add other
   attacks.  If local users are not explicitly informed that option as the last option in client
   has accepted an unauthenticated Advertise message, the "options"
   field of users may
   incorrectly assume that the Reconfigure-init message.

   The server MAY include a Reconfigure-delay option in a
   Reconfigure-init message client has received an authenticated
   address and is not subject to DHCP attacks through unauthenticated
   messages.

   A client MUST be unicast configurable to a client, discard unauthenticated messages,
   and MUST
   include a Reconfigure-delay option in a Reconfigure-init message to SHOULD be multicast configured by default to discard unauthenticated
   messages.  A client MAY choose to differentiate between Advertise
   messages with no authentication information and Advertise messages
   that do not pass the validation test; for example, a group of clients.

   The server MUST NOT include client might
   accept the former and discard the latter.  If a client does accept an
   unauthenticated message, the client SHOULD inform any other options in local users and
   SHOULD log the Reconfigure-init
   except as specifically allowed in event.

17.5.6.1. Sending Request, Confirm, Renew, Rebind or Release messages

   If the definition of individual
   options.

   The server may either unicast client authenticated the Reconfigure-init Advertise message to one through which the
   client or multicast selected the message to one server, the client MUST generate authentication
   information for subsequent Request, Confirm, Renew, Rebind or more Reconfigure Multicast
   Addresses previously Release
   messages sent as options to the clients.  The server
   may unicast Reconfigure-init messages to more than one as described in section 17.5.  When the
   client
   concurrently; for example, to reliably reconfigure all clients, sends a subsequent message, it MUST use the same secret used
   by the server will unicast a Reconfigure-init message to each client. generate the authentication information.

17.5.6.2. Receiving Reply messages

   If the server unicasts to one or more clients, client authenticated the Advertise it waits for a Request accepted, the client
   MUST validate the associated Reply message from those clients confirming that it has received the
   Reconfigure-init and are thus initiating a Request/Reply transaction
   with the server.  The server can determine that a Request message is
   in response to a Reconfigure-init because the transaction-ID in
   client MUST discard the
   Request will be Reply if the same value as was used in message fails to pass validation
   and MAY log the Reconfigure-init
   message. validation failure.  If the server multicasts Reply fails to pass
   validation, the Reconfigure-init message, it must use
   some TBD authentication mechanism that can authenticate client MUST restart the server DHCP configuration process by
   sending a Solicit message.  The client MAY choose to
   multiple clients.  There is no reliability mechanism for multicast
   Reconfigure-init messages.  A remember which
   server might use multicast in the
   case where it does not have a list of its clients; for example, replied with a
   server Reply message that failed to pass validation
   and discard subsequent messages from that distributes configuration server.

   If the client accepted an Advertise message that did not include
   authentication information to clients using
   stateless autoconfiguration might or did not keep a list of clients it has
   communicated with.

   DISCUSSION:

      Authentication of multicast reconfigure-init is still pass the validation test, the
   client MAY accept an
      open issue.

   See section 18.2 for recommendations on unauthenticated Reply message from the use of multicast server.

17.5.7. Server considerations for delayed authentication protocol

17.5.7.1. Receiving Solicit messages and unicast Reconfigure-init Sending Advertise messages

   The server selects a secret for reliable the client
   reconfiguration.

14.2.2. Time out and retransmission of unicast Reconfigure-init messages

   If includes
   authentication information in the server does not receive a Request Advertise message from returned to the
   client as specified in RECREP_MSG_TIMEOUT milliseconds, the section 17.5.  The server retransmits MUST record the Reconfigure-init message, doubles
   identifier of the RECREP_MSG_TIMEOUT
   value secret selected for the client and waits again. use that same
   secret for validating subsequent messages with the client.

17.5.7.2. Receiving Request, Confirm, Renew, Rebind or Release messages
   and Sending Reply messages

   The server continues this process until
   REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which point uses the server SHOULD abort secret identified in the reconfigure process.

   Default and initial values for RECREP_MSG_TIMEOUT message and
   REC_MSG_ATTEMPTS are documented validates
   the message as specified in section 7.5.

14.2.3. Time out and retransmission of multicast Reconfigure-init
   messages

   After the server transmits 17.5.3.  If the initial Reconfigure-init message, message fails to
   pass validation or the server waits RECREP_MSG_TIMEOUT milliseconds.  The server
   then retransmits does not know the Reconfigure-init message, doubles secret identified by
   the 'secret ID' field, the
   RECREP_MSG_TIMEOUT value and waits again.  The server repeats this
   process until a total of REC_MSG_ATTEMPTS Reconfigure-init messages
   have been transmitted.

   Default and initial values for RECREP_MSG_TIMEOUT MUST discard the message and
   REC_MSG_ATTEMPTS are documented in section 7.5.

14.2.4. Receipt of Request messages

   The MAY
   choose to log the validation failure.

   If the message passes the validation procedure, the server generates and sends Reply message(s) responds
   to the client specific message as described in section 13.4.6, including in the "option" field new
   values for configuration parameters.

14.3. Client Behavior

   A client 14.4.  The server
   MUST always monitor UDP port 546 for Reconfigure-init
   messages on interfaces upon which it has acquired DHCP parameters.
   Since the results of a reconfiguration event may affect application
   layer programs, include authentication information generated using the client SHOULD log these events, and MAY notify
   these programs of secret
   identified in the change through an implementation-specific
   interface.

14.3.1. Receipt of Reconfigure-init received message as specified in section 17.5.

17.5.7.3. Sending Reconfigure-Init messages

   Upon receipt of

   The server MUST include authentication information in a valid Reconfigure-init
   Reconfigure-Init message, generated as specified in section 17.5
   using the client
   initiates a Request/Reply transaction with secret the server.

14.3.2. Creation and sending of Request messages

   When responding to a Reconfigure-init, server initially selected for the client creates and
   sends to
   which the Request Reconfigure-Init message is to be sent.

18. DHCP options

   Options are used to carry additional information and parameters
   in exactly the same manner DHCP messages.  Every option shares a common base format, as outlined
   described in section 13.3.1 with the following differences:

      transaction-ID                 The client copies the
                                     transaction-ID from 18.1.

   This document describes the
                                     Reconfigure-init message into DHCP options defined as part of the
                                     Request message.

      IAs                            The client includes IA base
   DHCP specification.  Other options
                                     containing may be defined in the addresses future in a
   separate document.

18.1. Format of DHCP options

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          option-code          |           option-len          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          option-data                          |
     |                      (option-len octets)                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code   An unsigned integer identifying the client
                                     currently has assigned to those IAs
                                     for specific option
                    type carried in this option.

      option-len    An unsigned integer giving the interface through which length of the Reconfigure-init message was
                                     received.

      Pause before sending Request data in
                    this option in octets.

      option-data   The client pauses before sending
                                     the Request data for a random value
                                     within the range REC_REP_MIN and
                                     REC_REP_MAX seconds.  This delay
                                     helps reduce option; the load format of this data
                    depends on the
                                     server generated by processing
                                     large numbers of triggered
                                     Request messages from a multicast
                                     Reconfigure-init message.

14.3.3. Time out and retransmission definition of Request messages

   The client uses the same variables and retransmission algorithm as it
   does with Request messages generated as part of option.

18.2. DHCP unique identifier option

   The DHCP unique identifier option is used to carry a client-initiated
   configuration exchange.  See section 13.3.1 DUID. The format
   for details.

14.3.4. Receipt of Reply messages

   Upon the receipt of a valid Reply message, the client extracts DUID is keyed to mark the
   contents type of the "option" field, identifier and sets (or resets) configuration
   parameters appropriately. is of
   variable length.  The client records and updates the
   lifetimes for any addresses specified in IAs in format of the Reply message.
   If DUID option is:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          OPTION DUID          |          option-len           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           DUID type           |           DUID len            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             DUID                              |
     .                                                               .
     .                                                               .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

18.3. Identity association option

   The identity association option is used to carry an identity
   association, the configuration parameters changed were requested by the
   application layer, the client notifies the application layer of the
   changes using an implementation-specific interface.

15. Relay Behavior

   For this discussion, associated with the Relay may be configured to use a list of
   server destination addresses, which may include unicast addresses, IA and the All DHCP Servers multicast address, or other multicast addresses
   selected by the network administrator.  If
   assigned to the Relay has not been
   explicitly configured, it will use IA.

   The format of the All DHCP Servers multicast IA option is:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           OPTION IA           |          option-len           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        IAID (4 octets)                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              T1                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              T2                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   IA status   |   num-addrs   |T| addr status | prefix length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         IPv6 address as                          |
     |                          (16 octets)                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      preferred lifetime                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        valid lifetime                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |T| addr status | prefix length |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                         IPv6 address                          |
     |                          (16 octets)                          |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |      preferred lifetime       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | pref. lifetime (cont.)        |        valid lifetime         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | valid lifetime (cont.)        |T| addr status | prefix length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         IPv6 address                          |
     |                          (16 octets)                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              ...                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code          OPTION_IA (1)

      option-len           Variable; equal to 24 + num-addrs*26

      IA ID                The unique identifier for this IA; chosen by
                           the default.

15.1. Relaying of client messages

   When a Relay receives a valid client message, it constructs
   a Relay-forward message.

      T1                   The relay places an address from
   the interface on time at which the client message was received in the
   "relay-address" field and the prefix length for that address in the
   "prefix-length" field.  This address will be used by contacts the
                           server to
   identify the link to from which the client is connected and will be used
   by addresses in the relay IA
                           were obtained to forward extend the Advertise message from lifetimes of the server back
                           addresses assigned to the client. IA.

      T2                   The relay constructs a "client-message" option 16.4 that contains
   the entire message from time at which the client in the data field of the
   option.  The relay places the "relay-message" option along with contacts any
   "relay-specific" options in
                           available server to extend the options field lifetimes of
                           the Relay-forward
   message.  The Relay then sends the Relay-forward message addresses assigned to the list
   of server destination addresses that it has been configured with.

15.2. Relaying of server messages IA.

      T                    When set to 1, indicates that this address is
                           a "temporary address" [15]; when set to 0,
                           the relay receives address is not a Relay-reply message, it extracts temporary address.

      IA status            Status of the server
   message from IA in this option.

      num-addrs            An unsigned integer giving the "server-message" number of
                           addresses carried in this IA option and forwards (MAY be
                           zero).

      addr status          Status of the addresses in this IA.

      prefix length        Prefix length for this address.

      IPv6 address         An IPv6 address assigned to this IA.

      preferred lifetime   The preferred lifetime for the message
   to associated
                           IPv6 address.

      valid lifetime       The valid lifetime for the associated IPv6
                           address.

   The "IPv6 address", "preferred lifetime" and "valid lifetime" fields
   are repeated for each address in the client-link-local-address field in the server
   message.  The relay forwards IA option (as determined by the server message through
   "num-addrs" field).

   Note that an IA has no explicit "lifetime" or "lease length" of
   its own.  When the interface
   identified in lifetimes of all of the "relay-address" field addresses in an IA have
   expired, the Relay-reply message.

16. DHCP options

   Options IA can be considered as having expired.  T1 and T2
   are used included to carry additional information and parameters
   in DHCP messages.  Every option shares give servers explicit control over when a common base format, as
   described in section 16.1.

   this document describes the DHCP options defined as part of client
   recontacts the base
   DHCP specification.  Other options may be defined in server about a specific IA.

   The 'T' bit identifies the future in associated address as a
   separate document.

16.1. Format of DHCP options

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          option-code          |           option-len          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          option-data                          |
     |                      (option-len octets)                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code An unsigned integer identifying temporary address.
   If the specific option
                type carried in this option.

      option-len An unsigned integer giving server is configured to assign temporary addresses to the length of
   client, the data in
                this option in octets.

      option-data server marks those temporary addresses with the 'T'
   bit.  The data for number of temporary addresses assigned to the option; client and
   the format lifetimes of this data
                depends on those addresses is determined by the definition administrative
   configuration of the option.

16.2. Identity association option server.  The identity association option is used to carry 'T' bit only identifies an identity
   association, the parameters associated with address
   as a temporary address; identification of an address as ``temporary''
   has no implication on the IA and lifetime of the addresses
   assigned to extensibility of the IA.

   The format
   lifetime of the IA address.

18.4. Option request option is:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           OPTION IA           OPTION_ORO          |           option-len          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            IA DUID                            |
     |                          (8 octets)                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              T1                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              T2                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   IA status   |   num-addrs   |  addr status  | prefix length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         IPv6 address                          |
     |                          (16 octets)                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      preferred lifetime                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        valid lifetime                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  addr status  | prefix length |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                         IPv6 address                          |
     |                          (16 octets)                          |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |      preferred lifetime       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | pref. lifetime (cont.)    requested-option-code-1    |        valid lifetime    requested-option-code-2    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | valid lifetime (cont.)        |         IPv6 address          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                              ...                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code OPTION_IA (1)   OPTION_ORO (2)

      option-len    Variable; equal to 18 + num-addrs*25

      IA DUID   The unique identifier for this IA; chosen by the client

      T1        The time at which the client contacts the server from
                which the addresses in the IA were obtained to extend
                the lifetimes of the addresses assigned to the IA.

      T2        The time at which the client contacts any available
                server to extend the lifetimes of the addresses assigned
                to the IA.

      IA status Status of the IA in this option.

      num-addrs An unsigned integer giving twice the number of addresses option codes
                    carried in this IA option (MAY be zero).

      addr status Status option.

      option-data   A list of this address.

      prefix length Prefix length for this address.

      IPv6 address An IPv6 address assigned to this IA.

      preferred lifetime The preferred lifetime for the associated IPv6
                address.

      valid lifetime The valid lifetime option codes for the associated IPv6 address.

   The "IPv6 address", "preferred lifetime" and "valid lifetime" fields
   are repeated for each address options requested
                    in the IA this option.

18.5. Client message option (as determined by the
   "num-addrs" field).

   DISCUSSION:

      The details of the format and

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       OPTION_CLIENT_MSG       |           option-len          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       DHCP client message                     |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code   OPTION_CLIENT_MSG (3)

      option-len    Variable; equal to the selection of an IA's DUID
      are TBD.

   Note that an IA has no explicit "lifetime" or "lease length" length of
   its own.  When the lifetimes of all of forwarded DHCP
                    client message.

      option-data   The message received from the addresses in an IA have
   expired, client; forwarded
                    verbatim to the IA can be considered as having expired.  T1 and T2
   are included server.

18.6. Server message option

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       OPTION_SERVER_MSG       |           option-len          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       DHCP server message                     |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code   OPTION_SERVER_MSG (4)

      option-len    Variable; equal to give servers explicit control over when a client
   recontacts the length of the forwarded DHCP
                    server about a specific IA.

16.3. Option request message.

      option-data   The message received from the server; forwarded
                    verbatim to the client.

18.7. Retransmission parameter option

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           OPTION_ORO      OPTION_RETRANS_PARM      |           option-len          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    requested-option-code-1    |    requested-option-code-2                          option-data                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              ...                      (option-len octets)                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code OPTION_ORO (2)   OPTION_RETRANS_PARM (5)

      option-len Variable; equal to twice    An unsigned integer giving the number length of option codes
                carried the data in
                    this option. option in octets.

      option-data A list   TBD - The details of the operational parameters to
                    be set in the client

18.8. DSTM Global IPv4 Address Option

   The DSTM Global IPv4 Address Option informs a client or server that
   the Identity Association Option (IA) following this option codes for will
   contain an IPv4-Mapped IPv6 Address [9] in the options requested case of a Client
   receiving the option, or is a Request for an IPv4-Mapped IPv6 Address
   from a client in this the case of a DHCPv6 Server receiving the option.

16.4. Client message
   The option can also provide a set of IPv6 addresses to be used as the
   Tunnel Endpoint (TEP) to encapsulate an IPv6 packet within IPv6.

   This option can be used with the Request, Reply, and Reconfigure-Init
   Messages for cases where a server wants to assign to clients
   IPv4-Mapped IPv6 Addresses, thru the Option Request Option (ORO).

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       OPTION_CLIENT_MSG          OPTION_DSTM          |           option-len             option-length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       DHCP client message                          Tunnel End Point (TEP)               |
   |                           (If Present)                        |
   |                            (16 octets)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code OPTION_CLIENT_MSG (3)

      option-len Variable; equal

      option code        OPTION_DSTM (7)

      option length      Variable:  0 or multiple of 16

      tunnel end point   IPv6 Address or addresses if Present

   A DSTM IPv4 Global Address Option MUST only apply to the length of IA following
   this option.

18.9. Authentication option

   The Authentication option carries authentication information to
   authenticate the forwarded identity and contents of DHCP
                client message.

      option-data messages.  The message received from use of
   the client; forwarded
                verbatim to Authentication option is described in section 17.

   The format of the server.

16.5. Server message Authentication option is:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       OPTION_SERVER_MSG          OPTION_AUTH          |           option-len        option-length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       DHCP server message   Protocol    |   Algorithm   |      RDM      | Replay detect.|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Replay Detection (64 bits)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Replay cont.                  | Auth. Info    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |           Authentication Information                          |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code OPTION_SERVER_MSG (4)

      option-len Variable; equal                  OPTION_AUTH (TBD)
      option-length                Variable

      protocol                     The authentication protocol used in
                                   this authentication option

      algorithm                    The algorithm used in the
                                   authentication protocol

      RDM                          The replay detection method used in
                                   this authentication option

      Replay detection             The replay detection information for
                                   the RDM

      Authentication information   The authentication information,
                                   as specified by the protocol and
                                   algorithm used in this authentication
                                   option

18.10. Server unicast option

   This option is used by a server to send to a client to inform the length of
   client it can send a Request, Renew, Confirm, Release, and Decline by
   unicasting directly to the forwarded DHCP server message.

      option-data The message received from instead of the server; forwarded
                verbatim ALL-DHCPv6-Agents
   Multicast address as an optimization, when the client as an address
   of sufficient scope to reach the client.

16.6. Retransmission parameter option server.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      OPTION_RETRANS_PARM      |           option-len          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          option-data                          |          OPTION_UNICAST  |                      (option-len octets)             option-length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code OPTION_RETRANS_PARM (5)

      option-len An unsigned integer giving the length of the data in
                this     OPTION_UNICAST (TBD)

      option-length   0

   This option in octets.

      option-data TBD - The details of the operational parameters only applies to be
                set in the client

16.7. Reconfigure-delay option

   The Reconfigure-delay option specifies server address that sends this to the amount
   client.

18.11. Domain Search Option

   This option provides a list of time domain names a client
   should delay before sending a Request message in response can use to a
   Reconfigure-init message.
   resolve DNS names.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      OPTION_RECONF_DELAY   OPTION_DOMAIN_SEARCH_LIST   |           option-len         option-length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   minimum delay time (msec)                      Domain Search List                       |   maximum delay time (msec)
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code OPTION_RECONF_DELAY (6)

      option-len An unsigned integer giving the length of the data in
                this option in octets.

      minimum delay time An unsigned integer giving the minimum delay
                time in milliseconds

      maximum delay time An unsigned integer giving the maximum delay
                time in milliseconds

      msg type                    OPTION_DOMAIN_SEARCH_LIST (TBD)

      option-length               variable

      Domain Search List          The DNS domain search list the client chooses a random number between
                                  should use to resolve names.

   So that the minimum delay time search list may be encoded compactly and uniformly,
   search strings in the maximum delay time search list are concatenated and delays that number of milliseconds before
   sending its Request message.

16.8. DSTM Global IPv4 Address Option

   The DSTM Global IPv4 Address Option informs a client or server that encoded using
   the Identity Association Option (IA) following this option will
   contain an IPv4-Mapped IPv6 Address [7] technique described in the case section 4.1 of a Client
   receiving the option, or is a Request for an IPv4-Mapped IPv6 Address
   from a client [13].

   For use in this specification, the case compression pointer (see section
   4.1.4 of a DHCPv6 Server receiving the option.
   The option can also provide an IPv6 address [13]) refers to be used as the Tunnel
   Endpoint (TEP) to encapsulate an IPv4 packet offset within IPv6. the SearchString portion
   of the option.

18.12. Domain Name Server Option

   This option provides a list of Domain Name System [13] that a client
   name resolver can use to access DNS services.  There must be used with the Request, Reply, and Reconfigure-Init
   Messages for cases where a at least
   1 server wants to assign to clients
   IPv4-Mapped IPv6 Addresses, thru the Option Request Option (ORO). listed in this option.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          OPTION_DSTM      OPTION_DNS_SERVERS       |         option_length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                   DNS server (IP address)                     |
   |                                                               |
   |             option-length                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Tunnel End Point (TEP)                                                               |
   |                           (If Present)                   DNS server (IP address)                     |
   |                                                               |
   |                            (16 octets)                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      option code OPTION_DSTM (7)

      option length Variable:  0 or 16

      tunnel end point
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      msg-type             OPTION_DNS_SERVERS (TBD)

      option-length        variable

      DNS server           IPv6 Address if Present

   A DSTM IPv4 Global Address Option MUST only apply to address of a DNS name server for the IA following
   this option.

16.9. Authentication option
                           client to use.  The authentication option is TBD.

17. DNS servers are listed in
                           the order of preference for use by the client
                           resolver.

19. DHCP Client Implementor Notes

   This section provides helpful information for the client implementor
   regarding their implementations.  The text described here is not part
   of the protocol, but rather a discussion of implementation features
   we feel the implementor should consider during implementation.

17.1.

19.1. Primary Interface

   Since configuration parameters acquired through DHCP can be
   interface-specific or more general, the client implementor SHOULD
   provide a mechanism by which the client implementation can be
   configured to specify which interface is the primary interface.  The
   client SHOULD always query the DHCP data associated with the primary
   interface for non-interface specific configuration parameters.  An
   implementation MAY implement a list of interfaces which would be
   scanned in order to satisfy the general request.  In either case, the
   first interface scanned is considered the primary interface.

   By allowing the specification of a primary interface, the client
   implementor identifies which interface is authoritative for
   non-interface specific parameters, which prevents configuration
   information ambiguity within the client implementation.

17.2.

19.2. Advertise Message and Configuration Parameter Caching

   If the hardware the client is running on permits it, the implementor
   SHOULD provide a cache for Advertise messages and a cache of
   configuration parameters received through DHCP. Providing these
   caches prevents unnecessary DHCP traffic and the subsequent load
   this generates on the servers.  The implementor SHOULD provide a
   configuration knob for setting the amount of time the cache(s) are
   valid.

17.3.

19.3. Time out and retransmission variables

   Note that the client time out and retransmission variables outlined
   in section 7.5 can be configured on the server and sent to the client
   through the use of the "DHCP Retransmission Parameter Option", which
   is documented in section 16.6. 18.7.  A client implementation SHOULD be
   able to reset these variables using the values from this option.

17.4.

19.4. Server Preference

   A client MUST wait for SRVR_PREF_WAIT seconds after sending a DHCP
   Solicit message to collect Advertise messages and compare their
   preferences (see section 18.3), 20.3), unless it receives an Advertise
   message with a preference of 255.  If the client receives an
   Advertise message with a preference of 255, then the client MAY act
   immediately on that Advertise without waiting for any more additional
   Advertise messages.

18.

20. DHCP Server Implementor Notes

   This section provides helpful information for the server implementor.

18.1.

20.1. Client Bindings

   A server implementation MUST use the IA's DUID and the prefix
   specification from which the client sent its Request message(s) as an
   index for finding configuration parameters assigned to the client.
   While it isn't critical to keep track of the other parameters
   assigned to a client, the server MUST keep track of the addresses it
   has assigned to an IA.

   The server should periodically scan its bindings for addresses whose
   leases have expired.  When the server finds expired addresses, it
   MUST delete the assignment of those addresses, thereby making these
   addresses available to other clients.

   The client bindings MUST be stored in non-volatile storage.

   The server implementation should provide policy knobs to control
   whether or not the lifetimes on assigned addresses are renewable, and
   by how long.

18.2.

20.2. Reconfigure-init Considerations

   A server implementation MUST provide an interface to the
   administrator for initiating reconfigure-init events.

   A server implementation may provide a mechanism for allowing the
   specification of how many clients comprise a reconfigure multicast
   group.  This enables the administrator to control the processing load
   impact of the multicast of a Reconfigure-init message.

18.2.1. Reliable transmission of multicast Reconfigure-init messages

   Because clients will ignore Reconfigure-init messages with the
   same transaction-ID, a server can retransmit a Reconfigure-init
   message (using the same transaction-ID) without causing any
   client to reply more than once.  A server SHOULD retransmit a
   multicast Reconfigure-init message several times to maximize the
   probability that all clients in the multicast group have received the
   Reconfigure-init message.

   If a server does not receive a Reply message from some clients in a
   multicast group, the server MAY choose to unicast a Reconfigure-init
   message to those clients.  Because the clients may have received the
   multicast Reconfigure-init messages while the server did not receive
   the clients' Reply messages, the server SHOULD use a different
   transaction-ID in the unicast Reconfigure-init messages to trigger
   the client to reconfigure.

18.3. for initiating reconfigure-init events.

20.3. Server Preference

   The server implementation SHOULD allow the setting of a server
   preference value by the administrator.  The server preference
   variable is an unsigned single octet value (0--255), with the lowest
   preference being 0 and the highest 255.  Clients will choose higher
   preference servers over those with lower preference values.  If you
   don't choose to implement this feature in your server, you MUST set
   the server preference field to 0 in the Advertise messages generated
   by your server.

18.4. Request Message Transaction-ID Cache

   In order to improve performance, a server implementation MAY include
   an in memory transaction-ID cache.  This cache is indexed by client
   binding and transaction-ID, and enables the server to quickly
   determine whether a Request is a retransmission or a new Request
   without the cost of a database lookup.  If an implementor chooses to
   implement this cache, then they SHOULD provide a configuration knob
   to tune the lifetime of the cache entries.

19. DHCP Relay Implementor Notes

   A relay implementation SHOULD allow the specification of a list of
   destination addresses for forwarded messages.  This list MAY contain
   any mixture of unicast addresses and multicast addresses.

   If a relay receives an ICMP message in response to a DHCP message it
   has forwarded, it SHOULD log this event.

20. Open Issues for Working Group Discussion

   This section contains some items for discussion by the working group.

20.1. Authentication

   Authentication is not discussed in this document.  Authentication
   will be modeled on DHCPv4 authentication.  Authentication of
   multicast Reconfigure-init messages is a special problem.

20.2. Identification of IAs by servers

   Do servers identify an IA just by its DUID or by <prefix, DUID>?  If
   just by DUID, are DUIDs guaranteed unique (within the DHCP universe)?
   If so, how is that guarantee implemented?

20.3. DHCP-DNS interaction

   Interaction among DHCP servers, clients and DNS servers is not
   discussed in this document.

20.4. Temporary addresses

   How does DHCPv6 interact with temporary addresses? lower preference values.  If you
   don't choose to implement this feature in your server, you MUST set
   the server
   assigns temporary addresses (e.g., addresses with short lifetimes),
   how can preference field to 0 in the Advertise messages generated
   by your server.

20.4. Request Message Transaction-ID Cache

   In order to improve performance, a client application choose server implementation MAY include
   an temporary address as a source
   address in preference memory transaction-ID cache.  This cache is indexed by client
   binding and transaction-ID, and enables the server to quickly
   determine whether a non-temporary address?

20.5. Use of term "agent"

   The term "agent", taken to mean "relay agent or server", may be
   confusing.  "relay agent or server" might be clearer.

20.6. Client behavior when response to Rebind Request is not received

   Section 13.3.4 describes several plausible ways in which a client
   might respond when it does not receive retransmission or a Reply to new Request
   without the cost of a Rebind message.
   The acceptable client behaviors need database lookup.  If an implementor chooses to be defined and described
   in 13.3.4.

20.7. Additional options

   Which additional options should be included in
   implement this base spec
   document?

20.8. Operational parameters

   Should servers have an option cache, then they SHOULD provide a configuration knob
   to set operational parameters -
   retransmission timeouts, number tune the lifetime of retries - in clients? the cache entries.

21. Security

   This document references an "authentication option" which is TBD.

   DISCUSSION:

      Based on DHCP Relay Implementor Notes

   A relay implementation SHOULD allow the discussion specification of security issues at the 8/31/00
      design team teleconference and subsequent DHC WG mailing a list discussion, DHCPv6 will use the security model from
      DHCPv4, as described of
   destination addresses for forwarded messages.  This list MAY contain
   any mixture of unicast addresses and multicast addresses.

   If a relay receives an ICMP message in draft-ietf-dhc-authentication-16.txt
      (which is soon response to be an RFC). a DHCP message it
   has forwarded, it SHOULD log this event.

22. Security

   Section 17 describes a threat model and an option that provides an
   authentication framework to defend against that threat model.

23. Year 2000 considerations

   Since all times are relative to the current time of the transaction,
   there is no problem within the DHCPv6 protocol related to any
   hardcoded dates or two-digit representation of the current year.

23.

24. IANA Considerations

   This document defines several new name spaces associated with DHCPv6
   and DHCPv6 options.  IANA is requested to manage the allocation of
   values from these name spaces.

   New values in each of these name spaces should be approved by the
   process of IETF Consensus [14].

24.1. DHCPv6 options

   This document defines message types TBD to be received by UDP at port
   numbers 546 and 547.  Additional message types may be defined in the
   future.

24.2. Multicast addresses

   Section 7.1 lists several multicast addresses used by DHCP.

   This document also
   Additional multicast addresses may be defined in the future.

24.3. Status codes

   Section 9.7 defines several status codes that are to be returned with
   the Reply message (see section 9.7). message.  The non-zero values for these status codes which that
   are currently specified are shown in the table in section 7.4.

24.4. Retransmission parameter option

   There is a DHCPv6 option described in section 16.6, 18.7, which allows
   clients and servers to exchange values for some of the timing
   and retransmission parameters defined in section 7.5.  Adding new
   parameters in the future would require extending the values by which
   the parameters are indicated in the DHCP option.  Since there needs
   to be a list kept, the default values for each parameter should also
   be stored as part of the list.

   All

24.5. Authentication option

   Section 17 defines three new name spaces associated with the
   Authentication Option (section 18.9), which are to be created and
   maintained by IANA: Protocol, Algorithm and RDM.

   Initial values assigned from the Protocol name space are 0 (for the
   configuration token Protocol in section 17.4) and 1 (for the delayed
   authentication Protocol in section 17.5).  Additional protocols may
   be defined in the future.

   The Algorithm name space is specific to individual Protocols.  That
   is, each Protocol has its own Algorithm name space.  The guidelines
   for assigning Algorithm name space values for a particular protocol
   should be specified along with the definition of a new Protocol.

   For the configuration token Protocol, the Algorithm field MUST be
   0, as described in section 17.4.  For the delayed authentication
   Protocol, the Algorithm value 1 is assigned to the HMAC-MD5
   generating function as defined in section 17.5.  Additional
   algorithms for the delayed authentication protocol may be defined in
   the future.

   The initial value of 0 from the RDM name space is assigned to the
   use of these protocol elements a monotonically increasing value as defined in section 17.3.
   Additional replay detection methods may be specified to assume new values
   at some point defined in the future.  New values should be approved by the
   process of IETF Consensus [9].

24.

25. Acknowledgments

   Thanks to the DHC Working Group for their time and input into the
   specification.  Ralph Droms and Thomas Narten have had a major
   role in shaping the continued improvement of the protocol by their
   careful reviews.  Many thanks to Matt Crawford, Erik Nordmark, Gerald
   Maguire, and Mike Carney for their studied review as part of the
   Last Call process.  Thanks also for the consistent input, ideas, and
   review by (in alphabetical order) Brian Carpenter, Francis DuPont,
   Ted Lemon, Jack McCann, Yakov Rekhter, Matt Thomas, Sue Thomson,
   Bernie Volz and Phil Wells.

   Thanks to Steve Deering and Bob Hinden, who have consistently
   taken the time to discuss the more complex parts of the IPv6
   specifications.

   Bill Arbaugh reviewed the authentication mechanism described in
   section 17.

   The Domain Search option described in section 18.11 is based on the
   DHCPv4 domain search option, [1], and was reviewed by Bernard Aboba.

A. 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 [6, 1] [7, 2] and DHCPv6.
   There are three key reasons for the differences:

     o IPv6 inherently supports a new model and architecture for
       communications and autoconfiguration of addresses.

     o DHCPv6 benefits from the new IPv6 features.

     o New features were added to support the expected evolution and
       the existence of more complicated Internet network service
       requirements.

   IPv6 Architecture/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 an on-link server or
       relay.

     o The need for BOOTP compatibility and the broadcast flag have been
       removed.

     o Multicast and address scoping in IPv6 permit the design of
       discovery packets that would inherently define their range by the
       multicast address for the function required.

     o Stateful autoconfiguration has to coexist and integrate with
       stateless autoconfiguration supporting Duplicate Address
       Detection and the two IPv6 lifetimes, to facilitate the dynamic
       renumbering of addresses and the management of those addresses.

     o Multiple addresses per interface are inherently supported in
       IPv6.

     o Some DHCPv4 options are unnecessary now because the configuration
       parameters are either obtained through IPv6 Neighbor Discovery or
       the Service Location protocol [14]. [21].

   DHCPv6 Architecture/Model Changes:

     o The message type is the first octet in the packet.

     o IPv6 Address allocations are now handled in a message option as
       opposed to the message 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 off-link server
       through an on-link relay.

     o Servers are discovered by a client Solicit, followed by a server
       Advertise message

     o The client will know if the server is on-link or off-link.

     o The on-link relay may locate off-link server addresses from
       system configuration or by the use of a site-wide multicast
       packet.

     o ACKs and NAKs are not used.

     o The server assumes the client receives its responses unless it
       receives a retransmission of the same client request.  This
       permits recovery in the case where the network has faulted.

     o Clients can issue multiple, unrelated Request messages to the
       same or different servers.

     o The function of DHCPINFORM is inherent in the new packet design;
       a client can request configuration parameters other than IPv6
       addresses in the optional option headers.

     o Clients MUST listen to their UDP port for the new Reconfigure
       Reconfigure-init message from servers.

     o New options have been defined.

   With the changes just enumerated, we can support new user features,
   including
     o Configuration of Dynamic Updates to DNS

     o Address deprecation, for dynamic renumbering.

     o Relays can be preconfigured with server addresses, or use of
       multicast.

     o Authentication

     o Clients can ask for multiple IP addresses.

     o Addresses can be reclaimed using the Reconfigure-init message.

     o Integration between stateless and stateful address
       autoconfiguration.

     o Enabling relays to locate off-link servers.

B. Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However,
   this document itself may not be modified in any way, such as by
   removing the copyright notice or references to the Internet Society
   or other Internet organizations, except as needed for the purpose
   of developing Internet standards in which case the procedures
   for copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

C. Changes in this draft

   This section describes the changes between this version of the DHCPv6
   specification and draft-ietf-dhc-dhcpv6-16.txt. draft-ietf-dhc-dhcpv6-19.txt.

C.1. New messages for confirming addresses and extending the lease on an
   IA

   Four new messages, DHCP Confirm, DHCP Renew, DHCP Rebind and DHCP
   Decline, have been added and are Reconfigure-init

   The client behavior in response to a Reconfigure-init message
   described in section 13.  Client
   behavior 15 has been changed.  When the client receives
   a Reconfigure-init message, the client goes into "Reconfigure"
   mode.  The client initiates a Request/Reply exchange in which the
   XID in client Request is independent of server Reconfigure-init XID.
   The server waits for the next Request message from the client to
   determine if the client has received the Reconfigure-init.

   To avoid redundant Request/Reply messages exchanges, the client
   ignores subsequent Reconfigure-init messages until it completes the
   Request/Reply exchange.

   Use of multicast for Reconfigure-init message delivery has been
   removed:

    -  Multicast only saves, at most, 1/3 of the messages when
       reconfiguring multiple clients

    -  Multicast might cause an implosion of Request messages;
       additional complexity in the client and how protocol messages would
       be required to send these new add delay to spread out Request messages

    - and server
   behavior - how  Authentication of multicast Reconfigure-init messages (where a
       single message must be authenticated by multiple clients) is an
       open problem

   Text has been added clarifying that the ORO option applies to respond IAs as
   well as other options.  The server may choose to each - omit the IA option
   from the ORO in the Reconfigure-init message.

   The Reconfigure-delay option (used only by multicast
   Reconfigure-init) has been defined. removed.

   The transaction ID feild in the Reconfigure-init message
   type codes for these messages have header is
   now marked as "(unused) MUST be zero".

C.2. Authentication

   DHCPv4-style authentication has been added to this draft in
   section 7.3.

C.2. New 17.

C.3. Confirm message formats

   Section 9 has been restructured to include only one copy

   The following DISCUSSION was removed from the description of the DHCP
   message header, because now all
   Confirm message:

   DISCUSSION:

      This section used to allow servers to change the addresses
      in an IA. Without some additional mechanism, servers
      responding to Confirm messages have the same header
   format.  Descriptions of can't change safely
      change the use of header fields addresses in IAs (although they can change
      the Confirm,
   Renew, lifetimes), because servers may send back different
      addresses.

C.4. Failure of Rebind and Decline messages have been added to 9.

C.3. Renamed Server-forward message

   Section 10.2 has been renamed "relay-reply"

   In section 14.3.4, the alternatives for consistency with client behavior in the
   rest of
   case that the document

C.4. Clarified relay forwarding of messages

   Added text to sections on relay behavior client receives no response to clarify encapsulation a Rebind message were
   taken out of a DISCUSSION section and
   decapsulation made part of client messages in Relay-forward the spec.  These
   alternatives are really an implementation issue and Relay-reply
   messages. not part of the
   DHCPv6 spec.

C.5. Addresses and options Server behavior in response to Release message

   The following DISCUSSION was merged into the text describing server
   behavior in response to a Release message in Advertise messages

   Modified section 12.4.2 so that servers include 14.4.5:

   DISCUSSION:

      What is the behavior of the server relative to a "partially
      released" IA; i.e., an IA for which some but not all
      addresses are released?

      Can a client send an empty IA to be
   assigned and other options release all addresses in Advertise messages.  Also
      the IA?

      If the IA becomes empty - all addresses are released - can
      the server discard any record of the IA?

C.6. Client behavior when sending a Release message

   Text has been added text to section 12.3.1 14.3.6 clarifying that a client MAY
   (but not MUST) wait for a Reply to disallow option values (except as noted in option
   definitions) in Solicit messages.

C.6. Clarification of a Release message.

C.7. IA option

   The format

   Changed the label of diagram has been corrected to include the prefix length field
   and address status with each address.  PROPOSAL - use left-most bit
   in address status to indicate whether an IA address is "temporary".

C.8. DSTM option to
   "prefix length" in the

   Definition of DSTM option format diagram, and moved the prefix
   before the address for consistency with relay messages and other has been updated to carry multiple IPv6
   protocols.

C.7. Specification of transaction ID
   addresses as tunnel endpoints.

C.9. Server unicast option

   An option to allow clients to use unicast where possible has been
   added in Solicit message

   Add text (which was missing) section 18.10.

C.10. Domain search option

   An option to specify the insertion of pass a
   transaction ID domain name search list to a client has been
   added in Solicit messages.

C.8. Edits section 18.11.

C.11. DNS servers option

   An option to definitions

   Some pass a list of the definitions DNS options to a client has been added in
   section 6 have been edited for clarity.

C.9. Relay agent messages 18.12.

C.12. DUID and IAID

   The formats of relay agent messages are now described in "DHCP unique identifier" is defined as a separate
   section, 10.

C.10. Relay agent behavior typed, variable length
   value (see section 18.2).  The behavior of relay agents for all client and server messages DUID is
   now described carried in a single section, 15.

C.11. Transmission of all client messages through relays

   All client messages are now multicast to an option.  The
   details of the All Agents multicast
   address and forwarded by relays DUID are TBD.

   The "IA identifier" is defined as appropriate.

C.12. Reconfigure-init messages

   Client behavior in response a 4 octet identifier, unique among
   all IAIDs for IAs from a client.

C.13. Continuing to poll with Solicit

   Text has been added to section 13.3.2 allowing a Reconfigure-init client to continue
   to send Solicit messages at low frequency indefinitely.

C.14. Using DHCPv6 without address assignment

   Text has been extended added to accommodate receipt of multiple copies of section 14.3.1 allowing a
   Reconfigure-init client to send a
   Solicit message due containing no IAs to duplicate messages or retransmission.

   Server use request other configuration
   information without address assignment (equivalent to DHCPv4
   DHCPINFORM).

C.15. Potential crossing in flight of multicast Request and Reconfigure-init
   messages

   Text has been specified.

   Hints about use of multicast and unicast for reliable reconfiguration
   have been added to section 15 addressing the case in which the
   client sends a Request after a server implementor's hints.

C.13. Ordering of sections

   Several sections have been re-ordered for clarity.

C.14. DSTM option

   The DSTM option has been added (section 16.8).

C.15. Message and option numbering

   (In rev -18) Replaced TBD sent a Reconfigure-init but
   before the client receives the Reconfigure-init.

D. Open Issues for message Working Group Discussion

   This section contains some items for discussion by the working group.

D.1. Generation and option code numbering with
   names use of DUID and temporary values.

C.16. Inclusion IAID

   Details for generation and use of IAs in Solicit message by DUID and IA identifiers is TBD.

D.2. Address registration

   Should there be a way for a DHCP client

   Added text to section 12.3.1 explaining that clients include empty
   IA(s) in register stateless
   autoconfig addresses with the server?

D.3. Prefix advertisement

   Can a Solicit message and DHCP server advertise prefixes?  This function might be used
   to section 12.3.3 explaining that provide managed temporary addresses - the server advertises a
   prefix and the client then registers selected addresses with the DHCP
   server.

D.4. DHCP-DNS interaction

   Interaction among DHCP servers, clients and DNS servers should be
   discussed in client IAs.

C.17. Clarification of destination this document.

   What is relationship between DHCP-DNS for IPv4 (work-in-progress) and
   DHCP-DNS interaction requirements for IPv6?

D.5. Use of client messages

   Added text term "agent"

   The term "agent", taken to section 13 clarifying the destination (specific server mean "relay agent or any available server) of client messages

C.18. Clarification of client use of Confirm messages

   Changed text server", may be
   confusing.  "relay agent or server" might be clearer.

D.6. Additional options

   Which additional options should be included in section 13.3.2 this base spec
   document?  How should we reserve space for "local options" (as in
   DHCPv4)?

D.7. Operational parameters

   Should servers have an option to correctly describe behavior set operational parameters -
   retransmission timeouts, number of
   clients retries - in response to Replay messages from servers. clients?

References

    [1] B. Aboba.  DHCP Domain Search Option.  Internet Draft, Internet
        Engineering Task Force, December 2000.  Work in progress.

    [2] S. Alexander and R. Droms.  DHCP Options and BOOTP Vendor
        Extensions.  Request for Comments (Draft Standard) 2132,
        Internet Engineering Task Force, March 1997.

    [2]

    [3] S. Bradner.  Key words for use in RFCs to Indicate Requirement
        Levels.  Request for Comments (Best Current Practice) 2119,
        Internet Engineering Task Force, March 1997.

    [3]

    [4] S. Bradner and A. Mankin.  The Recommendation for the IP Next
        Generation Protocol.  Request for Comments (Proposed Standard)
        1752, Internet Engineering Task Force, January 1995.

    [4]

    [5] W. J. Croft and J. Gilmore.  Bootstrap Protocol.  Request for
        Comments 951, Internet Engineering Task Force, September 1985.

    [5]

    [6] S. Deering and R. Hinden.  Internet Protocol, Version 6 (IPv6)
        Specification.  Request for Comments (Draft Standard) 2460,
        Internet Engineering Task Force, December 1998.

    [6]

    [7] R. Droms.  Dynamic Host Configuration Protocol.  Request for
        Comments (Draft Standard) 2131, Internet Engineering Task Force,
        March 1997.

    [7]

    [8] R. Droms and W. Arbaugh.  Authentication for DHCP Messages.
        Internet Draft, Internet Engineering Task Force, January 2001.
        Work in progress.

    [9] R. Hinden and S. Deering.  IP Version 6 Addressing Architecture.
        Request for Comments (Proposed Standard) 2373, Internet
        Engineering Task Force, July 1998.

    [8]

   [10] H. Krawczyk, M. Bellare, and R. Canetti.  HMAC: Keyed-Hashing
        for Message Authentication.  Request for Comments
        (Informational) 2104, Internet Engineering Task Force,
        February 1997.

   [11] J. McCann, S. Deering, and J. Mogul.  Path MTU Discovery for
        IP version 6.  Request for Comments (Proposed Standard) 1981,
        Internet Engineering Task Force, August 1996.

    [9]

   [12] David L. Mills.  Network Time Protocol (Version 3)
        Specification, Implementation.  Request for Comments (Draft
        Standard) 1305, Internet Engineering Task Force, March 1992.

   [13] P. V. Mockapetris.  Domain names - implementation and
        specification.  Request for Comments (Standard) 1035, Internet
        Engineering Task Force, November 1987.

   [14] T. Narten and H. Alvestrand.  Guidelines for Writing an IANA
        Considerations Section in RFCs.  Request for Comments (Best
        Current Practice) 2434, Internet Engineering Task Force, October
        1998.

   [10]

   [15] T. Narten and R. Draves.  Privacy Extensions for Stateless
        Address Autoconfiguration in IPv6.  Request for Comments
        (Proposed Standard) 3041, Internet Engineering Task Force,
        January 2001.

   [16] T. Narten, E. Nordmark, and W. Simpson.  Neighbor Discovery for
        IP Version 6 (IPv6).  Request for Comments (Draft Standard)
        2461, Internet Engineering Task Force, December 1998.

   [11]

   [17] D. C. Plummer.  Ethernet Address Resolution Protocol:  Or
        converting network protocol addresses to 48.bit Ethernet address
        for transmission on Ethernet hardware.  Request for Comments
        (Standard) 826, Internet Engineering Task Force, November 1982.

   [12]

   [18] J. Postel.  User Datagram Protocol.  Request for Comments
        (Standard) 768, Internet Engineering Task Force, August 1980.

   [13]

   [19] R. Rivest.  The MD5 Message-Digest Algorithm.  Request for
        Comments (Informational) 1321, Internet Engineering Task Force,
        April 1992.

   [20] S. Thomson and T. Narten.  IPv6 Stateless Address
        Autoconfiguration.  Request for Comments (Draft Standard) 2462,
        Internet Engineering Task Force, December 1998.

   [14]

   [21] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan.  Service
        Location Protocol.  Request for Comments (Proposed Standard)
        2165, Internet Engineering Task Force, June 1997.

   [15]

   [22] P. Vixie, Ed., S. Thomson, Y. Rekhter, and J. Bound.  Dynamic
        Updates in the Domain Name System (DNS UPDATE).  Request for
        Comments (Proposed Standard) 2136, Internet Engineering Task
        Force, April 1997.

Chair's Address

   The working group can be contacted via the current chair:

         Ralph Droms
         Cisco Systems
         300 Apollo Drive
         Chelmsford, MA 01824

         Phone:  (978) 244-4733
         E-mail:  rdroms@cisco.com

Author's Address

   Questions about this memo can be directed to:

        Jim Bound
        Nokia Networks
        5 Wayside
        Compaq Computer Corporation
        ZK3-3/W20
        110 Spit Brook Road
        Burlington, MA 01803
        Nashua, NH 03062-2698
        USA
        Phone:  +1-781-492-6010  +1 603 884 0062
        Email:  jim.bound@nokia.com  Jim.Bound@compaq.com

        Mike Carney
        Sun Microsystems, Inc
        Mail Stop:  UMPK17-202
        901 San Antonio Road
        Palo Alto, CA 94303-4900
        USA
        Phone:  +1-650-786-4171
        Email:  mwc@eng.sun.com

        Charles E. Perkins
        Communications Systems Lab
        Nokia Research Center
        313 Fairchild Drive
        Mountain View, California 94043
        USA
        Phone:  +1-650 625-2986
        EMail:
        Email:  charliep@iprg.nokia.com
        Fax:  +1 650 625-2502

        Ralph Droms
        Cisco Systems
        300 Apollo Drive
        Chelmsford, MA 01824
        USA
        Phone:  +1 978 244 4733
        Email:  rdroms@cisco.com