Internet Engineering Task Force                                 J. Bound
INTERNET DRAFT                                     Compaq Computer Corp.
DHC Working Group                                             C. Perkins                                              M. Carney
Obsoletes:  draft-ietf-dhc-dhcpv6-13.txt  draft-ietf-dhc-dhcpv6-14.txt           Sun Microsystems Laboratories
                                                        25 February 1999 Microsystems, Inc
                                                              C. Perkins
                                                   Nokia Research Center
                                                              5 May 2000
          Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
                      draft-ietf-dhc-dhcpv6-14.txt
                      draft-ietf-dhc-dhcpv6-15.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 (DHCPv6) for IPv6 (DHCP) enables
   DHCP servers to pass configuration information, via extensions, parameters using extensions 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 the IPv6 ``IPv6 Stateless Address
   Autoconfiguration protocol,
   Autoconfiguration'' [15], and can be used separately or together concurrently
   with the latter to obtain configuration information. parameters.

                                Contents
Status of This Memo                                                    i

Abstract                                                               i

 1. Introduction                                                       1

 2. Terminology and Definitions                                                        2
     2.1. IPv6 Terminology  . . . . . . . . . . . . . . . . . . . .    2
     2.2. DHCPv6 DHCP Terminology  . . . . . . . . . . . . . . . . . . . .    3
     2.3. Specification Language

 3. DHCP Constants                                                     5
     3.1. Multicast Addresses . . . . . . . . . . . . . . . . .    4
     2.4. Error Values . .    5
     3.2. UDP ports . . . . . . . . . . . . . . . . . . . .    4

 3. Protocol Design Model                                              4
     3.1. Design Goals . . . .    5
     3.3. DHCP message types  . . . . . . . . . . . . . . . . . . .    4
     3.2. DHCP Messages    6
     3.4. Error Values  . . . . . . . . . . . . . . . . . . . . . .    5
     3.3. Request/Response Processing Model    8
           3.4.1. Generic Error Values  . . . . . . . . . . . .    7

 4. DHCP Message Formats and Field Definitions                         8
     4.1. DHCP Solicit Message Format . .    8
           3.4.2. Server-specific Error Values  . . . . . . . . . .    8
     3.5. Configuration Variables . . .    8
     4.2. DHCP Advertise Message Format . . . . . . . . . . . . . .    8

 4. Requirements                                                       9
     4.3. DHCP Request Message Format

 5. Background                                                         9

 6. Design Goals                                                      11

 7. Non-Goals                                                         11

 8. Overview                                                          12
     8.1. How does a node know to use DHCP? . . . . . . . . . . . .   12
     8.2. How does a client find out about DHCP agents? . . . . .   10
     4.4. DHCP Reply Message Format .   12
     8.3. What if the client and server(s) are on different links?    12
     8.4. How does a client request configuration parameters from
             servers? . . . . . . . . . . . . . . . . . .   12
     4.5. DHCP Release Message Format . . . . .   13
     8.5. What are releasable resources, and when are they used?  .   13
     8.6. Can a client release its releasable resources before the lease
             expires? . . . . . . . . .   13
     4.6. DHCP Reconfigure Message Format . . . . . . . . . . . . .   15

 5. DHCP Client Considerations                                        16
     5.1. Verifying Resource Allocations After Restarts .   14
     8.7. What if the client determines its releasable resource is
             already being used by another client?  . . . . .   16
     5.2. Sending . . .   14
     8.8. How are clients notified of server configuration changes?   14

 9. Message Formats                                                   15
     9.1. DHCP Solicit Messages Message Format . . . . . . . . . . . . . .   16
     5.3. Receiving .   15
     9.2. DHCP Advertise Messages Message Format . . . . . . . . . . . .   17
     5.4. Sending . .   16
     9.3. DHCP Request Messages Message Format . . . . . . . . . . . . . . .   18
     5.5. Receiving
     9.4. DHCP Reply Messages Message Format . . . . . . . . . . . . . .   20
     5.6. Sending . .   19
     9.5. DHCP Release Messages Message Format . . . . . . . . . . . . . . .   20
     5.7. Receiving
     9.6. DHCP Reconfigure Messages Message Format . . . . . . . . . . .   21
     5.8. Interaction with Stateless Address Autoconfiguration . .   22

 6. DHCP Server Considerations                                        23
     6.1. Receiving
     9.7. DHCP Solicit Messages Reconfigure-reply Message Format . . . . . . . . . .   23
     9.8. DHCP Reconfigure-init Message Format  . . .   23
     6.2. Sending DHCP Advertise Messages . . . . . . .   24

10. DHCP Server Solicitation and Subnet Prefix Discovery              25
    10.1. Solicit Message Validation  . . . . . .   24
     6.3. DHCP Request and Reply . . . . . . . . .   25
    10.2. Advertise Message Processing Validation  . . . . . . . . . .   24
           6.3.1. Processing for Extensions to DHCP Request and Reply
                          Messages . . . .   25
    10.3. Client Behavior . . . . . . . . . . . . . . . . . . . .  25
           6.3.2. Client Requests to Deallocate Unknown Resources .   26
     6.4. Receiving DHCP Release
          10.3.1. Creation and sending of the Solicit message . . .   26
          10.3.2. Time out and retransmission of Solicit Messages .   27
          10.3.3. Receipt of Advertise messages . . . . . . . . . .   27
    10.4. Relay Behavior  . . .   26
     6.5. Sending DHCP Reconfigure Messages . . . . . . . . . . . .   27
     6.6. Client-Resource timeouts . . . . . .   28
          10.4.1. Relaying of Solicit messages  . . . . . . . . . .   28

 7. DHCP Relay Considerations
          10.4.2. Relaying of Advertise messages  . . . . . . . . .   28
     7.1. DHCP
    10.5. Server Behavior . . . . . . . . . . . . . . . . . . . . .   28
          10.5.1. Receipt of Solicit messages . . . . . . . . . . .   28
          10.5.2. Creation and DHCP sending of Advertise Message Processing messages  . . .   28
     7.2.   29

11. DHCP Client-Initiated Configuration Exchange                      29
    11.1. Request Message Processing Validation  . . . . . . . . . . . . . . .   29
     7.3. DHCP
    11.2. Reply Message Processing Validation  . . . . . . . . . . . . . . . .   30

 8. Retransmission
    11.3. Release Message Validation  . . . . . . . . . . . . . . .   31
    11.4. Client Behavior . . . . . . . . . . . . . . . . . . . . .   31
          11.4.1. Creation and Configuration Variables                        30

 9. Security Considerations sending of Request messages  . . . .   32
          11.4.2. Time out and retransmission of Request Messages .   33

10. Year 2000 considerations
          11.4.3. Receipt of Reply message in response to a Request   33

11. IANA Considerations                                               34

12. Acknowledgements                                                  34

 A. Changes for this revision                                         34

 B. Related Protocol Specifications                                   35

 C. Comparison between DHCPv4
          11.4.4. Creation and DHCPv6                              37

 D. Full Copyright Statement sending of Release messages  . . . .   33
          11.4.5. Time out and retransmission of Release Messages .   34
          11.4.6. Receipt of Reply message in response to a Release   35
    11.5. Relay Behavior  . . . . . . . . . . . . . . . . . . . . .   35
          11.5.1. Relaying of Request or Release messages . . . . .   35
    11.6. Server Behavior . . . . . . . . . . . . . . . . . . . . .   35
          11.6.1. Receipt of Request messages . . . . . . . . . . .   35
          11.6.2. Receipt of Release messages . . . . . . . . . . .   36
          11.6.3. Creation and sending of Reply messages  . . . . .   36

12. DHCP Server-Initiated Configuration Exchange                      37
    12.1. Reconfigure Message Validation  . . . . . . . . . . . . .   37
    12.2. Reconfigure-reply Message Validation  . . . . . . . . . .   38
    12.3. Reconfigure-init Message Validation . . . . . . . . . . .   38
    12.4. Server Behavior . . . . . . . . . . . . . . . . . . . . .   38
          12.4.1. Creation and sending of Reconfigure messages  . .   39
          12.4.2. Time out and retransmission of Reconfigure
                          messages . . . . . . . . . . . . . . . . .  40

Chair's Address                                                       43

Author's Address                                                      43

1. Introduction
          12.4.3. Receipt of Reconfigure-reply messages . . . . . .   40
          12.4.4. Creation and sending of Reconfigure-init messages   40
          12.4.5. Time out and retransmission of Reconfigure-init
                          messages . . . . . . . . . . . . . . . . .  41
          12.4.6. Receipt of Request messages . . . . . . . . . . .   41
    12.5. Client Behavior . . . . . . . . . . . . . . . . . . . . .   41
          12.5.1. Receipt of Reconfigure messages . . . . . . . . .   42
          12.5.2. Creation and sending of Reconfigure-reply messages  42
          12.5.3. Receipt of Reconfigure-init messages  . . . . . .   43
          12.5.4. Creation and sending of Request messages  . . . .   43
          12.5.5. Time out and retransmission of Request messages .   43
          12.5.6. Receipt of Reply messages . . . . . . . . . . . .   43

13. Using DHCP for network renumbering                                43
    13.1. Passive Renumbering . . . . . . . . . . . . . . . . . . .   44
    13.2. Active Renumbering  . . . . . . . . . . . . . . . . . . .   44

14. DHCP Client Implementator Notes                                   44
    14.1. Primary Interface . . . . . . . . . . . . . . . . . . . .   45
    14.2. Advertise Message and Configuration Parameter Caching . .   45
    14.3. Time out and retransmission variables . . . . . . . . . .   45
    14.4. Server Preference . . . . . . . . . . . . . . . . . . . .   45

15. DHCP Server Implementator Notes                                   46
    15.1. Client Bindings . . . . . . . . . . . . . . . . . . . . .   46
    15.2. Reconfigure Considerations  . . . . . . . . . . . . . . .   46
    15.3. Server Preference . . . . . . . . . . . . . . . . . . . .   46
    15.4. Request Message Transaction-ID Cache  . . . . . . . . . .   47

16. DHCP Relay Implementator Notes                                    47

17. Open Issues for Working Group Discussion                          47
    17.1. Trade-offs:  Optional fields in DHCP messages . . . . . .   47
    17.2. Use DHCPv4 authentication or the current DHCPv6 method? .   48
    17.3. The Reconfigure Message and Subnet Prefix Extensions  . .   48
    17.4. ``R'' bit in Request message not needed?  . . . . . . . .   48

18. Security Considerations                                           48

19. Year 2000 considerations                                          49

20. IANA Considerations                                               49

21. Acknowledgements                                                  50

 A. Comparison between DHCPv4 and DHCPv6                              50

 B. Full Copyright Statement                                          52

Chair's Address                                                       55

Author's Address                                                      55

1. Introduction

   This document describes DHCP for IPv6 (DHCP), a UDP [14] 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 network resources more varied than that
   offered by ``IPv6 Stateless Autoconfiguration'' [15].  The 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.

   The 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.
   The DHCP is designed to be easily extended to carry new configuration
   parameters through the addition of new DHCP ``extensions'' defined to
   carry this information.  See this document's companion specification,
   ``Extensions for the Dynamic Host Configuration Protocol for
   IPv6'' [2] for specifications of existing extensions as well as
   information on the process by which an interested party might specify
   new extensions.

   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.

   This document is organized as follows.  Section 2 defines terminology
   used throughout this document.  Section 3 defines constant values
   used by DHCP. Section 4 briefly discusses requirement levels.
   Section 5 points the reader to helpful background specifications
   covering related IPv6 protocols.  Section 6 discusses the design
   goals that influenced DHCP. Section 7 identifies some of the
   non-goals of this specification.  Section 8 gives a high level
   overview of DHCP, its message types, and identifies DHCP functional
   entities (client, relay, server).  Section 9 describes in detail the
   format of each DHCP message type.  Section 10 discusses DHCP server
   solicitation and subnet prefix discovery.  Section 11 discusses DHCP
   client-initiated configuration information exchange.  Section 12
   discusses DHCP server-initiated configuration information exchange.
   Section 13 describes how DHCP can be used to renumber networks.
   Section 14 presents helpful notes for DHCP client implementators.
   Section 15 presents helpful notes for DHCP server implementors.

   Section 16 presents helpful notes for DHCP relay implementors.
   Section 18 discusses security considerations for DHCP.
2. Terminology

2.1. IPv6 Terminology

   IPv6 terminology relevant to this specification from the IPv6
   Protocol [6], IPv6 Addressing Architecture [8], and IPv6 Stateless
   Address Autoconfiguration [15] 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 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 are used only in contexts where it is necessary to
                 avoid ambiguity.

      interface
                 A node's attachment to a link.

      link       A communication facility or medium over which nodes
                 can communicate at the link layer, i.e., the layer
                 immediately below IP. Examples are Ethernet (simple or
                 bridged); Token Ring; PPP links, X.25, Frame Relay, or
                 ATM networks; and Internet (or higher) layer "tunnels",
                 such as tunnels over IPv4 or IPv6 itself.

      link-layer identifier
                 a link-layer identifier for an interface.  Examples
                 include IEEE 802 addresses for Ethernet or Token Ring
                 network interfaces, and E.164 addresses for ISDN links.

      link-local address
                 An IP address having link-only scope, indicated by
                 having the subnet prefix (FE80::0000/64), that can be
                 used to reach neighboring nodes attached to the same
                 link.  Every interface has a link-local address.

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

      neighbor   A node attached to the same link.

      node       A device that implements IP.

      packet     An IP header plus payload.

      prefix     A bit string that consists of some number of initial
                 bits of an address.

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

   Terminology specific to DHCP can be found below.
      abort status
                 A status value returned to the application that has
                 invoked a DHCP client operation, indicating anything
                 other than success.

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

      binding    A binding (or, client binding) is a group of server
                 data records indexed by <client's link-local address,
                 subnet prefix> containing the releasable resource data
                 which a DHCP server has assigned to a client.

                 Note that the transaction-ID from the Request message
                 that produced the assignment of the releasable resource
                 is also stored in the server data record including the
                 releasable resource identifier.

      DHCP       Dynamic Host Configuration Protocol for IPv6.  The
                 terms DHCPv4 and DHCPv6 are used only in contexts where
                 it is necessary to avoid ambiguity.

      configuration parameter
                 An element of the configuration information set on the
                 server and delivered to the client using DHCP. Such
                 parameters may be used to carry information to be used
                 by a node to configure its network subsystem and enable
                 communication on a link or internetwork, for example.

      DHCP client (or client)
                 A node that initiates requests on a link to obtain
                 configuration parameters from one or more DHCP servers.

      DHCP domain
                 A chunk of network topology managed by DHCP and
                 operated by a single administrative entity.

      DHCP server (or server)
                 A server is a node that responds to requests from
                 clients, and may or may not be on the same link as the
                 client(s).

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

      DHCP agent (or agent)
                 Either a DHCP server on the same link as a client, or a
                 DHCP relay.

      Releasable resource
                 Any configuration resource allocated by a server for
                 a finite period of time.  As of this writing, the
                 only example of such a resource is the IP address.
                 Releasable resources are carried in extensions
                 allocated out of the 1--8192 range.

      solicit-ID
                 An unsigned integer generated by the client and
                 inserted into its DHCP Solicit messages, and echoed
                 back to the client by the server in its resultant DHCP
                 Advertise message(s).  The client uses the solicit-ID
                 to match received Advertise messages to Solicit
                 messages it has generated.

      transaction-ID
                 An unsigned integer to match responses with replies
                 initiated either by a client or server.  Servers
                 allocate their transaction-IDs from the range of
                 0--1023, and clients allocate their transaction-IDs
                 from the range of 1024--65535.  Limiting clients and
                 servers to different ranges prevents transaction-ID
                 collisions (e.g.  client and server happen to use the
                 same transaction-ID for unrelated transactions (e.g.
                 client Request, server Reconfigure-init).
3. DHCP Constants

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

   The DHCP makes use of the following multicast addresses:

      All DHCP Agents address:  FF02::1:2
                 This link-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 of this multicast
                 group.

      All DHCP Servers address:  FF05::1:3
                 This site-local multicast address is used by clients or
                 relays to communicate with server(s), either because
                 they want to send messages to all servers or because
                 they do not know the server(s) unicast address(es).
                 Note that in order for a client to use this address,
                 it must have an address of sufficient scope to be
                 reachable by the server(s).  All servers within the
                 site are members of this multicast group.
3.2. UDP ports

   The DHCP uses the following destination UDP [14] port numbers.  While
   source ports MAY be arbitrary, client implementations SHOULD permit
   their specification through a local configuration parameter to
   facilitate the use of DHCP through firewalls.

      546        Client port.  Used by agents to send messages to
                 clients.  Also used by servers to send messages to
                 relays.

      547        Agent port.  Used by clients to send messages to
                 agents.  Also used by relays to send messages to
                 servers.
3.3. DHCP message types

   The DHCP defines the following message types.  More detail on these
   message types can be found in Section 9.  Message types 0 and 9--255
   are reserved and MUST be silently ignored.

      01 DHCP Solicit

         The DHCP Solicit (or Solicit) message is used by clients to
         locate servers and (optionally) learn about the subnet prefixes
         on the client's link for networks that are managed by DHCP.
         This message is multicast using the All-DHCP-Agents address.
         Relay(s) forward Solicits as necessary to off-link servers.

         Section 9.1 contains more details about the Solicit message.

      02 DHCP Advertise

         The DHCP Advertise (or Advertise) message is used by servers
         responding to Solicits.  This message is unicast to the
         client's link-local address (if the server and client are
         on the same link) or unicast to the relay through which the
         Solicit was sent for final delivery to the client.

         Section 9.2 contains more details about the Advertise message.

      03 DHCP Request

         The Dynamic Host Configuration Protocol (DHCPv6, DHCP Request (or Request) message is used by clients to
         request configuration parameters from servers.  This message
         is unicast to the server if the client has an address with
         sufficient scope to be reachable by the server, otherwise it
         is unicast to the on-link relay through which the Advertise
         message was relayed.

         Section 9.3 contains more details about the Request message.

      04 DHCP Reply

         The DHCP Reply (or Reply) message is used by servers responding
         to Request and Release messages.  In the case of responding to
         a Request message, the Reply contains configuration parameters
         destined for the client.  This message is unicast to the client
         if the client has an address of sufficient scope that is
         reachable by the server.  Otherwise, it is unicast to the relay
         through which the Request or Release message was sent for final
         delivery to the client.

         Section 9.4 contains more details about the Reply message.

      05 DHCP Release

         The DHCP Release (or Release) message is used by clients to
         return one or more instances of releasable resources (e.g.  IP
         addresses) to servers.  This message is unicast to the server
         if the client will have an address of sufficient scope after
         the Release operation to receive a Reply message.  Otherwise,
         the Release message is sent through the relay.  The server will
         acknowledge the receipt of the Release message by sending the
         client a Reply message.

         Section 9.5 contains more details about the Release message.

      06 DHCP Reconfigure

         The DHCP Reconfigure (or Reconfigure) message is sent by
         servers to client(s).  It contains new or in this
   document usually DHCP) provides updated configuration
         parameters for use by the client(s).  This message may be
         unicast or multicast to Internet
   nodes. the client(s).

         Section 9.6 contains more details about the Reconfigure
         message.

      07 DHCP consists of a protocol for delivering node-specific
   configuration parameters from a Reconfigure-reply

         The DHCP Reconfigure-reply (or Reconfigure-reply) message is
         unicast by client(s) to the server to a client, and
   extensions for allocation acknowledge the receipt
         of network addresses and other related
   parameters to IPv6 [7] nodes.

   DHCP uses a client-server model, where designated Reconfigure message.

         Section 9.7 contains more details about the Reconfigure-reply
         message.

      08 DHCP servers
   automatically allocate network addresses and deliver configuration
   parameters Reconfigure-init

         The DHCP Reconfigure-init (or Reconfigure-init) message is set
         by server(s) to dynamically configurable clients.  Throughout inform client(s) that the
   remainder of this document, server(s) has new or
         updated configuration parameters, and that the term "server" refers client(s) are
         to initiate a node
   providing initialization parameters by way of the DHCP protocol,
   and Request/Reply transaction with the term "client" refers server(s) in
         order to a node requesting initialization
   parameters from a receive the updated information.

         Section 9.8 contains more details about the Reconfigure-init
         message.

3.4. Error Values

   This section describes error values exchanged between DHCP server.

   DHCPv6 uses Request and Reply messages to support a client/server
   processing model whereby both
   implementations.
3.4.1. Generic Error Values

   The following symbolic names are used between client and server are assured that
   requested configuration parameters have been received and accepted
   by
   implementations to convey error conditions.  The following table
   contains the client.  DHCP supports optional configuration parameters and
   processing for nodes through extensions described in its companion
   document ``Extensions actual numeric values for each name.  Note that the Dynamic Host Configuration Protocol for
   IPv6'' [15].

   The IPv6 Addressing Architecture [9] and IPv6 Stateless Address
   Autoconfiguration [20] specifications provide new features
   numeric values do not
   available start at 1, nor are they consecutive.  The
   errors are organized in IP version 4 (IPv4) [18], which 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_______|Resources_unavailable________________|

3.4.2. Server-specific Error Values

   The following symbolic names are used by server implementations to
   convey error conditions to simplify
   and generalize the operation of DHCP clients.  The following table contains the
   actual numeric values for each name.
   _______________________________________________________________
   |_Error_Name____|Error_ID_|Description_________________________|
   |_NoBinding_____|20_______|Client_record_(binding)_unavailable_|
   |_InvalidSource_|21_______|Invalid_Client_IP_address___________|
   |_NoServer______|23_______|Relay_cannot_find_Server_Address____|
   |_ICMPError_____|64_______|Server_unreachable_(ICMP_error)_____|

3.5. Configuration Variables

   This document is
   intended to complement those specifications section presents a table of client and server configuration
   variables and the default or initial values for clients attached these variables.  The
   client-specific variables MAY be configured on the server and MAY be
   delivered to the kinds of Internet media for which those specifications apply.  In
   particular, client through the specification ``DHCP Retransmission Parameter
   Extension''carried in this document does not necessarily
   apply to nodes which do not enjoy a bidirectional link to Reply message.  This extension is documented
   in the
   Internet.

   Section 2 provides definitions for terminology used throughout ``extensions document'' [2].

   ______________________________________________________________
   |_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_____|REQ_Retrans_timer_(msecs)______|
   |_REQ_MSG_ATTEMPTS___|10______|MAX_Request_attempts___________|
   |_REL_MSG_ATTEMPTS___|5_______|MAX_Release_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)_|

4. Requirements

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document.  Section 3 provides an overview of the protocol
   design model that guided the design choices
   document, are to be interpreted as described in the specification;
   section 3.2 briefly describes the [3].

   This document also makes use of internal conceptual variables
   to describe protocol messages behavior and external variables that an
   implementation must allow system administrators to change.  The
   specific variable names, how their
   semantics.  Section 4 provides the message formats and field
   definitions used for each message.  Sections 5,  6, values change, and  7 specify how clients, servers, and relays respectively interact.  The timeout
   and retransmission guidelines as well as configuration variables for
   DHCP their
   settings influence protocol operations behavior are discussed provided to demostrate
   protocol behavior.  An implementation is not required to have them in Section 8.  Appendix B
   summarizes related
   the exact form described here, so long as its external behavior is
   consistent with that described in this document.
5. Background

   Related work in IPv6 that will provide helpful context;
   it would best serve an implementor to study
   is not part of this specification, but included for informational
   purposes.  Appendix C discusses the differences between DHCPv4 and
   DHCPv6.

2. Terminology and Definitions

   Relevant terminology from the IPv6 Protocol [7], Specification [6], the IPv6 Addressing Architecture [9], and [8],
   IPv6 Stateless Address Autoconfiguration [20]
   is given, followed by DHCPv6 terminology.

2.1. [15], IPv6 Terminology

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

      unicast address
                 An identifier for a single interface.  A packet sent Neighbor
   Discovery Processing [12], and Dynamic Updates to a unicast address is delivered DNS [17].  These
   specifications enable DHCP to build upon the interface
                 identified by that address.

      multicast address
                 An identifier for a set of interfaces (typically
                 belonging IPv6 work to different nodes). provide
   both robust stateful autoconfiguration and autoregistration of DNS
   Host Names.

   The IPv6 Specification provides the base architecture and design of
   IPv6.  A packet sent key point for DHCP implementors to a
                 multicast address understand 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 are used only in contexts where it is necessary to
                 avoid ambiguity.

      interface
                 A node's attachment to a link.

      link       A communication facility or medium over which nodes
                 can communicate at the
   requires that every link layer, i.e., in 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 Internet have an interface.  Examples
                 include IEEE 802 addresses for Ethernet MTU of 1280 octets
   or Token Ring
                 network interfaces, and E.164 addresses for ISDN links.

      link-local address
                 An IP address having link-only scope, indicated by
                 having the routing prefix (FE80::0000/64), that can be
                 used to reach neighboring nodes attached to greater (in IPv4 the same
                 link.  Every interface has requirement is 68 octets).  This means that
   a link-local address.

      message    A unit UDP packet of data carried 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 a packet, exchanged the packet.  But, IPv6 does not
   support fragmentation at routers, so that fragmentation takes place
   end-to-end between hosts.  If a DHCP agents and clients.

      neighbor   A node attached implementation needs to send a
   packet greater than 1500 octets it can either fragment the same link.

      node       A device that implements IP. UDP packet     An IP header plus payload.

      prefix     A bit string that consists of some number of initial
                 bits
   into fragments of an address.

      router     A node that forwards IP packets not explicitly
                 addressed 1500 octets or less, or use Path MTU Discovery [10]
   to itself.

2.2. DHCPv6 Terminology

      agent address
                 The address determine the size of the packet that will traverse a neighboring network
   path.

   DHCP Agent on the same
                 link as clients use Path MTU discovery when they have an address of
   sufficient scope to reach the DHCP client.

      binding    A binding (or, client binding) containing the data
                 which server.  If a DHCP server maintains for each of client does not
   have such an address, that client MUST fragment its clients
                 (see Section 6).

      resource-server association
                 An association between a resource 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 DHCP server,
                 maintained by
   destination.

   The IPv6 Addressing Architecture specification [8] defines the client which received that resource
                 from that DHCP server.

      configuration parameter
                 Any parameter
   address scope that can be used by a node to configure
                 its in an IPv6 implementation, and the
   various configuration architecture guidelines for network subsystem designers
   of the IPv6 address space.  Two advantages of IPv6 are that support
   for multicast is required, and enable communication on a
                 link or internetwork.

      DHCP client (or client)
                 A node nodes can create link-local addresses
   during initialization.  This means that initiates requests on a link to obtain
                 configuration parameters.

      DHCP server (or server)
                 A server is client can immediately use
   its link-local address and a node that responds well-known multicast address to requests from
                 clients, and may or may not be on the same link as as
                 the client.

      DHCP relay (or relay)
                 A node that acts as an intermediary begin
   communications to deliver DHCP
                 messages between clients and servers, and is discover neighbors on the
                 same link as link.  For instance, a client.

      DHCP agent (or agent)
                 Either
   client can send a DHCP server on the same link as Solicit message and locate a client, server or a
                 DHCP relay.

      transaction-ID
                 An unsigned integer to match responses with replies
                 initiated either

   IPv6 Stateless Address Autoconfiguration [15] (Addrconf) specifies
   procedures by which a client or server.  Clients MUST
                 use integers from 1 to 1000, node may autoconfigure addresses based on
   router advertisements [12], and servers the use integers
                 greater than 1000 for transaction-ID's.

2.3. Specification Language of a valid lifetime to
   support renumbering of addresses on the Internet.  In this document, addition the words MUST, MUST NOT, SHOULD, SHOULD NOT, and
   MAY are used
   protocol interaction by which a node begins stateless or stateful
   autoconfiguration is specified.  The DHCP is one vehicle to signify the requirements perform
   stateful autoconfiguration.  Compatibility with addrconf is a design
   requirement of DHCP (see Section 6).

   IPv6 Neighbor Discovery [12] is the specification, node discovery protocol in
   accordance with RFC 2119 [2].

2.4. Error Values

   This IPv6
   which replaces and enhances functions of ARP [13].  To understand
   IPv6 and Addrconf it is strongly recommended that implementors
   understand IPv6 Neighbor Discovery.

   Dynamic Updates to DNS [17] is a specification document uses symbolic names that supports the
   dynamic update of DNS records for both IPv4 and IPv6.  DHCP can use
   the errors known dynamic updates to DHCP clients DNS to integrate addresses and servers, as used for instance name space
   to not only support autoconfiguration, but also autoregistration
   in the status field
   of the DHCP Reply message (see section 4.4). IPv6.  The symbolic names have
   the actual values listed below:

         Error Name             ErrorID
         ================================
         PoorlyFormed             18
         Unavail                  19
         NoBinding                20
         InvalidSource            21
         NoServer                 23
         ICMPError                64

3. Protocol Design Model

   This section is provided for implementors security model to understand the be used with DHCPv6
   protocol design should conform
   as closely as possible to the authentication model from an architectural perspective.  Goals and
   conceptual models are presented outlined in this section.

3.1.
   RFC2402 [9].

6. Design Goals

   The following list gives general design goals for this DHCP
   specification.

    -  DHCP should be is a mechanism rather than a policy.  DHCP must allow
       local system  Network administrators control over
       set their administrative policies through the configuration
       parameters
       where desired; e.g., local system administrators should be able they place upon the DHCP servers in the DHCP domain
       they're managing.  DHCP is simply used to enforce local policies concerning allocation and access deliver parameters
       according to
       local resources where desired. that policy to each of the DHCP clients within the
       domain.

    -  DHCP must is compatible with IPv6 stateless autoconf [15].

    -  DHCP does not require manual configuration of network parameters
       on DHCP clients, except as dictated by in cases where such configuration is
       needed for security requirements.  Each reasons.  A node configuring itself using
       DHCP should be
       able to obtain appropriate local configuration parameters without require no user intervention.

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

    -  In some installations, clients on certain subnets can be served
       by more than one DHCP server, improving reliability and/or
       performance.  Therefore, a DHCP client must be prepared to
       receive multiple (possibly different) responses to a DHCP Solicit
       message.

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

    -  DHCPv6 must be compatible with IPv6 Stateless Address
       Autoconfiguration [20].

    -  A DHCPv6 Client implementation may be started in the absence of
       any  DHCP clients can operate on a link without IPv6 routers on the client's link. present.

    -  DHCP architecture must support automated renumbering of IP
       addresses [3]. 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 should be able at any time.  DHCP will provide enough information
       to support Dynamic Updates enable a DHCP server to
       DNS [22]. keep track of a DHCP client's
       configuration state.

    -  DHCP servers must be able will contain the appropriate time out and retransmission
       mechanisms to support multiple IPv6 addresses for
       each client.

   On efficiently operate in environments with high
       latency and low bandwidth characteristics.
7. Non-Goals

   This specification explicitly does not cover the other hand, following:

    -  Specification of a DHCP server to server protocol is NOT part of
   this specification.  Furthermore, it is NOT protocol.

    -  How a design goal of DHCP server stores its DHCP data.

    -  How to
   specify how manage a server configuration parameter database is maintained DHCP domain or determined.  Methods for configuring DHCP servers are outside server.

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

   This section provides a general overview of the
   scope interaction
   between the functional entities of DHCP. The overview is organized
   as a series of questions and answers.  Details of this document.

3.2. DHCP Messages

   Each DHCP such
   as message contains formats and retransmissions are left to sections 9,
   10, 11, 12, 14, 15, and  16.
8.1. How does a type, which defines its function within
   the protocol.  Formats node know to use DHCP?

   An unconfigured node determines that it is to use DHCP for
   configuration of an interface by detecting the messages presence (or absence)
   of routers on the link.  If router(s) are found in section 4, with
   an initial description and discussion.  Processing details for these present, the node examines
   router advertisements to determine if DHCP messages should be used to
   configure the interface.  If there are specified no routers present, then
   the node MUST use DHCP to configure the interface.  Detail on
   this process can be found in Sections 5, 6, neighbor discovery [12] and 7.  The message
   types are as follows:

      01 stateless
   autoconfiguration [15].
8.2. How does a client find out about DHCP Solicit agents?

   The DHCP Solicit message is an IP multicast message sent by a client to one or more agents, or forwarded by forms a relay Solicit message, and multicasts it to one or
         more servers.

      02 DHCP Advertise

         The the
   FF02::1:2(All DHCP Agents) address.  Server(s) receiving the Solicit
   respond with Advertise is an IP unicast message sent by a DHCP
         Agent message(s).  If requested in response to a the client's DHCP
   Solicit message.

      03 DHCP Request

         The DHCP Request is an IP unicast message sent message, the Advertise message(s) can include one or more
   subnet prefix extensions [2], informing the client of subnet prefixes
   for the networks(s) managed by a the server(s) on the client's link.
   Now that the client to a
         server to knows the IP address(es) of agents(s) on the
   link, it can request configuration parameters from servers.
8.3. What if the client and server(s) are on a network.

      04 different links?

   Use of DHCP Reply

         The in such environments requires one or more DHCP Reply is an IP unicast message sent by relays
   be set up on the client's link, because a server in
         response to client may only have a client's
   link-local address.  Relays pick up the Solicit and Request messages
   from the client and forward them to some set of servers within the
   DHCP Request, or by domain.  A relay will include one of its own addresses (of
   sufficient scope) of the interface on the same link as the client.
   The relay also includes the subnet prefix length of that
         relayed that address
   in the client's DHCP Request.  Extensions [15] messages.  Servers receiving the forwarded traffic
   use this information to aid in selecting configuration parameters
   appropriate to the
         DHCP Reply describe client's link.  The servers also use the resources that relay's
   address as the server has committed
         and allocated destination to this client, and may contain other information forward client-destined messages
   for use by this client.

      05 DHCP Release

         The DHCP Release is an IP unicast message sent final delivery by a the relay.  Relays forward client messages
   to
         inform the server that servers using some combination of the client is releasing resources.

      06 DHCP Reconfigure

         The DHCP Reconfigure is an IP unicast or FF05::1:3(All Servers)
   site-local multicast message sent
         by address, some other (perhaps a server to inform one or more clients that the server has
         new configuration information combination)
   of importance to site-local multicast addresses set up within the client.
         Each client is expected to initiate a new DHCP Request in
         response domain to
   include the Reconfiure message.

   DHCP message types not defined here (msg-types 0 and 7-255) are
   reserved and SHOULD be silently ignored.

3.3. Request/Response Processing Model

   The request/response processing servers in that domain, or a list of unicast addresses
   for DHCPv6 is transaction servers.  The network administrator makes relay configuration
   decisions based and
   uses a set upon the topological requirements (scope) of best-effort messages the
   DHCP domain they are managing.  Note that if the DHCP domain spans
   more than the site-local scope, then the relays MUST be configured
   with global addresses for the client's link so as to complete be reachable by
   servers outside the transaction.

   To find a server, relays' site-local environment.
8.4. How does a client sends a DHCP Solicit request configuration parameters from servers?

   To request configuration parameters, the interface
   which it wishes to configure.  The client then awaits forms a DHCP
   Advertise message containing Request
   message, and sends it to the server either directly (client has an IP
   address of a DHCP server.
   Transactions are started by a client with a DHCP Request, which may
   be issued after the client knows sufficient scope) or indirectly (through the server's address. on-link
   relay).  The server
   then unicasts a DHCP Reply, possibly via client MAY include a relay.  At this point in
   the flow all data has been transmitted and is presumed Extension Request Extension [2]
   along with other extensions to have been
   received.  To provide a method of recovery if either request specific information from the
   server.  Note that the client or
   server does not receive MAY form multiple Request messages
   and send each of them to different servers to request potentially
   different information (perhaps based upon what was advertised) in
   order to satisfy its messages, needs.  As a client's needs may change over time
   (perhaps based upon an application's requirements), the client retransmits each
   DHCP may
   form additional Request message until messages to request additional information as
   it elicits is needed.

   The server(s) respond with Reply messages containing the corresponding DHCP Reply,
   or until it requested
   configuration parameters, which can be reasonably certain that include status information
   regarding the desired DHCP server
   is unavailable, or it determines that it does not want a response
   (i.e., it MAY abort information requested by the transaction). client.  The timeout and retransmission
   guidelines and configuration variables are discussed in Section 8.

   DHCP uses UDP [17] to communicate between clients and servers.  UDP
   is not reliable, but Reply MAY
   also include additional information, such as a reconfiguration event
   multicast group for the DHCP retransmission scheme just client to join to monitor reconfiguration
   events, as described
   provides reliability between clients and servers. in section 8.8.

   The following
   well-known multicast addresses receipt of a Reply from a server concludes the basic
   request/reply transaction of the protocol.
8.5. What are used by DHCP agents releasable resources, and clients:

      FF02:0:0:0:0:0:1:2
               All DHCP Agents (servers when are they used?

   A releasable resource is configuration information leased to a client
   by a server for some finite period of time.  When negotiating for a
   releasable resource, the client and relays) MUST join server agree upon a finite period
   of time the
               link-local All-DHCP-Agents multicast group at client may use the address
               FF02:0:0:0:0:0:1:2.

      FF05:0:0:0:0:0:1:3
               All DHCP servers MUST join resource.  The client MAY request a
   renewal of the site-local
               All-DHCP-Servers multicast group lease on the resource at any time.  The length of time
   of the address
               FF05:0:0:0:0:0:1:3.

      FF05:0:0:0:0:0:1:4
               All DHCP relays lease (and whether it is renewable) are server-based policy
   tunables.  The client MUST join stop using the site-local All-DHCP-Relays
               multicast group at resource when the address FF05:0:0:0:0:0:1:4.

   A DHCP lease on
   the resource expires.  The server or agent MUST transmit all messages to DHCP clients on
   UDP port 546.  A DHCP NOT reallocate an assigned
   resource before either its lease expires or the client MUST transmit all messages to releases the
   resource.

   See the ``extensions document'' [2] for more information about
   releasable resources.
8.6. Can a DHCP
   agent over UDP using port 547. client release its releasable resources before the lease
   expires?

   A DHCP server MUST transmit all
   messages client forms a Release message, including extensions carrying the
   resource(s) to DHCP relays over UDP on port 546. be released.  The source port for
   DHCP messages is arbitrary.

   For client sends the proper operation of Release to the DHCP protocol
   server which leased the resource(s) to operate within the client initially.  If that
   server cannot be reached after a
   network where one or more firewallsare used, DHCP transactions sent
   to certain number of attempts (see
   section 3.5), the client can abandon the IP addresses of DHCP servers at UDP destination ports 546 and
   547 Release attempt.  In this
   case, the resource(s) will need to be permitted.

4. DHCP Message Formats and Field Definitions

   All reserved fields in reclaimed by the server(s) when the
   client's lease(s) expire.
8.7. What if the client determines its releasable resource is already
   being used by another client?

   If the client determines through a message MUST be transmitted as zeroes and
   ignored releasable resource-specific
   manner that the resource it was assigned by the receiver of server is already
   in use by another client, the message.

4.1. DHCP Solicit Message Format

   A client transmits will form a DHCP Solicit message over Release message,
   including the interface to extension carrying the in-use resource.  The
   extension's status field MUST be
   configured, set to obtain one or more server addresses.  Unless otherwise
   noted, the extension-specific value
   reflecting the ``in use'' status of all fields are set by the client.

      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 = 1 |C|           reserved            | prefix-size |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   client's link-local resource.

   For example, if the releasable resource is an IP address, the client
   uses Duplicate Address Detection (DAD) to verify that the IP address                 |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         relay-address                         |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     saved agent-address                       |
     |                   (if present, 16 octets)                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      C
   is not in use.  If set, the client requests determines that all servers receiving the IP address is
   already in use, it forms a Release message deallocate the resources associated with including the client.  If set, IP address
   extension containing the client SHOULD provide a saved
                 agent-address appropriate status value and sends it to locate the clients binding by a
   server.

      prefix-size A nonzero prefix-size is  See the number of leftmost bits
                 of ``extensions document''for details on the agent's IPv6 IP address which make up the routing
                 prefix.  The prefix-size field is set by
   extension. [2].
8.8. How are clients notified of server configuration changes?

   There are two possibilities.  Either the DHCP relay
                 if clients discover the relay receives new
   information when they revisit the solicitation and forwards it server(s) to one request additional
   configuration information / renew the lease on a releasable resource,
   or more DHCP Servers.

      reserved   0

      client's link-local address through a server-initiated event known as a reconfigure event.

   The IP link-local address reconfiguration feature of DHCP offers network administrators
   the client interface from
                 which opportunity to update configuration information on DHCP clients
   whenever necessary.  If the client issued information to be updated is not
   client-specific, the DHCP Request server will form a Reconfigure message

      relay-address
                 Set by and add
   the client new or changed configuration information to it.  The Reconfigure
   may be zero.  If received by unicast or multicast (to a DHCP
                 relay, set by preassigned multicast address for
   this purpose) to one or more client(s) to which the relay new or updated
   information needs to be directed.  The client(s) will acknowledge the IP address
   receipt of the
                 interface on which the relay received the client's DHCP
                 Solicit Reconfigure message

      saved agent-address
                 If present, the IP address of an agent's interface
                 retained by the client from a previous DHCP
                 transaction.

   A client SHOULD send forming a DHCP Solicit Reconfigure-reply
   message and unicasting it to the All-DHCP-Agents
   multicast group (see section 3.3), setting server.  If the relay-address to
   zero.  Any relay receiving configuration
   information change is different for each client (e.g.  a change in
   subnet prefix, perhaps, which would affect the solicitation MUST forward it to IP address releasable
   resource(s)), the
   All-DHCP-Servers server will form a Reconfigure-init message and
   unicast / multicast group.  In that case, as needed to the relay MUST copy client(s).  A Reconfigure-init
   is a non-link-local address of its interface from trigger which will cause the client's
   solicitation was received into the relay-address field.  Servers
   receiving client(s) to initiate a standard
   Request/Reply exchange with the solicitation then send their advertisements server in order to acquire the
   prospective client.

4.2. new or
   updated resources.
9. Message Formats

   All reserved fields in a message MUST be transmitted as zeroes and
   ignored by the receiver of the message.
9.1. DHCP Advertise Solicit Message Format

   A DHCP agent sends client multicasts a DHCP Advertise Solicit message to inform a prospective
   client about the IP FF02::1:2(All DHCP
   agents) address of a server over the interface to which a DHCP Request
   message may be sent.  When the client and server configured to locate one or
   more servers which are configured to provide configuration parameters
   to nodes on different
   links, the server sends the advertisement back through the relay
   whence client's link.

   Unless otherwise noted, the solicitation came.  The value of all fields in the DHCP
   Adverstise message are filled in set by the DHCP Server and not changed
   by any DHCP Relay.
   client.

      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 = 2 |S| 1 |C|P|  reserved |  preference  prefix-len |   solicit-ID    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   client's link-local address                 |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         agent-address                         relay-address                         |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         server-address                        |
     |                    (16 octets, if present)                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              extensions (variable number and length) ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      S
      C          If set, the server-address is present.

      reserved     0
      preference   An octet (unsigned) indicating a server's willingness
                   to provide service to the client (see Section 5.3).

      client's link-local address
                   The IP link-local address of the client interface
                   from which the client issued requests that all servers receiving
                 the DHCP Request message

      agent-address
                   The IP address of a DHCP Agent interface on the same
                   link as the client.

      server-address
                   If present, deallocate the releasable resources (e.g.
                 IP address of addresses) associated with the DHCP server

      extensions   See [15].

   Suppose that a server on client's binding.

      P          If set, the same link as a client issues requests that all servers receiving
                 the
   DHCP Advertise in response to a DHCP Solicit message sent to the
   All-DHCP-Agents multicast address.  Then the agent-address will be an
   IP address of one SHOULD return a list of subnet prefix
                 extensions identifying the server's interfaces networks on the same client's
                 link as the
   client, and that the `S' bit will be set server(s) are configured to zero, indicating manage.

      reserved   0

      prefix-len
                 An unsigned 7 bit number (0-127) non-zero prefix-len is
                 the absence number of leftmost bits of the server-address in the DHCP Advertise message.  See section 5.3
   for information about how clients handle the preference field.

   The server MUST copy the client's link-local agent's IPv6 address into the
   advertisement
                 which is sent in response to a DHCP Solicit.  Both
   server-address (if present) and agent-address of make up the DHCP Advertise
   message MUST have sufficient scope to be reachable subnet prefix.  The prefix-len field
                 is set by the client.
   Moreover, relay if the agent-address of any DHCP Advertise message sent by a relay MUST NOT be a link-local address.  In situations where there
   are no routers sending Router Advertisements, then a DHCP server MUST
   be configured on receives the same link as prospective clients.  The DHCPv6
   protocol design does not apply Solicit
                 message and forwards it to situations where one or more servers.

      solicit-ID
                 An unsigned 9 bit number (0-511) generated by the
                 client is
   unable to route messages used to a server not on identify this Solicit message.

      client's link-local address
                 The IP link-local address of the same link.

4.3. DHCP Request Message Format

   In order to request configuration parameters from a server, a client
   sends a DHCP Request message, and MAY append extensions [15].  If interface
                 through which the client does not know any server address, it MUST first obtain
   one by multicasting a DHCP will issue the Solicit message (see Section 4.1).
   Typically, when a
                 message.

      relay-address
                 Set by the client reboots, it does not have to be zero.  If received by a valid relay,
                 set by the relay to the site-local IP address of sufficient scope for the server to communicate with
                 interface on which the relay received the client.
   In such cases, client's
                 Solicit message.  Note that if the DHCP domain crosses
                 site boundaries, the relay MUST place a globally-scoped
                 address in this field.

   A client MUST NOT send the Solicit message directly to the server because All-DHCP-Agents
   multicast group (see section 3.1), setting the relay-address to zero.
9.2. DHCP Advertise Message Format

   A server could not return any sends an Advertise message in response to the
   client; a client's
   Solicit message.  The Advertise message notifies the client MUST send of the message to
   server's IP address.  If the local relay server is so configured by the network
   administrator and
   insert the relay-address as client requests it through the agent-address ``P'' bit in
   its Solicit message, the server SHOULD add a list of subnet prefix
   extensions to the Advertise message header.

   Otherwise, to notify the client MAY omit of the server-address in
   networks it manages on the DHCP Request
   message; in this case, client's link.

   When the client MUST clear the S-bit and send server are on different links, the
   message directly to server sends
   the server, using Advertise message back through the server's address as relay whence the IP
   destination address in corresponding
   Solicit came.  The solicit-ID is copied from the IP header.  In either case, client's Solicit
   Message.  The value of all fields in the DHCP Request Advertise message are entered filled
   in by the client. server and not changed in any way by any intervening relay.

      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 = 3 |C|S|R|  rsvd 2 |        transaction-ID  reserved   |   solicit-ID    |  preference   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   client's link-local address                 |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         agent-address                         |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         server-address                        |
     |                    (16 octets, if present)                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  extensions (variable number and length)   ....
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      C          If set, the client requests the server to remove all
                 resources associated with the client binding, except
                 those resources provided as extensions.

      S          If set, the server-address is present

      R          If set, the client has rebooted and requests that all
                 of its previous transaction-IDs be expunged
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         relay-address                         |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         server-address                        |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              extensions (variable number and made
                 available for re-use.

      rsvd length) ...      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      reserved     0

      transaction-ID
                 A

      solicit-ID   An unsigned integer identifier 9 bit number (0-511) used to identify
                   this
                 Request. Advertise message.  Copied from the client's
                   Solicit message.

      preference   An octet (unsigned) indicating a server's willingness
                   to provide service to the client.

      client's link-local address
                   The IP link-local address of the client interface
                   from which the client issued the DHCP Request message

      agent-address
                 The IP address of an agent's interface, copied from a
                 DHCP Advertisement Solicit message.

      server-address
                 If present, the

      relay-address
                   The IP address of the server which should
                 receive relay interface on the client's DHCP Request message.

      extensions See [15].

   When same
                   link as the client sets client.  Copied from the `C' bit and adds extensions, client's
                   Solicit.  If the server is expected to deallocate all other resources not listed in the
   extension.  The resources explicitly requested in extensions to the
   Request message SHOULD be reallocated by on the server to same link as the
                   client,
   assuming the client is still authorized to receive them. then this field MUST be zero.

      server-address
                   The transaction-ID is selected by site-local IP address of the client to be greater than or
   equal to 1024, unless server.  If the DHCP Request is sent in response to a
   Reconfigure msg (see section 4.6).  In that case, the transaction-ID
   is copied from
                   domain crosses site boundaries, then this address
                   MUST be globally-scoped.

      extensions   See the transaction-ID in ``extensions document'' for details [2].

   See Sections 14.4 and 15.3 for information about how clients and
   servers handle the Reconfigure message.

4.4. preference field.

9.3. DHCP Reply Request Message Format

   The server

   A client sends one DHCP Reply a Request message in response to every DHCP
   Request or DHCP Release received.  If request configuration parameters
   from a server.  It MAY append appropriate extensions [2].

   When a client reboots, it often does not have a valid IP address of
   sufficient scope for the request comes server to communicate with the `S'
   bit set, client.  In
   such cases, the client MUST NOT unicast the message to the server
   because the server could not directly return a response to the client.  The
   client MUST send the Request message to the server
   and had to use a neighboring relay agent.  In that case, indirectly, by using the server
   sends back
   on-link relay.  The client MUST fill in the DHCP Reply relay address field with
   the `L' bit set, and on-link relay's IP address.

   If the DHCP Reply Request message is addressed being formed in response to a
   Reconfigure-init message from the agent-address found in server, then the DHCP Request message.
   ALl transaction ID
   used must be copied from the Reconfigure-init.

   All fields in the DHCP Reply Request message are set entered by the DHCP server. client.

      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 = 4 |L|   status 3 |C|R|  reserved |        transaction-ID         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   client's link-local address                 |
     |                          (16 octets, if present) octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         relay-address                         |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         server-address                        |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         extensions (variable number and length)   ....        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      L
      C          If set, the client's link-local address is present
      status     One of client requests the server to remove
                 all releasable resources associated with the following decimal values:

                  0   Success
                 16   Failure, reason unspecified
                 17   Authentication failed or nonexistent
                 18   Poorly formed Request or Release
                 19   Resources unavailable
                 20   Client record unavailable
                 21   Invalid client IP address in Release
                 23   Relay cannot find Server Address
                 64   Server unreachable (ICMP error)
                 binding, except those releasable resources provided as
                 extensions.

      R          If set, the client has rebooted and requests that the
                 server clear any transaction-ID cache entries for the
                 client.

      reserved   0
      transaction-ID
                 An unsigned integer identifier used to identify this
                 Reply, and copied from the client's Request.
                 request.

      client's link-local address
                 The link-local address of the client interface from
                 which the client will issue the Request message.

      relay-address
                 The IP address of a relay's interface, copied from an
                 Advertise message.  If present, the server is on the same link
                 as the client, then this field MUST BE zero.

      server-address
                 The IP address of the client interface server to which issued the corresponding DHCP the client's
                 Request message is directed, copied from an Advertise
                 message.

      extensions
                 See [15].

   If the `L' bit is set, ``extensions document'' [2].

   A DHCP client selects the client's link-local address is present
   in transaction-ID from the Reply message.  Then range of
   1024--65535 used to identify its Request.  In contrast, a
   transaction-ID from the Reply is sent range of 0--1023is selected by the a DHCP server
   to identify a Reconfigure-init.  In the
   relay's address which was specified as latter case, the agent-address in transaction
   ID from the DHCP Reconfigure-init is copied by the client into its Request message,
   message.

   When the client sets the `C' bit and adds extensions documenting
   the relay uses releasable resources the link-local address client wishes to deliver keep, the Reply message server is
   expected to the client. deallocate all other releasable resources not listed.
   The transaction-ID in the DHCP
   Reply is copied by the server from SHOULD examine the included extensions to check whether
   the client Request message.

4.5. is still authorized to use them.
9.4. DHCP Release Reply Message Format

   The DHCP

   A server sends a Reply message in response to a client's Request
   message or Release message.

   If a Request message is sent without the assistance of any DHCP
   relay.  When received which contains a non-zero relay
   address field, then the client sends could not unicast the Request message
   to the server and thus had to use a on-link relay.  In that case, the
   server unicasts the Reply message to the relay address found in the
   Request message.

   If a Release message, it message is assumed to
   have received which contains a valid non-zero relay
   address field, then the client will not have an IP address with of
   sufficient scope after the Release to allow access to receive the target server.  If parameters are specified Reply message.  In
   this case, the server unicasts the Reply message to the relay address
   found in the extensions,
   only those parameters are released.  The values of all Release message.

   All the fields
   of in the DHCP Release Reply message are entered set by the Client.  The DHCP
   server acknowledges the Release message by sending a DHCP Reply
   (Sections 4.4, 6.3). 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  msg-type = 1 |D|  reserved 4 |R|  status     |        transaction-ID         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   client's link-local address                 |
     |                           (16 octets)                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         agent-address                   relay-address (if present)                  |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        client-address                         |
     |                    (16 octets, if present)                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         extensions (variable number and length)   ....        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      msg-type   5

      D
      R          If the `D' flag is set, the client instructs the server
                 to send the DHCP Reply directly back to the client,
                 instead ``relay-address'' field is present.

      status
                 This 7-bit field contains one of using the given agent-address and link-local
                 address to relay values in the Reply message.

      reserved   0
                 errors table in section 3.4.

      transaction-ID
                 A unsigned integer identifier used to identify this
                 Release, and copied into
                 Copied from the Reply. client's Request or Release.

      client's link-local address
                 The IP link-local address of the client interface
                 Copied from
                 which the the client issued the DHCP client's Request or Release message

      agent-address
                 The IP address of the agent interface for the IP
                 address to be released.

      client-address message.

      relay-address
                 The IP address of the client interface a relay's interface, copied from which the the client issued the DHCP
                 Request or Release message.  The
                 client-address field is present whenever  If the `D' bit is
                 set, even if it server is equal to on the link-local address.

      extensions See [15]

   It is an error (status code ``InvalidSource'' (see Section 2.4)) to
   include within
                 same link as the DHCP Release message both client, then the `D' ``R'' bit is not set
                 and an IP
   address extension which has the IP address used as the client-address this field of is not present.

      extensions
                 See the ``extensions document'' [2].
9.5. DHCP Release message header.

4.6. DHCP Reconfigure Message Format

   DHCP Reconfigure messages can only be sent

   A client sends a Release message to clients which have
   established an IP address which routes a server when it wishes to return
   one or more releasable resources to the link at server which they allocated
   them.  This can occur either because the client no longer needs the
   resource(s) or the client has determined through a resource-specific
   manner that the resource(s) are
   reachable, hence already in use by different
   client(s).  The client communicates the DHCP Reconfigure message is sent without reason for the
   assistance premature
   release of any DHCP relay. the resource in the status field of the resource's
   extension.  See ``extensions document'' [2] for more details.

   When a server client sends a Reconfigure Release message, the receivers are assumed it needs to have a valid IP
   address with sufficient scope to be accessible allow access by the target server.
   If such an address is not available, a relay is used.  Only the parameters
   which those
   releasable resources identified by extensions are specified released.  If no
   extensions are included in the extensions to Release message, then all releasable
   resources associated with the Reconfigure message need client's binding are to be requested again by released.

   The values of all fields of the client.  A Reconfigure Release message can either
   be unicast or multicast are set by the server.
   client.  The client will extract DHCP server acknowledges the
   extensions provided Release message by the server and send sending
   a DHCP Request message to
   the server using those extensions (see section 5.7). 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 = 6 |N| 5 |R|  reserved   |        transaction-ID         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   client's link-local address                 |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         server-address                        |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           X-address                           |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         extensions (variable number and length)   ....        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      N            The `N' flag indicates that the client should not
                   expect a DHCP Reply in response to the DHCP Request
                   it sends as a result of the DHCP Reconfigure message.

      reserved     0

      transaction-ID
                   A unsigned integer identifier used to identify this
                   Reconfigure, to by copied into the following DHCP
                   Request message that will be transmitted by the
                   client.

      server-address
                   The IP address of
      R          If set, the DHCP server issuing ``X-address'' field contains the DHCP
                   Reconfigure message.

      extensions   See [15]

5. DHCP Client Considerations

   A node which is address of
                 relay.  If not set, the ``X-address'' field contains a DHCP agent MUST silently discard any DHCP
   Solicit, DHCP Request, or DHCP Release message it receives.

5.1. Verifying Resource Allocations After Restarts

   A client MAY retain its configured parameters and resources across
   client system reboots and program restarts.  Any
                 non-local scope client wishing address.

      reserved   0

      transaction-ID
                 An unsigned integer identifier used to use identify this feature MUST also maintain state
                 Release message.

      client's link-local address
                 The client's link-local address for the address of
   its DHCP agent address.  When interface
                 from which the client restarts, issued the client MUST
   also formulate a DHCP Request Release message (and
                 to verify that its configured
   parameters and which the releasable resources are still valid.  This Request message MUST
   have the `C' bit set, to clean up stale client binding information bound at the
                 server).

      server-address
                 The IP address of the server which may no longer be in use by allocated the client; stale
   information
                 resource.

      X-address
                 If the ``R'' bit is that which set, the client does not include in extensions
   to such request messages.

   If ``X-address'' field
                 contains the server does not respond to IP address of the DHCP Request message after
   REQUEST_MSG_MIN_RETRANS (see section 8), relay interface on the client may still
   use any resources whose lifetimes have not yet expired.  In such
   cases, however,
                 same link as the client MUST begin to search for another server
   by multicasting a DHCP Solicit message with client.  If the `C' ``R'' bit set (see
   section 5.2).  The client SHOULD log a DHCP System Error.

   This also handles the case wherein a client restarts on a new
   network, where its IP address is no longer valid.  In not set,
                 this situation,
   when the client receives field contains a new non-link-local IP address and of the
                 client interface from which the old IP address
   is no longer needed, the client MUST release its old IP address by
   issuing a DHCP issued the
                 Release message with message.

      extensions See the appropriate extension if it
   can communicate with its previous server. ``extensions document'' [2].

   A mobile client (that is not stationary on a network) SHOULD keep its
   agent-address, and possibly selects the relevant server address, along with
   all resource-server associations [15] on non-volatile storage.  This
   will allow transaction-ID from the client range of
   1024--65535 used to release resources with identify the DHCP Solicit or Release messages if message.

   A client MUST NOT specify an IP address in the client-address field
   that it enters a different network location before is releasing its resources.

5.2. Sending in the extensions field.
9.6. DHCP Solicit Messages Reconfigure Message Format

   A client server sends a Reconfigure message when it wishes to inform one or
   more clients of new or updated values for configuration parameters.
   The new configuration parameters are carried in the extensions
   portion of the Reconfigure message.  Note that a Reconfigure message
   MUST NOT carry releasable resource extensions.

   Reconfigure messages can ONLY be sent to clients which have the
   established an IP address of a server sufficient scope as to send a Request message.
   The client SHOULD locate a DHCP be directly
   reachable by the server.

   Clients acknowledge Reconfigure messages with Reconfigure-reply
   messages.

      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 = 6 |   reserved    |        transaction-ID         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        server-address                         |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         extensions (variable number and length)   ....        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      reserved   0
      transaction-ID
                 An unsigned integer identifier in the range of
                 0--1023 chosen by the server by multicasting a DHCP Solicit
   message to the All-DHCP-Agents link-local multicast identify this
                 Reconfigure message.

      server-address
                 The IP address (see
   Section 3.3), setting of the Hop Limit == 1.  If there are no DHCP
   servers on the same link as server issuing the node, then a DHCP relay
                 Reconfigure message.  MUST be
   present if solicitations sent from a client's link-local address are of sufficient scope to be handled.

   When sending a
                 reachable by all clients.

      extensions
                 See the ``extensions document'' [2].
9.7. DHCP Solicit message, a Reconfigure-reply Message Format

   A client MUST set the Relay
   Address field sends a Reconfigure-reply message to 16 octets acknowledge receipt of zeros, and zero the prefix-size field.

   If
   a client reboots and does not have Reconfigure message from a valid server.

   A Reconfigure-reply message can only be sent if the client has an IP address, it SHOULD
   set
   address of sufficient scope to contact the `C' bit server.  No interaction
   with a relay is possible.

   All fields in the DHCP Solicit Reconfigure-reply message it sends when restarting.
   By setting are entered by the `C' bit in
   client.

      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 = 7 |r|  status     |      transaction-ID           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   client's link-local address                 |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         server-address                        |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      r          reserved (0)

      status
                 This 7-bit field contains one of the solicitation, a client requests that
   all values from the DHCP servers that receive
                 errors table in section 3.4.

      transaction-ID
                 An unsigned integer identifier copied from the solicitation should clean up
   their client records that match its server's
                 Reconfigure message.

      client's link-local address.

   If a address
                 The client's link-local address for the interface from
                 which the client issued the Reconfigure-reply message.

      server-address
                 Copied from the Reconfigure message.
9.8. DHCP Reconfigure-init Message Format

   A server sends a DHCP Solicit Reconfigure-init message after when it reboots, the
   solicitation SHOULD be delayed after reception wishes to notify
   one or more clients of new or updated values for configuration
   parameters available on the first Router
   Advertisement [14] message (see section 5.8), by at least some random
   amount of time between MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY (see
   section 8).  This delay is intended to help stagger requests to
   DHCP servers (and avoid link-layer collisions) after a power outage
   causes many nodes server.

   Reconfigure-init messages can ONLY be sent to reboot all at once.  Each subsequent DHCP
   Solicit message that is issued before receiving clients which have
   established an advertisement
   MUST IP address of sufficient scope as to be delayed by twice the amount directly
   reachable by which the previous DHCP
   Solicit message was delayed, plus a small random delay between
   MIN_SOLICIT_DELAY and MAX_SOLICIT_DELAY seconds.

5.3. Receiving DHCP Advertise Messages

   After a client has received server.

   A ``Reconfigure-init'' serves as a DHCP Advertise message, it has trigger which will cause the
   address of
   clients to initiate a server for subsequent DHCP Request messages.  If the `S'
   bit is zero, Request/Reply exchange with the DHCP Advertise message was transmitted by a server
   on the same link as in order
   to receive the client, new information.

      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 = 8 |   reserved    |        transaction-ID         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        server-address                         |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         extensions (variable number and length)   ....        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      reserved   0

      transaction-ID
                 An unsigned integer identifier in the client uses the agent-address
   as the server's address; otherwise, range of
                 0--1023 chosen by the server's server to identify this
                 Reconfigure-init message.

      server-address
                 The IP address is
   located in the server-address field.  If of the server-address is a
   multicast address, DHCP server issuing the advertisement
                 Reconfigure-init message.  MUST be silently discarded.

   A server MAY append extensions of sufficient scope
                 to its advertisements; this might
   allow be reachable by all clients.

      extensions SHOULD only include an ERE and/or authentication
                 extensions.  No configuration information SHOULD be
                 included.  See the ``extensions document'' [2] for more
                 information about extensions.
10. DHCP Server Solicitation and Subnet Prefix Discovery

   This section describes how a client to select locates agents (relays and
   servers) and how it can learn about the configuration that best meets networks on its
   needs from among several prospective link that are
   managed by these servers.

   Unless a DHCP Advertisement  The behavior of client, server, and relay
   implementations is received discussed, along with a preference equal
   to 255 (see Section 4.2), the client messages they use.
10.1. Solicit Message Validation

   Clients MUST wait CLIENT_ADV_WAIT
   seconds after issuing the DHCP silently discard any received Solicit message in order to receive
   the Advertisement with messages.

   Agents MUST discard any received Solicit messages if the highest preference.  After waiting for
   that period of time, ``client's
   link-local address'' field does not contain a client valid link-local
   address.

   Servers MUST select the highest preference
   server as discard each received Solicit message which meet the target of its DHCP request.  If a client receives an
   advertisement with a preference of 255, it
   following criteria:

     o The ``relay-address'' field does not have to wait for
   any more advertisements.

   If a client sends a DHCP Request to a highly preferred server but
   fails to receive a DHCP reply from contain an address of
       sufficient scope that server after following the
   retransmission algorithm in section 8, is reachable by the client MUST then try to
   send a DHCP Request to a less preferred server.

   A client

     o The ``relay-address'' field is non-zero, but prefix-len is free to cache zero.

   An error message MAY be logged by the result agent.  The logging of
   such messages SHOULD be controlled by an agent implementation
   configuration flag.
10.2. Advertise Message Validation

   Servers MUST silently discard any DHCP Advertisement it
   receives.  This is purely a potential performance enhancement,
   because received Advertise messages.

   Clients MUST discard any Advertise messages that meet any of the results might change over time.  A client may
   following criteria:

     o The ``Solicit-ID'' field value does not get
   a DHCP Reply if it uses a cached server-address, and match the value the
       client used in that case
   SHOULD multicast another DHCP its Solicit message.

5.4. Sending DHCP Request Messages

   A client obtains configuration information from a server by sending
   a DHCP Request message.

     o The client MUST know ``client's link-local address'' field value does not match
       the server's link-local address
   before sending the Request message, and of the client MUST have acquired
   a (possibly identical) DHCP agent address.  If interface upon which the client and server
   are on
       sent the same link, Solicit message.

   Relays MUST discard any Advertise messages that meet any of the agent-address used by
   following criteria:

     o The ``relay-address'' field does not contain the client MUST be relay's address
       on the same link as the DHCP server's client.

     o The ``client's link-local address'' field does not contain a
       valid link-local address.  A DHCP Request
10.3. Client Behavior

   Clients use the Solicit message MUST
   NOT be sent primarily to any multicast address, since otherwise multiple discover DHCP servers would possibly allocate resources
   configured to serve networks on the link containing the client.
   Optionally, the client MAY set the ``P'' bit which has the effect
   of requesting that the server return subnet prefix extensions
   identifying the networks on the client's link the server is
   configured to manage.
10.3.1. Creation and sending of the Solicit message

   When creating a Solicit message, the client SHOULD start out with
   a buffer initialized with zeroed octets.  The client sets the
   ``msg-type'' field to 1, and places the link-local address of the
   interface it wishes to configure in the link-local address field.

   If the client is prepared to process multiple Advertise messages
   in response to the same Request, and its Solicit message, the client would have no way to know which
   servers had made will set the allocations, if any packets were lost due
   Solicit-ID field to
   collisions, etc.

   If 1.  Every time the DHCP client initiates a new server is off-link, and
   solicitation attempt (not a retransmission), the client has no valid IP
   address of sufficient scope, increments
   the Solicit-ID by one.  If the 9-bit field rolls over to 0, then the
   client MUST include sets the
   server-address and set Solicit-ID to 1.  A client which will only accept
   the `S' bit in first Advertise message it receives leaves the DHCP Request message.  In
   this case, Solicit-ID field
   initialized to zero.

   The ``C'' bit of the IP destination address in Solicit message is set by the IP header will be a DHCP
   relay address.

   Otherwise, if client when the
   client has a valid IP address no cached knowledge of sufficient scope
   and knows previous DHCP configuration for the IP address of a candidate server, it MUST send
   interface.  Setting this bit requests that the
   Request message directly server release any
   information assigned to the server without requiring client for the services
   of networks on the local DHCP relay. client's
   link.

   If a the client wishes desires to instruct a server to deallocate all unknown
   previous resources, configuration information, and bindings
   associated with learn of the networks managed by DHCP on
   the link its agent-address and link-local address, interface is attached to, it sets the `C' ``P'' bit in the DHCP Request.  A client MAY send in
   such a Request even when it is no longer attached to the link on
   which the relay-address is attached.
   Solicit message.

   The `C' bit allows better
   reclamation of available resources when a client lost records for
   its resource-server associations and might not otherwise be able transmits the Solicit message to
   release the associated resources.

   When FF02::1:2  (All DHCP
   Agents) multicast address, destination port 547.  The source port
   selection can be arbitrary, although it SHOULD be possible using a
   client reboots configuration facility to set a specific source port value.

10.3.2. Time out and loses its previous state, the server
   should no longer keep track retransmission of Solicit Messages

   The client's first Solicit message on the the XID-TIMEOUT binding cache interface MUST be delayed
   by a random amount of
   transaction IDs (see section 6) associated with that previous state.
   In order to inform time between the server that interval of MIN_SOL_DELAY and
   MAX_SOL_DELAY. This random delay desynchronizes clients which start
   at the same time (e.g., after a power outage).

   The client waits ADV_MSG_TIMEOUT, collecting Advertise messages.
   If no longer wishes
   any association to be maintained between used transaction-IDs Advertise messages are received, the client retransmits
   the Solicit, and
   previous transactions, 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 SHOULD set stops trying to DHCP configure the `R' bit in its
   interface.  An event external to DHCP
   Request.

   In any case, after choosing a transaction-ID which is numerically
   greater than its last recorded transaction-ID, required to restart the DHCP
   configuration process.

   Default and filling initial values for MIN_SOL_DELAY, MAX_SOL_DELAY,
   ADV_MSG_TIMEOUT, AND ADV_MSG_MAX are documented in the
   appropriate fields section 3.5.
10.3.3. Receipt of the DHCP Request message, Advertise messages

   Upon receipt of one or more validated Advertise messages, the client MAY append
   various DHCP Extensions to
   selects one or more Advertise messages based upon the message.  These extensions denote
   specific requests by following
   criteria.

    -  Those Advertise messages with the client; for example, highest server preference
       value (see section 14.4) are preferred over all other Advertise
       messages.

    -  Within a client may request group of Advertise messages with the same server
       preference value, a particular IP address, or request that client MAY select those servers whose
       Advertise messages advertise information of interest to
       the client.  For example, one server send an update
   containing may be advertising the client's new
       availability of IP addresses on networks which have an address
       scope of interest to a Domain Name Server.  When
   all desired extensions have been applied, the client.

   Once a client sends the DHCP
   Request to has selected Advertise message(s), the appropriate agent.

   For each pending DHCP Request message, a client MUST maintain will
   typically store information about each server, such as relay address
   and prefix length, server preference value, networks advertised,
   when the
   following information:

    - The transaction-ID advertisement was received, and so on.  Depending on the
   requirements of the request message,
    - The server-address,
    - The agent-address (which can be client's invoking user, the same as client MAY initiate a
   configuration exchange with the server-address),
    - The time at which server(s) immediately, or MAY defer
   this exchange until later.

10.4. Relay Behavior

   For this discussion, the next retransmission will be attempted, and
    - All extensions appended Relay is assumed to the request message.

   If a client does not receive a DHCP Reply message (Section 5.5) have been configured
   with some list of server destination addresses, which may be unicast,
   the same transaction-ID as a pending FF05::1:3 (All DHCP Request message within
   REPLY_MSG_TIMEOUT (see section 8) seconds, Servers) multicast address, or if some other
   multicast address selected by the received DHCP
   Reply message contains network administrator.
10.4.1. Relaying of Solicit messages

   When a DHCP Authentication extension Relay receives a valid Solicit message, it places the IP
   address of the interface upon which fails
   to provide it received the correct authentication information, Solicit message
   in the client MUST
   retransmit ``relay-address'' field of the Request with Solicit.  The Relay also places
   the same transaction-ID and continue to
   retransmit according to number of bits of that make up the rules subnet prefix for this address
   in Section 8.  If (after following
   those rules) the client ``prefix-len'' field of the Solicit.

   The Relay then forwards this Solicit to the list of server
   destination addresses that it has not received been configured with.
10.4.2. Relaying of Advertise messages

   When a Reply Relay receives a valid Advertise message, it SHOULD
   start over again by multicasting a new DHCP Solicit unicasts the
   message to find a
   different server.

   If the client receives an ICMP error message link-local address found in response the ``client's link-local
   address'' field by way of the appropriate network interface.
10.5. Server Behavior

   For this discussion, the Server is assumed to such a have been configured in
   an implementation specific manner.  This configuration is assumed to
   contain all network topology information for the DHCP Request, it likewise SHOULD start over again by multicasting domain, as well
   as any necessary authentication information.
10.5.1. Receipt of Solicit messages

   Upon the receipt of a
   new DHCP valid Solicit message, to find a different server. the server first
   identifies the client's location within the DHCP domain.  If the
   ``relay-address'' and / or ``prefix-len'' fields of the Solicit are
   zeroed, then the client transmits a DHCP Request in response to a DHCP
   Reconfigure message, further processing is as specified in
   Section 5.7.  The client can continue attached to operate with its existing
   configuration information and resources until it receives the
   corresponding DHCP Reply from same link as the server.  The
   If these fields are non-zero, then the client exists on the same retransmission
   rules apply link
   as for any other DHCP Request message from the client.
   When network identified by these two fields.

   If administrative policy permits the `N' bit is set, a DHCP Request sent in response server to respond to a DHCP
   Reconfigure message client on
   that link, the server will not elicit a DHCP Reply generate and send an Advertise message from to
   the
   server.

5.5. Receiving DHCP Reply Messages client.

10.5.2. Creation and sending of Advertise messages

   When a client receives a DHCP Reply creating an Advertise message, it MUST check whether
   the transaction-ID in the Reply message matches server SHOULD start out
   with a buffer initialized with zeroed octets.  The server sets the transaction-ID
   of a pending DHCP Request message.  If no match is found,
   ``msg-type'' field to 2 and copies the Reply
   message MUST be silently discarded.

   If values of the Reply message is acceptable, following fields
   from the client processes each
   Extension [15], extracting client's Solicit to the relevant configuration information
   and parameters for its network operation. Advertise message:

     o solicit-ID

     o client's link-local address

     o relay-address

   The client can determine
   when all extensions server places one of its IP addresses (determined through
   administrator setting) in the Reply have been processed by using the UDP
   Length ``server-address'' field of the Reply.  Some extensions in
   Advertise message.  The server initializes the Reply may have
   status codes, which indicate to ``preference''
   field from its configuration information.  See section 15.3 for a
   description of server preference.

   If the client requests subnet prefix extensions (by setting the reason for failure
   when ``P''
   bit in its Solicit) and the server was unable implements and is configured to honor the request.  If
   provide prefix extensions, the server will generate and insert a
   subnet prefix extension for each network on the client's link it is
   unable
   configured to honor manage.

   If the request in an extension included by ``relay-address'' field of the client,
   that extension may simply be omitted from Advertise message is zero, then
   the Reply.  The server MAY
   also provide unicasts the client with configuration parameters Advertise message directly to the client did
   not specifically request.

   Some configuration information extracted from
   using the extensions to ``client's link-local address'' field value as destination
   address.  If the
   DHCP Reply message MUST remain associated with ``relay-address'' field is non-zero, then the server that sent
   unicasts the message.  The particular extensions that require this extra
   measure of association with Advertise message directly to the server are indicated in relay using the
   ``relay-address'' field value as the destination address.
11. DHCP
   Extensions document [15].  These "resource-server" associations are
   used when sending DHCP Release messages.

5.6. Sending Client-Initiated Configuration Exchange

   A client initiates a configuration exchange with one or more servers
   it has found through DHCP Release Messages

   If a client wishes server solicitation whenever requested to ask
   do so by the server application layer in order to release all acquire configuration
   information and
   resources relevant to the client, of interest.
11.1. Request Message Validation

   Clients MUST silently discard any received Request messages.

   Agents MUST discard any Request messages in which the client SHOULD send ``client's
   link-local address'' field does not contain a DHCP
   Release message without valid link-local
   address.

   Relays MUST discard any extensions; this is preferable to sending
   a DHCP received Request message with messages in which the `C' bit set and no extensions.  If a
   client wishes to retain some
   ``relay-address'' field value does not match any of its network configuration parameters,
   but determines that others are no longer needed, it SHOULD enable the server to release allocated resources which are no longer in
   use by sending a DHCP Release relay's
   addresses.

   Servers MUST discard any received Request message to the server, and including
   extensions to identify which meets any of
   the unneeded items. following criteria:

     o The client consults its
   list ``server-address'' field value does not match any of resource-server associations in order the
       server's addresses.

     o If the ``relay-address'' field is set, and that field's value
       does not contain an address of sufficient scope as to determine which
   server should receive be
       reachable by the desired Release message. server.

     o The Release
   MUST be transmitted to ``extensions'' field contains an authentication extension,
       and the server that provided cannot successfully authenticate the configuration
   parameters.

   Suppose a client wishes to release resources which were granted to
   it at another IP address.  Further, suppose client.
11.2. Reply Message Validation

   Servers MUST silently discard any received Reply messages.

   Clients MUST discard any Reply message that meets any of the client has an
   IP address that will still be valid after
   following criteria:

     o The ``transaction-ID'' field value does not match the server performs value the
   operations requested
       client used in its Request or Release message.

     o The ``client's link-local address'' field value does not match
       the extensions to link-local address of the DHCP Release message,
   and interface upon which has sufficient scope to be reachable from the server.  In
   that case, and only then, the client MUST set the `D' bit
       sent in the DHCP its Request or Release message.

     o The Reply message (see section 4.5).  This instructs contains an authentication extension, and the server
       client's attempt to
   send authenticate the DHCP message fails.

   Relays MUST discard any Reply directly back to the client at the latter valid
   IP address, instead message that meets any of performing the default processing of sending following
   criteria:

     o The ``R'' bit isn't set.

     o The ``relay-address'' field value does not contain the DHCP Reply back through relay's
       address on the agent-address included in same link as the DHCP
   Release.

5.7. Receiving DHCP Reconfigure Messages

   Each client implementation client.

     o The ``client's link-local address'' field value does not contain
       a valid link-local address.

11.3. Release Message Validation

   Clients MUST support listening at UDP port 546 to
   receive possible DHCP Reconfigure messages; in cases where the client
   knows that no Reconfigure silently discard any received Release messages.

   Agents MUST discard any Release message will ever be issued, that meets any of the client MAY
   be configured to avoid executing this supported feature.  Any DHCP
   Reconfigure message received with
   following criteria:

     o The ``transaction-ID'' field contains a transaction-ID greater than or
   equal to 1024 value not in the
       1024--65535 range.

     o The ``client's link-local address'' field does not contain a
       valid link-local address.

   Relays MUST be silently discarded.

   In some cases, discard any received Release message that meets any of
   the following criteria:

     o The ``R'' bit is not set.

     o The ``X-address'' field value does not match any of the IP address at relay's
       addresses.

   Servers MUST discard any received Release message which meets any of
   the client listens will be a
   multicast following criteria:

     o The ``X-address'' field does not contain an address sent of sufficient
       scope as to the client be reachable by the server in an extension
   to server.

     o The ``extensions'' field contains an earlier DHCP Reply message.  If the client does not listen for
   DHCP Reconfigure messages, it is possible that authentication extension,
       and the client will not
   receive notification that its server has deallocated the client's
   IP address and/or other resources allocated to cannot successfully authenticate the client.  See
   discussion in 6.5.  The
11.4. Client Behavior

   A client MAY receive a prefix update for will generate one or more of their addresses and then MUST use that prefix for those
   addresses.

   If a client receives a DHCP Reconfigure message, it is a request for
   the client to send a new DHCP Request to the server which sent the
   Reconfigure message.  Unless the `N' bit is set, messages when prompted by
   the client MUST
   await a DHCP Reply with a matching transaction-ID, retransmitting
   (as specified application layer in section 8) until the Reply is received.  The server
   sending the Reconfigure message MAY be different than the server
   which sent a DHCP Reply message containing the original order to acquire configuration information.

   Reconfigure messages MAY be retransmitted by
   A client may initiate such an exchange automatically in order to
   acquire the server necessary network parameters to communicate with nodes
   off-link.  The client uses the same
   transaction-ID.

   When server and relay address information
   from previous Advertise message(s) for use in delivering Request
   message(s).  Note that a client receives a retransmitted unicast Reconfigure message
   within XID_TIMEOUT of the last received Reconfigure message with the
   same transaction-ID, the may request configuration information
   from one or more servers at any time.

   A client MUST reformulate exactly uses the same
   DHCP Request Release message and retransmit in the request message to management of releasable
   resources when:

     o The client has determined through a resource-specific manner
       that the server
   again.  In this way, resource assigned by the server can make is already in use of the retransmission
   algorithm to ensure that by a
       different client.

     o The client has received been instructed to release the Reconfigure
   message. resource prior to
       the lease expiration time since it is no longer needed.
11.4.1. Creation and sending of Request messages

   When creating a Request message, the client receives SHOULD start out with
   a retransmitted multicast Reconfigure message
   within XID_TIMEOUT of the last received Reconfigure message buffer initialized with
   the same transaction-ID, the client MUST not resend the the Request
   message if RECONF_MULTICAST_REQUEST_WAIT (see section 8) has not
   expired.  If RECONF_MULTICAST_REQUEST_WAIT has expired then the zeroed octets.  The client MUST reformulate exactly the same DHCP Request message and
   retransmit sets the Request message
   ``msg-type'' field to the server again, 3, and then reset
   RECONF_MULTICAST_REQUEST_WAIT to its default value or the value that
   was provided from a retransmission extension [15] provided by the
   server.  In this way, places the server can make use link-local address of the retransmission
   algorithm
   interface it wishes to ensure that all affected clients have received associate with the
   multicast Reconfigure message.

   For each Extension which is present configuration information
   with in the Reconfigure message, ``client's link-local address'' field.

   Unless the
   client MUST append a matching Extension to its Request message, which
   it formulates to send message is created in response to a
   Reconfigure-init message, the server specified client generates a transaction
   ID in the server-address
   field range of 1024--65535 and inserts this value in the message.
   ``transaction-ID'' field.

   The client also copies a transaction-ID from places the Reconfigure message into address of the Request message.  Processing for destination server in the
   Request
   ``server-address'' field.

   If the client is not on the same link as specified in Section 5.4, except:

    - the destination
   server, the client retransmits as stated above places the appropriate relay's address in this section

    - the
   ``relay-address'' field.

   If the client never needs a Relay to send is acquiring configuration information on the Request to interface
   for the DHCP
       Server

    - first time, the client MUST NOT SHOULD set the `S' or `R' bits

    -  if ``C'' bit in the
   header.  How the `N' Bit client determines if this is set, the first configuration
   attempt on the interface is implementation-specific.  A client will not get may
   implement a Reply cache of configuration information on a per-interface
   basis; if that cache does not exist, that client would set the
   ``C'' bit.  Clients which do not implement caching of per-interface
   configuration information MUST always set the ``C'', and include
   any extensions carrying releasable resources received from earlier
   configuration exchanges in the
       server

    -  if extensions field of the Request.

   If the client receives has determined through an ICMP error message implementation-specific
   manner that the client implementation itself has restarted, it should abort MUST
   set the ``R'' bit in the header.  After the first successful exchange
   with the server, the
       Reconfigure transaction and log an error message.  The client MUST NOT transmit a DHCP Solicit message set the ``R'' bit in order to rediscover subsequent
   Request messages.

   Client considerations for extensions are now considered (see the
   ``extensions document'', [2] for more details).

   If the client already has an IP address of sufficient scope to
   directly reach the DHCP Server.

   Resources held by server, then the client which are not identified by Extensions
   in SHOULD unicast the Request
   to the server.  Otherwise, if the server's Reconfigure message are not affected.

   A server may ask its is off-link, the client
   unicasts the Request message to join a multicast group for the
   purpose appropriate relay.

11.4.2. Time out and retransmission of receiving DHCP Reconfigure Request Messages

   The client waits REP_MSG_TIMEOUT milliseconds, collecting
   Reply messages.  When a Reconfigure
   message is delivered to  If no Reply messages are received, the client by way of
   retransmits the selected multicast
   address, Request with the same transaction-ID, and doubles
   the REP_MSG_TIMEOUT value, and waits again.  The client MUST delay its further response for continues
   this process until a random
   amount of Reply is received or REQUEST_MSG_ATTEMPTS
   unsuccessful attempts have been made, at which time uniformly distributed within the interval between
   RECONF_MMSG_MIN_RESP and RECONF_MMSG_MAX_RESP seconds (see
   section 8).  This will minimize client MUST
   abort the likelihood that configuration attempt.  The client SHOULD report the server will
   be flooded with DHCP Request messages.

5.8. Interaction with Stateless Address Autoconfiguration

   Please refer abort
   status to the Stateless Address Autoconfiguration Protocol
   specification [20] for details regarding the actions taken by clients
   upon receiving Router Advertisements with changing application layer.

   Default and initial values for the `M' REP_MSG_TIMEOUT and `O' bits.

6. DHCP Server Considerations

   A node which is not a client or relay MUST ignore any DHCP Advertise,
   DHCP Reply, or DHCP Reconfigure REQ_MSG_ATTEMPTS
   are documented in section 3.5.
11.4.3. Receipt of Reply message it receives.

   A server maintains in response to a collection Request

   Upon the receipt of a valid Reply message, the client records, called
   ``bindings''.  Each binding is uniquely identifiable by extracts the ordered
   pair <link-local address, agent-address>, since
   configuration information contained in the link-local
   address is guaranteed Reply.  If the ``status''
   field contains a non-zero value, the client reports the error status
   to be unique [20] on the link identified by application layer.

   If the
   agent-address and prefix.  An implementation extensions field contains one or more ``Reconfigure Multicast
   Address'' extensions (see ``extensions document'', ``Reconfigure
   Multicast Address Extension'' section [2]), the client MUST support bindings
   consisting of at least a client's link-local address, agent-address,
   preferred lifetime join
   these multicast groups, and valid lifetime [20] for each client address.

   A server MAY, at MUST monitor the discretion of UDP 546 port for
   Reconfigure or Reconfigure-init messages on the network administrator, be networks configured so that client bindings are identified
   by DHCP.

   If the client's
   link-local address, without need to use the additional configuration information
   supplied by returned in the Reply contains
   releasable resources, then the client MUST take over lease management
   of the agent-address. resource.  A client binding may be used MUST NOT request releasable resources
   unless it is prepared to store any other information,
   resources, appropriately manage the resource lease.
11.4.4. Creation and configuration data which will be associated with sending of Release messages

   When creating a Release message, the
   client.  A server MUST retain its clients' bindings across server
   reboots, and, whenever possible, client SHOULD start out with
   a buffer initialized with zeroed octets.  The client should be assigned sets the
   same configuration parameters despite server system reboots
   ``msg-type'' field to 5, and DHCP
   server program restarts.  A server MUST support fixed or permanent
   allocation places the link-local address of the
   interface the configuration parameters to specific clients.

   In addition information it wishes to release is
   associated with in the ``client's link-local address'' field.

   The client binding a server must maintain an
   XID_TIMEOUT binding cache to determine if a previous transaction-ID
   is being retransmitted by a client.  An implementation of an
   XID_TIMEOUT binding cache MUST support at least generates a tuple consisting of transaction ID in the client's link-local address, agent-address prefix, IPv6 address, range of
   1024--65535  and XID_TIMEOUT inserts this value when in the cache entry can be deleted (see
   Section 8).

6.1. Receiving DHCP Solicit Messages

   If ``transaction-ID''
   field.

   The client includes extensions containing the DHCP Solicit message was received at releasable resources it
   is releasing in the All-DHCP-Servers
   multicast address, ``extensions'' field.  The appropriate ``status''
   field in the server extensions MUST check be set to make sure that indicate the
   relay-address is present, and is not a link-local address.  If reason for the
   relay-address is not present, or if it is a link-local address,
   release.

   The client places the IP address of the server MUST silently discard who allocated the packet.  Note that if
   resource(s) in the
   client sends a DHCP Solicit message from a link-local address, ``server-address'' field.

   If the
   multicast destination client will be have an appropriately scoped IP address after the All-DHCP-Agents address, not
   release transaction is completed, the
   All-DHCP-Servers address.

   When client clears the `C' ``R'' bit is set
   and places this address in the solicitation, the server deallocates
   all resources that match ``X-address'' field.  If the link-local client
   will not have an appropriately scoped IP address after the release
   transaction is completed, the client sets the ``R'' bit and saved
   agent-address places
   the address of the appropriate relay in the solicitation message, if a binding for ``X-address'' field.

   If the client can be found.  If a is configured to use authentication, the client binding cannot be found
   generates the server
   SHOULD continue appropriate authentication extension, and adds this
   extension to process the Solicit message.

   As an optimization, a server processing a Solicit message from relays
   MAY check ``extensions'' field.  Note that the prefix of authentication
   extension MUST be the IP source address last extension in the IP header to
   determine whether ``extensions''
   field.  See the server has received ``extension document'' for more details about the Solicit from multiple
   relays on
   authentication extension [2].

   If the same link.  The prefix-size field in ``R'' bit is set, then the solicitation
   enables client MUST unicast the server Release
   to ascertain when two the relay addresses belong to indicated in the same link.

6.2. Sending DHCP Advertise Messages

   Upon receiving and verifying ``X-address'' field.  Otherwise, the correctness of a DHCP Solicit
   message, a server constructs a DHCP Advertise
   client unicasts the Release message directly to the server indicated
   in the ``server-address'' field.
11.4.5. Time out and transmits
   it on retransmission of Release Messages

   The client waits REP_MSG_TIMEOUT milliseconds, collecting Reply
   messages.  If no Reply messages are received, the same link as client retransmits
   the solicitation was received from.  When Release, and doubles the
   solicitation REP_MSG_TIMEOUT value, and waits again.
   The client continues this process until a Reply is received or
   REL_MSG_ATTEMPTS unsuccessful attempts have been made, at which
   time the All-DHCP-Servers multicast address, client SHOULD abort the server release attempt.  The client
   SHOULD delay return the transmission of its advertisement abort status to the application, if an application
   initiated the release.

   Default and initial values for a random amount of time between SERVER_MIN_ADV_DELAY REP_MSG_TIMEOUT and
   SERVER_MAX_ADV_DELAY (see REL_MSG_ATTEMPTS
   are documented in section 8).

   If 3.5.

   Note that if the relay-address is nonzero, client fails to release the resource, the resource
   will be reclaimed by the server MUST copy it into when the
   agent-address field lease associated with it
   expires.

11.4.6. Receipt of Reply message in response to a Release

   Upon receipt of the advertisement a valid Reply message, the client can consider the
   Release event successful, and send SHOULD return the
   advertisement successful status to
   the relay-address.  Otherwise, the server MUST
   send application layer, if an application initiated the advertisement release.
11.5. Relay Behavior

11.5.1. Relaying of Request or Release messages

   When a Relay receives a valid Request or Release message, it forwards
   it to the client's link-local address.  An IP address of the interface on which the server received the Solicit
   message MUST appear found in the server-address ``server-address'' field of the corresponding
   advertisement, and
   message.
11.6. Server Behavior

   For this discussion, the 'S' bit MUST be set.

   The server MAY append extensions Server is assumed to the Advertisement, have been configured
   in order an implementation specific manner with configuration of interest
   to
   offer the soliciting node the best possible clients.  Such configuration information about the
   available services and resources.

6.3. DHCP MAY contain releasable
   resources such as IP addresses.
11.6.1. Receipt of Request and Reply Message Processing

   DHCP server MUST check to ensure that messages

   Upon the client's link-local address
   field receipt of the a valid Request message contains from a link-local address.  If not,
   the message MUST be silently discarded.  If client the `S' bit is set, server
   can respond to, (implementation-specific administrative policy
   satisfied) the server MUST check that scans the server-address matches one of its own IP
   addresses. extensions field.

   If the server-address does not match, client has set the Request message ``C'' bit, the server MUST be silently discarded.

   If release all
   releasable resources currently associated with the received agent-address and link-local address client's binding
   that do not
   correspond to any binding known to appear in the server, then ``extensions'' field.

   If the client has set the ``R'' bit, the server
   SHOULD create a new binding MUST delete any
   transaction-ID cache entries it is maintaining for the previously unknown this client,
   and send a DHCP Reply with any resources allocated to the new
   binding.  Otherwise, if
   the server cannot create a new binding,
   it SHOULD return a DHCP Reply with implements such a status of ``NoBinding'' cache.

   Server considerations for extensions are now evaluated (see
   Section 2.4). the
   ``extensions document'', [2] for more details).

   If the client is updating its resources but configuration information to be returned to the
   database is temporarily unavailable, client
   includes releasable resources, the server SHOULD return a DHCP
   Reply with checks if a status of ``Unavail'' (see Section 2.4).

   While processing binding
   already exists for the Request, client.  If so, the server MUST first examines the
   data records within the binding to determine whether
   or not if the client's
   Request is a retransmission of an earlier DHCP Request
   from or a new Request.
   Releasable resource identifiers are stored within the same client.  This is done by comparing binding with
   the transaction-ID
   to all those transaction-IDs in the XID_TIMEOUT binding cache
   received from used by the same client during to request the previous XID_TIMEOUT
   seconds. resource's
   assignment.  If the transaction-ID transaction-ID's match, this is the same as one received during
   that time, a retransmission
   and the server MUST take simply return the same action (e.g., retransmit contents of the same DHCP Reply to client's binding
   which satisfy its request.  If the client) as transaction-ID's do not match,
   the server records the additional resources it did after processing is assigning in the
   previous DHCP Request
   existing binding with the same new Request's transaction-ID.

   Otherwise, if

   If the client does not have an existing binding, the server has no record of creates a message from
   binding for the client and records the resources it is assigning in
   this binding along with the same transaction-ID, transaction-ID from the client's Request.

   The server identifies then constructs a Reply message and allocates
   all sends it to the relevant information, resources, and configuration data that
   client.
11.6.2. Receipt of Release messages

   Upon the receipt of a valid Release message, the server performs a
   lookup to find the client's binding.  If the binding is associated with found, the client.  Then it sends that information
   server examines the binding to
   its client see if the resource(s) identified by constructing a DHCP Reply message and including
   the
   client's information client in the Release message's extensions field are in DHCP Extensions fact
   assigned to the Reply message.  The
   DHCP Reply message uses client.  If they are, the same transaction-ID as found in server deletes these
   resources from the
   received DHCP Request client's binding, making them available to other
   clients.

   The server then generates a Reply message.  Note that the reply message MAY
   contain information not specifically requested by the client.  If a binding was
   found and the DHCP Request message has resources presented to the `S' bit set in server were deleted from
   the message
   header, client's binding, the server MUST send sets the corresponding DHCP Reply message ``status'' field to
   ``Success''.  If no binding is found, the agent-address found in server sets the Request (see section 7.2).  Otherwise, ``status''
   field to ``NoBinding''(section 3.4).
11.6.3. Creation and sending of Reply messages

   When creating a Reply message, the server SHOULD send start out with
   a buffer initialized with zeroed octets.  The server sets the corresponding DHCP Reply message
   ``msg-type'' field to 4 and copies the
   IP source address in values of the IP header received following fields
   from the client client's Request
   message.

6.3.1. Processing for Extensions or Release to DHCP Request and Reply Messages

   The DHCP Request may contain extensions [15], which are interpreted
   (by default) as advisory information from the client about its
   configuration preferences.  For instance, if Reply message:

     o transaction-ID

     o client's link-local address

     o If the IP Address Extension client's message is present, a Request with a non-zero
       ``relay-address'' field value, the server SHOULD attempt sets the ``R'' bit in
       the Reply and copies the ``relay-address'' field value from the
       Request to allocate or extend the
   lifetime of Reply.  If the address indicated by client's message is a Release with
       the extension.  Some extensions
   may be marked by ``R'' bit set, the client as required.

   The server may accept some extensions for successful processing and
   allocation, while still rejecting others, or it may reject various
   extensions for different reasons, sets the ``R'' bit in the Reply and set
       sets the status appropriately
   for those extensions which return status ``relay-agent'' field to the client. contents of the Release's
       X-address field.

   The server
   sends sets the ``status'' field appropriately (see the table
   in section 3.4) based upon the results of processing the client's
   request.

   If configured to do so, a single DHCP server will include ``Reconfigure Multicast
   Address'' extensions (see ``extensions document'', ``Reconfigure
   Multicast Address Extension'' [2]), in Reply message messages sent in
   response to each DHCP a Request,
   with informing the same transaction-ID as the Request.

   Whenever client of one or more multicast
   groups it should join to facilitate the receipt of Reconfigure or
   Reconfigure-init messages.

   If the DHCP domain is able to, using authentication, the server includes will generate
   an authentication extension in with the
   Reply message for every appropriate settings and add
   that extension sent by as the client last extension in the Request ``extensions'' field of
   the Reply message.

   If the client requests some extensions that cannot be
   supplied by ``relay-address'' field of the server, Reply message is zero, then the
   server can simply fail to provide them,
   not including them in the Reply.  Other extensions can be rejected
   by including them in unicasts the Reply with an appropriate status indicating
   failure.  The server can include extensions in the reply that were
   not requested by the client.

6.3.2. Client Requests directly to Deallocate Unknown Resources

   When a client DHCP Request is received that has the `C' bit set, the server should check to find out whether client using the extensions listed
   in ``client's
   link-local address'' field value as destination address.  If the Request message match those which it has associated with
   ``relay-address'' field is non-zero, then the
   client's binding.  Any resources which are not indicated by server unicasts the
   client are presumed
   Reply directly to be unknown by the client, and thus possible
   candidates for reallocation to satisfy requests from other clients.
   The server MUST deallocate all resources associated with relay using the client
   upon reception of ``relay-address'' field value
   as the destination address.

   If the server implements a DHCP Request with transaction-ID cache, the `C' bit set, except server would add
   an entry for
   those which the server is willing to reallocate in response client to this cache.
12. DHCP Server-Initiated Configuration Exchange

   A server initiates a configuration exchange on behalf of the
   client's request.  It
   administrator of the DHCP domain.  An administrator may be more efficient initiate such
   an exchange when new networks are added to avoid deallocating any
   resources until after the list of extensions domain or existing
   networks are to be renumbered.  Other examples include changes in
   the request has been
   inspected.

6.4. Receiving DHCP Release Messages

   If the server receives a DHCP Release Message, it location of directory servers, addition of new services such as
   printing, and availability of new software (system or application).
12.1. Reconfigure Message Validation

   Agents MUST verify silently discard any received Reconfigure messages.

   Clients MUST discard any Reconfigure message that meets any of the link-local address
   following criteria:

     o The ``transaction-ID'' field of value is not within
       the 0--1023 range.

     o The Reconfigure message contains an address which
   could be a valid link-local address (see Section 2.1).  If not, authentication extension, and
       the
   message MUST be silently discarded.

   In response client's attempt to a DHCP Release authenticate the message fails.

12.2. Reconfigure-reply Message with a valid client's
   link-local address Validation

   Clients and agent-address, the server formulates a DHCP
   Reply Relays MUST silently discard any received
   Reconfigure-reply messages.

   Servers MUST discard any Reconfigure-reply message that will be sent back to the releasing client.  When meets any of
   the `D' flag following criteria:

     o The ``transaction-ID'' field value is set, not that same value the
       server MUST send the DHCP Reply back to
   the client using the client-address used in its Reconfigure message.

     o The ``server-address'' field of value does not match the Release value the
       server placed in its Reconfigure message.
   Otherwise, if
12.3. Reconfigure-init Message Validation

   Agents MUST silently discard any received Reconfigure-init messages.

   Clients MUST discard any Reconfigure-init messages that meets any of
   the `D' bit following criteria:

     o The ``transaction-ID'' field value is not set, within
       the server MUST send its DHCP
   Reply 0--1023 range.

     o The Reconfigure-init message (with contains an authentication
       extension, and the `L' bit set) client's attempt to authenticate the agent-address in the
   Release message, so that the relay agent can subsequently forward message
       fails.
12.4. Server Behavior

   For this discussion, the
   Reply back server is assumed to have a
   implementation-specific interface by which an administrator
   may initiate a reconfiguration event with some set of clients.

   There are two methods of initiating a reconfiguration event.  Each
   has its advantages:

      Reconfigure with payload
                   This method uses the releasing client at the client's link-local address
   indicated in the Reply Reconfigure message.

   If the received agent-address and link-local address do not
   correspond  Items
                   to any binding known to the server, then be changed are included as extensions in the
                   ``extensions'' field.  This method MUST NOT be used
                   to reconfigure releasable resources.  Examples of
                   information which can be reconfigured using this
                   method are DNS domain and servers, NTP servers, other
                   name service parameters.  The server SHOULD
   return a DHCP Reply, indicating generates and
                   sends the error by setting Reconfigure message; clients respond with
                   Reconfigure-reply messages.

      Reconfigure Trigger
                   This method uses the status code
   to ``NoBinding'' (see Section 2.4).

   Otherwise, if Reconfigure-init message.  When
                   a client receives a Reconfigure-init message, it
                   initiates a Request/Reply exchange with the agent-address server.
                   Any kind of resource can be reconfigured using this
                   method, including releasable resources.  An example
                   of an releasable resource is an IP address.

   A server can send Reconfigure and link-local Reconfigure-init messages only to
   those clients who have an address indicate a
   binding known of sufficient scope to be reachable
   by the server, then the server continues processing the
   Release message.  If there server.  Thus, those clients who have not requested an IP
   address and are any extensions, off-link cannot be reconfigured by the server.

   Before initiating a reconfigure process, the server releases SHOULD be
   configured with a REC_THRESHOLD threshold value which represents
   the particular configuration items specified in percentage of clients successfully reconfigured before the extensions.
   If there are no extensions,
   reconfigure process is considered a success.  See section 3.5 for the
   default setting of REC_THRESHOLD. Note that the server releases all configuration
   information in MUST be able
   to determine the client's binding.

   After performing set of clients that should receive the operations indicated reconfigure,
   in order to determine when the DHCP Release message reconfigure process is complete.
12.4.1. Creation and its extensions, sending of Reconfigure messages

   When creating a Reconfigure message, the server formulates SHOULD start out
   with a DHCP Reply message,
   copying buffer initialized with zeroed octets.  The server sets the
   ``msg-type'' field to 6.  The server generates a transaction-ID
   from the DHCP Release message.  For
   each Extension 0--1023 range and inserts it in the DHCP Release message successfully processed
   by the server, a matching Extension is appended to the DHCP Reply
   message.  For extensions ``transaction-ID''
   field.  The server places its address (of appropriate scope) in the DHCP Release message which cannot be
   successfully processed by the server, a DHCP Reply message containing
   ``server-address'' field.

   The server then generates extensions with for the appropriate status MUST non-releasable resources
   to be returned by changed and places them in the
   server. ``extensions'' field.

   If the Release message contains no extensions, DHCP domain is using authentication, the server
   does not include any extensions will generate
   an authentication extension with the appropriate settings and add
   that extension as the last extension in the corresponding DHCP Reply
   message to ``extensions'' field of
   the client.

6.5. Sending DHCP Reconfigure Messages

   If a message.

   The server needs to change multicasts the configuration associated with any
   of its clients, it constructs a DHCP Reconfigure message (possibly
   including relevant extensions) and sends it to each such client.  The one or more
   Reconfigure MAY be sent to a multicast address chosen by the server,
   which was Multicast Addresses previously sent as extensions to each such client in an extension to a
   previous DHCP Reply message.

   It may happen that a client does not send a DHCP Request message
   after the DHCP
   clients.  Note that a server MAY unicast Reconfigure message has been issued and retransmitted
   RECONF_MSG_MIN_RETRANS times, according message(s) to
   specific clients by walking its list of bindings to determine the algorithm specified
   in Section 8.  This can happen when
   unicast address(es) of the client is clients.  Whether or not listening for the Reconfigure message, possibly because the client
   is a mobile
   node disconnected multicast or unicast is an implementation detail.

   A server waits for Reconfigure-reply messages from clients confirming
   that they have received the network, or because Reconfigure.

12.4.2. Time out and retransmission of Reconfigure messages

   The server waits RECREP_MSG_TIMEOUT milliseconds, collecting
   Reconfigure-reply messages.  If all the client node
   has sustained a power outage expected Reconfigure-reply
   messages are received, then the reconfigure process is successful.
   If some or operating system crash.  In such
   cases, all of the expected Reconfigure-reply messages are not
   received, then the server SHOULD reserve any resources issued to retransmits the client
   until Reconfigure, and doubles
   the client responds at some future time, RECREP_MSG_TIMEOUT value, and waits again.  The server continues
   this process until the resource
   allocation times out (see section 6.6), all Reconfigure-reply messages are received or until administrative
   intervention causes
   REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which time
   the resources to be manually returned to use. server SHOULD abort the reconfigure process.  The server SHOULD also
   log the result of the reconfigure process.

   Default and initial values for RECREP_MSG_TIMEOUT and
   REC_MSG_ATTEMPTS are documented in section 3.5.
12.4.3. Receipt of Reconfigure-reply messages

   Upon receipt of a DHCP System Error.

   If valid Reconfigure-reply message, the server gets another DHCP Request
   removes that client from the list of clients it is expecting a client,
   Reconfigure-reply message from.
12.4.4. Creation and sending of Reconfigure-init messages

   When creating a Reconfigure-init message, the server SHOULD start
   out with a buffer initialized with zeroed octets.  The server sets
   the ``msg-type'' field to 8.  The server generates a transaction-ID which does not match
   from the 0--1023 range and inserts it in the ``transaction-ID''
   field.  The server places its address (of appropriate scope) in the
   ``server-address'' field.

   The server MAY generate an ERE extension to inform the client of what
   information has been changed or new information that of has been added.

   If the recently transmitted
   reconfigure message, DHCP domain is using authentication, the server SHOULD send a DHCP Reply to will generate
   an authentication extension with the client, appropriate settings and wait for RECONF_MSG_RETRANS_INTERVAL, before
   retransmitting add
   that extension as the DHCP Reconfigure again.

6.6. Client-Resource timeouts

   Some resources (for instance, a client's IP address) may only be
   allocated to a client for a particular length of time (for instance, last extension in the valid lifetime ``extensions'' field of an IP address).  If
   the client does Reconfigure-init message.

   Typically, the server will not renew provide more than an ERE and / or
   Authentication extension, since it will provide the resource allocation for such a resource, new configuration
   information as part of the Request/Reply transaction triggered by the
   Reconfigure-init message.

   The server MAY make multicasts the
   resource available for allocation Reconfigure-init message to another client.  However, under
   administrative control, the server MAY reserve any resources issued one or more
   Reconfigure Multicast Addresses previously sent as extensions
   to the client until the client responds at some future time.

7. DHCP Relay Considerations

   The DHCP protocol is constructed so clients.  Note that a relay does not have
   to maintain any state in order server MAY unicast Reconfigure-init
   message(s) to mediate DHCP client/server
   interactions.

   The DHCP relay enables specific clients and servers to carry out DHCP protocol
   transactions.  DHCP Solicit messages are issued by the relay when
   initiated by prospective clients.  By default, the relay locates
   servers by use walking its list of multicasting solicitations to the All-DHCP-Servers
   multicast group, but relays SHOULD allow this behavior to be
   configurable.  The relay MUST be able bindings to
   determine which the unicast address(es) of its
   interfaces received the client's solicitation message.

7.1. DHCP Solicit and DHCP Advertise Message Processing

   Upon receiving clients.  Whether or not the
   Reconfigure-init is multicast or unicast is an implementation detail.

   A server waits for a DHCP Solicit Request message from each client confirming that
   they have received the Reconfigure-init and are thus initiating a prospective client,
   a relay, by default, forwards
   Request/Reply transaction with the server.  The server can determine
   that a Request message is in response to servers at a site
   according to Reconfigure-init because
   the following procedure:

    -  copying transaction-ID in the prospective client's solicitation message fields into Request will be the appropriate fields same value as was used
   in the Reconfigure-init message.
12.4.5. Time out and retransmission of Reconfigure-init messages

   The server uses the outgoing solicitation,

    -  copying a non-link-local address same algorithm and configuration values for
   sending Reconfigure-init messages as it does with Reconfigure
   messages.  See Section 12.4.2 for this algorithm.
12.4.6. Receipt of its interface from which Request messages

   Upon receipt of a valid Request message with the
       solicitation was received from same transaction-ID
   as the Reconfigure-init messages it sent, the server removes that
   client into from the relay-address
       field, list of clients it is expecting to initiate a
   Request/Reply transaction.

   The server generates and

    -  setting sends Reply message(s) to the prefix-size field appropriately,

    -  by default, setting client as
   described in section 11.6.3, including in the hop-count ``extension'' field in
   new values for configuration parameters.  If the IP header of extensions include
   releasable resources, the solicitation server will include two extensions for each
   resource - one with the original values with the lease times set to
   zero, and another with new values and lease times.  Note that the value DEFAULT_SOLICIT_HOPCOUNT (see
       section 8).

    -  setting
   server can terminate the IP source address client's ability to be use a site-local or global-scope
       address belonging to resource simply by
   including only the relay's interface first extension value.
12.5. Client Behavior

   A client MUST always monitor UDP port 546 for Reconfigure and
   Reconfigure-init messages on interfaces upon which it has acquired
   DHCP parameters.  Since the client's
       original solicitation was received,

    -  finally, sending results of a reconfiguration event may
   affect application layer programs, the resulting message to one or more servers.

   By default, client SHOULD log these
   events, and MAY notify these programs of the change through an
   implementation-specific interface.

12.5.1. Receipt of Reconfigure messages

   Upon receipt of a valid Reconfigure message, the relay sends solicitations to client extracts
   the All-DHCP-Servers
   multicast address, FF05:0:0:0:0:0:1:3.  However, configuration parameters contained in the relay MAY be
   configured with an alternate server address, or ``extensions''
   field, and notifies the FQDN of a server.
   Methods application layer that new values for automatically updating such alternately configured server
   addresses these
   parameters are not specified in this document.

   When the relay receives available.  The client then generates and sends a DHCP advertisement, it relays the
   advertisement
   Reconfigure-reply message to the client at the client's link-local address by way server.
12.5.2. Creation and sending of the interface indicated in the agent's address field.

7.2. DHCP Request Message Processing Reconfigure-reply messages

   When creating a relay receives a DHCP Request Reconfigure-reply message, it SHOULD check that
   the IP source address in the IP header is client SHOULD start
   out with a link-local address,
   that the link-local address matches buffer initialized with zeroed octets.  The client sets
   the link-local address ``msg-type'' field in
   the Request message header, to 7, and that places the agent-address field of the
   message matches an IP link-local address associated with of
   the interface from upon which it received the DHCP Request Reconfigure message was received.  If any of these checks
   fail, the relay MUST silently discard in
   the Request message. ``client's link-local address'' field.  The relay MUST check whether the `S' bit is set in client copies the message
   header.  If not,
   values of the packet is discarded, and following fields from the relay SHOULD
   return a DHCP Reply Reconfigure message to the address contained
   Reconfigure-reply message:

     o transaction-ID

     o server-address

   The client sets the ``status'' field appropriately (see the table
   in section 3.4) based upon the results of processing the server's
   reconfigure-reply.

   The client places the client's
   link-local address field of the Request message, with status
   ``PoorlyFormed'' (see Section 2.4). destination server in the
   ``server-address'' field.

   If the received request message client is acceptable, configured to use authentication, the relay then
   transmits client
   generates the DHCP Request message appropriate authentication extension, and adds this
   extension to the address of ``extensions'' field.  Note that the authentication
   extension MUST be the server found last extension in the server-address field of ``extensions'' field.

   The client delays the received DHCP Request message.
   All sending of the fields of DHCP Request message transmitted Reconfigure-reply by some
   random value selected in the relay
   are copied over unchanged from the DHCP Request received from range of REC_REP_MIN and REC_REP_MAX
   seconds.  This delay helps reduce the
   client.  Only load on the fields server generated by
   processing large numbers of Reconfigure-reply messages.

   Default and initial values for REC_REP_MIN and REC_REP_MAX are
   documented in section 3.5.

   The client unicasts the IP header will differ from the
   packet received from the client.  All relays MUST send DHCP Request
   messages using Reconfigure-reply to the source IP address from identified
   in the interface where ``server-address'' field.  Sending the
   DHCP request was received.  If Reconfigure-reply
   completes the Relay receives an ICMP error, reconfiguration process for the
   Relay SHOULD return client.

12.5.3. Receipt of Reconfigure-init messages

   Upon receipt of a DHCP Reply message to valid Reconfigure-init message, the client address (which
   can be found in the payload of the ICMP message [5]), with status
   ``ICMPError'' (see Section 2.4), along
   initiates a Request/Reply transaction with the DHCP Relay ICMP Error
   extension [15].

7.3. DHCP Reply Message Processing server.
12.5.4. Creation and sending of Request messages

   When the relay receives a DHCP Reply, it MUST check that the message
   has the `L' bit set.  It MUST check that the client's link-local
   address field contains responding to a link-local address.  If either check fails, Reconfigure-init, the packet MUST be silently discarded.  If both checks are satisfied, client creates and
   sends the relay MUST send a DHCP Reply Request message to the link-local address
   listed in exactly the received Reply message.  Only the fields same manner as outlined in
   section 11.4.1 with the IP
   header will differ from following differences:

      transaction-ID
                   The client copies the packet received transaction-ID from the server, not
                   Reconfigure-init message into the
   payload.

8. Retransmission Request message.

      Pause before sending Request
                   The client pauses before sending the Request for
                   a random value within the range REC_REP_MIN and
                   REC_REP_MAX seconds, as outlined in section 12.5.2.
12.5.5. Time out and Configuration Variables

   When a retransmission of Request messages

   The client uses the same variables and retransmission algorithm as it
   does not receive with Request messages generated as part of a DHCP client-initiated
   configuration exchange.  See section 11.4.2 for details.
12.5.6. Receipt of Reply in response to messages

   Upon the receipt of a pending
   DHCP Request, valid Reply message, the client MUST retransmit extracts
   the identical DHCP Request,
   with contents of the same transaction-ID, to ``extension'' field, and sets (or resets)
   configuration parameters appropriately.  If the same server again until it can
   be reasonably sure that configuration
   parameters changed were requested by the server is unavailable and an alternative
   can be chosen.  The DHCP server assumes that application layer, the
   client has received notifies the configuration information included with application layer of the extensions changes using an
   implementation-specific interface.  If the resources changed are
   releasable, the client makes the appropriate adjustments to its
   management of the leases of these resources.
13. Using DHCP Reply message, for network renumbering

   An administrator can use DHCP to renumber links within her DHCP
   domain through two techniques, passive renumbering and it is up active
   renumbering.

13.1. Passive Renumbering

   The administrator can configure her servers to return relatively
   short preferred and valid lifetimes for the client IP addresses she
   makes available to continue clients.  When she determines that she'd like
   to try for renumber a reasonable amount of time network, she configures her servers through an
   implementation-specific manner to complete disallow the transaction.  All extension of the
   actions specified for DHCP Request in this section hold also for DHCP
   Release messages sent by IP
   address lifetimes on the client.

   Similarly, when a client sends a DHCP Request message in response original network, and adds the new network
   configuration data to
   a Reconfigure message the server's database.

   The clients on the original network will fail to acquire lifetime
   extensions on their IP addresses, and will request and acquire
   IP addresses from the server, new network when the client assumes that valid lifetime of the
   original IP addresses approaches expiration.

   When the lifetimes for all of the IP addresses on the
   DHCP server has received original
   network expire, the Request. network can be considered renumbered.
13.2. Active Renumbering

   The server MUST retransmit
   the identical DHCP Reconfigure to administrator can force the client a reasonable number renumbering of times to try to elicit the Request message from the client.
   If no corresponding networks in her DHCP Request is received
   domain by using the server after
   REQUEST_MSG_MIN_RETRANS retransmissions, reconfigure feature of DHCP. She instructs her
   servers of the server MAY erase or
   deallocate information as needed from network renumbering through an implementation-specific
   interface.  The servers in the client's binding, but see
   section 6.5.

   Retransmissions occur using domain will generate Reconfigure-init
   messages, which will cause the following configuration variables
   for a DHCP implementation.  These configuration variables MUST be
   configurable by a client or server:

      CLIENT_ADV_WAIT

         The minimum amount of time a client waits clients to receive DHCP
         Advertisements after transmitting initiate a DHCP Solicit to Request/Reply
   transaction with the
         All-DHCP Agents multicast server.  The servers will include two IP address (see section 5.3).

         Default:  2 seconds
      DEFAULT_SOLICIT_HOPCOUNT
   extensions for each IP address being changed.  The default hop-count used in first will contain
   the original IP header by DHCP relays when
         sending DHCP Solicit messages on behalf of a client.

         Default:  4

      SERVER_MIN_ADV_DELAY address, with the preferred and valid lifetimes set
   to zero.  The minimum amount of time a second will contain the new IP address, with non-zero
   preferred and valid lifetimes.

   A server waits implementation MAY permit the administrator to transmit a
         DHCP Advertisement after receiving a set the
   original IP address lifetimes to some small value greater than zero,
   to allow applications running on the client to orderly transfer to
   the new network over time.
14. DHCP Solicit at Client Implementator Notes

   This section provides helpful information for the
         All-DHCP-Servers or All-DHCP-Agents multicast address.

         Default:  100 milliseconds

      SERVER_MAX_ADV_DELAY client implementor
   regarding their implementations.  The maximum amount text described here is not part
   of time a server waits to transmit a DHCP
         Advertisement after receiving the protocol, but rather a discussion of implementation features
   we feel the implementor should consider during implementation.

14.1. Primary Interface

   Since configuration parameters acquired through DHCP Solicit at can be
   interface-specific or more general, the All-DHCP
         Agents multicast address.

         Default:  1 second

      REPLY_MSG_TIMEOUT

         The time in seconds that a client waits to receive a server's
         DHCP Reply before retransmitting implementor SHOULD
   provide a DHCP Request.  The
         client MUST multiply REPLY_MSG_TIMEOUT mechanism by a factor of 2 in
         an exponential manner for each time it retransmits until
         REQUEST_MSG_MIN_RETRANS (below) is attained.  A which the client MAY implementation can be
   configured to attempt 2 retransmissions before beginning the
         exponential backoff retransmission in specify which interface is the previous sentence.

         Default:  2 seconds.

      REQUEST_MSG_MIN_RETRANS primary interface.  The minimum number of DHCP Request transmissions that a
   client
         should retransmit, before aborting SHOULD always query the request.

         Default:  10 retransmissions.

      RECONF_MSG_MIN_RETRANS

         The minimum number of DHCP Reconfigure messages that a
         server should retransmit, before assuming the data associated with the client is
         unavailable.

         Default:  10 retransmissions.

      RECONF_MSG_RETRANS_INTERVAL

         The least time in seconds that a server waits primary
   interface for non-interface specific configuration parameters.  An
   implementation MAY implement a
         client's DHCP Request before each retransmission list of interfaces which would be
   scanned in order to satisfy the DHCP
         Reconfigure.

         Default:  12 seconds.

      RECONF_MMSG_MIN_RESP

         The minimum amount general request.  In either case, the
   first interface scanned is considered the primary interface.

   By allowing the specification of time before a primary interface, the client can respond to a
         DHCP Reconfigure message sent to a multicast address.

         Default:  2 seconds.

      RECONF_MMSG_MAX_RESP

         The maximum amount of time before a
   implementor identifies which interface is authoritative for
   non-interface specific parameters, which prevents configuration
   information ambiguity within the client MUST respond to a
         DHCP Reconfigure message sent to a multicast address.

         Default:  10 seconds.

      RECONF_MULTICAST_REQUEST_WAIT

         The time a implementation.
14.2. Advertise Message and Configuration Parameter Caching

   If the hardware the client should wait before retransmitting is running on permits it, the implementor
   SHOULD provide a Request
         message in reponse to cache for Advertise messages and a retransmitted multicast Reconfigure
         message.

         Default:  120 seconds

      MIN_SOLICIT_DELAY cache of
   configuration parameters received through DHCP. Providing these
   caches prevents unnecessary DHCP traffic and the subsequent load
   this generates on the servers.  The minimum implementor SHOULD provide a
   configuration knob for setting the amount of time a prospective client is required to
         wait, after determining from a Router Advertisement message the cache(s) are
   valid.
14.3. Time out and retransmission variables

   Note that the client should perform stateful address configuration,
         before sending a DHCP Solicit to a server.

         Default:  1 second

      MAX_SOLICIT_DELAY

         The maximum amount of time a prospective out and retransmission variables outlined
   in section 3.5 can be configured on the server and sent to the client
   through the use of the ``DHCP Retransmission Parameter Extension'',
   which is required documented in the ``extensions document'' [2].  A client
   implementation SHOULD be able to
         wait, after determining from a Router Advertisement message
         that reset these variables using the
   values from this extension.
14.4. Server Preference

   A client should perform stateful address configuration,
         before MUST wait for SRVR_PREF_WAIT seconds after sending a DHCP
   Solicit message to collect Advertise messages and compare their
   preferences (see section 15.3), unless it receives an Advertise
   message with a server.

         Default:  5 seconds
      XID_TIMEOUT

         The amount preference of time 255.  If the client receives an
   Advertise message with a DHCP server has to keep track preference of 255, then the client transaction-IDs in order to make sure MAY act
   immediately on that client
         retransmissions using Advertise without waiting for any more additional
   Advertise messages.

15. DHCP Server Implementator Notes

   This section provides helpful information for the same transaction-ID are idempotent.

         Default:  600 seconds

9. Security Considerations

   Clients server implementor.
15.1. Client Bindings

   A server implementation can use the client's link-local address
   and servers often have to authenticate the messages they
   exchange.  For instance, a server may wish to be certain that a DHCP
   Request originated subnet prefix specification from which the client identified by the <link-local
   address, agent-address> fields included within the sent its
   Request message
   header.  Conversely, it is quite often essential message(s) as an index for a client to
   be certain that the finding configuration parameters and addresses
   assigned to the client.  While it has
   received were sent isn't critical to keep track
   of which clients were given information (resources) that isn't
   releasable, it by an authoritative server.  Similarly, a IS critical for the server should only accept a DHCP Release message which seems to be
   from one keep track of its clients, if which
   client it has some assurance that assigned releasable resources.  The server MUST
   include the client
   actually did transmit transaction-ID from the Release message.  Again, client's Request along with
   the releasable resource identifier(s) within the binding.  This is
   done so that the server can detect whether a client might
   wish to only accept DHCP Reconfigure messages that are certain to
   have originated from Request is a server with authority to issue them.
   retransmission of an earlier Request or an entirely new Request.

   The IPv6 Authentication Header can provide security server should periodically scan its bindings for DHCPv6
   messages when both endpoints releasable
   resources whose leases have a suitable IP address.  However,
   a expired.  When the server finds expired
   resource assignments, it MUST delete these assignments, thereby
   making these resources available to other clients.

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

   The server implementation should provide policy knobs to control
   whether or not the lease on a link-local address, releasable resource is renewable, and such
   by how long.
15.2. Reconfigure Considerations

   A server implementation MUST provide an address
   is not sufficient interface to the
   administrator for a initiating reconfigure events.

   A server which is off-link.  In those
   circumstances implementation may provide a mechanism for allowing the DHCP relay is involved, so that
   specification of how many clients comprise a reconfigure multicast
   group.  This enables the DHCP message
   MUST have administrator to control the hit a server
   takes when a reconfigure event occurs.
15.3. Server Preference

   The server implementation SHOULD allow the setting of a server
   preference value by the relay's address in administrator.  The server preference
   variable is an unsigned single octet value (0--255), with the IP destination address field,
   even though lowest
   preference being 0 and the client aims highest 255.  Clients will choose higher
   preference servers over those with lower preference values.  If you
   don't choose to deliver implement this feature in your server, you MUST set
   the message server preference field to 0 in the Advertise messages generated
   by your server.
   The DHCP Client-Server Authentication Extension [15] is intended
15.4. Request Message Transaction-ID Cache

   In order to
   be used in these circumstances.

   Note that, if improve performance, a server implementation MAY include
   an in memory transaction-ID cache.  This cache is indexed by client receives a DHCP message which fails
   authentication, it should continue
   binding and transaction-ID, and enables the server to wait for another message which
   might be correctly authenticated just as if quickly
   determine whether a Request is a retransmission or a new Request
   without the failed message had
   never arrived; however, receiving such failed messages cost of a database lookup.  If an implementor chooses to
   implement this cache, then they SHOULD be
   logged.

10. Year 2000 considerations

   Since all times are relative provide a configuration knob
   to tune the current time lifetime of the transaction,
   there is no problem within cache entries.
16. DHCP Relay Implementator Notes

   A relay implementation SHOULD allow the DHCPv6 protocol related to any
   hardcoded dates or two-digit representation specification of the current year.

11. IANA Considerations a list of
   destination addresses for Solicit messages.  This document defines message types 1-7 to be received by UDP at port
   numbers 546 and 547.  Additional message types may be defined in the
   future.

   Section 3.3 specifies the use list MAY contain
   any mixture of several multicast groups, with
   multicast unicast addresses FF02:0:0:0:0:0:1:2, FF05:0:0:0:0:0:1:3, and
   FF05:0:0:0:0:0:1:4.

   This document also defines several status codes that are multicast addresses.

   If a relay receives an ICMP message in response to be
   returned with the a DHCP Reply message (see section 4.4).  The nonzero
   values it
   has forwarded, it SHOULD log this event.
17. Open Issues for these status codes which are currently specified are shown
   in Working Group Discussion

   This section 2.4.

   There is a DHCPv6 extension [15] which allows clients and servers to
   exchange values for contains some of items for discussion by the timing and retransmission parameters
   defines in section 8.  Adding new parameters working group.
17.1. Trade-offs:  Optional fields in DHCP messages

   You'll notice that the future would
   require extending the values by which message formats have changed.  In particular,
   some of the parameters optional fields are indicated in now required.  This will increase the
   size of DHCP extension.  Since there needs to be a list kept, messages in some cases, consuming network bandwidth and
   memory on the default
   values DHCP client (an issue for each parameter should also be stored small devices such as part of PDAs).

   The changes were made for the list.

   All following reasons:

     o Fields that were used most of these protocol elements may be specified to assume new values
   at some point in the future.  New values should be approved by the
   process of IETF Consensus [12].

12. Acknowledgements

   Thanks time were made required.

     o Some fields that were optional were either made required or added
       to messages which previously didn't have them.  This was done for
       robustness reasons (receivers can validate that the DHC Working Group message is
       for their time them, and input into in the
   specification.  Ralph Droms case of clients, know which interface the
       message is intended for).

     o Simplicity.

   Please look at the messages as they are now defined, and Thomas Narten have had a major
   role let us know
   your opinion.
17.2. Use DHCPv4 authentication or the current DHCPv6 method?

   Now that the DHCPv4 authentication draft is in last call, should
   we use the technique described in shaping that document to provide
   authentication for DHCPv6, or should we continue with the continued improvement of
   authentication technique currently documented in the protocol by their
   careful reviews.  Many thanks to Matt Crawford, Erik Nordmark, Gerald
   Maguire, extensions
   draft?
17.3. The Reconfigure Message and Mike Carney for their studied review Subnet Prefix Extensions

   The drafts currently specify that Releasable resources (such as part of an IP
   address) can only be reconfigured using the
   Last Call process.  Thanks also Reconfigure-init trigger
   message.  This was done for the consistent input, ideas, and
   review by (in alphabetical order) Brian Carpenter, Jack McCann, Yakov
   Rekhter, Matt Thomas, Sue Thomson, and Phil Wells.

   Thanks simplicity (enables clients to Steve Deering perform
   DAD on the new address and Bob Hinden, who have consistently
   taken return the time appropriate result to discuss the more complex parts
   server) using the same mechanism as a standard Request/Reply/Release
   exchange.  This method also makes no assumptions about the
   charactistics of the IPv6
   specifications.

A. Changes releasable resource.

   However, for IP addresses with interface IDs, one could send out
   two IP address extensions, one for this revision

    -  Fixed grammatical and clarity problems.

    -  Added saved agent-address field to the solicit message old prefix and
       altered one for the
   new, and enhanced references cause clients to change the C bit use.

    -  Removed all references of agent-address prefix as it is implied
       by the agent-address and can be used as such by implementors.

    -  Verified all binding dependencies use thus renumber over
   time.  This scheme avoids the link-local address and
       agent-address. added DHCP Request traffic -  Added clients
   acknowledge with a Reconfigure-reply message.
17.4. ``R'' bit in what cases SHOULD retain specific addresses when Request message not needed?

   Now that the client transaction-ID is not stationary.

    -  Updated DHCP terminology section and re-ordered.

    -  Put RFC 2119 terms in lower case, stored along with the releasable
   resource identifier in section 3.1.

    -  Changed definition of a client's binding, the transaction-ID and specified ranges for
       client and cache
   becomes an optional feature of the DHCP server use.

    -  Added implementation, not a
   requirement of the protocol.  Should we do away with the ``R'' bit?
18. Security Considerations

   Clients and fixed text servers often have to clarify use of Reconfigure message for
       clients in all relevant sections.

    -  Added words in spec authenticate the messages they
   exchange.  For instance, a server may wish to differentiate format section be certain that a
   Request originated from
       processing section.

    -  Added retransmission algorithm for Reconfigure multicast messages
       and new configuration parameter.

    -  Differentiated processing for requests the client identified by clients when received
       from Reconfigure message.

    -  Added more words when binding cache the <link-local
   address, subnet-prefix> fields included within the Request message
   header.  Conversely, it is used quite often essential for XID timeout.

    -  Added exponential backoff to a client retransmissions.

    -  Updated the references section.

B. Related Protocol Specifications

   Related work in IPv6 to
   be certain that would best serve the configuration parameters and addresses it has
   received were sent to it by an implementor authoritative server.  Similarly, a
   server should only accept a Release message which seems to study
   is be from
   one of its clients, if it has some assurance that the IPv6 Specification [7], client actually
   did transmit the IPv6 Addressing Architecture [9],
   IPv6 Stateless Address Autoconfiguration [20], IPv6 Neighbor
   Discovery Processing [14], and Dynamic Updates Release message.  Again, a client might wish to DNS [22].  These
   specifications enable DHCP only
   accept Reconfigure or Reconfigure-init messages that are certain to build upon the IPv6 work
   have originated from a server with authority to provide
   both robust stateful autoconfiguration and autoregistration of DNS
   Host Names. issue them.

   The IPv6 Specification provides the base architecture Authentication Header can provide security for DHCPv6
   messages when both endpoints have a suitable IP address.  However,
   a client often has only a link-local address, and design of
   IPv6.  A key point such an address
   is not sufficient for DHCP implementors to understand a server which is off-link.  In those
   circumstances the relay is involved, so that IPv6
   requires that every link in the internet DHCP message MUST
   have an MTU of 1500 octets
   or greater (in IPv4 the requirement is 68 octets).  This means that
   a UDP packet of 536 octets will always pass through an internet
   (less 40 octets for relay's address in the IPv6 header), as long as there are no IP
   options prior destination address field, even
   though the client aims to deliver the UDP header in message to the packet.  But, IPv6 does not
   support fragmentation at routers, so that fragmentation takes place
   end-to-end between hosts.  If a server.  The
   DHCP implementation needs Client-Server Authentication Extension [2] is intended to send be
   used in these circumstances.

   Note that, if a
   packet greater than 1500 octets client receives a DHCP message which fails
   authentication, it can either fragment should continue to wait for another message which
   might be correctly authenticated just as if the UDP packet
   into fragments of 1500 octets or less, or use Path MTU Discovery [11] failed message had
   never arrived; however, receiving such failed messages SHOULD be
   logged.
19. Year 2000 considerations

   Since all times are relative to determine the size current time of the packet that will traverse a network
   path.  It is implementation dependent how this is accomplished in
   DHCP. Path MTU Discovery for IPv6 transaction,
   there is supported for both UDP and TCP
   and can cause end-to-end fragmentation when no problem within the PMTU changes for a
   destination.

   The IPv6 Addressing Architecture specification [9] DHCPv6 protocol related to any
   hardcoded dates or two-digit representation of the current year.
20. IANA Considerations

   This document defines the
   address scope that can message types 1--8 to be used in an IPv6 implementation, received by UDP at
   port numbers 546 and 547.  Additional message types may be defined in
   the
   various configuration architecture guidelines for network designers
   of the IPv6 address space.  Two advantages of IPv6 are that support
   for future.

   Section 3.1 lists several multicast is required, and nodes can create link-local addresses
   during initialization. used by DHCP.

   This means document also defines several status codes that a client can immediately use
   its link-local address and a well-known multicast address to begin
   communications are to discover neighbors on
   be returned with the link.  For instance, a
   client can send a DHCP Solicit Reply 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 [14], Reconfigure-reply messages (see
   sections 9.4 and 9.7).  The non-zero values for these status codes
   which are currently specified are shown in the use of table in section 3.4.

   There is a valid lifetime DHCPv6 extension [2] which allows clients and servers to
   support renumbering
   exchange values for some of addresses on the Internet.  In addition timing and retransmission parameters
   defined in section 3.5.  Adding new parameters in the
   protocol interaction future would
   require extending the values by which a node begins stateless or stateful
   autoconfiguration is specified. the parameters are indicated in
   the DHCP is one vehicle extension.  Since there needs to perform
   stateful autoconfiguration.  Compatibility with Addrconf is be a design
   requirement list kept, the default
   values for each parameter should also be stored as part of the list.

   All of these protocol elements may be specified to assume new values
   at some point in the future.  New values should be approved by the
   process of DHCP (see Section 3.1).

   IPv6 Neighbor Discovery [14] is IETF Consensus [11].
21. Acknowledgements

   Thanks to the node discovery protocol in IPv6
   which replaces DHC Working Group for their time and enhances functions of ARP [16].  To understand
   IPv6 input into the
   specification.  Ralph Droms and Addrconf it is strongly recommended that implementors
   understand IPv6 Neighbor Discovery.

   Dynamic Updates to DNS [22] is Thomas Narten have had a specification that supports major
   role in shaping the
   dynamic update continued improvement of DNS records for both IPv4 and IPv6.  DHCP can use the dynamic updates to DNS protocol by their
   careful reviews.  Many thanks to integrate addresses Matt Crawford, Erik Nordmark, Gerald
   Maguire, and name space to
   not only support autoconfiguration, but Mike Carney for their studied review as part of the
   Last Call process.  Thanks also autoregistration in
   IPv6.  The security model for the consistent input, ideas, and
   review by (in alphabetical order) Brian Carpenter, Jack McCann, Yakov
   Rekhter, Matt Thomas, Sue Thomson, and Phil Wells.

   Thanks to be used with DHCPv6 should conform as
   closely as possible Steve Deering and Bob Hinden, who have consistently
   taken the time to discuss the authentication model outlined in [10].

C. more complex parts of the IPv6
   specifications.
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 [8, [7, 1] 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 a an on-link server or relay agent
       on the local link.
       relay.

     o The need for BOOTP compatibility and the broadcast flags is 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 Many Some DHCPv4 options are unnecessary now because the configuration
       parameters are either obtained through IPv6 Neighbor Discovery or
       the Service Location protocol [21]. [16].

   DHCPv6 Architecture/Model Changes:

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

     o IPv6 Address allocations are now handled in a message extension
       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 remote off-link server
       through an on-link relay-agent. relay.

     o Servers are discovered by a client solicit, Solicit, followed by a server
       or relay-agent advertisement.
       Advertise message

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

     o The on-link relay-agent locates remote relay may locate off-link server addresses from
       system configuration or by the use of a site wide 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 DHCP 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 extension headers.

     o Clients MUST listen to their UDP port for the new Reconfigure
       message from servers.

     o New extensions 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 allocated with too-long lifetimes can be reclaimed using the Reconfigure Reconfigure-init message.

     o Integration between stateless and stateful address
       autoconfiguration.

     o Enabling relay-agents relays to locate remote servers for a link.

D. off-link servers.
B. Full Copyright Statement

   Copyright (C) The Internet Society (1998). (2000).  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.
References

    [1] S. Alexander and R. Droms.  DHCP Options and BOOTP Vendor
        Extensions.  RFC  Request for Comments (Draft Standard) 2132,
        Internet Engineering Task Force, March 1997.

    [2] J. Bound, M. Carney, and C. Perkins.  Extensions for the Dynamic
        Host Configuration Protocol for IPv6.
        draft-ietf-dhc-dhcpv6ext-12.txt, May 2000.  (work in progress).

    [3] S. Bradner.  Key Words words for Use use in RFCs to Indicate Requirement
        Levels.  RFC  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.  RFC 1752, January 1995.

    [4] A. Conta and S. Deering.  Internet Control Message Protocol
        (ICMPv6)  Request for the Comments (Proposed Standard)
        1752, Internet Protocol Version 6 (IPv6).  RFC 1885,
        December Engineering Task Force, January 1995.

    [5] A. Conta W. J. Croft and S. Deering.  RFC 2463:  Internet Control Message
        Protocol (ICMPv6) J. Gilmore.  Bootstrap Protocol.  Request for the
        Comments 951, Internet Protocol Version 6 (IPv6)
        Specification, December 1998.  Obsoletes RFC1885 [4]. Status:
        DRAFT STANDARD. Engineering Task Force, September 1985.

    [6] S. Deering and R. Hinden.  Internet Protocol, Version 6 (IPv6)
        Specification.  RFC 1883, December 1995.

    [7] S. Deering and R. Hinden.  RFC 2460:  Request for Comments (Draft Standard) 2460,
        Internet Protocol, Version
        6 (IPv6) specification, Engineering Task Force, December 1998.  Obsoletes RFC1883 [6].
        Status:  DRAFT STANDARD.

    [8]

    [7] R. Droms.  Dynamic Host Configuration Protocol.  RFC  Request for
        Comments (Draft Standard) 2131, Internet Engineering Task Force,
        March 1997.

    [9]

    [8] R. Hinden and S. Deering.  IP Version 6 Addressing Architecture.
        RFC
        Request for Comments (Proposed Standard) 2373, Internet
        Engineering Task Force, July 1998.

   [10]

    [9] S. Kent and R. Atkinson.  RFC 2402:  IP authentication header, Authentication Header.  Request for
        Comments (Proposed Standard) 2402, Internet Engineering Task
        Force, November 1998.  Status:  PROPOSED STANDARD.

   [11]

   [10] J. McCann, S. Deering, and J. Mogul.  Path MTU Discovery for
        IP version 6.  RFC  Request for Comments (Proposed Standard) 1981,
        Internet Engineering Task Force, August 1996.

   [12]

   [11] T. Narten and H. Alvestrand.  RFC 2434:  Guidelines for writing Writing an IANA considerations section
        Considerations Section in RFCs, RFCs.  Request for Comments (Best
        Current Practice) 2434, Internet Engineering Task Force, October
        1998.  Status:
        BEST CURRENT PRACTICE.

   [13]

   [12] T. Narten, E. Nordmark, and W. Simpson.  Neighbor Discovery for
        IP version Version 6 (IPv6).  RFC 1970, August 1996.

   [14] T. Narten, E. Nordmark, and W. Simpson.  RFC 2461:  Neighbor
        discovery  Request for IP Version 6 (IPv6), Comments (Draft Standard)
        2461, Internet Engineering Task Force, December 1998.  Obsoletes
        RFC1970 [13]. Status:  DRAFT STANDARD.

   [15] C. Perkins.  Extensions for the Dynamic Host Configuration
        Protocol for IPv6.  draft-ietf-dhc-dhcpv6ext-11.txt, February
        1999.  (work in progress).

   [16] David

   [13] D. C. Plummer.  An  Ethernet Address Resolution Protocol:  Or Converting Network Protocol Addresses
        converting network protocol addresses to 48.bit Ethernet
        Addresses address
        for Transmission transmission on Ethernet Hardware.  RFC hardware.  Request for Comments
        (Standard) 826, Internet Engineering Task Force, November 1982.

   [17]

   [14] J. B. Postel.  User Datagram Protocol.  RFC  Request for Comments
        (Standard) 768, Internet Engineering Task Force, August 1980.

   [18] J. B. Postel, Editor.  Internet Protocol.  RFC 791, September
        1981.

   [19]

   [15] S. Thomson and T. Narten.  IPv6 Stateless Address
        Autoconfiguration.  RFC 1971, August 1996.

   [20] S. Thomson and T. Narten.  RFC 2462:  IPv6 stateless address
        autoconfiguration,  Request for Comments (Draft Standard) 2462,
        Internet Engineering Task Force, December 1998.  Obsoletes RFC1971 [19].
        Status:  DRAFT STANDARD.

   [21]

   [16] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan.  Service
        Location Protocol.  RFC  Request for Comments (Proposed Standard)
        2165, July Internet Engineering Task Force, June 1997.

   [22]

   [17] P. Vixie, Ed., S. Thomson, Y. Rekhter, and J. Bound.  Dynamic
        Updates in the Domain Name System (DNS).  RFC (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
      Computer Science Department
      323 Dana Engineering
      Bucknell University
      Lewisburg, PA 17837

      Phone:  (717) 524-1145  (570) 577-1145
      E-mail:  droms@bucknell.edu

Author's Address

   Questions about this memo can be directed to:

        Jim Bound                         Charles E. Perkins
        Compaq Computer Corporation       Sun Microsystems Laboratories
        Mail Stop:  ZK03-3/U14
        110 Spitbrook Road, ZKO3-3/U14    15 Network Circle Road
        Nashua, NH 03062                  Menlo Park, CA 94025
      USA
        USA
        Phone:  +1-603-884-0400           Phone:  +1 650 786-6464
      EMail:
        Email:  bound@zk3.dec.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:  cperkins@eng.sun.com  charliep@iprg.nokia.com
        Fax:  +1 650 786-6445 625-2502