INTERNET-DRAFT
Internet Engineering Task Force                                 J. Bound
INTERNET DRAFT                                   Digital Equipment Corp.
DHC Working Group                                 Digital Equipment Corp                                             C. Perkins
Obsoletes: draft-ietf-dhc-dhcpv6-02.txt                    November 1995  draft-ietf-dhc-dhcpv6-03.txt                    IBM Research
                                                        12 February 1996

         Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

                      draft-ietf-dhc-dhcpv6-03.txt
                      draft-ietf-dhc-dhcpv6-04.txt

Status of this This Memo

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

   This document is an Internet-Draft.  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- Internet Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet- Drafts
   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   Distribution of this document is unlimited.

Abstract

   This document is an Internet application protocol, for IP version 6
   (IPv6), that specifies

   The Dynamic Host Configuration Protocol (DHCP) provides a client/server model framework
   for communications
   between hosts passing configuration information, via options, to dynamically configure parameters for a network, and
   autoconfigure IPv6 hosts.
   It offers the capability of automatic allocation of reusable network
   addresses within and additional configuration options.  This protocol should
   be considered a stateful model.  This document
   supports counterpart to the model for IPv6 Stateless Address Autoconfiguration,
   where there are clear integration points between stateless and
   stateful address autoconfiguration for IPv6.

Table
   Autoconfiguration protocol specification.

                                Contents

Status of Contents: This Memo                                                    i

Abstract                                                               i

 1. Introduction.................................................3 Introduction                                                       1
     1.1. Requirements...............................................3 Specification Language  . . . . . . . . . . . . . . . . .    1

 2. Terminology and Definitions..................................4 Definitions                                        2
     2.1. IPv6 Terminology...........................................4 Terminology  . . . . . . . . . . . . . . . . . . . .    2
     2.2. DHCPv6 Terminology.........................................6 Terminology  . . . . . . . . . . . . . . . . . . .    4

 3. Protocol Design Model........................................9 Model                                              5
     3.1. Design Goals...............................................9 Goals  . . . . . . . . . . . . . . . . . . . . . .    5
     3.2. Request/Response Model....................................10 DHCPv6 Messages . . . . . . . . . . . . . . . . . . . . .    6
     3.3. Leased Address Model......................................11
3.3.1. Address Lifetimes.......................................11
3.3.2. Duplicate Address Detection.............................12
3.3.3. Releasing Infinite Lifetime Addresses...................13
3.4. DNS Host Name Autoregistration Model......................13
4. Request/Response Processing.................................13
4.1. Processing when Server Address is not Known...............14 Model . . . . . . . . . . . .    7

 4. DHCPv6 Message Formats and Field Definitions                       8
     4.1. UDP Ports used for DHCPv6 messages  . . . . . . . . . . .    8
     4.2. Processing when Server Address is Known...................16 DHCP Solicit Message Format . . . . . . . . . . . . . . .    8
     4.3. Retransmission and Configuation Variables.................16 DHCP Advertise Message Format . . . . . . . . . . . . . .    9
     4.4. DHCP Request Message Format . . . . . . . . . . . . . . .   10
     4.5. DHCP Reply Message Format . . . . . . . . . . . . . . . .   12
     4.6. DHCP Release Message Format . . . . . . . . . . . . . . .   13
     4.7. DHCP Reconfigure Message Format . . . . . . . . . . . . .   14

 5. Datagram and Field Definitions..............................18 DHCP Client Considerations                                        15
     5.1. Datagram..................................................18 DHCP Solicit Message Processing . . . . . . . . . . . . .   15
     5.2. Field Definitions.........................................19
6. Client/Server DHCP Advertise Message Processing . . . . . . . . . . . .   15
     5.3. DHCP Request Message Processing . . . . . . . . . . . . .   16
     5.4. DHCP Reply Message Processing . . . . . . . . . . . . . .   17
     5.5. DHCP Release Message Formats...............................21 Processing . . . . . . . . . . . . .   18
     5.6. DHCP Reconfigure Message Processing . . . . . . . . . . .   18

 6. DHCP Server Considerations                                        19
     6.1. Client/Server UDP Ports, Multicast Group, DHCP Solicit and Addresses...21 Advertise Message Processing . . . . . .   19
     6.2. Client DISCOVER DHCP Request and CONF-REQUEST Messages.................21 Reply Message Processing . . . . . . . .   19
     6.3. Server CONF-RESPONSE Message..............................23 DHCP Release Message Processing . . . . . . . . . . . . .   20
     6.4. Client ACCEPT Message.....................................24
6.5. Server SERVER-ACK Message.................................25
6.6. Client RELEASE Message....................................27 DHCP Reconfigure Message Processing . . . . . . . . . . .   21

 7. Relay-Agent Processing......................................28 DHCP Relay Considerations                                         22
     7.1. DHCP Solicit and DHCP Advertise Message Processing  . . .   22
     7.2. DHCP Request Message Processing . . . . . . . . . . . . .   23
     7.3. DHCP Reply Message Processing . . . . . . . . . . . . . .   23
     7.4. Retransmission and Configuation Variables . . . . . . . .   23

 8. Security Considerations.....................................29
Appendix A - Considerations                                           25

 9. Acknowledgements                                                  25

 A. Related Work in IPv6..............................29 IPv6                                              26

 B. Change History.................................................31
Acknowledgements...............................................33
References.....................................................33
Authors' Address...............................................34 History                                                    27
     B.1. Changes from November 95 to February 96 Drafts  . . . . .   27

Chair's Address                                                       29

Author's Address                                                      29

1. Introduction

   DHCPv6 is an Internet application protocol, for IP version 6 (IPv6),
   that specifies

   The Dynamic Host Configuration Protocol (DHCP) provides configuration
   parameters to Internet hosts.  DHCP consists of a client/server model protocol for communications between
   delivering host-specific configuration parameters from a DHCP server
   to a host, and a mechanism for allocation of network addresses and
   other related parameters to IPv6 hosts.

   DHCP is built on a client-server model, where designated DHCP
   server hosts allocate network addresses and automatically deliver
   configuration parameters to dynamically configure parameters for configured hosts.  Throughout
   the remainder of this document, the term "server" refers to a network, host
   providing initialization parameters through DHCP, and autoconfigure
   addresses within the term
   "client" refers to a stateful model. host requesting initialization parameters from
   a DHCP server.  DHCPv6 supports the model servers maintain state for their clients,
   in contrast to IPv6 Stateless Address Autoconfiguration [IPv6-ADDRCONF], [9],
   where there
   are clear integration points between stateless and stateful address IPv6 hosts should get the same results if they repeat the
   autoconfiguration for IPv6. procedure multiple times.

   DHCPv6 uses a set of request/response Request and Reply messages to support a
   transaction client/server
   processing model where a commit to the data can be
   verified by whereby both the client and server.  This affords DHCPv6 the
   ability in the future to support dynamic updates to data located
   within a sites network.  In addition to the capability of verifying
   commits to transactions a recovery mechanism is specified, should
   commits need to be rolled back during server are assured that
   requested configuration parameters have been received and accepted by
   the course of a DHCPv6
   transaction being processed. client.  DHCPv6 supports optional configuration parameters and
   processing for hosts through its companion document Options Extensions for
   the Dynamic Host Configuration Protocol for IPv6 [DHCPv6-OPT]. [5].

   The IPv6 Addressing Architecture [IPv6-ADDR] [3] and IPv6 Stateless Address
   Autoconfiguration specifications provide new functionality features not present available
   in IP version 4 (IPv4).  This new IPv6 functionality
   provides inherent benefits to autoconfigure IPv6 addresses for nodes.
   In addition the IETF DNS Working Group has defined a method to
   support Dynamic Updates to DNS [DYN-UPD], (IPv4) [8], which can be are used by a node to add, delete, simplify and change node names dynamically.

   DHCPv6 used several of the architecture principles from DHCPv4
   [DHCP-v4], but it is beyond generalize
   the scope operation of this document to contrast
   and compare DHCPv6 with DHCPv4. clients.

   Section 2 provides definitions for terminology used throughout this
   document.  Section 3 provides a review overview of the protocol design model
   parts
   that are inherent guides the design choices in the specification. specification; section 3.2
   briefly describes the protocol messages and their semantics.
   Section 4 provides the
   request/response model and interaction between the set of messages
   and the semantics for those messages.  Section 5 provides the
   datagram packet format message formats and field definitions used for that datagram.
   Section 6 provides the message formats and field contents for
   processing the client
   each message.  Sections 5,  6, and server messages.  Section  7 provides the
   specification of specify how relay-agents and servers interact with clients,
   when the server is not on the same link as the client.  Section 8
   provides the security specifications that can be used to support
   security in DHCPv6. servers,
   and relays interact.  Appendix A provides a summary of summarizes related work in IPv6 that
   will help put DHCPv6 in the context of IPv6 for the reader,
   and provide helpful context; it is not part of this specification,
   but here included for information informational purposes.

1.1. Requirements

   Throughout Specification Language

   In this document, the several words that are used to define signify the
   significance requirements
   of the particular requirements are capitalized. specification.  These words are:

      o "MUST" are often capitalized.

      MUST               This word word, or the adjective "REQUIRED" "required", means
                         that the item definition is an absolute requirement
                         of this the specification.

      o "MUST NOT"

      MUST NOT           This phrase means that the item definition is an
                         absolute prohibition of this the specification.

      o "SHOULD"

      SHOULD             This word word, or the adjective "RECOMMENDED" "recommended",
                         means that there may exist valid reasons in
                         particular circumstances to ignore this item,
                         but the full implications should must be understood
                         and the case carefully weighed before choosing a
                         different course.

      o "SHOULD NOT"

      This phrase means that there  Unexpected results may exist valid reasons in particular
      circumstances when the listed behavior is acceptable or even
      useful, but the full implications should be understood and the
      case carefully weighted before implementing any behavior described
      with this label.

      o "MAY"
                         result otherwise.

      MAY                This word word, or the adjective "OPTIONAL" "optional", means
                         that this item is
      truly optional.  One vendor may choose one of an allowed set of
                         alternatives.  An implementation which does
                         not include this option MUST be prepared to
                         interoperate with another implementation which
                         does include the item because
      a particular marketplace requires it or because it enhances option.

      silently discard   The implementation discards the
      product, for example, another vendor may omit datagram
                         without further processing, and without
                         indicating an error to the same item. sender.  The
                         implementation SHOULD provide the capability of
                         logging the error, including the contents of
                         the discarded datagram, and SHOULD record the
                         event in a statistics counter.

2. Terminology and Definitions

   Relevant terminology from the IPv6 Protocol [IPv6-SPEC], [2], IPv6 Addressing
   Architecture, and IPv6 Stateless Address Autoconfiguration will be
   provided, and then the DHCPv6 terminology.

2.1. IPv6 Terminology

      IP           -

         Internet Protocol Version 6 (IPv6).  The terms IPv4 and IPv6
         are used only in contexts where necessary to avoid ambiguity.

      node         -

         A device that implements IPv6.

      router       -

         A node that forwards IPv6 packets datagrams not explicitly addressed to
         itself.

      host         -

         Any node that is not a router.

   upper-layer  - A protocol layer immediately above IP. Examples are
                  transport protocols such as TCP and UDP, control
                  protocols such as ICMP, routing protocols such as
                  OSPF, and internet or lower-layer protocols being
                  "tunneled" over (e.g. encapsulated in) IP such as
                  IPX, Appletalk, or IP itself.

      link         -

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

   neighbors    - Nodes attached to

      link-layer identifier

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

      link-local address

         An address having link-only scope that can be used to reach
         neighboring nodes attached to the same link.  All interfaces
         have a link-local address.

      neighbors

         Nodes attached to the same link.

      interface    -

         A node's attachment to the link.

      address      -

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

   packet       -

      message

         The data exchanged between DHCP agents and clients; in this
         specification, messages are delivered via IPv6 and UDP.

      datagram

         An IP header plus payload.

   communication
                - Any packet exchange between nodes that requires
                  that the address of each node used in the exchange
                  remain the same for the duration of the packet
                  exchange.  Examples are a TCP connection or UDP
                  request/response.

      unicast address
                -

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

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

   link-local address
                - An address having link-only scope

2.2. DHCPv6 Terminology

      configuration parameter

         Any parameter that can be used by a node to reach neighboring nodes attached to the same link.
                  All interfaces have configure its
         network environment and enable communication on a link-local address.

   preferred address
                - An address assigned link or
         internetwork.

      client

         A host that initiates requests on a link to an interface whose use by
                  upper layer protocols obtain
         configuration parameters.

      server

         A server is unrestricted.  Preferred
                  addresses a node that responds to requests from clients on a
         link to provide:  addresses, dynamic updates to DNS, or other
         configuration parameters.

      relay

         A node that may be used advertise DHCP server addresses, or may act as the source
         an intermediary to deliver DHCP messages between clients and
         servers.

      DHCP Agent

         Either a DHCPv6 server or destination a DHCPv6 relay.

      agent address

         The address of packets sent from a neighboring DHCP relay or to DHCP server on the interface.

   deprecated address
                - An address assigned to an interface whose use is
                  discouraged, but not forbidden.  A deprecated
                  address should no longer be used
         same link as the DHCP client.

      msg-type

         The msg-type defines the DHCPv6 protocol type for a source address
                  in new communications. but packets sent message.

      transaction-ID

         The transaction-ID is a monotonically increasing integer
         identifier specified by the client and is used by the client to
         match a
                  deprecated address are delivered as expected.
                  A deprecated address may continue DHCP Reply to be used as a
                  source address for the duration of existing
                  communications.

   valid pending DHCP Request.

      server address
                - A preferred or deprecated address.  A valid

         The server address
                  may appear as specifies the source or destination address of a
                  packet, and for the internet routing system is expected to
                  be able to deliver packets sent server
         responding to a valid address.

   invalid address
                - An address that is not assigned to any interface. client.

      binding

         A
                  valid address becomes invalid when its valid
                  lifetime expires.  Invalid addresses should not appear
                  as binding in DHCPv6 contains the source or destination of data which a packet.

   preferred lifetime
                - The length DHCPv6 server
         MUST maintain for each of time that its clients.  An implementation
         MUST support bindings consisting of at least a valid address is preferred.
                  When the client's
         link-local address, agent address, preferred lifetime expires, the address
                  becomes deprecated. and valid
         lifetime
                - The length of time [9] for each client address, and the address remains transaction-ID.

3. Protocol Design Model

   This section is provided for implementors to understand the DHCPv6
   protocol design model from an architectural perspective.  The goals,
   conceptual models and implementation examples presented in this
   section do not specify requirements of the valid
                  state. DHCPv6 protocol.

3.1. Design Goals

   The valid lifetime MUST following list gives general design goals for this DHCPv6
   specification.

    -  DHCPv6 should be greater a mechanism rather than or
                  equal to the preferred lifetime.  When the valid
                  lifetime expires, the address becomes invalid.

   interface token
                - A link-dependent identifier for an interface that
                  is (at least) unique per link.  Stateless Address
                  Autoconfiguration combines an interface token with
                  a prefix to form an address.  From an address
                  autoconfiguration perspective, an interface token
                  is a bit string of known length.  The exact length
                  of an interface token and the way it is created is
                  defined in a separate link-specific document that
                  covers issues related to the transmission of IP
                  over a particular link type (e.g., [IPv6-ETHER]).
                  In many cases the token will be the same as the
                  link-layer address.

2.2. policy.  DHCPv6 Terminology must
       allow local system administrators control over configuration
       parameters
                - Is any parameter that can where desired; e.g., local system administrators
       should be used by a node able to
                  configure their network environment so the node can
                  communicate on a link or on an internet.

   client enforce local policies concerning allocation
       and access to local resources where desired.

    - A  DHCPv6 MUST NOT introduce any requirement for manual
       configuration of DHCPv6 client is a hosts, except possibly for
       manually configured keys.  Each host that initiates requests on a link
                  to obtain: addresses, dynamic updates should be able to DNS, or
                  other discover
       appropriate local configuration parameters.

   server parameters without user
       intervention, and incorporate those parameters into its own
       configuration.

    - A server is  DHCPv6 MUST NOT require a node that responds to requests from
                  clients server on a link to provide: addresses, dynamic
                  updates to DNS, or other configuration parameters.

   relay-agent each link.  To allow for
       scale and economy, DHCPv6 must work across relay agents.

    -  A relay-agent is a node that listens on a link for DHCPv6 client requests, and then forwards the packet must be prepared to a
                  server on the network.  The server will respond back receive multiple responses to the relay-agent, who will forward the response
       solicitations for DHCP servers.  Some installations may include
       multiple, overlapping DHCPv6 servers to
                  the client on the relay-agents link.

   message-type enhance reliability
       and/or to increase performance.

    - The message-type defines the  DHCPv6 must coexist with statically configured, non-participating
       hosts and with existing network protocol type for
                  this packet.

   message-flag implementations.

    - The message-flag defines an optional processing
                  notification for DHCPv6.  The message-flag can also  DHCPv6 MUST be used by compatible with IPv6 Stateless Address
       Autoconfiguration.

    -  DHCPv6 must support the Options for requirements of automated renumbering of
       IPv6 addresses [1].

    -  DHCPv6 servers should be able to support Dynamic Updates to
       DNS [10].

    -  A DHCPv6 server to server protocol is NOT part of this DHCPv6
       specification.

   error-code

    - The error-code specifies errors from  It is NOT a client design goal of DHCPv6 to specify how a server
       configuration parameter database is maintained or
                  server.  The error-code can also be used by the
                  Options determined.
       Methods for DHCPv6 specification.

   total-addresses
                -  The total-addresses specifies configuring DHCP servers are outside the total number scope of
                   addresses being provided
       this document.

3.2. DHCPv6 Messages

   Each DHCPv6 message contains a type, which defines whether the
   message originated from a DHCPv6 server to a or client.
                   For each address there is a preferred and valid
                   lifetime.

   completed-transaction
                -  A completed-transaction

   The message types are as follows:

      01 DHCP Solicit

         The DHCP Solicit message is a communications exchange
                   between DHCPv6 multicast (or in special
         circumstances unicast) message from a client and server, using the required set
                   of to one or more
         neighboring DHCPv6 request/response message-types, where the
                   final response Agents.

      02 DHCP Advertise

         The DHCP Advertise is an IPv6 unicast message from a DHCP Agent
         in the request/response set
                   has been received by the response to a client and by the server.

   transaction-ID
                - DHCP Solicit.

      03 DHCP Request

         The transaction-ID DHCP Request is an integer identifier specified
                  by IPv6 unicast message from a client to
         a server, when the client and is used by the client and server as
                  a transaction identifier to define knows the set IPv6 unicast address of
                  request/response messages between the client and a
         server, for to request configuration parameters on a clients interface token.

   client-link address
                - The client-link address specifies the clients
                  link-local address. network.

      04 DHCP Reply

         The client-link address DHCP Reply is used an IPv6 unicast message sent by a relay-agent server to
         respond to a client
                  on a link, after receiving a server response.

   server address
                - The server address specifies client's DHCP Request.  Extensions [5] to the address for DHCP
         Reply describe the
                  server responding to a client.

   gateway address
                - The gateway address specifies resources that the address of DHCP Server has committed
         and allocated to the
                  relay-agent for a server, which client, and may be multiple
                  relay-agent hops away from contain other information
         for use by the original relay-agent.

   client address
                - client.

      05 DHCP Release

         The client address specifies an address from a
                  server to be DHCP Release message is used by a client.

   binding      - A binding in DHCPv6 is an N-tuple that a client
                  and to inform
         the server MUST maintain in DHCPv6 for a
                  completed-transaction, where N is that the number of
                  configuration parameters for a client. An
                  implementation MUST support at least a 5-tuple
                  binding consisting of a clients interface token, client is releasing a particular address, preferred lifetime and
         or set of addresses or resources, even though the addresses or
         resources may still be marked valid
                  lifetime in the server's binding for each client address, and
         the
                  transaction-ID.

3. Protocol Design Model

   This section client.

      06 DHCP Reconfigure

         The DHCP Reconfigure message is provided for implementors used by a DHCPv6 server
         to understand inform the DHCPv6
   protocol design model from an architectural perspective.  Any
   conceptual models presented in this specification client that provide
   implementation examples are not a requirement the server has new configuration
         information of importance to the DHCPv6 protocol.

3.1. Design Goals client.  The following list gives general design goals client is
         expected to initiate a new Request/Reply transaction.

3.3. Request/Response Processing Model

   Processing details for the DHCP messages listed above are specified
   in Sections 5, 6, and 7.

   The request/response processing for DHCPv6. DHCPv6 should be a mechanism rather than is transaction based
   and uses a policy.  DHCPv6 must
      allow local system administrators control over configuration
      parameters where desired; e.g., local system administrators should
      be able best-effort set of messages to enforce local policies concerning allocation guarantee a completed
   transaction.  The timeout and access
      to local resources where desired.

      Hosts should require no manual configuration.  Each host should be
      able to discover appropriate local configuration parameters
      without user intervention, retransmission guidelines and incorporate those parameters into
      its own configuration.

      Networks should require no hand
   configuration for individual
      hosts.  Under normal circumstances, variables are discussed in Section 7.4.

   The request/response set is always started by a client with a DHCP
   Request, which may be issued after the network manager should client knows the server's
   address.  The response message is from the server and is the DHCP
   Reply.  At this point in the flow all data has been received.  To
   provide a method of recovery if either the client or server do not
      have
   receive the messages to complete the transaction, the client is
   required to enter retransmit any per-host configuration parameters.

      DHCPv6 should not require DHCP Request message until it elicits a server on each link.  To allow for
      scale and economy,
   DHCP Reply, or until it can be reasonably certain that the desired
   DHCP Server is unavailable.

4. DHCPv6 must work across relay agents.

      A Message Formats and Field Definitions

   All fields in DHCPv6 client must messages MUST be prepared to receive multiple responses initialized to
      a request for configuration parameters.  Some installations may
      include multiple, overlapping DHCPv6 servers to enhance
      reliability binary zeroes by
   both the client and increase performance. server unless otherwise noted.  DHCPv6 must coexist with statically configured, non-participating
      hosts message
   types not defined here (msg-types 0 and with existing network protocol implementations. 7-255) are reserved.

   All DHCP Agents MUST join the DHCPv6 should as much Server/Relay-Agent multicast
   group at the well-known multicast address FF02:0:0:0:0:0:1:0.

   Servers on the same link as possible be compatible with IPv6
      Stateless Address Autoconfiguration.

      DHCPv6 must support the requirements of automated renumbering of client MUST use the source address
   in the IPv6 addresses. header from the client as the destination address in the
   server's response datagrams.

4.1. UDP Ports used for DHCPv6 servers should be able to support Dynamic Updates to DNS
      [DYN-UPD].

      It is NOT a design goal of messages

   DHCPv6 uses the UDP [7] protocol to specify a server to server
      protocol.

      It communicate between clients
   and servers.  UDP is NOT a design goal of not reliable, but DHCPv6 to specify how must provide some
   reliability between clients and servers.  If a server
      configuration parameter database response is maintained or determined.

   The following list gives design goals specific to the not
   received after transmission of
   the network layer parameters.

      Guarantee that any specific network address will not be in use by
      more than one host at a time.

      Guarantee that client addresses that are not provided by DHCPv6
      will not DHCP message, the message MUST be added
   retransmitted according to a servers configuration parameter database or the servers binding for a clients interface token.

      Retain host configuration parameters across client reboots. rules specified in  7.4.

   A
      client should, whenever possible, be assigned Client MUST transmit all messages over UDP using UDP port 547 as
   the same
      configuration parameters in response to a request.

      Retain host configuration across server reboots, and, whenever
      possible, a host should be assigned the same configuration
      parameters despite restarts of the DHCPv6 mechanism,

      Allow automatic assignment of configuration parameters to new
      hosts to avoid hand configuration for new hosts.

      Support fixed or permanent allocation of configuration parameters
      to specific hosts.

3.2. Request/Response Model

   DHCPv6 uses a message-type to define whether the packet originated destination port.  A client MUST receive all messages from a DHCPv6 server or client.  The set of packets used to complete
   a DHCPv6 transaction are defined UDP
   port 546.

   A DHCP Agent MUST transmit all messages over UDP using UDP port 546
   as the request and response set.

   The message types are as follows:

      01 DISCOVER

         The DISCOVER message is a destination port.  A DHCP Agent MUST receive all messages over
   UDP using UDP port 547.

4.2. DHCP Solicit Message Format

   A DHCPv6 multicast packet from a client
         to locate and request configuration parameters on a network,
         when the client does not know the servers address.

      02 CONF-REQUEST

         The CONF-REQUEST is an IPv6 unicast packet from transmits a client DHCP Solicit message to a
         server, when the client knows obtain the IPv6 unicast
   address of a
         server, to request configuration parameters on a network.

      03 CONF-RESPONSE

         The CONF-RESPONSE is an IPv6 unicast packet from a server in
         response neighboring DHCP Agent, and to a client DISCOVER obtain one or CONF-REQUEST, more
   addresses for DHCP servers which provides the requested configuration parameters.

      04 ACCEPT

         The ACCEPT DHCP Agent is a client response configured to
   advertise.  If a server CONF-RESPONSE. When
         the DHCPv6 client used DISCOVER does not know any DHCP Agent address,
   or wants to locate a new server and request to receive configuration parameters on a network, parameters,
   the ACCEPT should be
         sent using client SHOULD use, as the DHCPv6 multicast destination IP address, which also serves to
         inform other servers that responded to the DISCOVER they were
         not selected.  When the client used CONF-RESPONSE to request
         configuration parameters from a server whose DHCPv6
   Server/Relay-Agent multicast address was known,
         the ACCEPT should be sent as an IPv6 unicast packet.  The
         ACCEPT is also an implied acknowledgment to the server selected
         that the client has received the servers configuration
         parameters from the CONF-RESPONSE.

      05 SERVER-ACK

         The SERVER-ACK is an IPv6 unicast packet sent by FF02:0:0:0:0:0:1:0.

    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   |   msg-flags   |            RESERVED           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  extensions (variable number and length) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      msg-type      1

      msg-flags     0

      RESERVED      0

      extensions    No extensions are defined at this time.

4.3. DHCP Advertise Message Format

   A DHCPv6 agent sends a server DHCP Advertise message to inform a prospective
   client that it received an ACCEPT. The SERVER-ACK is
         used by the server to inform the client it has received an
         acknowledgment that the client has received the configuration
         parameters from about the server, and denotes IPv6 address of a completed-transaction DHCP Agent to which a server.  The server at that point MUST commit its bindings
         and any updates it DHCP Request
   message may do for the client. The SERVER-ACK for
         the client denotes a completed-transaction. The client at that
         point MUST commit its bindings.

      06 RELEASE

         The RELEASE is used by the client for two reasons:

            1. To inform the server that the client did not receive the
               SERVER-ACK required be sent.

   A DHCPv6 agent MAY periodically transmit DHCP Advertise messages to complete
   the client transaction,
               and the server should delete that binding and any
               updates it may have done on behalf of the client.

            2. To inform the server that the client is releasing a
               particular address or set of addresses, even though the
               lifetimes for those addresses may not have become
               invalid.

      The processing All-DHCPv6 Clients multicast address, no more often than once per
   second, and algorithms for the request/response set of
      message-types will be discussed in section 4.0.

3.3. Leased Address Model

   The leased address model specifies a set of lifetimes associated with TTL == 1.

    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   |S|  msg-flags  |  server-count |   reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         agent address                         |
   |                          (16 octets)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        server addresses returned by the server.  These lifetimes are meant to
   support site renumbering,                       |
   |                        (16 octets each)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              extensions (variable number and are completely compatible with the
   leasing model in IPv6 Stateless Address Autoconfiguration.

   The DHCPv6 philosophy is that the client has length) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      msg-type           2

      S                  If set, the responsibility to
   renew a lease for an agent address that is about to expire, or request a
   new address or the same address before the lease actually expires.
   If the client does not request also a new lease for an address, the server
   MUST assume the client does not want a new lease for that
                         address.

      msg-flags          0

      server-count       The server MAY provide that address to another client requesting an
   address, after all other number of addresses available to listed in the server have been
   exhausted.

3.3.1. Address Lifetimes

   An
                         addresses field.

      RESERVED           0

      agent address returned to a client has a preferred and valid lifetime.      The lifetimes represent the lease for IPv6 address of a neighboring DHCP Agent
                         interface

      server addresses provided to the
   client, from the server.   The client MAY request a value for the lifetimes returned by a
   server, but the client MUST use IPv6 address(es) of the lifetimes provided by DHCPv6 server(s)
                         which the server
   response.

   When an address for DHCP Agent has been configured to
                         advertise.

      extensions         See [5].

   Note that if a client interface becomes deprecated neighboring DHCPv6 server issues the
   processing of DHCP Advertise,
   then the lease MUST agent address will be as follows:

      When the preferred lifetime of an IPv6 address expires, of one of the clients
      address becomes a deprecated address.  A deprecated address can be
      used as a source address in new communications and existing
      communications. But a deprecated address means
   server's interfaces, the node will soon
      have an address whose valid lifetime 'S' bit will expire, when this
      happens the address cannot be used in any communications.

      An address is a deprecated until its valid lifetime expires at
      which point set, the agent address becomes an invalid address. An invalid
      address MUST NOT will
   be used as a source an address in outgoing
      communications, of the server, and MUST NOT there may be recognized as a valid destination
      address for incoming communications.

      Once an address zero server addresses
   sent in the DHCP Advertise message.  It is deprecated an implementation SHOULD error for server-count
   to be zero if the 'S' bit is not set.

4.4. DHCP Request Message Format

   In order to request parameters from a
      new lease or address DHCP server, a client sends a
   DHCP Request message and appends the extensions which are appropriate
   for that interface. obtaining the needed parameters [5].  If the clients preferred lifetime is zero for an client does not know
   any DHCPv6 server address, it must first obtain a server address by
   multicasting a DHCP Solicit message (see Section 4.2).  If the client
   does not have a valid IPv6 address which is immediately deprecated.

   Implementors of reachable by the DHCPv6 would find it beneficial to coordinate
   server, the client MUST use the unicast IP address of a local DHCPv6
   relay as the preferred lifetime and valid lifetime for layers below destination IP address.  Otherwise, the
   DHCPv6 application layer with their implementation of Stateless
   Address Autoconfiguration.  It is suggested that implementations use client MAY omit
   the same modules to configure addresses for stateless and stateful server address autoconfiguration.  Implementors might want to consider an
   option in the DHCP Request message; in this case, the
   client MUST send the DHCP Request message directly to stop all new communications the server just
   as it would any other datagram destined for a deprecated address, to
   support a very robust renumbering strategy, but this cannot be the
   default behavior.

3.3.2. Duplicate Address Detection

   DHCPv6 clients MUST support Duplicate Address Detection as specified
   in IPv6 Stateless Address Autoconfiguration. This will provide a high
   guarantee that DHCPv6 client addresses are not duplicated on a link.

   It is an option for a server, using the
   server address as the IPv6 destination address in the IPv6 header.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    msg-type   |S|C| reserved  |        transaction-ID         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         (if present)                          |
   |                   server address (16 octets)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         agent address                         |
   |                          (16 octets)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       link-local address                      |
   |                          (16 octets)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  extensions (variable number and length)   ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      msg-type             3

      S                    If set, the server to inform address is present

      C                    If set, the client it does not have to
   perform Duplicate Address Detection by requests the server setting a value of
   01 in to
                           clear all existing resources and bindings
                           currently associated with the client,
                           deallocating as needed.

      reserved             0

      transaction-ID       A monotonically increasing number which the message-flag in
                           client responses.  In this case it is
   assumed that asks the server implementation is providing the guarantee to copy into its DHCP
                           Reply, so that the client addresses returned are unique on the link.  It is
   implementation defined how a can match Replies
                           with pending Requests.

      server verifies address       If present, the uniqueness of client
   addresses on a link.

   A conceptual model of an implementation for DHCPv6 duplicate IPv6 address
   detection is that of the client DHCPv6 module,
                           server which supports updating should receive the network interfaces for a host, would use client's DHCP
                           Request message.

      agent address        The IPv6 address of the same application
   configuration relay or server
                           interface for DHCPv6 as is used for IPv6 Stateless
   Address Autoconfiguration on an IPv6 conforming implementation.  An
   implementation can integrate and reuse from which the same modules in client received the
   network operating system kernel to spawn duplicate
                           DHCP Advertise message

      link-local address detection,   The IPv6 link-local address lifetime processing, and the processing of deprecated and
   invalid addresses for existing and new connections.

3.3.3. Releasing Infinite Lifetime Addresses

   DHCPv6 specifies no behavior which would require a the client to listen
   for asynchronous messages
                           interface from servers on a well known UDP port.  The
   reason for this is that minimal implementations may not be able to
   support such a feature in a client.  But DHCPv6 does permit which the the client to request an infinite lease for addresses. issued
                           the DHCP Request message
      extensions           See [5].

4.5. DHCP Reply Message Format

   The problem server sends a DHCP Reply message in
   this case is that though response to every DHCP
   Request received.  If the server has permitted an infinite lease
   for a client it may later be required that request comes with the 'S' bit set, the
   client give up that
   lease or could not directly send the addresses, for some organizational reason.

   This specification leaves it as implementation defined how this
   problem is solved in a DHCPv6 network environment.

   One solution Request to the problem is server and had to define an SNMP MIB for DHCPv6
   clients that when set by a network management agent causes
   use a client
   to revalidate all of its addresses with neighboring relay agent.  In that case, the DHCPv6 server or issue a
   RELEASE to sends back
   the server.

3.4. DNS Host Name Autoregistration Model

   It DHCP Reply with the 'L' bit set, and the DHCP Reply is important that DHCPv6 provide a server implementation set of
   options for Dynamic Updates to DNS (DYNDNS), addressed
   to support the
   autoregistration of addresses to names in IPv6.  DYNDNS SHOULD be
   supported as a set of options in DHCPv6 as specified agent address found in the Options
   for DHCPv6 specification.  The minimum requirements to support DYNDNS
   in DHCPv6 are as follows:

      1.  Clients SHOULD be able to request or change names for
          addresses.

      2.  Servers SHOULD be able to provide names for addresses
          provided to a client.

      3. DHCP Request message.  If servers support DYNDNS the
   'L' bit is set, then they MUST support the
          following:

          a)  Create, Update, and Delete of IPv6 AAAA Records
              [IPv6-DNS] as specified in DYNDNS [DYN-UPD].

          b)  Create, Update, client's link-local address will also be
   present.

    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   |   error code  |        transaction-ID         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |L|                         RESERVED                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         (if present)                          |
   |                 link-local address (16 octets)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  extensions (variable number and Delete length)   ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      msg-type             3

      error code           One of IPv6 IP6.INT Domain PTR
              records for any IPv6 AAAA addresses defined in a client
              DYNDNS request, the following values:

                            0 Success
                            1 Failure, reason unspecified
                            2 Authentication failed or that nonexistent
                            3 Poorly formed request
                            4 Resources unavailable
                            5 Client record unavailable
                           16 Wrong phase of moon
                           32 Dogbert didn't like it
                           64 Server unreachable (ICMP error)

      transaction-ID       Copied from the transaction-ID which the server automatically generated
              for a client.

4. Request/Response Processing

   The request/response processing for
                           DHCPv6 is transaction based and
   uses a best-effort set of messages server received in the DHCP Request.
                           to guarantee a completed-
   transaction. The case where help the client does not know match this reply with an
                           outstanding Request.

      L                    If set, the servers link-local address is depicted, and then present
      RESERVED             0

      link-local address   If present, the case where IPv6 address of the client does know
                           interface which issued the
   servers address is depicted.  Then corresponding DHCP
                           Request message.

      extensions           See [5].

   If the timeout and retransmission
   guidelines 'L' bit is set, and configuration variables are discussed.

4.1. Processing when Server Address thus the link-local address is not Known

   The processing for present in
   the DHCPv6 request/response model when Reply message, the client
   does not know Reply is sent by the server to the relay's
   address is which was specified as follows:

                   Server          Client          Server
               (not selected)                    (selected)

                     v               v               v
                     |               |               |
                     |       Begin Transaction       |
                     |               |               |
                     | _____________ | _____________ |
                     |      DISCOVER | DISCOVER      |
                     |       (DHCPv6 Multicast)      |
                     |               |               |
      Determine Client Configuration | Determine Client Configuration
                     |           (Unicast)           |
                     |  ___________  | ____________  |
                     | CONF-RESPONSE | CONF-RESPONSE |
                     |               |               |
                     |       Collects replies        |
                     |               |               |
                     |     Selects configuration     |
                     |               |               |
                     | _____________ | _____________ |
                     |       ACCEPT  |   ACCEPT      |
                     |        (DHCPv6 Multicast)     |
                     |               |               |
                     |               |       Commits Client Bindings
                     |               |            (Unicast)
                     |               |               |
                     |               | _____________ |
                     |               |  SERVER-ACK   |
                     |               |               |
                     |       Transaction Complete    |
                     |       Client commits Bindings |
                     |               |               |
                     |       IF the Client did not   |
                     |       receive agent address in the DHCP Request
   message, and the relay uses the link-local address to deliver the
   Reply message to the client.

4.6. DHCP Release Message Format

   The DHCP Release message is sent without the assistance of any DHCPv6
   relay.  When a client sends a Release message, it is assumed to
   have a valid IPv6 address with sufficient scope to allow access to
   the target server.  Only the SERVER-ACK  |
                     |       delete parameters which are specified in the Bindings     |
                     |            (Unicast)          |
                     |               |               |
                     |
   extensions are released.  The DHCP server acknowledges the Release
   message by sending a DHCP Reply (Section 6.2).

    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   |D|  msg-flags  |        transaction-ID         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  RELEASE                         agent address                         |
   |                          (16 octets)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      link-local address                       |
   |    Server deletes the Bindings                          (16 octets)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  extensions (variable number and rolls back any updates that
                     |               |    that may have been done for length)   ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      msg-type             5

      D                    If the
                     |               |    client.
                     |               |               |
                     v               v               v

   DHCPv6 uses 'D' ("Direct") flag is set, the UDP [RFC-768] protocol client
                           instructs the server to communicate between clients
   and servers.  UDP is not reliable, but DHCPv6 must provide some
   reliabilty between clients and servers.  The network trade-off is
   time versus send the reliability that DHCP Reply
                           directly back to the completed set client, instead of
   request/response messages were received by both
                           using the client given agent address and link-local
                           address to relay the Reply message.

      msg-flags            0
      transaction-ID       A monotonically increasing number which the
                           client asks the server to define a completed-transaction.

   The request/response set is always started by a use in its DHCP
                           Reply, to help the client either match Replies with a
   DISCOVER when
                           outstanding Releases.

      agent address        The IPv6 address of the agent interface to
                           which the client does not know issued the DHCP Request
                           message

      link-local address   The IPv6 link-local address of the client
                           interface from which the the client issued
                           the DHCP Request message

      extensions           See [5]

   If the client knows that the address it uses as the source IP address
   in its IPv6 header will still be valid after the server performs the
   operations requested in the extensions to the servers address, or a
   CONF-REQUEST when DHCP Release message,
   the client does know can then specify the servers address.  The
   second message 'D' flag.  When the 'D' flag is from set,
   the server and is MUST send the CONF-RESPONSE.  The
   client then acknowledges DHCP Reply back to the servers CONF-RESPONSE with an ACCEPT.
   At this point client's address
   as shown in the flow all data has been received and additional
   messages are defined to insure source address of the transaction is completed, and to
   provide a method IPv6 header of recovery if either the client or server do Release
   message.  Otherwise, when the 'D' bit is not
   receive set, the messages server MUST use
   the agent address and link-local address in its DHCP Reply message to complete
   forward the transaction. Reply message back to the releasing client.

4.7. DHCP Reconfigure Message Format

   The server after receiving DHCP Reconfigure message is sent without the ACCEPT assistance of any
   DHCPv6 relay.  When a server sends a SERVER-ACK, Reconfigure message, the client
   to which it is an
   acknowledgment sent is assumed to have a valid IPv6 address with
   sufficient scope to be accessible by the server.  Only the parameters
   which are specified in the extensions to the Reconfigure message need
   be requested again by the client.

   The client SHOULD listen at UDP port 546 to receive possible DHCP
   Reconfigure messages.  If the client does not listen for DHCP
   Reconfigure messages, it is possible that the client will not receive
   notification that its DHCP server has received deallocated the clients
   ACCEPT.  At that point client's IPv6
   address and/or other resources allocated to the time vs reliability trade-off client.

   See discussion in 6.3.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    msg-type   |   msg-flags   |           reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  extensions (variable number and length)   ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      msg-type    6

      msg-flags   0

      reserved    0

      extensions  See [5]

5. DHCP Client Considerations

   A DHCPv6 is
   for the server to commit client MUST silently discard any DHCP Solicit, DHCP Request,
   or DHCP Release message it receives.

   A DHCPv6 client should retain its bindings, configured parameters and perform any updates as a
   result of the client messages (e.g. Update DNS).  If the resources
   across client
   receives the SERVER-ACK, then the system reboots and DHCPv6 client can commit its bindings.
   But if the program restarts.
   However, in these circumstances a DHCPv6 client does not receive the SERVER-ACK then it should send
   the server SHOULD also formulate
   a RELEASE DHCP Request message to inform the server verify that any bindings should be
   deleted its configured parameters and any updates for
   resources are still valid.  This Request message MUST have the 'C'
   bit set, to clear client should be rolled back.  The
   client RELEASE provides the final recovery check in binding information at the DHCPv6
   request/response set to complete a transaction.

   Retransmission server, of messages is discussed in section 4.3.

   The ACCEPT in the flow above is a multicast packet which serves an
   overloaded function, to respond to the selected server, and to inform
   other servers on the network
   the client is not selecting them.

4.2. may no longer have any record.

5.1. DHCP Solicit Message Processing when Server Address is Known

   The processing for the

   If a node wishes to become a new DHCPv6 request/response model when the client, it must first locate
   a neighboring DHCP Agent.  The client does knows this by multcasting
   a DHCP Solicit message to the server well-known multicast address is as follows (all packets are
   Unicast):

                                  Client          Server

                     v               v               v
                     |               |               |
                     |       Begin Transaction       |
                     |               |               |
                     |               | _____________ |
                     |               | CONF-REQUEST  |
                     |               |               |
                     |               |  Determine Client Configuration
                     |               |               |
                     |               | ____________  |
                     |               | CONF-RESPONSE |
                     |               |               |
                     |               | _____________ |
                     |               | ACCEPT        |
                     |               |               |
                     |               |  Commits Client Bindings
                     |               |               |
                     |               | _____________ |
                     |               |  SERVER-ACK   |
                     |               |               |
                     |       Transaction Complete    |
                     |       Client commits Bindings |
                     |               |               |
                     |       IF
   FF02:0:0:0:0:0:1:0, setting the Client did not   |
                     | TTL == 1.

5.2. DHCP Advertise Message Processing

   When a DHCPv6 client receives a DHCP Advertise message, it may
   formulate a DHCP Request message to receive configuration information
   and resources from the SERVER-ACK  |
                     |               |               |
                     |               | _____________ |
                     |               |  RELEASE      |
                     |               |               |
                     |               |    Server deletes DHCP servers listed in the Bindings
                     |               | advertisement.  If
   the Advertise message has zero server addresses and rolls back any updates that
                     |               |    that may does not have been done for the
                     |               |    client.
                     |               |               |
                     v               v               v

The processing above is
   'S' bit set, the same as was discussed in 4.1, except client MUST silently discard the message.

   If the
CONF-REQUEST 'S' bit is used set, the DHCP Advertise message was transmitted
   by a DHCPv6 server.  In this case, the Advertise message may
   have Extensions; this might allow the DHCPv6 client to request select
   the configuration parameters that best meets its needs from among several
   prospective servers.  Also in this case, the server, and client MUST use the CONF-REQUEST and ACCEPT are unicast packets.

4.3. Retransmission and Configuation Variables

   Configuration variables
   agent address as the address of its server for a future DHCPv6 message
   transactions.

5.3. DHCP Request Message Processing

   A DHCPv6 implementation that MUST be
   configurable by a client or server are as follows:

      Retranstimer - The time in seconds that obtains configuration information from a DHCPv6 client or
   server
                     should wait before retransmitting by sending a DHCP Request message.

                     Default: 3 seconds.

      Maxretrans   -  The maximum retransmissions that a DHCPv6 client
                     or server should retransmit, must know the
   server's address before logging a
                     DHCPv6 System Error to sending the Request message.  In addition,
   the user.

                     Default: 3 retransmissions.

   The problem with retransmissions occurs when they are continually
   received by a client or server (e.g. duplicate bindings or updates).

   To support informing must have acquired a valid DHCP agent address.  If the
   client or and server that a retransmission is
   being done a second set of message-types are supported in DHCPv6 as
   follows:

      20 - DISCOVER-Retrans
      21 - CONF-REQUEST-Retrans
      22 - CONF-RESPONSE-Retrans
      23 - ACCEPT-Retrans
      24 - SERVER-ACK-Retrans
      25 - RELEASE-Retrans

   When a on the same link, the agent address used by the
   client or MUST be the same as the DHCP server's address.

   If the client has no valid IPv6 address and the DHCP server retransmits a DHCPv6 packet at is
   off-link, then the
   application layer over UDP, they client MUST change include the message-type to server address in the
   same message-type with
   appropriate field of the Retrans suffix.

   A response to a retransmission SHOULD DHCP Request message and set the 'S' bit.
   In this case, the IPv6 destination address of the Request message
   MUST be the agent address.

   Otherwise, if the client already has a duplicate valid IPv6 address and knows
   the IPv6 address of a previous
   response candidate IPv6 server, it MUST send the Request
   message directly to the client or server.  It is implementation defined how
   this is accomplished.

   One method DHCPv6 server without requiring the services
   of retransmitting duplicates in an implementation
   conceptually is to use the 5-Tuple binding for local DHCPv6 relay.

   If a client or server wishes to
   search for instruct a DHCP server to deallocate all
   previous response.  At a minimum resources, configuration information, and bindings
   associated with its agent address and link-local address, it sets the
   'C' bit in the DHCP Request.  A client interface
   token and transaction-ID will be present MAY send in all messages; hence such a
   binding can be searched (whether committed or in process) Request
   even when it is no longer attached to verify
   if a previous response has been sent.

5. Datagram and Field Definitions

5.1. Datagram

                              DHCPv6 Datagram

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  msg-type     |    msg-flag   |   error-code  | total-addrs   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            RESERVED           |      transaction-ID           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                     interface token                           |
        |                        (8 octets)                             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       server address                          |
        |                        (16 octets)                            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       gateway address                         |
        |                        (16 octets)                            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                   client-link the link on which the relay
   address                         |
        |                        (16 octets)                            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                      preferred lifetime                       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                      valid lifetime                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | is attached.

   A client MAY maintain information about which relay address and
   server address                         |
        |                         (16 octets)                           |
        |        (can be multiple addresses it has been using for use after a reboot.  When
   the client has a pending DHCP Request and lifetimes present)      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  options (variable number reboots before the
   corresponding DHCP Reply is received, the client MUST issue its next
   DHCP Request after rebooting with the 'C' bit set.

   In any case, after choosing a transaction-ID which is numerically
   greater than its previous transaction-ID, and length)                         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2. Field Definitions

   All fields filling in the datagram MUST be initialized
   appropriate fields of the DHCP Request message, the client MAY append
   various DHCPv6 Extensions to binary zeroes the message.  These Extensions denote
   specific requests by
   both the client; for example, a client and may request
   a particular IP address, or request that the server messages unless otherwise noted in Section
   6.

   msg-type            - 1 octet integer value (message-type)

      Value        Description

      01           DISCOVER
      02           CONF-REQUEST
      03           CONF-RESPONSE
      04           ACCEPT
      05           SERVER-ACK
      06           RELEASE
      07-19        RESERVED
      20           DISCOVER-Retrans
      21           CONF-REQUEST-Retrans
      22           CONF-RESPONSE
      23           ACCEPT-Retrans
      24           SERVER-ACK-Retrans
      25           RELEASE-Retrans
      26-255       RESERVED

   msg-flag            - 1 octet integer value (message-flag)

      Value        Description

      01           Server - Duplicate Address Detection not Required.
      02-255       RESERVED

   error-code          - 1 octet integer value

      Value        Description

      01           Server - Addresses are not available at this time.
      02           Server - Address not known by send an update
   containing the Server
      03-255       RESERVED

   total-addrs         - 1 octet integer value (total-addresses)

   RESERVED client's new IP address to a Domain Name Server.  When
   all Extensions have been applied, the DHCPv6 client unicasts the DHCP
   Request to the appropriate DHCP Agent.

   For each pending DHCP Request message, a client MUST maintain the
   following information:

    - 2 octets Reserved for future use.  The transaction-ID of the Request message,

    - 2 octets integer value

   interface token     - 8 octets link-dependent identifier  The server address      - 16 octets address

   gateway address     - 16 octets address

   client-link address address,

    - 16 octets link-local address

   preferred lifetime  The agent address,

    - 4 octets integer value in seconds

   valid lifetime  The time at which the next retransmission will be attempted, and

    - 4 octets integer value  All Extensions appended to the reply message.

   If a client does not receive a DHCP Reply message with the
   same transaction-ID as a pending DHCP Request message within
   REPLY_MSG_INITIAL_TIMEOUT seconds, it MUST retransmit the Request
   with the same transaction-ID and continue to retransmit according to
   the rules in seconds Section 7.4.

   Note that if a client address      - 16 octets address

   options             - variable number of octets [DHCPv6-OPT]

6. Client/Server Message Formats

6.1. Client/Server UDP Ports, Multicast Group, crashes while its DHCP Request is still
   pending, no state is maintained, and Addresses

   A the client MUST transmit all messages over UDP using UDP Server Port 547.

   A server or relay-agent MUST transmit all messages over UDP using UDP
   Client Port 546.

   A reissue a DHCP
   Request after it restarts.

5.4. DHCP Reply Message Processing

   When a client receives a DHCP Reply message, it MUST receive all messages over UDP using UDP Client Port 546.

   A server or relay-agent MUST receive all messages over UDP using UDP
   Server Port 547.

   A server or relay-agent check whether
   the transaction-ID in the Reply message matches the transaction-ID
   of a pending DHCP Request message.  If no match is found, the Reply
   message MUST join be silently discarded, and an error SHOULD be logged.
   If the DHCPv6 Server/Relay-Agent
   multicast group well-known multicast transaction-ID matches that of a pending Request, and the 'L'
   bit is set, but the source address FF02:0:0:0:0:0:1:0.

   Servers on in the same link as IPv6 header does not match
   the pending agent address, the client MUST use discard the message, and
   SHOULD log the event.  Likewise, if the transaction-ID matches that
   of a pending Request, and the 'L' bit is not set, but the source
   address in the IPv6 header from does not match the pending server address,
   the client as MUST discard the destination address in message, and SHOULD log the
   servers response packet.  Servers that respond to relay-agents event.

   If the Reply message is acceptable, the client processes each
   Extension [5], extracting the relevant configuration information and
   relay-agent processing
   parameters for its network operation.

   Some configuration information extracted from the Extensions to the
   DHCP Reply message must remain associated with the DHCP server that
   sent the message.  The particular extensions that require this extra
   measure of association with the server are discussed indicated in section 7.

   In the cases where DHCPv6
   Extensions document [5].  These associations may be useful with DHCP
   Release messages.

5.5. DHCP Release Message Processing

   If a DHCPv6 client or server must retransmit messages determines that some of its network configuration
   parameters are no longer valid, it may enable the
   msg-type codes in this section DHCPv6 server to
   release allocated resources which are used as stated no longer in section 4.3 with
   the values that represent use by sending a
   DHCP Release message to the Retrans suffix for server.  The client must consult its list
   of resource-server associations in order to determine which server
   should receive the msg-types.

6.2. Client DISCOVER and CONF-REQUEST Messages

   msg-type: desired Release message.  If the a client does not know wishes to
   ask the server address or wants to locate a new
   server release all information and resources relevent to receive configuration parameters
   the client sets client, the msg-type client specifies no Extensions.

   A client wishes to release resources which were granted to DISCOVER. it at
   another link-local address.  In this case that case, the client MUST use as must instruct
   the destination
   IP address server to send the DHCPv6 Server/Relay-Agent multicast address
   FF02:0:0:0:0:0:1:0.

   If DHCP Reply directly back to the client knows client,
   instead of performing the server address default processing of sending the client sets DHCP
   Reply back through the msg-type agent-address included in the DHCP Release.
   This is done by setting the 'D' bit in the DHCP Release message.

5.6. DHCP Reconfigure Message Processing

      DISCUSSION:    On the one hand, clients REALLY SHOULD listen for
                     Reconfigure messages.  On the other hand, some
                     implementors claim that requiring a client to
   CONF-REQUEST. In this case
                     always listen at a port is asking too much.  This
                     issue needs further discussion.

   If a DHCPv6 client receives a DHCP Reconfigure message, it is
   a request for the client MUST use as to initiate a new DHCP Request/Reply
   transaction with the destination
   IP address server which sent the Reconfigure message.
   The server address.

   msg-flag:

   Set to binary zeroes.

   error-code:

   Set to binary zeroes.

   total-addrs:

   Set to sending the Reconfigure message MAY be different than
   the server which sent a DHCP Reply message containing the original
   configuration information.

   For each Extension which is present in the number of addresses Reconfigure message, the
   client is requesting.

   transaction-ID:

   Set to an integer value.

   interface token:

   Set to appends a unique link dependent identifier for the clients interface.

   server address:

   Set to binary zeroes for DISCOVER.
   Set matching Extension to server address for CONF-REQUEST.

   gateway address:

   Set its DHCP Request message
   which it formulates to binary zeroes.

   client-link address:

   Set send to the clients link-local address for the link on DHCPv6 server which is found in
   the client
   transmitted the packet.

   preferred lifetime:

   Set to binary zeroes if IP source address of the message.  The client is not requesting also selects a lifetime.
   Set to
   transaction-ID numerically greater than its last choice and inserts
   it into the number of seconds Request message.  From then on, processing is the client wants for same as
   specified above in Section 5.3.

6. DHCP Server Considerations

   A server MUST ignore any DHCP Advertise, DHCP Reply, or DHCP
   Reconfigure message it receives.

   A server uses the lifetime.
   Set combination <link-local address, agent address> to all 1's (oxffffffff) if the client wants an infinite lifetime.

   The
   index into its records of client must provide bindings.  A DHCPv6 server should
   retain its client's bindings across server reboots, and, whenever
   possible, a preferred lifetime for each address
   requested.

   valid lifetime:

   Set to binary zeroes if the DHCPv6 client is not requesting a lifetime.
   Set to should be assigned the number same configuration
   parameters despite server host system reboots and DHCPv6 server
   program restarts.  A DHCPv6 server MUST support fixed or permanent
   allocation of seconds configuration parameters to specific hosts.

6.1. DHCP Solicit and Advertise Message Processing

   Upon receiving a DHCP Solicit message from a client, a server
   constructs a DHCP Advertise message and transmits it to the
   soliciting client wants for on the lifetime.
   Set to all 1's (oxffffffff) if same link as the client wants an infinite lifetime. solicitation was received
   from.  The client must provide a valid lifetime for each destination address
   requested.  The valid lifetime must of the advertisement MUST be greater than or equal to the
   preferred lifetime.

   client address:

   Set to binary zeroes if
   source address of the client is not requesting a renewal for an
   existing solicitation.  The DHCP server must use a IPv6
   address of the interface on which it received from a server.
   Set to an the client's DHCP
   Solicit message as the source address field of the client previously received from a server when IPv6 header of the
   client is requesting
   message.

6.2. DHCP Request and Reply Message Processing

   The DHCPv6 server MUST check to ensure that a new set valid link-local
   address is present in the client's link-local address field of lifetimes the
   Request message.  If not, the message MUST be silently discarded.
   Otherwise, it checks for the address.

   A client presence of the 'S' bit.  If the 'S' bit
   is set, the server MUST NOT provide a check that the server with an address that was not given
   to matches the client
   destination IPv6 address at which the Request message was received
   by a the server.  DHCPv6  If the server address does not permit a match, the Request
   message MUST be silently discarded.

   If the message is accepted, the server extracts the client's
   link-local address and the agent address, and uses the information to create
   leases for manual configured addresses,
   locate or update leases for addresses
   created by IPv6 Stateless Address Autoconfiguration.

   options:

   See Options for DHCPv6 specification [DHCPv6-OPT].

6.3. Server CONF-RESPONSE Message

   msg-type:

   Set msg-type to CONF-RESPONSE.

   msg-flag:

   Set create an appropriate client record (called a binding) used
   to 01 if store all the server knows addresses provided are verified to relevant information, resources, and configuration
   data which will be
   unique, otherwise set to binary zeroes.

   error-code:

   Set associated with the client.  Each client record is
   uniquely identifiable by the ordered pair <link-local address, agent
   address>, since the link-local address is guaranteed to 01 if be unique [9]
   on the server cannot provide link identified by the agent address.  If the received agent
   address and link-local address do not correspond to any addresses binding known
   to the client at
   this time.
   Set to 02 if server, then the server detects an address from MAY create a new binding for the client
   previously unknown client; otherwise, it did not
   provide to the client.

   total-addrs:

   Set to SHOULD return a DHCP Reply
   with a error code of 5.

   Before processing the number of addresses Request, the server must determine whether or
   not the Request is returning a retransmission of an earlier DHCP Request from
   the same client.

   transaction-ID:

   Set to  This is done by comparing the value transaction-ID to
   all those transaction-IDs received from the same client provided in during the DISCOVER or CONF-REQUEST
   msg-type.

   interface token:

   Set to a unique link dependent identifier for
   previous TRANSACTION_ID_TIMEOUT seconds.  If the clients interface transaction-ID is
   the same as
   provided in one received during that time, the clients DISCOVER or CONF-REQUEST msg-type. server address:

   The address of MUST take the server responding.

   gateway address:

   Set to
   same action (e.g., retransmit the same value that existed when DHCP Reply to the server received client)
   as it did after processing the packet.

   client-link address:

   Set to previous DHCP Request with the same value that existed
   transaction-ID.

   Otherwise (the transaction-ID has not been recently used), when the
   server received the packet.

   preferred lifetime:

   Set to has identified and allocated all the value requested by relevant information,
   resources, and configuration data that is associated with the client,
   it sends that information to its DHCPv6 client or the value required by constructing a
   DHCP Reply message and including the
   server.

   valid lifetime:

   Set client's information in DHCPv6
   Extensions to the value requested by Reply message.  The DHCP Reply message uses the client or
   same transaction-ID as found in the value required by received DHCP Request message.

   If the
   server.

   The valid lifetime MUST be greater than or equal to DHCP Request message has the preferred
   lifetime.

   client address:

   Set to an address provided by 'S' bit set in the message
   header, the DHCPv6 server if MUST send the client is not attempting corresponding DHCP Reply
   message to renew existing addresses, meaning the agent address fields found in the Request.

   The DHCP Request may contain Extensions, which are interpreted
   as advisory (or mandatory) information from the client
   have a value of binary zeroes.

   If about its
   configuration preferences.  For instance, if the error-code IP Address Extension
   is set to 02 present, the DHCPv6 server will only return SHOULD attempt to allocate or extend
   the addresses
   that lifetime of the server can verify were provided address indicated by the server. Extension.

6.3. DHCP Release Message Processing

   If no addresses
   could be verified the total-addrs field, lifetimes, and client server receives a DHCP Release Message, it MUST verify that a
   valid link-local address
   will be set to binary zeroes.  In is present in the link-local address field
   of the case as far as message.  If not, the server is
   concerned message MUST be silently discarded.

   In response to a DHCP Release Message with a valid link-local
   address, the DHCPv6 transaction is completed and the server will not
   expect formulates a client ACCEPT DHCP Reply message that
   will be sent back to its CONF-RESPONSE message.

   options:

   See Options for DHCPv6 specification [DHCPv6-OPT].

6.4. Client ACCEPT Message

   msg-type:

   Set msg-type to ACCEPT.

   If the releasing client by way of the client's
   link-local address.  A DHCP Reply message sent in response to a DISCOVER DHCP
   Release message MUST be sent to request configuration parameters on the
   link, then the client should use as the IP destination client's link-local address via
   the DHCPv6
   Server/Relay-Agent multicast agent address FF02:0:0:0:0:0:1:0.

   If the client sent a CONF-REQUEST to request configuration parameters on in the link, then Release message and set the client should use as 'L' bit in the IP destination address
   Reply, (unless the server
   address 'D' bit is set in the CONF-RESPONSE from the server. Release message).

   If the client sees an error-code of 02 received agent address and link-local address do not
   correspond to any binding known to the total-addrs field is
   zero, server, then the server cannot process any SHOULD
   return a DHCP Reply with a error code of 5.

   Otherwise, if the addresses requested agent address and the
   client should not send an ACCEPT link-local address indicate a
   binding known to the server.  If server, then the client sees an
   error-code of 02 and total-addrs does not equal zero it means server continues processing
   for the Release message.  If there are any Extensions, the server
   dropped addresses that it could not locate requested by
   releases the client.

   msg-flag:

   Set to binary zeroes.

   error-code:

   Set to binary zeroes.

   total-addrs:

   Set to 1.

   transaction-ID:

   Set to particular configuration items specified in the integer value that
   extensions.  Otherwise, if there are no extensions, the client used on its initial DISCOVER or
   CONF-REQUEST msg-type to server
   releases all configuration information in the server.

   interface token:

   Set to client's binding.

   After performing the unique link dependent identifier for operations indicated in the clients interface
   that was used for DHCP Release
   message and its Extensions, the clients initial DISCOVER or CONF-REQUEST msg-type
   to DHCPv6 server formulates a DHCP
   Reply message, copying the transaction-ID, from the server.

   server address:

   Set to DHCP Release
   message.  For each Extension in the address provided DHCP Release message successfully
   processed by the servers CONF-RESPONSE.

   gateway address:

   Set to binary zeroes.

   client-link address:

   Set server, a matching Extension is appended to the clients link-local address for DHCP
   Reply message.  Extensions in the link on DHCP Release message which cannot
   be successfully processed by the client
   transmitted the packet.

   preferred lifetime:

   Set server MUST NOT correspond to any
   Extension appended to the first or only preferred lifetime returned for an address Reply by the server.

   valid lifetime:

   Set

6.4. DHCP Reconfigure Message Processing

   If a DHCPv6 server needs to change the first or only valid lifetime returned for an address by the
   server. configuration associated
   to any of its clients, it constructs a DHCP Reconfigure message
   and sends it to each such client.  The valid lifetime Reconfigure message MUST
   contain the particular Extensions which inform the client about which
   configuration information needs to be greater than or equal changed.

      DISCUSSION:    Perhaps a DHCPv6 server should be allowed to
                     multicast a DHCP Reconfigure message to its
                     clients.  There are issues to be resolved here.
                     There is concern about encouraging servers to send
                     such messages to any DHCP-wide multicast address.

                     Perhaps a new extension should be defined so that
                     the preferred
   lifetime.

   client address:

   Set server can ask (some of) its clients to join a
                     specific multicast group.  Then the first or only address provided by server could
                     efficiently multicast Reconfigure messages to
                     whatever group it wants.

                     This would have the server. additional advantage that
                     clients could receive Reconfigure messages without
                     listening to any specific UDP port.

                     If multiple clients can receive the same
                     Reconfigure message, some algorithm must be
                     specified so that the clients stagger their
                     responses (i.e., their DHCP Requests) so that
                     the server isn't deluged all at once with some
                     arbitrarily large number of client did receive more than one address and lifetime, it MUST
   store this data in an implementation defined manner, Requests.

7. DHCP Relay Considerations

   The DHCPv6 protocol is constructed so that it can
   issue a complete RELEASE for all addresses provided relay does not have
   to maintain any state in order to facilitate DHCPv6 client/server
   interactions.

   All relays MUST use the IPv6 address of the interface from which the server
   CONF-RESPONSE, if necessary later.  But
   DHCPv6 message is transmitted as the ACCEPT does not need to carry
   all those addresses to acknowledge source address for the servers CONF-RESPONSE packet in
   an ACCEPT.

   options:

   No options are present.

6.5. Server SERVER-ACK IP header
   of that DHCPv6 message.

7.1. DHCP Solicit and DHCP Advertise Message

   msg-type:

   Set msg-type Processing

   Upon receiving a DHCP Solicit message from a client, a relay
   constructs a DHCP Advertise message and transmits it to SERVER-ACK.

   If the
   soliciting client sent the ACCEPT to acknowledge a servers CONF-RESPONSE
   message on the DHCPv6 Server/Relay-Agent multicast same link as the solicitation was received
   from.  The destination address
   FF02:0:0:0:0:0:1:0, of the server advertisement MUST look at be the server
   source address in the
   packet to determine if of the ACCEPT is for them or not. solicitation.

      DISCUSSION:    If the message is not for a particular server then this Solicit is an indirect
   message delivered to that particular a server and
                     the client is not accepting them as
   their server for this transaction, and MUST NOT send a SERVER-ACK is allowed to send the
   clients ACCEPT.

   msg-flag:

   Set to binary zeroes.

   error-code:

   Set to binary zeroes.

   total-addrs:

   Set to 1.

   transaction-ID:

   Set corresponding
                     Advertise back to a client, the integer value that the client used on its initial DISCOVER or
   CONF-REQUEST msg-type server could then
                     include some prospective information to the server.

   interface token:

   Set "entice" a
                     client to use its services.  For instance, a server
                     could include proposed lifetime information, and a
                     client could pick the unique link dependent identifier for server with the clients interface best "terms".
                     Presumably, this forwarding behavior should be a
                     matter of relay configuration instead of client
                     request.  I'll assume that was used for the clients initial DISCOVER or CONF-REQUEST msg-type now and try to make
                     the server.

   server address:

   Set to protocol reflect the servers address.

   gateway address:

   Set ability of DHCP Advertise
                     messages to contain Extensions and come from DHCP
                     servers off-link.  That may take a little more
                     doing which isn't in the same value that existed when the protocol right now, be
                     patient.

   When transmitting a DHCP Advertise message, a relay indicates how
   many server received the packet.

   client-link address:

   Set addresses which it was configured to advertise, and
   includes each address in the same value that existed when the server received DHCP Advertise message.  The DHCP
   Advertise message must use a routeable IPv6 address in the packet.

   preferred lifetime:

   Set to source
   address of the value provided by IPv6 header of the client.

   valid lifetime:

   Set to message.  In particular, the value provided source
   address of any DHCP Advertise message sent by the client.

   The valid lifetime a DHCPv6 relay MUST NOT
   be greater than or equal to a link-local address.

7.2. DHCP Request Message Processing

   When a relay receives a DHCP Request message, it MUST check that the preferred
   lifetime.

   client address:

   Set to
   message is received from a link-local address, that the link-local
   address provided by the client.

   At this point the server MUST commit matches the configuration parameters
   provided to link-local address field in the client from Request message
   header, and that the servers CONF-RESPONSE.

   options:

   No options are present.

6.6. Client RELEASE Message

   msg-type:

   Set msg-type to RELEASE.

   If agent address field of the client had sent message matches an ACCEPT
   IPv6 address associated to the server and received a SERVER-ACK
   for that message then interface from which the client DHCP Request
   message was received.  The relay MUST commit the configuration
   parameters provided by also check whether the servers CONF-RESPONSE and a RELEASE message 'S'
   bit is not required.  But if the client did not receive a SERVER-ACK set in response to the clients ACCEPT, then message header.  If any of these checks fail, the client
   message is not acceptable and MUST issue a RELEASE
   to the server. be silently discarded.

   If the client no longer needs an address or has been notified to return
   an address to received request message is acceptable, the server, relay then
   transmits the client SHOULD issue a RELEASE DHCP Request message to the
   server.

   msg-flag:

   Set to binary zeroes.

   error-code:

   Set to binary zeroes.

   total-addrs:

   Set to DHCPv6 server found in the total number
   Server Address field of addresses the client is releasing.  In the
   case received DHCP Request message.  All of a RELEASE where the client did not receive the SERVER-ACK this
   value MUST equal
   the total number fields of addresses for the servers
   CONF-RESPONSE.

   transaction-ID:

   Set to the integer value that the client used on its initial DISCOVER or
   CONF-REQUEST msg-type to DHCP Request message header transmitted by the server.

   interface token:

   Set to relay
   are copied over unchanged from the unique link dependent identifier for DHCP Request received from the clients interface
   that was used for
   client.  Only the clients initial DISCOVER or CONF-REQUEST msg-type
   to fields in the server.

   server address:

   Set to binary zeroes.

   gateway address:

   Set to binary zeroes.

   client-link address:

   Set to IPv6 header will differ from the clients link-local address for
   datagram received from the link on which client, not the client
   transmitted payload.

7.3. DHCP Reply Message Processing

   When the packet.

   preferred lifetime:

   Set to relay receives a DHCP Reply, it MUST check whether the valid lifetime returned for an address by
   message has the server.

   valid lifetime:

   Set to 'L' bit set.  It must check whether the valid lifetime returned for link-local
   address field contains an IPv6 address by that has prefix FE80::00 .
   If all the server.

   The valid lifetime MUST be greater than or equal to checks are satisfied, the preferred
   lifetime.

   client address:

   Set relay MUST send a DHCP Reply
   message to the link-local address provided by listed in the server.

   The client will return received Reply
   message.  Only the number of addresses and associated lifetimes
   provided fields in the servers CONF-RESPONSE.

   options:

   No options are present.

7. Relay-Agent Processing

   The relay-agent MUST use UDP DHCPv6 Server Port 547 as IPv6 header will differ from the UDP port to
   accept client responses in an implementation.

   The relay-agent MUST join
   datagram received from the DHCP Server/Relay-Agent multicast group
   well-known multicast address FF02:0:0:0:0:0:1:0. server, not the payload.

7.4. Retransmission and Configuation Variables

   When a DHCPv6 Relay-Agent hears a request from client does not receive a DHCPv6 Client it MUST:

      If the gateway address is NOT zero then the relay-agent MUST:

         Put the relay-agents IP address DHCP Reply in response to a
   pending DHCP Request, the gateway address field of
         the clients request packet.

   All relay-agents MUST:

      Put their relay-agent address as client MUST retransmit the source address for identical DHCP
   Request to the IP
      header.

      Put same server again until it can be reasonably sure that
   the next relay-agent or known DHCPv6 server address as is unavailable and an alternative can be chosen.
   It is important for the
      destination address in DHCP Server to be sure that its client has
   received the IP header.

      Forward configuration information included with the packet Extensions
   to the DHCP Reply message.

   Likewise, but less commonly, when a DHCP server does not receive a
   DHCP Request message in response to its DHCP Reconfigure message to
   the next hop relay-agent or
      known server.

   When client, the remote server receives MUST retransmit the client request from identical DHCP Reconfigure
   to the relay-agent
   it will know its a remote client request (not on the servers link),
   because there until it is a gateway address in the request.  So servers MUST
   verify reasonably certain that the gateway address client is not zero, to determine if the clients request
   available for reconfiguration.  If no corresponding DHCP Request
   is ever received by the server, the server MAY erase or deallocate
   information as needed from the client's binding.

   These retransmissions occur using the following configuration
   variables for a remote link.

   The DHCPv6 implementation that MUST be configurable by a
   client or server responds are as specified follows:

      REPLY_MSG_INITIAL_TIMEOUT

         The time in section 6.0, but uses seconds that a DHCPv6 client waits to receive a
         server's DHCP Reply before retransmitting a DHCP Request.

         Default:  2 seconds.

      REPLY_MSG_MIN_RETRANS

         The minimum number of DHCP Request transmissions that a DHCPv6
         client should retransmit, before aborting the
   gateway address as request, possibly
         retrying the destination address Request with another Server, and logging DHCPv6
         System Error.

         Default:  10 retransmissions.

      RECONF_MSG_INITIAL_TIMEOUT

         The time in the IP header.

   When the relay-agent receives the remote servers response, it MUST
   forward the packet seconds that a DHCPv6 server waits to receive
         a client's DHCP Request before retransmitting its DHCP
         Reconfigure.

         Default:  2 seconds.

      RECONF_MSG_MIN_RETRANS

         The minimum number of DHCP Reconfigure messages that a DHCPv6
         server should retransmit, before assuming the client, by using the client-link address as the source address for client is
         unavailable and that the IP Header.

8. Security Considerations

Security for DHCPv6 server can be used as specified in [IPv6-SA], [IPv6-AUTH], proceed with the needed
         reconfiguration of that client's resources, and [IPv6-ESP], which are implementation requirements for IPv6.

Appendix A - Related Work in IPv6 logging DHCPv6
         System Error.

         Default:  10 retransmissions.

   The related work following parameter specifies how long a DHCPv6 server has to
   keep track of client transaction-IDs in IPv6 that would best serve an implementor order to study
   is the IPv6 Specification [IPv6-SPEC], make sure that
   client retransmissions using the IPv6 Addressing Architecture
   [IPv6-ADDR], IPv6 Stateless Address Autoconfiguration [IPv6-ADDRCONF],
   IPv6 Neighbor Discovery Processing [IPv6-ND], same transaction-ID are idempotent.

      TRANSACTION_IT_TIMEOUT

         Default:  10800 seconds

8. Security Considerations

   It may often be very important for DHCP clients and Dynamic Updates servers to DNS
   [DYN-UPD].  These specifications afford DHCPv6 be
   able to build upon authenticate the IPv6
   work messages they exchange.  For instance, a
   DHCP server may wish to provide both robust stateful autoconfiguration and
   autoregistration of DNS Host Names.

   The IPv6 Specification provides be certain that a DHCP Request originated
   from the base architecture and design of
   IPv6.  A key point client identified by the <link-local address, agent address>
   fields included within the Request message header.  Conversely,
   it is often essential for DHCPv6 implementors a DHCP client to understand is that IPv6
   requires be certain that every link in the internet have
   configuration parameters and addresses it has received were sent to
   it by an MTU authoritative DHCP server.  Similarly, a DHCP server should
   only accept a DHCP Release message which seems to be from one of 576 octets or
   greater (in IPv4
   its clients, if it has some assurance that the requirement client actually did
   transmit the Release message.  At the time of this writing, there
   is 68 octets).  This means no generally accepted mechanism useful with DHCPv4 that a
   UDP datagram of 536 octets will always pass through an internet (less 40
   octets can be
   extended for use with DHCPv6.

   There has been some discussion about the advisability and
   desirability of using IPv6 header), as long as there are no IP options prior Authentication to
   the UDP datagram in the packet. But, IPv6 does not support
   fragmentation at routers allow DHCPv6 clients
   and servers to authenticate messages which they exchange.  However,
   in many circumstances a client has only a link-local address, and fragmentation must take place end-to-end
   between hosts.  If a DHCPv6 implementation needs
   link-local address cannot be forwarded to send a packet
   greater than 536 octets it can either fragment server which is off-link.
   Thus, the UDP datagram in UDP
   or use Path MTU Discovery [IPv6-SPEC] to determine DHCP relay _has_to be involved, for instance, with the size of DHCP
   Request when the
   packet that will traverse client has only a network path.  It is implementation defined
   how link-local address, and therefore
   the DHCP Request (in this is accomplished in DHCPv6.

   The IPv6 Addressing Architecture Specification provides circumstance) MUST have the relay's address
   scope that can be used
   in an IPv6 implementation, and the various
   configuration architecture guidelines for network designers of the IPv6 destination address space. Two advantages of IPv6 is field.

   That means that multicast addressing is well
   defined and nodes can create link-local addresses during initialization
   of the nodes environment.  This authentication (in this circumstance) CANNOT be
   end-to-end.  That means that IPsec cannot apply.  Thus, in order to
   authenticate DHCP Request messages in many circumstances will require
   a host immediately can configure
   an IPv6 address at initialization more specialized technique for an interface, before communicating message authentication, as specified
   in
   any manner on the link.  The host can then use a well-known multicast address DHCPv6 Extensions companion document [5].

   One possibility is to begin communications allow relays to discover neighbors on encapsulate the link, or DHCP Request
   before delivery to the server.  Then the client could apply
   end-to-end authentication (such as was
   discussed in afforded by IPSec) which would
   nevertheless remain untouched by the specification relay.  The relay could, if
   desired, apply its own authentication header to the encapsulated
   datagrams.

9. Acknowledgements

   Thanks to the DHC Working Group for their time and input into the
   specification.  A special thanks for the consistent input, ideas,
   and review by (in alphabetical order) Brian Carpenter, Ralph Droms,
   Thomas Narten, Jack McCann, Yakov Rekhter, Matt Thomas, Sue Thomson,
   and Phil Wells.

   Thanks to locate a DHCPv6 server or relay-agent.

   The IPv6 Stateless Address Autoconfiguration Specification (addrconf)
   defines how a host can autoconfigure addresses based on neighbor discovery
   router advertisements, Steve Deering and Bob Hinden, who have consistently
   taken the use of a validation lifetime time to support
   renumbering of addresses on the Internet. In addition discuss the addrconf
   specification defines more complex parts of the protocol interaction IPv6
   specifications.

   The authors MUST also thank their employers for a host to begin stateless
   or stateful autoconfiguration.  DHCPv6 is one vehicle the opportunity and
   funding to perform stateful
   autoconfiguration.  Compatibility with addrconf is a design goal of work on DHCPv6
   where possible. and IPv6 Neighbor Discovery (ND) is in general as an individual in the node discovery protocol
   IETF.

A. Related Work in IPv6
   (replaces and enhances functions of IPv4 ARP Model).  To truly
   understand

   The related work in IPv6 and addrconf it is strongly recommended that
   implementors understand would best serve an implementor
   to study is the IPv6 ND. Specification [2], the IPv6 Addressing
   Architecture [3], IPv6 Stateless Address Autoconfiguration [9], IPv6
   Neighbor Discovery Processing [4], and Dynamic Updates to DNS is a specification that supports the
   dynamic update of DNS records for both IPv4 and IPv6. [10].
   These specifications afford DHCPv6 can use
   the dynamic updates to DNS build upon the IPv6 work to now integrate addresses
   provide both robust stateful autoconfiguration and name space to
   not only support autoconfiguration, but also autoregistration in IPv6.

Change History

   Changes from July 95 to November 95 Drafts:

      Refined request/response codes and processing to support transaction
      processing model.

      Permit multiple addresses and lifetimes in a request and response.

      Moved Dynamic Updates to
   of DNS as an Option Host Names.

   The IPv6 Specification provides the base architecture and design of
   IPv6.  A key point for DHCPv6 implementors to be defined understand is that IPv6
   requires that every link in the internet have an MTU of 576 octets or
   greater (in IPv4 the requirement is 68 octets).  This means that
      specification.

      Settled on using a
   UDP datagram of 536 octets will always pass through an internet (less
   40 octets for the IPv6 header), as it supports DHCP client server model long as opposed
      to TCP which has overhead for this model.

      Reformatted specification there are no IP options
   prior to the UDP header in the datagram.  But, IPv6 does not support analysis, packet formats,
   fragmentation at routers and
      processing in their own sections fragmentation must take place end-to-end
   between hosts.  If a DHCPv6 implementation needs to make send a datagram
   greater than 536 octets it easier for implementors can either fragment the UDP datagram
   in UDP or use Path MTU Discovery [2] to
      read.

      Removed address count as it determine the size of the
   datagram that will traverse a network path.  It is not necessary for synchronization.

      Added error-code, msg-flag, and total-addrs fields.

      Made transaction-ID 2 octets.

      Updated terminology to coordinate with IPv6 Stateless Address
      Autoconfiguration.

      Added more implementation notes.

      Moved IPv6 Related Work to an Appendix.

      Fixed various bugs
   defined how this is accomplished in DHCPv6.

   The IPv6 Addressing Architecture Specification provides the spec from DHC WG input.

      Added Security reference pointers.

      Removed options format, which will address
   scope that can be used in an IPv6 implementation, and the options spec.

      Added retransmission various
   configuration variables, msg-types, and logic.

   Changes from March 95 to July 95 Drafts:

      Used integer values instead of bit values architecture guidelines for type and code fields.

      Used message-type and message-code fields network designers of
   the IPv6 address space.  Two advantages of IPv6 is that multicast
   addressing is well defined and rely on looking at nodes can create link-local addresses
   during initialization of the fields nodes environment.  This means that a
   host immediately can configure an IPv6 address at initialization
   for an interface, before communicating in any manner on the datagram instead of multiple over-lapping
      request/response codes.

      Added address-count field processing link.
   The host can then use a well-known multicast address to be specified by the
      client as opposed begin
   communications to discover neighbors on the server, and the processing for when
      client and server address-counts become disjoint.

      Added Requirements wording for MUST, SHOULD, MAY, etc.

      Added Design Goals section.

      Redefined transaction-ID and interface-token.

      Added Client/Server Binding definition and processing
      section to handle those bindings.

      Added more terminology, definitions, and rationale.

      Added model to support Dynamic Updates to DNS for Host Names.

      Reduced link, or as was discussed
   in the request/response model specification to 3 packets by not doing locate a DHCPv6 server confirm to a clients confirm to a servers response.

      Added model to support like lifetime fields for lease
      management to coordinate with or relay.

   The IPv6 Stateless Address
      Autoconfiguration.

      Added model and processing definitions for future DHCPv6 Options
      Specification.

      Added gateway-address Autoconfiguration Specification [9]
   defines how a host can autoconfigure addresses based on neighbor
   discovery router advertisements, and client-link-address for relay-agent
      processing.

      Removed excessive the use of a validation lifetime
   to support renumbering of addresses on the acronym DHCPv6 for section titles
      and when referencing clients and servers.

      Added Draft ***Open Issues*** Section for review by Internet.  In addition the DHC Working
      Group.

      Added Change History.

Acknowledgements

   The DHC Working Group for their time and input into
   addrconf specification defines the specification.
   A special thanks protocol interaction for the consistent input, ideas, and review by (in
   alphabetical order) Brian Carpenter, Ralph Droms, Thomas Narten, Jack
   Mccann, Charlie Perkins, Yakov Rekhter, Matt Thomas, Sue Thomson, and
   Phil Wells.

   The author would also like a host to thank Steve Deering and Bob Hinden,
   who have consistently taken
   begin stateless or stateful autoconfiguration.  DHCPv6 is one vehicle
   to perform stateful autoconfiguration.  Compatibility with addrconf
   is a design goal of DHCPv6.

   IPv6 Neighbor Discovery (ND) [4] is the time node discovery protocol in
   IPv6 (replaces and enhances functions of IPv4 ARP Model [6]).  To
   truly understand IPv6 and addrconf it is strongly recommended that
   implementors understand IPv6 ND.

   Dynamic Updates to discuss DNS [10] is a specification that supports the more complex
   parts
   dynamic update of DNS records for both IPv4 and IPv6.  DHCPv6 can use
   the IPv6 specifications.

   The author MUST dynamic updates to DNS to now integrate addresses and name space
   to not only support autoconfiguration, but also thank his employer autoregistration in
   IPv6.

B. Change History

B.1. Changes from November 95 to February 96 Drafts

   Substituted use of client's link-local address for previous uses of
   client's interface token.

   Reorganized DHCP messages into Solicit/Advertise, Request/Reply,
   Release, and Reconfigure.

   Made message-specific formats instead of using the opportunity same DHCP header
   for each message.

   Eliminated retransmission message types.

   Server commits after receiving DHCP Request, and funding
   to work optimistically
   depends on DHCPv6 client retransmissions as negative acknowledgement.

   Eliminated total-addrs.

   Eliminated all definitions and most fields related to allocating IPv6 in general as an individual in
   addresses (moved to the IETF. Extensions specification).

   Renamed "gateway address" to be "agent address".

References

   [DHCPv6-OPT]
       C. Perkins, "Options

    [1] S. Bradner and A. Mankin.  The Recommendation for the Dynamic Host Configuration
       Protocol for IPv6 (ODHCPv6)" Internet Draft, November 1995
       <draft TBD>

   [IPv6-SPEC] IP Next
        Generation Protocol.  RFC 1752, January 1995.

    [2] S. Deering and R. Hinden, "Internet Protocol Hinden.  Internet Protocol, Version 6
       [IPv6] Specification" Internet Draft, June 1995
       <draft-ietf-ipngwg-ipv6-spec-02.txt>

   [IPv6-ADDR] (IPv6)
        Specification.  RFC 1883, December 1995.

    [3] R. Hinden, Hinden and S. Deering, Editors, "IP Deering.  IP Version 6 Addressing Architecture"
       <draft-ietf-ipngwg-ipv6-addr-arch-03.txt>

   [IPv6-ADDRCONF]
       S. Thomson, T. Narten, "IPv6 Stateless Address Autoconfiguration"
       <draft-ietf-addrconf-ipv6-auto-05.txt>

   [IPv6-ND] Architecture.
        RFC 1883, December 1995.

    [4] T. Narten, E. Nordmark, and W. A. Simpson, "IPv6 Simpson.  IPv6 Neighbor Discovery"
       <draft-ietf-ipngwg-discovery-02.txt>

   [IPv6-DNS]
       S. Thompson and
        Discovery.  draft-ietf-ipngwg-discovery-03.txt -- work in
        progress, November 1995.

    [5] C. Huitema, "DNS Perkins.  Extensions to support IP
       version 6", DHCPv6.  draft-ietf-dhc-dhcpv6ext-00.txt
        -- work in progress, November 1995.

    [6] David C. Plummer.  An Ethernet Address Resolution Protocol:
        Or Converting Network Protocol Addresses to 48.bit Ethernet
        Addresses for Transmission on Ethernet Hardware.  RFC 826,
        November 1982.

    [7] J. B. Postel.  User Datagram Protocol.  RFC 768, August 1980.

    [8] J. B. Postel, editor.  Internet Draft, March 1995
       <draft-ietf-ipngwg-dns-00.txt>

   [RFC-1034]
       P. Mockapetris, "Domain Names - implementation Protocol.  RFC 791, September
        1981.

    [9] S. Thomson and specification"
       STD-13, 11/01/87
   [RFC-1035]
       P. Mockapetris, "Domain Names T. Narten.  IPv6 Stateless Address
        Autoconfiguration.  draft-ietf-addrconf-ipv6-auto-06.txt
        - concepts and facilities"
       STD-13, 11/01/87

   [DYN-UPD] work in progress, November 1995.

   [10] S. Thomson, Y. Rekhter, and J. Bound, "Dynamic Bound.  Dynamic Updates in the
        Domain Name System (DNS)" Internet Draft, March 1995
       <draft-ietf-dnsind-dynDNS-01.txt>

   [RFC-768]
       J. Postel, "User Datagram Protocol"
       STD-6, 08/28/80.

   [DHCP-v4]
       R. Droms, "Dynamic Host Configuration Protocol"
       RFC 1541 Proposed Standard, October 1993

   [IPv6-Ether]
       M. Crawford, "A Method for the Transmission of IPv6 Packets over
       Ethernet Networks", Internet Draft, October 1995
       <draft-ietf-ipngwg-ethernet-ntwrks-01.txt>

   [IPv6-SA]
       R. Atkinson, "Security Architecture for (DNS).  draft-ietf-dnsind-dynDNS-06.txt --
        work in progress, February 1996.

Chair's Address

   The working group can be contacted via the Internet Protocol"
       RFC 1825, August 1995

   [IPv6-AUTH]
       R. Atkinson, "IP Authentication Header"
       RFC 1826, August 1995

   [IPv6-ESP]
       R. Atkinson, "IP Encapsulating Security Payload (ESP)"
       RFC 1827, August 1995

Authors' current chair:

   Ralph Droms
   Computer Science Department
   323 Dana Engineering
   Bucknell University
   Lewisburg, PA 17837

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

Author's Address

   Questions about this memo can be directed to:

   Jim Bound                            Charles Perkins
   Digital Equipment Corporation        T. J. Watson Research Center
   110 Spitbrook Road, ZKO3-3/U14       IBM Corporation
   Nashua, NH 03062                     30 Saw Mill River Rd., Rm J1-A25
                                        Hawthorne, NY  10532
   Phone: (603) 881-0400
    Email: +1-603-881-0400               +1-914-784-7350
   Fax:                                 +1-914-784-6205
   E-mail: bound@zk3.dec.com            perk@watson.ibm.com