Internet Engineering Task Force                                 J. Bound
INTERNET DRAFT                                     Compaq Computer Corp.
DHC Working Group                                              M. Carney
Obsoletes:  draft-ietf-dhc-dhcpv6-14.txt  draft-ietf-dhc-dhcpv6-15.txt           Sun Microsystems, Inc
                                                              C. Perkins
                                                   Nokia Research Center
                                                              5 May
                                                           R. Droms(ed.)
                                                           Cisco Systems
                                                        22 November 2000

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

Status of This Memo

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

   Distribution of this memo is unlimited.

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

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

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

Abstract

   The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables
   DHCP servers to pass configuration parameters using extensions such as IPv6 network
   addresses to IPv6 nodes.  It offers the capability of automatic
   allocation of reusable network addresses and additional configuration
   flexibility.  This protocol is a stateful counterpart to ``IPv6
   Stateless Address Autoconfiguration'' [15], [14], and can be used
   separately or concurrently with the latter to obtain configuration
   parameters.

                                Contents

Status of This Memo                                                    i

Abstract                                                               i

 1. Introduction                                                       1

 2. Terminology                                                        2
     2.1. IPv6 Terminology  . . . . . . . . . . . . . . . . . . . .    2
     2.2. DHCP Terminology  . . . . . . . . . . . . . . . . . . . .    3

 3. DHCP Constants                                                     5                                                     4
     3.1. Multicast Addresses . . . . . . . . . . . . . . . . . . .    5
     3.2. UDP ports . . . . . . . . . . . . . . . . . . . . . . . .    5
     3.3. DHCP message types  . . . . . . . . . . . . . . . . . . .    6    5
     3.4. Error Values  . . . . . . . . . . . . . . . . . . . . . .    8    7
           3.4.1. Generic Error Values  . . . . . . . . . . . . . .    8    7
           3.4.2. Server-specific Error Values  . . . . . . . . . .    8    7
     3.5. Configuration Variables . . . . . . . . . . . . . . . . .    8

 4. Requirements                                                       9                                                       8

 5. Background                                                         9

 6. Design Goals                                                      11                                                      10

 7. Non-Goals                                                         11

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

 9. Message Formats                                                   15 and Identity Associations                         14
     9.1. DHCP Solicit Message Format . . . . . . . . . . . . . . .   15   14
     9.2. DHCP Advertise Message Format . . . . . . . . . . . . . .   16   15
     9.3. DHCP Request Message Format . . . . . . . . . . . . . . .   18   16
     9.4. DHCP Reply Message Format . . . . . . . . . . . . . . . .   19   17
     9.5. DHCP Release Message Format . . . . . . . . . . . . . . .   20   18
     9.6. DHCP Reconfigure Message Format . . . . . . . . . . . . .   22   18
     9.7. DHCP Reconfigure-reply Message Format . . . . . . . . . .   23   18
     9.8. DHCP Reconfigure-init Message Format  . . . . . . . . . .   24   19
     9.9. Relay-forward message . . . . . . . . . . . . . . . . . .   20
    9.10. Server-forward message  . . . . . . . . . . . . . . . . .   20
    9.11. Identity association  . . . . . . . . . . . . . . . . . .   21

10. DHCP Server Solicitation and Subnet Prefix Discovery              25                                          21
    10.1. Solicit Message Validation  . . . . . . . . . . . . . . .   25   21
    10.2. Advertise Message Validation  . . . . . . . . . . . . . .   25   21
    10.3. Client Behavior . . . . . . . . . . . . . . . . . . . . .   26   22
          10.3.1. Creation and sending of the Solicit message . . .   26   22
          10.3.2. Time out and retransmission of Solicit Messages .   27   22
          10.3.3. Receipt of Advertise messages . . . . . . . . . .   27   23
    10.4. Relay Behavior  . . . . . . . . . . . . . . . . . . . . .   28   23
          10.4.1. Relaying of Solicit messages  . . . . . . . . . .   28   23
          10.4.2. Relaying of Advertise messages  . . . . . . . . .   28   24
    10.5. Server Behavior . . . . . . . . . . . . . . . . . . . . .   28   24
          10.5.1. Receipt of Solicit messages . . . . . . . . . . .   28   24
          10.5.2. Creation and sending of Advertise messages  . . .   29   24

11. DHCP Client-Initiated Configuration Exchange                      29                      25
    11.1. Request Message Validation  . . . . . . . . . . . . . . .   29   25
    11.2. Reply Message Validation  . . . . . . . . . . . . . . . .   30   26
    11.3. Release Message Validation  . . . . . . . . . . . . . . .   31   26
    11.4. Client Behavior . . . . . . . . . . . . . . . . . . . . .   31   26
          11.4.1. Creation and sending of Request messages  . . . .   32   27
          11.4.2. Time out and retransmission of Request Messages .   33   27
          11.4.3. Receipt of Reply message in response to a Request   33   28
          11.4.4. Creation and sending of Release messages  . . . .   33   28
          11.4.5. Time out and retransmission of Release Messages .   34   29
          11.4.6. Receipt of Reply message in response to a Release   35   29
          11.4.7. When a client should send a Request message . . .   29
          11.4.8. Initialization  . . . . . . . . . . . . . . . . .   29
          11.4.9. Confirming the validity of IPv6 addresses . . . .   29
         11.4.10. Extending the lifetimes on IPv6 addresses . . . .   30
    11.5. Relay Behavior  . . . . . . . . . . . . . . . . . . . . .   35   31
          11.5.1. Relaying of Request or Release messages . . . . .   35   31
    11.6. Server Behavior . . . . . . . . . . . . . . . . . . . . .   35   31
          11.6.1. Receipt of Request messages . . . . . . . . . . .   35   31
          11.6.2. Receipt of Release messages . . . . . . . . . . .   36   31
          11.6.3. Creation and sending of Reply messages  . . . . .   36   32

12. DHCP Server-Initiated Configuration Exchange                      37                      33
    12.1. Reconfigure Message Validation  . . . . . . . . . . . . .   37   33
    12.2. Reconfigure-reply Message Validation  . . . . . . . . . .   38   33
    12.3. Reconfigure-init Message Validation . . . . . . . . . . .   38   33
    12.4. Server Behavior . . . . . . . . . . . . . . . . . . . . .   38   33
          12.4.1. Creation and sending of Reconfigure messages  . .   39   34
          12.4.2. Time out and retransmission of Reconfigure
                          messages . . . . . . . . . . . . . . . . .  40  34
          12.4.3. Receipt of Reconfigure-reply messages . . . . . .   40   34
          12.4.4. Creation and sending of Reconfigure-init messages   40   34
          12.4.5. Time out and retransmission of Reconfigure-init
                          messages . . . . . . . . . . . . . . . . .  41  35
          12.4.6. Receipt of Request messages . . . . . . . . . . .   41   35
    12.5. Client Behavior . . . . . . . . . . . . . . . . . . . . .   41   35
          12.5.1. Receipt of Reconfigure messages . . . . . . . . .   42
          12.5.2. Creation and sending of Reconfigure-reply messages  42
          12.5.3. Receipt of Reconfigure-init messages  . . . . . .   43
          12.5.4.   35
          12.5.2. Creation and sending of Request messages  . . . .   43
          12.5.5.   36
          12.5.3. Time out and retransmission of Request messages .   43
          12.5.6.   36
          12.5.4. Receipt of Reply messages . . . . . . . . . . . .   43   36

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

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

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

16. DHCP Relay Implementator Implementor Notes                                    47                                      39

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

18. Security Considerations                                           48

19. Year 2000 considerations                                          49

20. IANA Considerations                                               49

21. Acknowledgements                                                  50

 A. Comparison between DHCPv4 and DHCPv6                              50

 B. Full Copyright Statement                                          52

Chair's Address                                                       55

Author's Address                                                      55

1. Introduction

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

   The DHCP reduces the cost . . . . . . . . . . . .   40
    17.5. Use of ownership by centralizing the management term ``agent'' . . . . . . . . . . . . . . . . . .   40
    17.6. Use of network resources such as IP addresses, routing information, OS
   installation information, directory service information, terms ``subnet'' and other
   such information on a few DHCP servers, rather than distributing such
   information in local configuration files among each network node.
   The DHCP is designed to be easily extended to carry new configuration
   parameters through the addition of new ``network'' . . . . . . . . .   40

18. Security                                                          40

19. Year 2000 considerations                                          41

20. IANA Considerations                                               41

21. Acknowledgments                                                   41

22. DHCP ``extensions'' defined to
   carry this information.  See this document's companion specification,
   ``Extensions for the Dynamic Host Configuration Protocol for
   IPv6'' [2] for specifications options                                                      42
    22.1. Format of existing extensions as well as
   information on the process by which an interested party might specify
   new extensions.

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

   This document is organized as follows.  Section 2 defines terminology
   used throughout this document.  Section 3 defines constant values
   used by DHCP. Section 4 briefly discusses requirement levels.
   Section 5 points the reader to helpful background specifications
   covering related IPv6 protocols.  Section 6 discusses the design
   goals that influenced DHCP. Section 7 identifies some of the
   non-goals of this specification.  Section 8 gives a high level
   overview of DHCP, its options  . . . . . . . . . . . . . . . . .   42
    22.2. Identity association option . . . . . . . . . . . . . . .   43
    22.3. Option request option . . . . . . . . . . . . . . . . . .   44
    22.4. Client message types, and identifies DHCP functional
   entities (client, relay, server).  Section 9 describes option . . . . . . . . . . . . . . . . . .   45
    22.5. Server message option . . . . . . . . . . . . . . . . . .   45
    22.6. Retransmission parameter option . . . . . . . . . . . . .   46
    22.7. Authentication option . . . . . . . . . . . . . . . . . .   46

23. Changes in detail the
   format this draft                                             46
    23.1. Order of each DHCP message type.  Section 10 discusses DHCP server
   solicitation and subnet prefix discovery.  Section 11 discusses DHCP
   client-initiated configuration information exchange.  Section 12
   discusses DHCP server-initiated configuration information exchange.
   Section 13 describes how DHCP can be used to renumber networks.
   Section 14 presents helpful notes for DHCP client implementators.
   Section 15 presents helpful notes for DHCP server implementors.

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

2.1. IPv6 Terminology

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

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

      unicast address
                 An identifier for a single interface.  A packet sent
                 to a unicast address is delivered to the interface
                 identified by that address.

      multicast address
                 An identifier for a set of interfaces (typically
                 belonging to different nodes).  A packet sent to a
                 multicast address is delivered to all interfaces
                 identified by that address.

      host       Any node that is not a router.

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

      interface
                 A node's attachment to a link.

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

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

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

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

      neighbor   A node attached to the same link.

      node       A device that implements IP.

      packet     An IP header plus payload.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   The DHCP makes use of the following multicast addresses:

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

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

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

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

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

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

      01 DHCP Solicit

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

         Section 9.1 contains more details about the Solicit message.

      02 DHCP Advertise

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

         Section 9.2 contains more details about the Advertise message.

      03 DHCP Request

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

         Section 9.3 contains more details about the Request message.

      04 DHCP Reply

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

         Section 9.4 contains more details about the Reply message.

      05 DHCP Release

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

         Section 9.5 contains more details about the Release message.

      06 DHCP Reconfigure

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

         Section 9.6 contains more details about the Reconfigure
         message.

      07 DHCP Reconfigure-reply

         The DHCP Reconfigure-reply (or Reconfigure-reply) message is
         unicast by client(s) to the server to acknowledge the receipt
         of a Reconfigure message.

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

      08 DHCP Reconfigure-init

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

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

3.4. Error Values

   This section describes error values exchanged between DHCP
   implementations.
3.4.1. Generic Error Values

   The following symbolic names are used between client and server
   implementations to convey error conditions.  The following table
   contains the actual numeric values for each name.  Note that the
   numeric values do not start at 1, nor are they consecutive.  The
   errors are organized in logical groups.

   _______________________________________________________________
   |_Error_Name___|Error_ID_|Description__________________________|
   |_Success______|00_______|Success______________________________|
   |_UnspecFail___|16_______|Failure,_reason_unspecified__________|
   |_AuthFailed___|17_______|Authentication_failed_or_nonexistent_|
   |_PoorlyFormed_|18_______|Poorly_formed_message________________|
   |_Unavail______|19_______|Resources_unavailable________________|

3.4.2. Server-specific Error Values

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

3.5. Configuration Variables

   This section presents a table of client and server configuration
   variables and the default or initial values for these variables.  The
   client-specific variables MAY be configured on the server and MAY be
   delivered to the client through the ``DHCP Retransmission Parameter
   Extension''carried in a Reply message.  This extension is documented
   in the ``extensions document'' [2].

   ______________________________________________________________
   |_Parameter__________|Default_|Description____________________|
   |_MIN_SOL_DELAY______|1_______|MIN_(secs)_to_delay_1st_mesg___|
   |_MAX_SOL_DELAY______|5_______|MAX_(secs)_to_delay_1st_mesg___|
   |_ADV_MSG_TIMEOUT____|500_____|SOL_Retrans_timer_(msecs)______|
   |_ADV_MSG_MAX________|30______|MAX_timer_value_(secs)_________|
   |_SOL_MAX_ATTEMPTS___|-1______|MAX_attempts_(-1_=_infinite)___|
   |_REP_MSG_TIMEOUT____|250_____|REQ_Retrans_timer_(msecs)______|
   |_REQ_MSG_ATTEMPTS___|10______|MAX_Request_attempts___________|
   |_REL_MSG_ATTEMPTS___|5_______|MAX_Release_attempts___________|
   |_RECREP_MSG_TIMEOUT_|2000____|Retrans_timer_(msecs)__________|
   |_REC_MSG_ATTEMPTS___|10______|Reconfigure_attempts___________|
   |_REC_REP_MIN________|5_______|Minimum_pause_interval_(secs)__|
   |_REC_REP_MAX________|7200____|Maximum_pause_interval_(secs)__|
   |_REC_THRESHOLD______|100_____|%_of_required_clients__________|
   |_SRVR_PREF_WAIT_____|2_______|Advertise_Collect_timer_(secs)_|

4. Requirements

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [3].

   This document also makes use of internal conceptual variables
   to describe protocol behavior and external variables that an
   implementation must allow system administrators to change.  The
   specific variable names, how their values change, and how their
   settings influence protocol behavior are provided to demostrate
   protocol behavior.  An implementation is not required to have them in
   the exact form described here, so long as its external behavior is
   consistent with that described in this document.
5. Background

   Related work in IPv6 that would best serve an implementor to study
   is the IPv6 Specification [6], the IPv6 Addressing Architecture [8],
   IPv6 Stateless Address Autoconfiguration [15], IPv6 Neighbor
   Discovery Processing [12], and Dynamic Updates to DNS [17].  These
   specifications enable DHCP to build upon the IPv6 work to provide
   both robust stateful autoconfiguration and autoregistration of DNS
   Host Names.

   The IPv6 Specification provides the base architecture and design of
   IPv6.  A key point for DHCP implementors to understand is that IPv6
   requires that every link in the Internet have an MTU of 1280 octets
   or greater (in IPv4 the requirement is 68 octets).  This means that
   a UDP packet of 536 octets will always pass through an internetwork
   (less 40 octets for the IPv6 header), as long as there are no IP
   options prior to the UDP header in the packet.  But, IPv6 does not
   support fragmentation at routers, so that fragmentation takes place
   end-to-end between hosts.  If a DHCP implementation needs to send a
   packet greater than 1500 octets it can either fragment the UDP packet
   into fragments of 1500 octets or less, or use Path MTU Discovery [10]
   to determine the size of the packet that will traverse a network
   path.

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

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

   The IPv6 Addressing Architecture specification [8] defines the
   address scope that can be used in an IPv6 implementation, and the
   various configuration architecture guidelines for network designers
   of the IPv6 address space.  Two advantages of IPv6 are that support
   for multicast is required, and nodes can create link-local addresses
   during initialization.  This means that a client can immediately use
   its link-local address and a well-known multicast address to begin
   communications to discover neighbors on the link.  For instance, a
   client can send a Solicit message and locate a server or relay.

   IPv6 Stateless Address Autoconfiguration [15] (Addrconf) specifies
   procedures by which a node may autoconfigure addresses based on
   router advertisements [12], and the use of a valid lifetime to
   support renumbering of addresses on the Internet.  In addition the
   protocol interaction by which a node begins stateless or stateful
   autoconfiguration is specified.  The DHCP is one vehicle to perform
   stateful autoconfiguration.  Compatibility with addrconf is a design
   requirement of DHCP (see Section 6).

   IPv6 Neighbor Discovery [12] is the node discovery protocol in IPv6
   which replaces and enhances functions of ARP [13].  To understand
   IPv6 and Addrconf it is strongly recommended that implementors
   understand IPv6 Neighbor Discovery.

   Dynamic Updates to DNS [17] is a specification that supports the
   dynamic update of DNS records for both IPv4 and IPv6.  DHCP can use
   the dynamic updates to DNS to integrate addresses and name space
   to not only support autoconfiguration, but also autoregistration
   in IPv6.  The security model to be used with DHCPv6 should conform
   as closely as possible to the authentication model outlined in
   RFC2402 [9].

6. Design Goals

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

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

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

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

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

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

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

    -  A DHCP client can make multiple, different requests for
       configuration parameters when necessary from one or more DHCP
       servers at any time.  DHCP will provide enough information
       to enable a DHCP server to keep track of a DHCP client's
       configuration state.

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

   This specification explicitly does not cover the following:

    -  Specification of a DHCP server to server protocol.

    -  How a DHCP server stores its DHCP data.

    -  How to manage a DHCP domain or DHCP server.

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

   This section provides a general overview of the interaction
   between the functional entities of DHCP. The overview is organized
   as a series of questions and answers.  Details of DHCP such
   as message formats and retransmissions are left to sections 9,
   10, 11, 12, 14, 15, and  16.
8.1. How does a node know to use DHCP?

   An unconfigured node determines that it is to use DHCP for
   configuration of an interface by detecting the presence (or absence)
   of routers on the link.  If router(s) are present, the node examines
   router advertisements to determine if DHCP should be used to
   configure the interface.  If there are no routers present, then
   the node MUST use DHCP to configure the interface.  Detail on
   this process can be found in neighbor discovery [12] and stateless
   autoconfiguration [15].
8.2. How does a client find out about DHCP agents?

   The client forms a Solicit message, and multicasts it to the
   FF02::1:2(All DHCP Agents) address.  Server(s) receiving the Solicit
   respond with Advertise message(s).  If requested in the client's
   Solicit message, the Advertise message(s) can include one or more
   subnet prefix extensions [2], informing the client of subnet prefixes
   for the networks(s) managed by the server(s) on the client's link.
   Now that the client knows the IP address(es) of agents(s) on the
   link, it can request configuration parameters from servers.
8.3. What if the client and server(s) are on different links?

   Use of DHCP in such environments requires one or more . . . . . . . . . . . . . . . . . . . .   47
    23.2. Reconfigure message . . . . . . . . . . . . . . . . . . .   47
    23.3. Releasable resources  . . . . . . . . . . . . . . . . . .   47
    23.4. DHCP relays
   be set up on the client's link, because a client may only have a
   link-local address.  Relays pick up the message header . . . . . . . . . . . . . . . . . . .   47
    23.5. Design goals  . . . . . . . . . . . . . . . . . . . . . .   47
    23.6. Overview  . . . . . . . . . . . . . . . . . . . . . . . .   47
    23.7. Message formats, 9  . . . . . . . . . . . . . . . . . . .   47
    23.8. Solicit and Request messages
   from the client and forward them to some set of servers within the
   DHCP domain.  A relay will include one of its own addresses (of
   sufficient scope) of the interface on the same link as the client.
   The relay also includes the subnet prefix length of that address Advertise messages, (section 10)  . . . . . .   48
    23.9. Prefix advertisement  . . . . . . . . . . . . . . . . . .   48
   23.10. Identity Associations . . . . . . . . . . . . . . . . . .   48
   23.11. Extensions renamed options; defined in the client's messages.  Servers receiving the forwarded traffic
   use this information to aid in selecting configuration parameters
   appropriate to the client's link.  The servers also use the relay's
   address as the destination to forward client-destined messages
   for final delivery by the relay.  Relays forward client document  . .   48
   23.12. Transaction-ID ranges . . . . . . . . . . . . . . . . . .   48
   23.13. Release messages
   to servers using some combination of the FF05::1:3(All Servers)
   site-local multicast address, some other (perhaps a combination)
   of site-local multicast addresses set up within the DHCP domain to
   include the servers in that domain, or a list of unicast addresses
   for servers.  The network administrator makes and relays . . . . . . . . . . . . . . .   48
   23.14. Discovering relay configuration
   decisions based upon the topological requirements (scope) of the
   DHCP domain they are managing.  Note that if the agents  . . . . . . . . . . . . . . . .   48

 A. Comparison between DHCPv4 and DHCPv6                              49

 B. Full Copyright Statement                                          51

Chair's Address                                                       54

Author's Address                                                      54

1. Introduction

   This document describes DHCP domain spans
   more than the site-local scope, then the relays MUST be configured
   with global addresses for the client's link so as to be reachable by
   servers outside the relays' site-local environment.
8.4. How does IPv6 (DHCP), a UDP [13] client request configuration parameters from servers?

   To request configuration parameters, the client forms a Request
   message, and sends it
   / server protocol designed to reduce the server either directly (client has an
   address cost of sufficient scope) or indirectly (through management of
   IPv6 nodes in environments where network managers require more
   control over the on-link
   relay).  The client MAY include allocation of IPv6 addresses and configuration
   of network stack parameters than that offered by ``IPv6 Stateless
   Autoconfiguration'' [14].  DHCP is a Extension Request Extension [2]
   along with other extensions stateful counterpart to request specific information from the
   server.
   stateless autoconfiguration.  Note that the client MAY form multiple Request messages both stateful and send each stateless
   autoconfiguration can be used concurrently in the same environment,
   leveraging the strengths of them to different servers to request potentially
   different information (perhaps based upon what was advertised) both mechanisms in order to satisfy its needs.  As a client's needs may change over time
   (perhaps based upon an application's requirements), the client may
   form additional Request messages to request additional information as
   it is needed.

   The server(s) respond with Reply messages containing reduce the requested
   configuration parameters, which can include status information
   regarding
   cost of ownership and management of network nodes.

   DHCP reduces the information requested cost of ownership by centralizing the client.  The Reply MAY
   also include additional information, management
   of network resources such as IP addresses, routing information, OS
   installation information, directory service information, and other
   such information on a reconfiguration event
   multicast group for the client few DHCP servers, rather than distributing such
   information in local configuration files among each network node.
   DHCP is designed to join be easily extended to monitor reconfiguration
   events, as described carry new configuration
   parameters through the addition of new DHCP ``options'' defined to
   carry this information.  (What were called ``extensions'' in the -15
   draft are now called ``options''; see section 8.8.

   The receipt of 23.11.)

   Those readers familiar with DHCP for IPv4 [6] will find DHCP for IPv6
   provides a Reply superset of features, and benefits from a server concludes the basic
   request/reply transaction additional
   features of IPv6 and freedom from BOOTP [4]-backward compatibility
   constraints.  For more information about the protocol.
8.5. What are releasable resources, differences between DHCP
   for IPv6 and when are they used?

   A releasable resource DHCP for IPv4, see Appendix A.

   This document is configuration information leased to a client organized as follows.  Section 2 defines terminology
   used throughout this document.  Section 3 defines constant values
   used by a server for DHCP. Section 4 briefly discusses requirement levels.
   Section 5 points the reader to helpful background specifications
   covering related IPv6 protocols.  Section 6 discusses the design
   goals that influenced DHCP. Section 7 identifies some finite period of time.  When negotiating for a
   releasable resource, the client and server agree upon
   non-goals of this specification.  Section 8 gives a finite period high level
   overview of time DHCP, its message types, and identifies DHCP functional
   entities (client, relay, server).  Section 9 describes in detail
   the format of each DHCP message type.  Section 10 discusses DHCP
   server solicitation.  Section 11 discusses DHCP client-initiated
   configuration information exchange.  Section 12 discusses DHCP
   server-initiated configuration information exchange.  Section 14
   presents helpful notes for DHCP client may use implementors.  Section 15
   presents helpful notes for DHCP server implementors.  Section 16
   presents helpful notes for DHCP relay implementors.  Section 18
   discusses security considerations for DHCP.

   Section 23 describes the resource.  The client MAY request a
   renewal changes between this version of the lease on the resource at any time.  The length of time
   of DHCPv6
   specification and draft-ietf-dhc-dhcpv6-15.txt.

2. Terminology

2.1. IPv6 Terminology

   IPv6 terminology relevant to this specification from the lease (and whether it IPv6
   Protocol [5], IPv6 Addressing Architecture [7], and IPv6 Stateless
   Address Autoconfiguration [14] is renewable) are server-based policy
   tunables.  The client MUST stop using the resource when the lease on
   the resource expires.  The server MUST NOT reallocate included below.

      address    An IP layer identifier for an assigned
   resource before either its lease expires interface or the client releases the
   resource.

   See the ``extensions document'' [2] a set of
                 interfaces.

      unicast address
                 An identifier for more information about
   releasable resources.
8.6. Can a client release its releasable resources before the lease
   expires? single interface.  A client forms packet sent
                 to a Release message, including extensions carrying unicast address is delivered to the
   resource(s) interface
                 identified by that address.

      multicast address
                 An identifier for a set of interfaces (typically
                 belonging to be released. different nodes).  A packet sent to a
                 multicast address is delivered to all interfaces
                 identified by that address.

      host       Any node that is not a router.

      IP         Internet Protocol Version 6 (IPv6).  The client sends the Release terms IPv4 and
                 IPv6 are used only in contexts where it is necessary to the
   server
                 avoid ambiguity.

      interface
                 A node's attachment to a link.

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

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

      link-local address
                 An IP address having link-only scope, indicated by
                 having the client initially.  If prefix (FE80::0000/64), that
   server cannot be reached after a certain number of attempts (see
   section 3.5), the client can abandon the Release attempt.  In this
   case, the resource(s) will be reclaimed by the server(s) when the
   client's lease(s) expire.
8.7. What if the client determines its releasable resource is already
   being used by another client?

   If
                 to reach neighboring nodes attached to the client determines through same link.
                 Every interface has a releasable resource-specific
   manner that the resource it was assigned by the server is already link-local address.

      message    A unit of data carried in use by another client, the client will form a Release message,
   including the extension carrying the in-use resource.  The
   extension's status field MUST be set packet, exchanged between
                 DHCP agents and clients.

      neighbor   A node attached to the extension-specific value
   reflecting the ``in use'' status same link.

      node       A device that implements IP.

      packet     An IP header plus payload.

      prefix     A bit string that consists of some number of initial
                 bits of the resource.

   For example, if the releasable resource is an IP address, the client
   uses Duplicate Address Detection (DAD) to verify address.

      router     A node that the forwards IP address
   is packets not in use.  If explicitly
                 addressed to itself.

2.2. DHCP Terminology

   Terminology specific to DHCP can be found below.

      abort status
                 A status value returned to the client determines application that the IP has
                 invoked a DHCP client operation, indicating anything
                 other than success.

      agent address is
   already in use, it forms
                 The address of a Release message including neighboring DHCP Agent on the IP address
   extension same
                 link as the DHCP client.

      binding    A binding (or, client binding) is a group of server
                 data records indexed by <prefix, UUID> containing the appropriate status value
                 server's information about the addresses and sends it other
                 information assigned to the
   server.  See the ``extensions document''for details on the IP address
   extension. [2].
8.8. How IA.

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

      configuration changes?

   There are two possibilities.  Either the clients discover parameter

                 An element of the new configuration information when they revisit set on the server(s)
                 server and delivered to request additional
   configuration information / renew the lease client using DHCP. Such
                 parameters may be used to carry information to be used
                 by a node to configure its network subsystem and enable
                 communication on a releasable resource, link or through a server-initiated event known as internetwork, for example.

      DHCP client (or client)
                 A node that initiates requests on a reconfigure event.

   The reconfiguration feature of link to obtain
                 configuration parameters from one or more DHCP offers servers.

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

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

      DHCP relay (or relay)
                 A node that acts as an intermediary to be updated deliver DHCP
                 messages between clients and servers, and is not
   client-specific, on the server will form
                 same link as a Reconfigure message and add client.

      DHCP agent (or agent)
                 Either a DHCP server on the new or changed configuration information to it.  The Reconfigure
   may be unicast same link as a client, or multicast (to a preassigned multicast address for
   this purpose)
                 DHCP relay.

      Identity association (IA)
                 A collection of addresses assigned to one or more client(s) a client.  Each
                 IA has an associated UUID. A server identifies an IA by
                 the tuple (prefix, UUID), where ``prefix'' is a prefix
                 assigned to the link to which the new client is attached,
                 An IA may have 0 or updated
   information needs more addresses associated with it.

      Releasable resource
                 (Removed; see section 23.3.)

      transaction-ID
                 An unsigned integer to be directed.  The client(s) will acknowledge the
   receipt of the Reconfigure message match responses with replies
                 initiated either by forming a Reconfigure-reply
   message and unicasting it to the client or server.  If the configuration
   information change is different

      UUID
                 A universally unique identifier for each client (e.g. a change in
   subnet prefix, perhaps, which would affect the IP address releasable
   resource(s)), the server will form client.

                 DISCUSSION:

                    Rules for choosing a Reconfigure-init message UUID are TBD.

3. DHCP Constants

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

3.1. Multicast Addresses

   DHCP makes use of the following multicast as needed addresses:

      All DHCP Agents address:  FF02::1:2
                 This link-local multicast address is used by clients to
                 communicate with the client(s).  A Reconfigure-init on-link agent(s) when they do not
                 know those agents' link-local address(es).  All agents
                 (servers and relays) are members of this multicast
                 group.

      All DHCP Servers address:  FF05::1:3
                 This site-local multicast address is a trigger which will cause the client(s) used by clients or
                 relays to initiate a standard
   Request/Reply exchange communicate with the server in order server(s), either because
                 they want to acquire the new send messages to all servers or
   updated resources.
9. Message Formats

   All reserved fields because
                 they do not know the server(s) unicast address(es).
                 Note that in order for a message MUST client to use this address,
                 it must have an address of sufficient scope to be transmitted as zeroes and
   ignored
                 reachable by the receiver of server(s).  All servers within the message.
9.1.
                 site are members of this multicast group.

3.2. UDP ports

   DHCP Solicit Message Format

   A uses the following destination UDP [13] port numbers.  While
   source ports MAY be arbitrary, client multicasts implementations SHOULD permit
   their specification through a DHCP Solicit message local configuration parameter to
   facilitate the FF02::1:2(All use of DHCP
   agents) address over the interface through firewalls.

      546        Client port.  Used by agents to be configured send messages to locate one or
   more
                 clients.  Also used by servers which are configured to provide configuration parameters send messages to nodes on the client's link.

   Unless otherwise noted, the value of all fields are set
                 relays.

      547        Agent port.  Used by clients to send messages to
                 agents.  Also used by relays to send messages to
                 servers.

3.3. DHCP message types

   DHCP defines the
   client.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 following message types.  More detail on these
   message types can be found in Section 9.  Message types 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  msg-type = 1 |C|P| and 9--255
   are reserved |  prefix-len |   solicit-ID    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   client's link-local address                 |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         relay-address                         |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      C          If set, and MUST be silently ignored.

      01 DHCP Solicit

         The DHCP Solicit (or Solicit) message is used by clients
         to locate servers.  This message is multicast using the
         All-DHCP-Agents address.  Relay(s) forward Solicits as
         necessary to off-link servers.

         Section 9.1 contains more details about the client requests that all Solicit message.

      02 DHCP Advertise

         The DHCP Advertise (or Advertise) message is used by servers receiving
                 the
         responding to Solicits.  This message deallocate the releasable resources (e.g.
                 IP addresses) associated with is unicast to the
         client's binding.

      P          If set, link-local address (if the server and client requests that all servers receiving are
         on the message SHOULD return a list of subnet prefix
                 extensions identifying same link) or unicast to the networks on relay through which the client's
                 link that
         Solicit was sent for final delivery to the server(s) are configured client.

         Section 9.2 contains more details about the Advertise message.

      03 DHCP Request

         The DHCP Request (or Request) message is used by clients to manage.

      reserved   0

      prefix-len
                 An unsigned 7 bit number (0-127) non-zero prefix-len
         request configuration parameters from servers.  This message is
         multicast using the number of leftmost bits of the agent's IPv6 address
                 which make up All-DHCP-Agents address.  Relay(s) forward
         Requests as necessary to off-link servers.

         Section 9.3 contains more details about the subnet prefix. Request message.

      04 DHCP Reply

         The prefix-len field DHCP Reply (or Reply) message is set used by servers responding
         to Request and Release messages.  In the relay if case of responding to
         a Request message, the relay receives Reply contains configuration parameters
         destined for the Solicit client.  This message and forwards it is unicast to one or more servers.

      solicit-ID
                 An unsigned 9 bit number (0-511) generated by the client used to identify this Solicit message.

      client's link-local address
                 The IP link-local
         if the client has an address of sufficient scope that is
         reachable by the client interface server.  Otherwise, it is unicast to the relay
         through which the client will issue Request or Release message was sent for final
         delivery to the client.

         Section 9.4 contains more details about the Solicit Reply message.

      relay-address
                 Set

      05 DHCP Release

         The DHCP Release (or Release) message is used by the client clients to be zero.  If received by a relay,
                 set by the relay
         return one or more IP addresses to servers.  The server will
         acknowledge the site-local IP address receipt of the
                 interface on which the relay received Release message by sending the client's
                 Solicit
         client a Reply message.  Note that if

         Section 9.5 contains more details about the Release message.

      06 DHCP domain crosses
                 site boundaries, the relay MUST place a globally-scoped
                 address in this field.

   A client MUST send the Solicit Reconfigure

      07 DHCP Reconfigure-reply

         Removed; see section 23.2.

      08 DHCP Reconfigure-init

         The DHCP Reconfigure-init (or Reconfigure-init) message is set
         by server(s) to inform client(s) that the All-DHCP-Agents
   multicast group (see section 3.1), setting server(s) has new or
         updated configuration parameters, and that the relay-address client(s) are
         to zero.
9.2. DHCP Advertise Message Format

   A server sends an Advertise message initiate a Request/Reply transaction with the server(s) in response
         order to a client's
   Solicit receive the updated information.

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

3.4. Error Values

   This section describes error values exchanged between DHCP
   implementations.

3.4.1. Generic Error Values

   The Advertise message notifies the following symbolic names are used between client of the
   server's IP address.  If the server is so configured by the network
   administrator and server
   implementations to convey error conditions.  The following table
   contains the client requests it through actual numeric values for each name.  Note that the ``P'' bit
   numeric values do not start at 1, nor are they consecutive.  The
   errors are organized in
   its Solicit message, the logical groups.

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

3.4.2. Server-specific Error Values

   The following symbolic names are used by server SHOULD add a list of subnet prefix
   extensions implementations to the Advertise message
   convey error conditions to notify clients.  The following table contains the client
   actual numeric values for each name.

   _______________________________________________________________
   |Error_Name____|Error_ID|_Description________________________|_
   |NoBinding_____|20______|_Client_record_(binding)_unavailable|_
   |InvalidSource_|21______|_Invalid_Client_IP_address__________|_
   |NoServer______|23______|_Relay_cannot_find_Server_Address___|_
   |ICMPError_____|64______|_Server_unreachable_(ICMP_error)____|_

3.5. Configuration Variables

   This section presents a table of the
   networks it manages on the client's link.

   When the client and server are configuration
   variables and the default or initial values for these variables.  The
   client-specific variables MAY be configured on different links, the server sends and MAY be
   delivered to the Advertise message back client through the relay whence the corresponding
   Solicit came.  The solicit-ID ``DHCP Retransmission Parameter
   Option'' in a Reply message.  This option is copied from the client's Solicit
   Message. TBD.

   ______________________________________________________________
   |Parameter__________|Default|_Description___________________|_
   |MIN_SOL_DELAY______|1______|_MIN_(secs)_to_delay_1st_mesg__|_
   |MAX_SOL_DELAY______|5______|_MAX_(secs)_to_delay_1st_mesg__|_
   |ADV_MSG_TIMEOUT____|500____|_SOL_Retrans_timer_(msecs)_____|_
   |ADV_MSG_MAX________|30_____|_MAX_timer_value_(secs)________|_
   |SOL_MAX_ATTEMPTS___|-1_____|_MAX_attempts_(-1_=_infinite)__|_
   |REP_MSG_TIMEOUT____|250____|_REQ_Retrans_timer_(msecs)_____|_
   |REQ_MSG_ATTEMPTS___|10_____|_MAX_Request_attempts__________|_
   |REL_MSG_ATTEMPTS___|5______|_MAX_Release_attempts__________|_
   |RECREP_MSG_TIMEOUT_|2000___|_Retrans_timer_(msecs)_________|_
   |REC_MSG_ATTEMPTS___|10_____|_Reconfigure_attempts__________|_
   |REC_REP_MIN________|5______|_Minimum_pause_interval_(secs)_|_
   |REC_REP_MAX________|7200___|_Maximum_pause_interval_(secs)_|_
   |REC_THRESHOLD______|100____|_%_of_required_clients_________|_
   |SRVR_PREF_WAIT_____|2______|_Advertise_Collect_timer_(secs)|_

4. Requirements

   The value of all fields keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in the Advertise message this
   document, are filled to be interpreted as described in by the server [2].

   This document also makes use of internal conceptual variables
   to describe protocol behavior and not changed in any way by any intervening relay.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  msg-type = 2 |  reserved   |   solicit-ID    |  preference   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   client's link-local address                 |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         relay-address                         |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         server-address                        |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              extensions (variable number external variables that an
   implementation must allow system administrators to change.  The
   specific variable names, how their values change, and length) ...      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      reserved     0

      solicit-ID how their
   settings influence protocol behavior are provided to demonstrate
   protocol behavior.  An unsigned 9 bit number (0-511) used implementation is not required to identify have them in
   the exact form described here, so long as its external behavior is
   consistent with that described in this Advertise message.  Copied from document.

5. Background

   Related work in IPv6 that would best serve an implementor to study
   is the client's
                   Solicit message.

      preference   An octet (unsigned) indicating a server's willingness IPv6 Specification [5], the IPv6 Addressing Architecture [7],
   IPv6 Stateless Address Autoconfiguration [14], IPv6 Neighbor
   Discovery Processing [11], and Dynamic Updates to provide service DNS [16].  These
   specifications enable DHCP to build upon the client.

      client's link-local address
                   The IP link-local address IPv6 work to provide
   both robust stateful autoconfiguration and autoregistration of DNS
   Host Names.

   The IPv6 Specification provides the client interface
                   from which the client issued base architecture and design of
   IPv6.  A key point for DHCP implementors to understand is that IPv6
   requires that every link in the Solicit message.

      relay-address
                   The IP address Internet have an MTU of 1280 octets
   or greater (in IPv4 the relay interface on requirement is 68 octets).  This means that
   a UDP packet of 536 octets will always pass through an internetwork
   (less 40 octets for the same
                   link IPv6 header), as long as there are no IP
   options prior to the client.  Copied from UDP header in the client's
                   Solicit. packet.  But, IPv6 does not
   support fragmentation at routers, so that fragmentation takes place
   end-to-end between hosts.  If a DHCP implementation needs to send a
   packet greater than 1500 octets it can either fragment the server is on UDP packet
   into fragments of 1500 octets or less, or use Path MTU Discovery [9]
   to determine the same link as size of the
                   client, then this field MUST be zero.

      server-address
                   The site-local IP packet that will traverse a network
   path.

   DHCP clients use Path MTU discovery when they have an address of
   sufficient scope to reach the DHCP server.  If the a DHCP
                   domain crosses site boundaries, then this address client does not
   have such an address, that client MUST be globally-scoped.

      extensions   See fragment its packets if the
   resultant message size is greater than the ``extensions document'' minimum 1280 octets.

   Path MTU Discovery for details [2].

   See Sections 14.4 and 15.3 IPv6 is supported for information about how clients both UDP and
   servers handle TCP and
   can cause end-to-end fragmentation when the preference field.

9.3. DHCP Request Message Format

   A client sends PMTU changes for a Request message to request
   destination.

   The IPv6 Addressing Architecture specification [7] defines the
   address scope that can be used in an IPv6 implementation, and the
   various configuration parameters
   from a server.  It MAY append appropriate extensions [2].

   When architecture guidelines for network designers
   of the IPv6 address space.  Two advantages of IPv6 are that support
   for multicast is required, and nodes can create link-local addresses
   during initialization.  This means that a client reboots, it often does not have can immediately use
   its link-local address and a valid IP well-known multicast address of
   sufficient scope for the server to communicate with the client.  In
   such cases, begin
   communications to discover neighbors on the link.  For instance, a
   client MUST NOT unicast the can send a Solicit message to the and locate a server
   because or relay.

   IPv6 Stateless Address Autoconfiguration [14] (Addrconf) specifies
   procedures by which a node may autoconfigure addresses based on
   router advertisements [11], and the server could not return use of a response valid lifetime to
   support renumbering of addresses on the client.  The
   client MUST send the message to Internet.  In addition the server indirectly,
   protocol interaction by using the
   on-link relay.  The client MUST fill in the relay address field with
   the on-link relay's IP address.

   If the Request message which a node begins stateless or stateful
   autoconfiguration is being formed in response specified.  DHCP is one vehicle to perform
   stateful autoconfiguration.  Compatibility with addrconf is a
   Reconfigure-init message from the server, then the transaction ID
   used must be copied from the Reconfigure-init.

   All fields in the design
   requirement of DHCP Request message are entered by (see Section 6).

   IPv6 Neighbor Discovery [11] is the client.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  msg-type = 3 |C|R|  reserved |        transaction-ID         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   client's link-local address                 |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         relay-address                         |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         server-address                        |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         extensions (variable number node discovery protocol in IPv6
   which replaces and length)   ....        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      C          If set, enhances functions of ARP [12].  To understand
   IPv6 and Addrconf it is strongly recommended that implementors
   understand IPv6 Neighbor Discovery.

   Dynamic Updates to DNS [16] is a specification that supports the client requests
   dynamic update of DNS records for both IPv4 and IPv6.  DHCP can use
   the server dynamic updates to DNS to integrate addresses and name space
   to remove
                 all releasable resources associated not only support autoconfiguration, but also autoregistration
   in IPv6.  The security model to be used with the client
                 binding, except those releasable resources provided DHCPv6 should conform
   as
                 extensions.

      R          If set, closely as possible to the client has rebooted and requests that authentication model outlined in
   RFC2402 [8].

6. Design Goals

    -  DHCP is a mechanism rather than a policy.  Network administrators
       set their administrative policies through the
                 server clear any transaction-ID cache entries for configuration
       parameters they place upon the
                 client.

      reserved   0
      transaction-ID
                 An unsigned integer identifier DHCP servers in the DHCP domain
       they're managing.  DHCP is simply used to identify this
                 request.

      client's link-local address
                 The link-local address deliver parameters
       according to that policy to each of the client interface from
                 which DHCP clients within the
       domain.

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

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

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

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

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

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

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

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

7. Non-Goals

   This specification explicitly does not cover the Request message.

      relay-address
                 The IP address following:

    -  Specification of a relay's interface, copied from an
                 Advertise message.  If the DHCP server to server protocol.

    -  How a DHCP server stores its DHCP data.

    -  How to manage a DHCP domain or DHCP server.

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

8. Overview

   This section provides a general overview of the same link
                 as interaction
   between the client, then this field MUST BE zero.

      server-address functional entities of DHCP. The IP address overview is organized
   as a series of the server to which the the client's
                 Request questions and answers.  Details of DHCP such
   as message formats and retransmissions are left to sections 9,
   10, 11, 12, 14, 15, and  16.

8.1. How does a node know to use DHCP?

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

      extensions
                 See interface by detecting the ``extensions document'' [2].

   A DHCP client selects presence (or absence)
   of routers on the transaction-ID from link.  If router(s) are present, the range of
   1024--65535 used node examines
   router advertisements to identify its Request.  In contrast, a
   transaction-ID from the range of 0--1023is selected by a determine if DHCP server should be used to identify a Reconfigure-init.  In
   configure the latter case, interface.  If there are no routers present, then
   the transaction
   ID from node MUST use DHCP to configure the Reconfigure-init is copied by interface.  Detail on
   this process can be found in neighbor discovery [11] and stateless
   autoconfiguration [14].

8.2. How does a client find out about DHCP agents?

   (Section removed, see 23.6

8.3. What if the client into its Request
   message.

   When and server(s) are on different links?

   Use of DHCP in such environments requires one or more DHCP relays
   be set up on the client's link, because a client sets may only have a
   link-local address.  Relays receive the `C' bit Solicit and adds extensions documenting
   the releasable resources Request messages
   from the client wishes and forward them to keep, some set of servers within the server is
   expected to deallocate all other releasable resources not listed.
   DHCP domain.  The server SHOULD examine the included extensions to check whether
   the client is still authorized to use them.
9.4. DHCP Reply Message Format

   A server sends a Reply message is forwarded verbatim as the payload
   in response to a client's Request
   message or Release message.

   If a Request message is received which contains a non-zero from the relay
   address field, then to the client could not unicast server.  A relay will include
   one of its own addresses (of sufficient scope) from the Request message
   to interface
   on the server and thus had to use a on-link relay.  In that case, same link as the
   server unicasts client, as well as the Reply prefix length of
   that address, in its message to the relay address found server.  Servers receiving
   the forwarded traffic use this information to aid in selecting
   configuration parameters appropriate to the
   Request message.

   If a Release message is received which contains a non-zero relay
   address field, then client's link.  The
   servers also use the client will not have an IP relay's address of
   sufficient scope after as the Release destination to receive forward
   client-destined messages for final delivery by the Reply message.  In
   this case, relay.

   Relays forward client messages to servers using some combination of
   the server unicasts FF05::1:3(All Servers) site-local multicast address, some other
   (perhaps a combination) of site-local multicast addresses set up
   within the Reply message DHCP domain to include the relay address
   found servers in that domain, or a
   list of unicast addresses for servers.  The network administrator
   makes relay configuration decisions based upon the Release message.

   All the fields in topological
   requirements (scope) of the DHCP Reply message domain they are set by managing.  Note
   that if the DHCP server.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  msg-type = 4 |R|  status     |        transaction-ID         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   client's link-local address                 |
     |                           (16 octets)                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   relay-address (if present)                  |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         extensions (variable number and length)   ....        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      R          If set, domain spans more than the ``relay-address'' field is present.

      status
                 This 7-bit field contains one of site-local scope, then
   the values in relays MUST be configured with global addresses for the
                 errors table in section 3.4.

      transaction-ID
                 Copied client's
   link so as to be reachable by servers outside the relays' site-local
   environment.

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

   To request configuration parameters, the client's client forms a Request or Release.

      client's link-local
   message, and sends it to the server either directly (client has an
   address
                 Copied of sufficient scope) or indirectly (through the on-link
   relay).  The client MAY include a Option Request Option 22.3 (ORO)
   along with other options to request specific information from the client's
   server.  Note that the client MAY form multiple Request or Release message.

      relay-address
                 The IP address messages
   and send each of them to different servers to request potentially
   different information (perhaps based upon what was advertised) in
   order to satisfy its needs.  As a relay's interface, copied from client's needs may change over time
   (perhaps based upon an application's requirements), the client may
   form additional Request or Release message.  If the server messages to request additional information as
   it is on needed.

   The server(s) respond with Reply messages containing the
                 same link as requested
   configuration parameters, which can include status information
   regarding the client, then information requested by the ``R'' bit is not set
                 and this field is not present.

      extensions
                 See client.  The Reply MAY
   also include additional information, such as a reconfiguration event
   multicast group for the ``extensions document'' [2].
9.5. DHCP Release Message Format

   A client sends a Release message to a server when it wishes join to return monitor reconfiguration
   events, as described in section 8.8.

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

   Servers and clients manage addresses in groups called ``identity
   associations.''  Each identity associations is identified using
   a unique identifier.  An identity association may contain one or
   more releasable resources IPv6 addresses.  DHCP servers assign addresses to identity
   associations.  DHCP clients use the server which allocated
   them.  This can occur either because the addresses in an identity
   association to configure interfaces.  There is always at least one
   identity association per interface that a client no longer needs wishes to configure.
   Each address in an IA has its own preferred and valid lifetime.  Over
   time, the
   resource(s) or server may change the client has determined through a resource-specific
   manner that characteristics of the resource(s) are already addresses in use by different
   client(s).  The client communicates the reason
   an IA; for example, by changing the premature
   release of the resource preferred or valid lifetime for
   an address in the status field of the resource's
   extension.  See ``extensions document'' [2] IA. The server may also add or delete addresses
   from an IA; for more details.

   When example, deleting old addresses and adding new
   addresses to renumber a client.  A client sends a Release message, it needs can request the current
   list of addresses assigned to have an IA from a valid IP
   address with sufficient scope to allow access by the target server.
   If such server through an address is not available, exchange
   of protocol messages.

8.6. Can a relay is used.  Only those
   releasable resources identified by extensions are released.  If no
   extensions are included in client release its assigned addresses before the lease
   expires?

   A client forms a Release message, then all releasable
   resources associated with including options identifying
   the client's binding are IA to be released.  The values of all fields of client sends the Release message are set by to the
   client.  The DHCP server acknowledges
   which assigned the Release message by sending addresses to the client initially.  If that
   server cannot be reached after a Reply message.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  msg-type = 5 |R|  reserved   |        transaction-ID         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   client's link-local address                 |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         server-address                        |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           X-address                           |
     |                          (16 octets)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         extensions (variable certain number and length)   ....        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      R          If set, of attempts (see
   section 3.5), the ``X-address'' field contains client can abandon the Release attempt.  In this
   case, the address(es) in the IA will be reclaimed by the server(s)
   when the lifetimes on the addresses expire.

8.7. What if the address client determines one or more of
                 relay. its assigned addresses
   are already being used by another client?

   If not set, the ``X-address'' field contains a
                 non-local scope client address.

      reserved   0

      transaction-ID
                 An unsigned integer identifier used to identify this
                 Release message.

      client's link-local address
                 The client's link-local determines through a mechanism like Duplicate Address
   Detection [14] that the address for it was assigned by the interface
                 from which server is
   already in use by another client, the client issued the will form a Release message (and
                 to which
   message, including the releasable resources are bound at option carrying the
                 server).

      server-address in-use address.  The IP address
   option's status field MUST be set to the value reflecting the ``in
   use'' status of the address.

8.8. How are clients notified of server which allocated configuration changes?

   There are two possibilities.  Either the
                 resource.

      X-address
                 If clients discover the ``R'' bit is set, new
   information when they revisit the ``X-address'' field
                 contains server(s) to request additional
   configuration information / extend the IP address lifetime on an address.  or
   through a server-initiated event known as a reconfigure event.

   The reconfiguration feature of DHCP offers network administrators
   the relay interface opportunity to update configuration information on DHCP clients
   whenever necessary.  To signal the
                 same link as the client.  If need for client reconfiguration,
   the ``R'' bit is not set,
                 this field contains server will unicast a non-link-local IP address of the Reconfigure-init message to each
   client interface from which individually.  The server may use multicast to signal the
   reconfiguration to multiple clients simultaneously.  (Note that
   there is no mechanism defined in the protocol to guarantee that
   every client issued actually performs a reconfiguration in response to a
   multicast reconfigure-init message.)  A Reconfigure-init is a trigger
   which will cause the
                 Release message.

      extensions See client(s) to initiate a standard Request/Reply
   exchange with the ``extensions document'' [2].

   A client selects server in order to acquire the transaction-ID from new or updated
   addresses.

9. Message Formats and Identity Associations

   All reserved fields in a message MUST be transmitted as zeroes and
   ignored by the range receiver of
   1024--65535 used to identify the Release message.

   A client MUST NOT specify

   DISCUSSION:

      Each DHCP message has an IP address identical fixed format header; some
      messages also allow a variable format area for options.  Not
      all fields in the client-address header are used in every message.  In this
      section, every field
   that it is releasing included in the extensions field.
9.6. DHCP Reconfigure Message Format

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

   Reconfigure messages can ONLY be sent to clients which have
   established an IP address of sufficient scope are marked
      as to ``unused''.  As an alternative, the unused fields could
      be directly
   reachable by labeled ``unused'' in the server.

   Clients acknowledge Reconfigure messages with Reconfigure-reply
   messages. format diagram.

9.1. DHCP Solicit Message Format

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  msg-type = 6 1 |   reserved  preference   |         transaction-ID        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        server-address                         |                                                               |                          (16 octets)
     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                   client-link-local-address                   |         extensions (variable number and length)   ....
     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      reserved   0
      transaction-ID
                 An unsigned integer identifier in the range of
                 0--1023 chosen by the server to identify this
                 Reconfigure message.

      server-address
                 The IP address of the DHCP server issuing the
                 Reconfigure message.  MUST be of sufficient scope to be
                 reachable by all clients.

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

   A client sends a Reconfigure-reply message to acknowledge receipt of
   a Reconfigure message from a server.

   A Reconfigure-reply message can only                          (16 octets)                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         server-address                        |
     |                          (16 octets)                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      preference
                 (unused) MUST be sent if 0

      transaction-ID
                 An unsigned integer generated by the client has an IP used to
                 identify this Solicit message.

      client-link-local-address
                 The link-local address of sufficient scope to contact the server.  No interaction
   with a relay is possible.

   All fields in interface for which the
                 client is using DHCP.

      server-address (unused) MUST be 0

9.2. DHCP Reconfigure-reply message are entered by the
   client. Advertise Message Format

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  msg-type = 7 |r|  status 2 |  preference   |         transaction-ID        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   client's link-local address                                                               |
     |                   client-link-local-address                   |
     |                          (16 octets)                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         server-address                        |
     |                          (16 octets)                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      r          reserved (0)

      status
                 This 7-bit field contains one of the values from
     |            options (variable number and length)   ....        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      preference   An unsigned integer indicating a server's willingness
                   to provide service to the
                 errors table in section 3.4. client.

      transaction-ID An unsigned integer identifier copied used to identify this Advertise
                   message.  Copied from the server's
                 Reconfigure message. client's link-local address Solicit message.

      client-link-local-address
                   The client's IP link-local address for of the client interface
                   from which the client issued the Reconfigure-reply Solicit message.

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

   A server sends a Reconfigure-init message when it wishes to notify
   one or more clients of new or updated values for configuration
   parameters available on the server.

   Reconfigure-init messages can ONLY be sent to clients which have
   established an
                   The IP address of sufficient scope as to be directly
   reachable by the server.

   A ``Reconfigure-init'' serves as a trigger which will cause the
   clients to initiate a Request/Reply exchange with  If the server DHCP domain
                   crosses site boundaries, then this address MUST be
                   globally-scoped.

      options      Options are described elsewhere in order
   to receive this document

   See Sections 14.4 and 15.3 for information about how clients and
   servers handle the new information. preference field.

9.3. DHCP Request Message Format

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  msg-type = 8 3 |   reserved  preference   |         transaction-ID        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                   client-link-local-address                   |
     |                          (16 octets)                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         server-address                        |
     |                          (16 octets)                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         extensions            options (variable number and length)   ....        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      reserved

      preference
                 (unused) MUST be 0

      transaction-ID
                 An unsigned integer identifier in the range of
                 0--1023 chosen by the server to identify this
                 Reconfigure-init message.

      server-address
                 The IP address of the DHCP server issuing the
                 Reconfigure-init message.  MUST be of sufficient scope
                 to be reachable by all clients.

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

   This section describes how a client locates agents (relays and
   servers) and how it can learn about the networks on its link that are
   managed by these servers.  The behavior of client, server, and relay
   implementations is discussed, along with the messages they use.
10.1. Solicit Message Validation

   Clients MUST silently discard any received Solicit messages.

   Agents MUST discard any received Solicit messages if the ``client's
   link-local address'' field does not contain a valid link-local
   address.

   Servers MUST discard each received Solicit message which meet the
   following criteria:

     o The ``relay-address'' field does not contain an address of
       sufficient scope that is reachable by the server.

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

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

   Servers MUST silently discard any received Advertise messages.

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

     o The ``Solicit-ID'' field value does not match the value integer generated by the client used in its Solicit to
                 identify this Request message.

     o

      client-link-local-address
                 The ``client's link-local address'' field value does not match
       the link-local address of the client interface upon from
                 which the client
       sent will issue the Solicit Request message.

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

     o

      server-address
                 The ``relay-address'' field does not contain the relay's IP address
       on the same link as the client.

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

   Clients use the Solicit message primarily to discover DHCP servers
   configured to serve networks on the link containing the client.
   Optionally, the client MAY set the ``P'' bit which has the effect of requesting that the server return subnet prefix extensions
   identifying to which the networks on the client's link the server is
   configured to manage.
10.3.1. Creation and sending of the Solicit
                 Request message

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

   If the client is prepared to process multiple directed, copied from an Advertise messages
                 message.

      options
                 Options are described elsewhere in response to its Solicit message, the client will set the
   Solicit-ID field to 1.  Every time the client initiates a new server
   solicitation attempt (not this document.

9.4. DHCP Reply Message Format

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  msg-type = 4 |  preference   |         transaction-ID        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                     client-link-local-address                 |
     |                           (16 octets)                         |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         server-address                        |
     |                          (16 octets)                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            options (variable number and length)   ....        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      preference An unsigned integer indicating a retransmission), the client increments
   the Solicit-ID by one.  If the 9-bit field rolls over server's willingness
                 to 0, then the
   client sets the Solicit-ID provide service to 1.  A client which will only accept
   the first Advertise message it receives leaves the Solicit-ID field
   initialized client.

      transaction-ID
                 An unsigned integer used to zero.

   The ``C'' bit of the Solicit message is set by the client when the
   client has no cached knowledge of previous DHCP configuration for the
   interface.  Setting identify this bit requests that the server release any
   information assigned to the client for the networks on Reply
                 message.  Copied from the client's
   link.

   If the client desires to learn Request message.

      client-link-local-address
                 The link-local address of the networks managed by DHCP on
   the link its interface is attached to, it sets the ``P'' bit in for which the
   Solicit message.

   The
                 client transmits is using DHCP.

      server-address
                 The IP address of the Solicit message to server.  If the FF02::1:2  (All DHCP
   Agents) multicast address, destination port 547.  The source port
   selection can domain
                 crosses site boundaries, then this address MUST be arbitrary, although it SHOULD
                 globally-scoped.

      options
                 Options are described elsewhere in this document.

9.5. DHCP Release Message Format

      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 = 5 | preference    |        transaction-ID         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                   client-link-local-address                   |
     |                          (16 octets)                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         server-address                        |
     |                          (16 octets)                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         options (variable number and length)   ....        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      preference (unused) MUST be possible using a 0

      transaction-ID
                 An unsigned integer generated by the client configuration facility used to set a specific source port value.

10.3.2. Time out and retransmission of Solicit Messages
                 identify this Release message.

      P          (unused) MUST be 0

      client-link-local-address
                 The client's first Solicit message on link-local address for the interface MUST be delayed
   by a random amount of time between the interval of MIN_SOL_DELAY and
   MAX_SOL_DELAY. This random delay desynchronizes clients from
                 which start
   at the same time (e.g., after a power outage).

   The client waits ADV_MSG_TIMEOUT, collecting Advertise messages.
   If no Advertise messages are received, the client retransmits
   the Solicit, and doubles issued the ADV_MSG_TIMEOUT value.  This process
   continues until either one or more Advertise messages are received or
   ADV_MSG_TIMEOUT reaches Release message.

      server-address
                 The IP address of the ADV_MSG_MAX value.  Thereafter, Solicits
   are retransmitted every ADV_MSG_MAX until SOL_MAX_ATTEMPTS have been
   made, at which time server that assigned the client stops trying to
                 addresses.

      options    See section 22.

9.6. DHCP configure the
   interface.  An event external to Reconfigure Message Format

   The Reconfigure message has been deleted (see section 23.2).

9.7. DHCP is required to restart the Reconfigure-reply Message Format

   The Reconfigure-reply message has been deleted (see section 23.2).

9.8. DHCP
   configuration process.

   Default Reconfigure-init Message Format

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  msg-type = 8 |  preference   |         transaction-ID        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                   client-link-local-address                   |
     |                          (16 octets)                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                        server-address                         |
     |                          (16 octets)                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            options (variable number and initial values for MIN_SOL_DELAY, MAX_SOL_DELAY,
   ADV_MSG_TIMEOUT, AND ADV_MSG_MAX are documented in section 3.5.
10.3.3. Receipt of Advertise messages

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

    -  Those Advertise messages with the highest server length)   ....        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      preference
       value (see section 14.4) are preferred over all other Advertise
       messages.

    -  Within a group of Advertise messages with (unused) MUST be 0

      transaction-ID
                 An unsigned integer generated by the same server
       preference value, a client MAY select those servers whose
       Advertise messages advertise information of interest to
       the client.  For example, one server may identify
                 this Reconfigure-init message

      client-link-local-address
                 (unused) MUST be advertising the
       availability of 0

      server-address
                 The IP addresses on networks which have an address
       scope of interest to the client.

   Once a client has selected Advertise message(s), DHCP server issuing the client will
   typically store
                 Reconfigure-init message.  MUST be of sufficient scope
                 to be reachable by all clients.

      options    SHOULD only include an ``Options request option''
                 (ORO) and/or authentication options.  No configuration
                 information SHOULD be included.  See section 22 more
                 information about each server, such as relay address
   and options.

9.9. Relay-forward message

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  msg-type TBD | prefix length, server preference value, networks advertised,
   when the advertisement was received, length |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                         relay-address                         |
     |                                                               |
     |                               |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |            options (variable number and so on.  Depending on the
   requirements length)   ....        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      msg-type   TBD

      prefix-length
                 The length of the client's invoking user, the client MAY initiate a
   configuration exchange with the server(s) immediately, or MAY defer
   this exchange until later.

10.4. Relay Behavior

   For this discussion, the Relay is assumed to have been configured
   with some list of server destination addresses, which may be unicast, prefix in the FF05::1:3 (All DHCP Servers) multicast address, or some other
   multicast address selected by the network administrator.
10.4.1. Relaying of Solicit messages

   When a Relay receives a valid Solicit message, it places in the IP
                 ``relay-address'' field.

      relay-address
                 An address of assigned to the interface upon through which it received the Solicit
                 message
   in the ``relay-address'' field of the Solicit.  The Relay also places from the client was received.

      options    MUST include a ``Client message option''; see
                 section 22.4.

9.10. Server-forward message

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  msg-type TBD | prefix length |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                         relay-address                         |
     |                                                               |
     |                               |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |            options (variable number and length)   ....        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      msg-type   TBD
      prefix-length
                 The length of bits of that make up the subnet prefix for this in the address in the ``prefix-len'' field
                 ``relay-address'' field.

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

      options    MUST include a ``Server message option''; see
                 section 22.5.

9.11. Identity association

   An ``identity-association'' (IA) is a construct through which a
   server and a client can identify, group and manage IPv6 addresses.
   Each IA consists of the Solicit.

   The Relay then forwards this Solicit to the a UUID and a list of server
   destination associated IPv6 addresses that it has been configured with.
10.4.2. Relaying
   (the list may be empty).  A client associates an IA with one of Advertise messages

   When a Relay receives a valid Advertise message, it unicasts
   its interfaces and uses the
   message IA to the link-local address found in the ``client's link-local
   address'' field by way of the appropriate network interface.
10.5. Server Behavior

   For this discussion, the obtain IPv6 addresses for that
   interface from a server.

10. DHCP Server is assumed to have been configured in
   an implementation specific manner. Solicitation

   This configuration section describes how a client locates servers.  The behavior of
   client, server, and relay implementations is assumed to
   contain all network topology information for discussed, along with
   the DHCP domain, as well
   as messages they use.

   (Prefix advertisements have been deleted; see 23.9.)

10.1. Solicit Message Validation

   Clients MUST silently discard any necessary authentication information.
10.5.1. Receipt of received Solicit messages.

   Agents MUST silently discard any received Solicit messages

   Upon if
   the receipt of ``client-link-local-address'' field does not contain a valid Solicit message, the server first
   identifies the client's location within the DHCP domain.  If the
   ``relay-address'' and / or ``prefix-len'' fields
   link-local address.

10.2. Advertise Message Validation

   Servers MUST discard any received Advertise messages.

   Clients MUST discard any Advertise messages that meet any of the Solicit are
   zeroed, then
   following criteria:

     o The ``Transaction-ID'' field value does not match the value the
       client is attached to used in its Solicit message.

     o The ``client-link-local-address'' field value does not match the same link as
       link-local address of the server.
   If these fields are non-zero, then interface upon which the client exists on the same link
   as sent
       the network identified by these two fields.

   If administrative policy permits Solicit message.

10.3. Client Behavior

   Clients use the server Solicit message to respond discover DHCP servers configured
   to a client serve addresses on
   that link, the server will generate and send an Advertise message link to which the client.

10.5.2. client is attached.

   (Prefix advertisement by servers has been deleted; see section 23.9.)

10.3.1. Creation and sending of Advertise messages

   When creating an Advertise message, the server SHOULD start out
   with a buffer initialized with zeroed octets. Solicit message

   The server client sets the ``msg-type'' field to 2 1, and copies places the values
   link-local address of the following fields
   from the client's Solicit interface it wishes to configure in the Advertise message:

     o solicit-ID

     o client's link-local address

     o relay-address
   ``client-link-local-address'' field.  The server places one of its IP addresses (determined through
   administrator setting) in client sets all other
   fields to zero.

   The client sends the ``server-address'' field of Solicit message to the
   Advertise message. FF02::1:2  (All DHCP
   Agents) multicast address, destination port 547.  The server initializes the ``preference''
   field from its configuration information.  See section 15.3 for source port
   selection can be arbitrary, although it SHOULD be possible using a
   description of server preference.

   If the
   client requests subnet prefix extensions (by setting the ``P''
   bit in its Solicit) and the server implements and is configured configuration facility to
   provide prefix extensions, the server will generate and insert set a
   subnet prefix extension for each network specific source port value.

10.3.2. Time out and retransmission of Solicit Messages

   The client's first Solicit message on the client's link it is
   configured to manage.

   If interface MUST be delayed
   by a random amount of time between the ``relay-address'' field interval of MIN_SOL_DELAY and
   MAX_SOL_DELAY. This random delay desynchronizes clients which start
   at the same time (e.g., after a power outage).

   The client waits ADV_MSG_TIMEOUT, collecting Advertise message is zero, then
   the server unicasts the messages.
   If no Advertise message directly to messages are received, the client
   using retransmits
   the ``client's link-local address'' field value as destination
   address.  If Solicit, and doubles the ``relay-address'' field is non-zero, then ADV_MSG_TIMEOUT value.  This process
   continues until either one or more Advertise messages are received or
   ADV_MSG_TIMEOUT reaches the server
   unicasts ADV_MSG_MAX value.  Thereafter, Solicits
   are retransmitted every ADV_MSG_MAX until SOL_MAX_ATTEMPTS have been
   made, at which time the Advertise message directly client stops trying to DHCP configure the relay using the
   ``relay-address'' field value as
   interface.  An event external to DHCP is required to restart the destination address.
11. DHCP Client-Initiated Configuration Exchange

   A client initiates a
   configuration exchange with process.

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

10.3.3. Receipt of Advertise messages

   Upon receipt of one or more servers
   it has found through DHCP server solicitation whenever requested to
   do so by validated Advertise messages, the application layer in order to acquire configuration
   information of interest.
11.1. Request Message Validation

   Clients MUST silently discard any received Request messages.

   Agents MUST discard any Request client
   selects one or more Advertise messages in which based upon the ``client's
   link-local address'' field does not contain a valid link-local
   address.

   Relays MUST discard any received Request following
   criteria.

    -  Those Advertise messages in which with the
   ``relay-address'' field highest server preference
       value does not match any of the relay's
   addresses.

   Servers MUST discard any received Request message which meets any (see section 14.4) are preferred over all other Advertise
       messages.

    -  Within a group of Advertise messages with the following criteria:

     o The ``server-address'' field value does not match any same server
       preference value, a client MAY select those servers whose
       Advertise messages advertise information of interest to
       the
       server's addresses.

     o If client.  For example, one server may be advertising the ``relay-address'' field is set, and that field's value
       does not contain
       availability of IP addresses which have an address of sufficient scope as of
       interest to be
       reachable by the server.

     o The ``extensions'' field contains an authentication extension,
       and client.

   Once a client has selected Advertise message(s), the client will
   typically store information about each server, such as server cannot successfully authenticate
   preference value, addresses advertised, when the client.
11.2. Reply Message Validation

   Servers MUST silently discard any received Reply messages.

   Clients MUST discard any Reply message that meets any of advertisement was
   received, and so on.  Depending on the
   following criteria:

     o The ``transaction-ID'' field value does not match requirements of the value client's
   invoking user, the client used in its Request MAY initiate a configuration exchange with
   the server(s) immediately, or Release message.

     o The ``client's link-local address'' field value does not match MAY defer this exchange until later.

10.4. Relay Behavior

   For this discussion, the link-local address Relay may be configured to use a list of the interface upon
   server destination addresses, which may include unicast addresses,
   the client
       sent in its Request FF05::1:3 (All DHCP Servers) multicast address, or Release other
   multicast addresses selected by the network administrator.  If
   the Relay has not been explicitly configured, it will use the
   FF05::1:3 (All DHCP Servers) multicast address as the default.

10.4.1. Relaying of Solicit messages

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

     o  The Reply message contains client Solicit message is carried as the
   payload of a ``client-message'' option.  The relay places an authentication extension, and address
   from the
       client's attempt to authenticate interface on which the Solicit message fails.

   Relays MUST discard any Reply message that meets any of was received in the following
   criteria:

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

     o The
   ``relay-address'' field value does not contain and the relay's prefix length for that address on the same link as in
   the client.

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

11.3. Release Message Validation

   Clients MUST silently discard any received Release messages.

   Agents MUST discard any Release Relay then sends the Relay-forward
   message to the list of server destination addresses that meets any it has been
   configured with.

10.4.2. Relaying of Advertise messages

   When the
   following criteria:

     o The ``transaction-ID'' field contains relay receives a value not Relay-reply message, it extracts the server
   message from the ``server-message'' option and forwards the server
   message to the address in the
       1024--65535 range.

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

   Relays MUST discard any received Release message that meets any of in
   the following criteria:

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

     o server message.  The ``X-address'' field value does not match any of relay forwards the relay's
       addresses.

   Servers MUST discard any received Release server message which meets any of through
   the following criteria:

     o The ``X-address'' interface identified in the ``relay-address'' field does not contain in the
   Relay-reply message.

10.5. Server Behavior

   For this discussion, the Server is assumed to have been configured in
   an address of sufficient
       scope as implementation specific manner.  This configuration is assumed to
   contain all network topology information for the DHCP domain, as well
   as any necessary authentication information.

10.5.1. Receipt of Solicit messages

   If the server receives a Solicit message, the client must be reachable by on the
   same link as the server.

     o The ``extensions'' field contains an authentication extension,
       and  If the server cannot successfully authenticate receives a Relay-forward
   message containing a Solicit message, the client.
11.4. Client Behavior

   A client will generate one or more Request messages when prompted by must be on the application layer in order to acquire configuration information.
   A client may initiate such an exchange automatically in order
   link to
   acquire which the necessary network parameters to communicate with nodes
   off-link.  The client uses prefix identified by the server ``relay-address'' and relay address information
   from previous Advertise message(s) for use
   ``prefix-length'' fields in delivering Request
   message(s).  Note that a client may request configuration information the Relay-forward message is assigned.
   The server records the ``relay-address'' field from one or more servers at any time.

   A client uses the Release Relay-forward
   message in and extracts the management of releasable
   resources when:

     o The client has determined through a resource-specific manner
       that solicit message from the resource assigned by ``client-message''
   option.

   If administrative policy permits the server is already in use by to respond to a
       different client.

     o The client has been instructed to release on
   that link, the resource prior server will generate and send an Advertise message to
   the lease expiration time since it is no longer needed.
11.4.1. client.

10.5.2. Creation and sending of Request Advertise messages

   When creating a Request message, the client SHOULD start out with
   a buffer initialized with zeroed octets.

   The client server sets the ``msg-type'' field to 3, 2 and places copies the link-local address values
   of the
   interface it wishes following fields from the client's Solicit to associate with the Advertise
   message:

     o transaction-ID

     o client-link-local-address

   The server places one of its IP addresses (determined through
   administrator setting) in the ``server-address'' field of the
   Advertise message.  The server sets the ``preference'' field
   according to its configuration information
   with in the ``client's link-local address'' field.

   Unless information.  See section 15.3 for a
   description of server preference.

   If the Request Solicit message is created was received in response to a
   Reconfigure-init Relay-forward message, the client generates
   server constructs a transaction
   ID in Relay-reply message with the range of 1024--65535 and inserts this value Advertise message
   in the
   ``transaction-ID'' field.

   The client places the address payload of the destination a ``server-message'' option.  The server in the
   ``server-address'' field.

   If the client is not on the same link as the destination
   server, unicasts
   the client places Relay-reply message to the appropriate relay's address in the ``relay-address'' field.

   If the client is acquiring configuration information on field
   from the interface
   for Relay-forward message.

   If the first time, Solicit message was received directly by the client SHOULD set server, the ``C'' bit in
   server unicasts the
   header.  How Advertise message directly to the client determines if this is using
   the first configuration
   attempt on ``client-link-local-address'' field value as the destination
   address.  The Advertise message MUST be unicast through the interface is implementation-specific.  A client may
   implement a cache of configuration information
   on a per-interface
   basis; if that cache does not exist, that client would set the
   ``C'' bit.  Clients which do not implement caching of per-interface
   configuration information MUST always set the ``C'', and include
   any extensions carrying releasable resources received from earlier
   configuration exchanges Solicit message was received.

   DISCUSSION:

      (From Ted Lemon) There is a danger in using Solicit versus
      DHCPDISCOVER: in the extensions field of the Request.

   If Solicit paradigm, the client has determined through an implementation-specific
   manner that to
      choose the client implementation itself has restarted, DHCP server before it MUST
   set the ``R'' bit in the header.  After the first successful exchange
   with the server, knows if the client MUST NOT set DHCP server
      will give it an IP address, or which addresses the ``R'' bit in subsequent
   Request messages.

   Client considerations for extensions are now considered (see server is
      willing to assign to the
   ``extensions document'', [2] for client.  It may be that there are
      two or more details).

   If DHCP servers owned by the same administrative
      domain, and both are theoretically willing to give the
      client already addresses, but only one actually has an IP address of sufficient scope any addresses to
   directly reach the server, then the
      give.

11. DHCP Client-Initiated Configuration Exchange

   A client SHOULD unicast uses the Request Request-Reply message exchange to acquire
   configuration information of interest.  The client may initiate the server.  Otherwise, if
   configuration exchange as part of the server is off-link, operating system configuration
   process or when requested to do so by the application layer.

   A client
   unicasts uses the Request Release-Reply message exchange to indicate to the appropriate relay.

11.4.2. Time out and retransmission of Request Messages

   The
   DHCP server that the client waits REP_MSG_TIMEOUT milliseconds, collecting
   Reply messages.  If will no Reply messages are received, longer be using the client
   retransmits addresses in
   the released IA.

11.1. Request with Message Validation

   Clients MUST silently discard any received Request messages.

   Agents MUST discard any Request messages in which the same transaction-ID, and doubles
   ``client-link-local-address'' field does not contain a valid
   link-local address.

   Servers MUST discard any received Request message which meets any of
   the REP_MSG_TIMEOUT value, and waits again. following criteria:

     o The client continues
   this process until a ``server-address'' field value does not match any of the
       server's addresses.

     o The ``options'' field contains an authentication option, and the
       server cannot successfully authenticate the client.

11.2. Reply is Message Validation

   Servers MUST silently discard any received or REQUEST_MSG_ATTEMPTS
   unsuccessful attempts have been made, at which time Reply messages.

   Clients MUST discard any Reply message that meets any of the
   following criteria:

     o The ``transaction-ID'' field value does not match the value the
       client MUST
   abort the configuration attempt. used in its Request or Release message.

     o The ``client-link-local-address'' field value does not match the
       link-local address of the interface upon which the client SHOULD report sent in
       its Request or Release message.

     o The Reply message contains an authentication option, and the abort
   status
       client's attempt to authenticate the application layer.

   Default and initial values for REP_MSG_TIMEOUT and REQ_MSG_ATTEMPTS
   are documented message fails.

   Relays MUST discard any Relay-reply message in section 3.5.
11.4.3. Receipt of which the
   ``client-link-local-address'' in the encapsulated Reply message in response to does
   not contain a Request

   Upon valid link-local address.

11.3. Release Message Validation

   Clients MUST silently discard any received Release messages.

   Agents MUST discard any Release message in which the receipt of
   ``client-link-local-address'' field does not contain a valid Reply message, the client extracts the
   configuration information contained
   link-local address.

   Servers MUST discard any received Release message in which the Reply.  If the ``status''
   ``options'' field contains a non-zero value, an authentication option, and the client reports server
   cannot successfully authenticate the error status client.

11.4. Client Behavior

   A client will generate one or more Request messages to acquire
   configuration information.  A client may initiate such an exchange
   automatically in order to acquire the application layer.

   If necessary network parameters
   to communicate with nodes off-link.  The client uses the extensions field contains server
   address information from previous Advertise message(s) for use in
   constructing Request message(s).  Note that a client may request
   configuration information from one or more ``Reconfigure Multicast
   Address'' extensions (see ``extensions document'', ``Reconfigure
   Multicast Address Extension'' section [2]), the servers at any time.

   A client MUST join
   these multicast groups, and MUST monitor uses the UDP 546 port for
   Reconfigure Release message in the management of IAs when:

     o The client has determined through DAD or some other method that
       one or Reconfigure-init messages on more of the networks configured addresses assigned by DHCP.

   If the configuration information returned server in the Reply contains
   releasable resources, then the IA is
       already in use by a different client.

     o The client MUST take over lease management
   of has been instructed to release the resource.  A client MUST NOT request releasable resources
   unless it is prepared IA prior to appropriately manage the resource lease.
11.4.4. IA
       expiration time since it is no longer needed.

11.4.1. Creation and sending of Release Request messages

   When creating a Release message, the client SHOULD start out with
   a buffer initialized with zeroed octets.

   The client sets the ``msg-type'' field to 5, 3, and places the
   link-local address of the interface the configuration information it wishes to release is
   associated with acquire
   configuration information for in the ``client's link-local address'' ``client-link-local-address''
   field.

   The client generates a transaction ID in the range of
   1024--65535  and inserts this value in the
   ``transaction-ID'' field.

   The client includes extensions containing the releasable resources it
   is releasing in the ``extensions'' field.  The appropriate ``status''
   field in the extensions MUST be set to indicate the reason for the
   release.

   The client places the IP address of the destination server who allocated the
   resource(s) in the
   ``server-address'' field.

   If the client will have an appropriately scoped IP address after the
   release transaction is completed, the client clears the ``R'' bit
   and places this address in the ``X-address'' field.  If the client
   will not have an appropriately scoped IP address after the release
   transaction is completed, the

   The client sets the ``R'' bit and places
   the address of the adds any appropriate relay in the ``X-address'' field.

   If options, including one or more IA
   options (if the client is configured to use authentication, the client
   generates the appropriate authentication extension, and adds this
   extension to the ``extensions'' field.  Note requesting that the authentication
   extension MUST be the last extension in the ``extensions''
   field.  See the ``extension document'' for more details about the
   authentication extension [2]. server assign it some
   network addresses).  If the ``R'' bit is set, then the client does include any IA options,
   it MUST unicast the Release
   to the relay indicated in include the ``X-address'' field.  Otherwise, list of addresses the client unicasts the Release message directly to currently has
   associated with that IA. If the server indicated
   in client is requesting configuration of
   a new IA, the ``server-address'' field.
11.4.5. list of addresses MUST be empty.

11.4.2. Time out and retransmission of Release Request Messages

   The client waits REP_MSG_TIMEOUT milliseconds, collecting server will respond to the Request message with a Reply
   messages.
   message.  If no Reply messages are received, message is received within REP_MSG_TIMEOUT
   milliseconds, the client retransmits the Release, Request with the same
   transaction-ID, and doubles the REP_MSG_TIMEOUT value, and waits
   again.  The client continues this process until a Reply is received
   or
   REL_MSG_ATTEMPTS REQUEST_MSG_ATTEMPTS unsuccessful attempts have been made, at
   which time the client SHOULD MUST abort the release configuration attempt.  The
   client SHOULD return report the abort status to the application, if an application
   initiated the release. layer.

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

   Note that if the client fails to release the resource, the resource
   will be reclaimed by the server when the lease associated with it
   expires.

11.4.6.

11.4.3. Receipt of Reply message in response to a Release Request

   Upon the receipt of a valid Reply message, the client can consider extracts the
   Release event successful, and SHOULD return
   configuration information contained in the successful Reply.  If the ``status''
   field contains a non-zero value, the client reports the error status
   to the application layer, if an application initiated the release.
11.5. Relay Behavior

11.5.1. Relaying of Request or Release messages

   When a Relay receives a valid Request or Release message, it forwards
   it to layer.

   The client records the IP address found T1 and T2 times for each IA in the ``server-address'' field of Reply
   message.  The client records any addresses included with IAs in
   the Reply message.
11.6. Server Behavior

   For this discussion,  The client updates the Server is assumed to have been configured preferred and valid
   lifetimes for the addresses in an implementation specific manner the IA from the lifetime information
   in the IA option.  The client leaves any addresses that the client
   has associated with configuration the IA that are not included in the IA option
   unchanged.

   Management of interest
   to clients.  Such the specific configuration information MAY contain releasable
   resources such as IP addresses.
11.6.1. Receipt is detailed in
   the definition of Request each option, in section 22.

11.4.4. Creation and sending of Release messages

   Upon

   The client sets the receipt ``msg-type'' field to 5, and places the
   link-local address of a valid Request message from a client the server
   can respond to, (implementation-specific administrative policy
   satisfied) interface associated with the server scans configuration
   information it wishes to release in the extensions ``client-link-local-address''
   field.

   If

   The client generates a transaction ID and places this value in the
   ``transaction-ID'' field.

   The client has set includes options containing the IAs it is releasing in the ``C'' bit,
   ``options'' field.  The appropriate ``status'' field in the server options
   MUST release all
   releasable resources currently associated with be set to indicate the client's binding reason for the release.

   The client places the IP address of the server that do not appear allocated the
   address(es) in the ``extensions'' ``server-address'' field.

   If the client has set is configured to use authentication, the ``R'' bit, client
   generates the server MUST delete any
   transaction-ID cache entries it is maintaining for appropriate authentication option, and adds this client, if option
   to the server implements such a cache.

   Server considerations for extensions are now evaluated (see ``options'' field.  Note that the
   ``extensions document'', [2] authentication option MUST
   be the last option in the ``options'' field.  See section  22.7 for
   more details).

   If the configuration information to be returned to details about the authentication option.

   (The client
   includes releasable resources, always forwards Release messages to the server checks if through a binding
   already exists for the client.
   relay; see section 11.5.)

11.4.5. Time out and retransmission of Release Messages

   If so, the server examines the
   data records no Reply message is received within REP_MSG_TIMEOUT milliseconds,
   the binding to determine if client retransmits the client's
   Request is Release, doubles the REP_MSG_TIMEOUT
   value, and waits again.  The client continues this process until a retransmission of an earlier Request
   Reply is received or a new Request.
   Releasable resource identifiers are stored within the binding with REL_MSG_ATTEMPTS unsuccessful attempts have been
   made, at which time the transaction-ID used by client SHOULD abort the release attempt.
   The client SHOULD return the abort status to request the resource's
   assignment.  If application, if an
   application initiated the transaction-ID's match, this is a retransmission release.

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

   Note that if the server simply return client fails to release the contents of IA, the client's binding
   which satisfy its request.  If addresses
   assigned to the transaction-ID's do not match, IA will be reclaimed by the server records when the additional resources lease
   associated with it is assigning expires.

11.4.6. Receipt of Reply message in response to a Release

   Upon receipt of a valid Reply message, the
   existing binding with client can consider the new Request's transaction-ID.

   If
   Release event successful, and SHOULD return the client does not have successful status to
   the application layer, if an existing binding, application initiated the server creates release.

11.4.7. When a
   binding for the client and records should send a Request message

   The description of the resources it is assigning Request/Reply message exchange in this binding along with section
   makes no assumptions about the transaction-ID from timing or state of the client's Request.

   The server then constructs client when
   it initiates a Reply Request/Reply message exchange.  Sections 11.4.8
   through 11.4.10 describe when a client MAY initiate a Request/Reply
   message exchange.  The procedures for timeout and sends it to the
   client.
11.6.2. Receipt retransmission of Release
   Request messages

   Upon the receipt of are described in section 11.4.2.

11.4.8. Initialization

   If a client has no valid Release message, the server performs a
   lookup IPv6 addresses of sufficient scope to find the client's binding.  If the binding is found, the
   server examines the binding
   communicate with a DHCP server, it may a Request message to see if the resource(s) identified by
   the obtain
   new addresses.  The client includes one or more IAs in the Release message's extensions field are in fact
   assigned Request
   message, to the client.  If they are, which the server deletes these
   resources from the client's binding, making them available to other
   clients. assigns new addresses.  The server then generates a Reply message.  If a binding was
   found and the resources presented
   returns to the server were deleted from
   the client's binding, the server sets the ``status'' field IA(s) to
   ``Success''.  If no binding is found, the server sets the ``status''
   field to ``NoBinding''(section 3.4).
11.6.3. Creation and sending of Reply messages

   When creating client in a Reply message, message.

11.4.9. Confirming the server SHOULD start out with validity of IPv6 addresses

   Whenever a buffer initialized with zeroed octets.  The server sets the
   ``msg-type'' field client may have moved to 4 and copies the values a new link, its IPv6 addresses
   may no longer be valid.  Examples of the following fields
   from the client's Request or Release times when a client may have
   moved to the Reply message:

     o transaction-ID a new link include:

     o client's link-local address The client reboots

     o If the client's message The client is physically disconnected from a Request with a non-zero
       ``relay-address'' field value, the server sets the ``R'' bit in
       the Reply and copies the ``relay-address'' field value wired connection

     o The client returns from the
       Request to the Reply.  If the client's message is sleep mode

     o The client using a Release with
       the ``R'' bit set, the server sets the ``R'' bit in the Reply and
       sets the ``relay-agent'' field wireless technology changes cells

   In any situation when a client may have moved to a new link, the contents of the Release's
       X-address field.
   client MUST initiate a Request/Reply message exchange.  The server sets the ``status'' field appropriately (see client
   includes any IAs, along with the table addresses associated with those IAs,
   in section 3.4) based upon its Request message.  The server returns the results IAs with updated list
   of processing addresses and associated lifetimes.

11.4.10. Extending the client's
   request.

   If configured lifetimes on IPv6 addresses

   IPv6 addresses assigned to do so, a client through an IA use the same
   preferred and valid lifetimes as IPv6 addresses obtained through
   stateless autoconfiguration.  The server will include ``Reconfigure Multicast
   Address'' extensions (see ``extensions document'', ``Reconfigure
   Multicast Address Extension'' [2]), in Reply messages sent in
   response assigns preferred and valid
   lifetimes to a Request, informing the client of one or more multicast
   groups IPv6 addresses it should join assigns to facilitate the receipt of Reconfigure or
   Reconfigure-init messages.

   If an IA. To extend those
   lifetimes, the DHCP domain is using authentication, client sends a Request to the server will generate containing an authentication extension with
   ``IA option'' for the appropriate settings IA and add
   that extension as its associated addresses.  The server
   determines new lifetimes for the last extension addresses in the ``extensions'' field of IA according to
   the Reply message.

   If server's administrative configuration.  The server may also add
   new addresses to the ``relay-address'' field of IA. The server remove addresses from the Reply message is zero, then IA by
   setting the preferred and valid lifetimes of those addresses to zero.

   The server unicasts controls the Reply directly to time at which the client using the ``client's
   link-local address'' field value as destination address.  If the
   ``relay-address'' field is non-zero, then contacts the server unicasts the
   Reply directly
   to extend the relay using the ``relay-address'' field value
   as the destination address.

   If the server implements a transaction-ID cache, lifetimes on assigned addresses through the server would add T1 and
   T2 parameters assigned to an entry for IA. If the client to this cache.
12. DHCP Server-Initiated Configuration Exchange

   A server initiates a configuration exchange on behalf of the
   administrator of the DHCP domain.  An administrator may initiate such does not assign an exchange when new networks are added
   explicit value to the domain T1 or existing
   networks are T2 for an IA, T1 defaults to be renumbered.  Other examples include changes in 0.5 times the location of directory servers, addition
   shortest preferred lifetime of new services such as
   printing, any address assigned to the IA and availability
   T2 defaults to 0.875 times the shortest preferred lifetime of new software (system or application).
12.1. Reconfigure Message Validation

   Agents MUST silently discard any received Reconfigure messages.

   Clients MUST discard any Reconfigure
   address assigned to the IA.

   At time T1 for an IA, the client initiates a Request/Reply message that meets
   exchange to extend the lifetimes on any of addresses in the
   following criteria:

     o IA. The ``transaction-ID'' field value is not within
   client includes an IA option with all addresses currently assigned
   to the 0--1023 range.

     o IA in its Request message.  The Reconfigure client unicasts this Request
   message contains to the server that originally assigned the addresses to the
   IA.

   At time T2 for an authentication extension, and IA (which will only be reached if the client's attempt server to authenticate
   which the Request message fails.

12.2. Reconfigure-reply Message Validation

   Clients and Relays MUST silently discard any received
   Reconfigure-reply messages.

   Servers MUST discard any Reconfigure-reply message that meets any of was sent at time T1 has not responded),
   the following criteria:

     o client initiates a Request/Reply message exchange.  The ``transaction-ID'' field value is not that same value client
   includes an IA option with all addresses currently assigned to the
       server used
   IA in its Reconfigure Request message.

     o  The ``server-address'' field value does not match the value client multicasts this message to
   the
       server placed in its Reconfigure message.
12.3. Reconfigure-init Message Validation

   Agents MUST silently discard any received Reconfigure-init messages.

   Clients MUST discard any Reconfigure-init messages that meets any FF02::1:2 (All DHCP Agents) multicast address.

11.5. Relay Behavior

11.5.1. Relaying of
   the following criteria:

     o Request or Release messages

   When a Relay receives a valid Request or Release message, it
   constructs a Relay-forward message.  The ``transaction-ID'' field value client message is not within carried
   as the 0--1023 range.

     o payload of a ``client-message'' option.  The Reconfigure-init message contains relay places an authentication
       extension,
   address from the interface on which the client message was received
   in the ``relay-address'' field and the client's attempt to authenticate prefix length for that
   address in the ``prefix-length'' field.  The Relay then forwards the
   Relay-forward message
       fails.
12.4. to the list of server destination addresses
   that it has been configured with.

11.6. Server Behavior

   For this discussion, the server Server is assumed to have a
   implementation-specific interface by which been configured in
   an administrator
   may initiate a reconfiguration event implementation specific manner with some set configuration of interest to
   clients.

   There are two methods

11.6.1. Receipt of Request messages

   Upon the receipt of initiating a reconfiguration event.  Each
   has its advantages:

      Reconfigure with payload
                   This method uses valid Request message from a client the Reconfigure message.  Items
                   to be changed are included as extensions in server
   can respond to, (implementation-specific administrative policy
   satisfied) the
                   ``extensions'' server scans the options field.

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

   DISCUSSION:

      This method MUST NOT section needs text about managing IAs and determining
      options to be used returned to reconfigure releasable resources.  Examples client.

11.6.2. Receipt of
                   information which can be reconfigured using this
                   method Release messages

   Upon the receipt of a valid Release message, the server examines the
   IAs and the addresses in the IAs for validity.  If the IAs in the
   message are DNS domain in a binding for the client and servers, NTP servers, other
                   name service parameters. the addresses in the IAs
   have been assigned by the server to those IA, the server deletes
   the addresses from the IAs and makes the addresses available for
   assignment to other clients.

   The server then generates a Reply message.  If all of the IAs were
   valid and
                   sends the Reconfigure message; clients respond with
                   Reconfigure-reply messages.

      Reconfigure Trigger
                   This method uses addresses successfully released,, the Reconfigure-init message.  When
                   a client receives a Reconfigure-init message, it
                   initiates a Request/Reply exchange with server sets the server.
                   Any kind
   ``status'' field to ``Success''.  If any of resource can be reconfigured using this
                   method, including releasable resources.  An example the IAs were invalid or
   if any of an releasable resource is an IP address.

   A the addresses were not successfully released, the server can send Reconfigure
   releases none of the addresses in the message and Reconfigure-init messages only sets the ``status''
   field to
   those clients who have an address ``NoBinding''(section 3.4).

   DISCUSSION:

      What is the behavior of sufficient scope to be reachable
   by the server.  Thus, those clients who have not requested server relative to a ``partially
      released'' IA; i.e., an IP
   address and IA for which some but not all
      addresses are off-link cannot be reconfigured by the server.

   Before initiating released?

      Can a reconfigure process, client send an empty IA to release all addresses in
      the IA?

      If the IA becomes empty - all addresses are released - can
      the server SHOULD discard any record of the IA?

11.6.3. Creation and sending of Reply messages

   DISCUSSION:

      XXX - This section needs to be
   configured with a REC_THRESHOLD threshold value which represents fixed (see section 11.6.1).

   The server sets the ``msg-type'' field to 4 and copies the percentage values
   of clients successfully reconfigured before the
   reconfigure process is considered a success.  See following fields from the client's Request or Release to the
   Reply message:

     o transaction-ID

     o client's link-local address

     o server-address

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

   If the Request or Release message from the
   default setting of REC_THRESHOLD. Note that client was originally
   received by the server, the server MUST be able
   to determine unicasts the set of clients that should receive Reply message to the reconfigure,
   link-local address in order to determine when the reconfigure process is complete.
12.4.1. Creation and sending of Reconfigure messages

   When creating a Reconfigure message, ``client-link-local-address'' field.

   If the server SHOULD start out
   with message was originally received in a buffer initialized with zeroed octets.  The Forward-request or
   Forward-release message from a relay, the server sets places the
   ``msg-type'' Reply
   message in the options field to 6.  The server generates of a transaction-ID
   from the 0--1023 range Response-reply message and inserts it in unicasts
   the ``transaction-ID''
   field.  The server places its message to the relay's address (of appropriate scope) in from the
   ``server-address'' field.

   The original message.

12. DHCP Server-Initiated Configuration Exchange

   A server then generates extensions for initiates a configuration exchange on behalf of the non-releasable resources
   administrator of the DHCP domain.  An administrator may initiate such
   an exchange when new links are added to the domain or existing links
   are to be changed and places them renumbered.  Other examples include changes in the ``extensions'' field.

   If location
   of directory servers, addition of new services such as printing, and
   availability of new software (system or application).

   DISCUSSION:

      Changed ``networks'' to ``links'' here (ed.).  Why would
      adding new links cause a server-initiated configuration
      exchange?

12.1. Reconfigure Message Validation

   Reconfigure messages have been deleted; see section 23.2.

12.2. Reconfigure-reply Message Validation

   Reconfigure-reply messages have been deleted; see section 23.2.

12.3. Reconfigure-init Message Validation

   Agents MUST silently discard any received Reconfigure-init messages.

   Clients MUST discard any Reconfigure-init messages that do
   not contain an authentication option or that fail the DHCP domain is using authentication, client's
   authentication check.

12.4. Server Behavior

   For this discussion, the server will generate is assumed to have a
   implementation-specific interface by which an authentication extension administrator
   may initiate a reconfiguration event with the appropriate settings and add
   that extension as the last extension in the ``extensions'' field some set of
   the Reconfigure message.

   The clients.

   A server multicasts the Reconfigure sends a Reconfigure-init message to one or more
   Reconfigure Multicast Addresses previously sent as extensions trigger a client to the
   clients.  Note that
   initiate immediately a Request/Reply message exchange with the
   server.  A server MAY unicast Reconfigure message(s) can send Reconfigure-init messages only to
   specific those
   clients by walking its list who have an address of bindings sufficient scope to determine the
   unicast address(es) of the clients.  Whether or not be reachable by
   the Reconfigure
   is multicast or unicast is an implementation detail.

   A server waits for Reconfigure-reply messages from server.  Thus, those clients confirming
   that they who have received the Reconfigure.

12.4.2. Time out not requested an IP address
   and retransmission of Reconfigure messages

   The server waits RECREP_MSG_TIMEOUT milliseconds, collecting
   Reconfigure-reply messages.  If all the expected Reconfigure-reply
   messages are received, then the reconfigure process is successful.
   If some or all of off-link cannot be reconfigured by the expected Reconfigure-reply server.

   DISCUSSION:

      It would be possible to forward Reconfigure-init messages are not
   received, then
      through relays if the server retransmits records the Reconfigure, client's link-local
      address and doubles the RECREP_MSG_TIMEOUT value, relay's address from the client's Request
      message.

12.4.1. Creation and waits again.  The server continues
   this process until all Reconfigure-reply sending of Reconfigure messages

   Reconfigure messages are received or
   REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which time
   the server SHOULD abort the reconfigure process.  The server SHOULD
   log the result of the reconfigure process.

   Default and initial values for RECREP_MSG_TIMEOUT and
   REC_MSG_ATTEMPTS are documented in deleted; see section 3.5. 23.2.

12.4.2. Time out and retransmission of Reconfigure messages

12.4.3. Receipt of Reconfigure-reply messages

   Upon receipt of a valid Reconfigure-reply message, the server
   removes that client from the list of clients it is expecting a
   Reconfigure-reply message from.

12.4.4. Creation and sending of Reconfigure-init messages

   When creating a Reconfigure-init message, the server SHOULD start
   out with a buffer initialized with zeroed octets.

   The server sets the ``msg-type'' field to 8.  The server generates
   a transaction-ID
   from the 0--1023 range and inserts it in the ``transaction-ID'' field.
   The server places its address (of appropriate scope) in the
   ``server-address'' field.

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

   If the DHCP domain is using authentication, the

   The server will generate MUST include an authentication extension option with the appropriate
   settings and add that extension option as the last extension option in the ``extensions'' ``options''
   field of the Reconfigure-init message.

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

   The server multicasts may either unicast the Reconfigure-init message to one
   client or multicast the message to one or more Reconfigure Multicast
   Addresses previously sent as extensions options to the clients.  Note that a  The server MAY
   may unicast Reconfigure-init
   message(s) messages to specific clients by walking its list of bindings more than one client
   concurrently; for example, to
   determine reliably reconfigure all clients, the
   server will unicast address(es) of the clients.  Whether or not the a Reconfigure-init is multicast or unicast is an implementation detail.

   A message to each client.

   If the server unicasts to one or more clients, it waits for a Request
   message from each client those clients confirming that
   they have it has received the
   Reconfigure-init and are thus initiating a Request/Reply transaction
   with the server.  The server can determine that a Request message is
   in response to a Reconfigure-init because the transaction-ID in the
   Request will be the same value as was used in the Reconfigure-init
   message.

   If the server multicasts the Reconfigure-init message, it must use
   some TBD authentication mechanism that can authenticate the server to
   multiple clients.  There is no reliability mechanism for multicast
   Reconfigure-init messages.  A server might use multicast in the
   case where it does not have a list of its clients; for example, a
   server that distributes configuration information to clients using
   stateless autoconfiguration might not keep a list of clients it has
   communicated with.

12.4.5. Time out and retransmission of Reconfigure-init messages

   It the server does not receive a Request message from the client
   in RECREP_MSG_TIMEOUT milliseconds, the server retransmits
   the Reconfigure-init message, doubles the RECREP_MSG_TIMEOUT
   value and waits again.  The server uses continues this process until
   REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which point
   the same algorithm server SHOULD abort the reconfigure process.

   Default and configuration initial values for
   sending Reconfigure-init messages as it does with Reconfigure
   messages.  See Section 12.4.2 for this algorithm. RECREP_MSG_TIMEOUT and
   REC_MSG_ATTEMPTS are documented in section 3.5.

12.4.6. Receipt of Request messages

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

   The server generates and sends Reply message(s) to the client as
   described in section 11.6.3, including in the ``extension'' ``option'' field new
   values for configuration parameters.  If the extensions include
   releasable resources, the server will include two extensions for each
   resource - one with the original values with the lease times set to
   zero, and another with new values and lease times.  Note that the
   server can terminate the client's ability to use a resource simply by
   including only the first extension value.

12.5. Client Behavior

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

12.5.1. Receipt of Reconfigure Reconfigure-init messages

   Upon receipt of a valid Reconfigure Reconfigure-init message, the client extracts
   the configuration parameters contained in the ``extensions''
   field, and notifies the application layer that new values for these
   parameters are available.  The client then generates and sends
   initiates a
   Reconfigure-reply message to Request/Reply transaction with the server.

12.5.2. Creation and sending of Reconfigure-reply Request messages

   When creating responding to a Reconfigure-reply message, Reconfigure-init, the client SHOULD start creates and
   sends the Request message in exactly the same manner as outlined in
   section 11.4.1 with the following differences:

      transaction-ID
                The client copies the transaction-ID from the
                Reconfigure-init message into the Request message.

      IAs
                The client includes IA options containing the addresses
                the client currently has assigned to those IAs for the
                interface through which the Reconfigure-init message was
                received.

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

12.5.3. Time out with a buffer initialized with zeroed octets.  The client sets
   the ``msg-type'' field to 7, and places the link-local address retransmission of
   the interface upon which it received the Reconfigure message in
   the ``client's link-local address'' field. Request messages

   The client copies uses the
   values same variables and retransmission algorithm as it
   does with Request messages generated as part of a client-initiated
   configuration exchange.  See section 11.4.2 for details.

12.5.4. Receipt of Reply messages

   Upon the following fields from the Reconfigure message to receipt of a valid Reply message, the
   Reconfigure-reply message:

     o transaction-ID

     o server-address

   The client sets the ``status'' field appropriately (see the table
   in section 3.4) based upon extracts the results
   contents of processing the server's
   reconfigure-reply. ``option'' field, and sets (or resets) configuration
   parameters appropriately.  The client places the address of records and updates the destination server
   lifetimes for any addresses specified in IAs in the
   ``server-address'' field. Reply message.
   If the client is configured to use authentication, configuration parameters changed were requested by the client
   generates
   application layer, the appropriate authentication extension, and adds this
   extension to client notifies the ``extensions'' field.  Note that application layer of the authentication
   extension MUST
   changes using an implementation-specific interface.

13. Using DHCP for network renumbering

   This section has been deleted (to be moved to ``Notes about DHCP''
   doc?).

14. DHCP Client Implementor Notes

   This section provides helpful information for the last extension in the ``extensions'' field.

   The client delays the sending implementor
   regarding their implementations.  The text described here is not part
   of the Reconfigure-reply by some
   random value selected in the range protocol, but rather a discussion of REC_REP_MIN and REC_REP_MAX
   seconds.  This delay helps reduce implementation features
   we feel the load on implementor should consider during implementation.

14.1. Primary Interface

   Since configuration parameters acquired through DHCP can be
   interface-specific or more general, the server generated client implementor SHOULD
   provide a mechanism by
   processing large numbers of Reconfigure-reply messages.

   Default and initial values for REC_REP_MIN and REC_REP_MAX are
   documented in section 3.5. which the client implementation can be
   configured to specify which interface is the primary interface.  The
   client unicasts SHOULD always query the Reconfigure-reply to DHCP data associated with the address identified primary
   interface for non-interface specific configuration parameters.  An
   implementation MAY implement a list of interfaces which would be
   scanned in order to satisfy the ``server-address'' field.  Sending general request.  In either case, the Reconfigure-reply
   completes
   first interface scanned is considered the reconfiguration process for primary interface.

   By allowing the client.

12.5.3. Receipt of Reconfigure-init messages

   Upon receipt specification of a valid Reconfigure-init message, primary interface, the client
   initiates a Request/Reply transaction with the server.
12.5.4. Creation and sending of Request messages

   When responding to a Reconfigure-init,
   implementor identifies which interface is authoritative for
   non-interface specific parameters, which prevents configuration
   information ambiguity within the client creates implementation.

14.2. Advertise Message and
   sends the Request message in exactly Configuration Parameter Caching

   If the same manner as outlined in
   section 11.4.1 with hardware the following differences:

      transaction-ID
                   The client copies is running on permits it, the transaction-ID from implementor
   SHOULD provide a cache for Advertise messages and a cache of
   configuration parameters received through DHCP. Providing these
   caches prevents unnecessary DHCP traffic and the
                   Reconfigure-init message into subsequent load
   this generates on the Request message.

      Pause before sending Request servers.  The client pauses before sending the Request for implementor SHOULD provide a random value within
   configuration knob for setting the range REC_REP_MIN and
                   REC_REP_MAX seconds, as outlined in section 12.5.2.
12.5.5. amount of time the cache(s) are
   valid.

14.3. Time out and retransmission of Request messages

   The client uses the same variables

   Note that the client time out and retransmission algorithm as it
   does with Request messages generated as part of a client-initiated
   configuration exchange.  See variables outlined
   in section 11.4.2 for details.
12.5.6. Receipt of Reply messages

   Upon the receipt of a valid Reply message, the client extracts
   the contents of 3.5 can be configured on the ``extension'' field, server and sets (or resets)
   configuration parameters appropriately.  If the configuration
   parameters changed were requested by the application layer, sent to the client notifies
   through the application layer use of the changes using an
   implementation-specific interface.  If the resources changed are
   releasable, the ``DHCP Retransmission Parameter Option'',
   which is documented in section 22.6.  A client makes the appropriate adjustments implementation SHOULD
   be able to its
   management of the leases of reset these resources.
13. Using DHCP variables using the values from this option.

14.4. Server Preference

   A client MUST wait for network renumbering

   An administrator can use DHCP to renumber links within her SRVR_PREF_WAIT seconds after sending a DHCP
   domain through two techniques, passive renumbering and active
   renumbering.

13.1. Passive Renumbering

   The administrator can configure her servers
   Solicit message to return relatively
   short preferred collect Advertise messages and valid lifetimes for the IP addresses she
   makes available to clients.  When she determines that she'd like
   to renumber a network, she configures her servers through compare their
   preferences (see section 15.3), unless it receives an
   implementation-specific manner to disallow Advertise
   message with a preference of 255.  If the extension client receives an
   Advertise message with a preference of 255, then the IP
   address lifetimes client MAY act
   immediately on that Advertise without waiting for any more additional
   Advertise messages.

15. DHCP Server Implementor Notes

   This section provides helpful information for the server implementor.

15.1. Client Bindings

   A server implementation MUST use the original network, IA's UUID and adds the new network prefix
   specification from which the client sent its Request message(s) as an
   index for finding configuration data parameters assigned to the server's database.

   The clients on the original network will fail client.
   While it isn't critical to acquire lifetime
   extensions on their IP addresses, and will request and acquire
   IP addresses from keep track of the new network when other parameters
   assigned to a client, the valid lifetime server MUST keep track of the
   original IP addresses approaches expiration.

   When the lifetimes it
   has assigned to an IA.

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

   The client bindings MUST be considered renumbered.
13.2. Active Renumbering stored in non-volatile storage.

   The administrator can force server implementation should provide policy knobs to control
   whether or not the renumbering of networks in her DHCP
   domain lifetimes on assigned addresses are renewable, and
   by using the reconfigure feature of DHCP. She instructs her
   servers of the network renumbering through how long.

15.2. Reconfigure-init Considerations

   A server implementation MUST provide an implementation-specific
   interface.  The servers in interface to the domain will generate Reconfigure-init
   messages, which will cause
   administrator for initiating reconfigure-init events.

   A server implementation may provide a mechanism for allowing the
   specification of how many clients to initiate comprise a Request/Reply
   transaction with reconfigure multicast
   group.  This enables the server.  The servers will include two IP address
   extensions for each IP address being changed. administrator to control the hit a server
   takes when a reconfigure-init event occurs.

15.3. Server Preference

   The first will contain server implementation SHOULD allow the setting of a server
   preference value by the original IP address, administrator.  The server preference
   variable is an unsigned single octet value (0--255), with the preferred lowest
   preference being 0 and valid lifetimes set
   to zero.  The second will contain the new IP address, highest 255.  Clients will choose higher
   preference servers over those with non-zero
   preferred and valid lifetimes.

   A server implementation MAY permit the administrator lower preference values.  If you
   don't choose to implement this feature in your server, you MUST set
   the
   original IP address lifetimes to some small value greater than zero, server preference field to allow applications running on 0 in the client to orderly transfer Advertise messages generated
   by your server.

15.4. Request Message Transaction-ID Cache

   In order to
   the new network over time.
14. DHCP Client Implementator Notes improve performance, a server implementation MAY include
   an in memory transaction-ID cache.  This section provides helpful information for the client implementor
   regarding their implementations.  The text described here cache is not part
   of indexed by client
   binding and transaction-ID, and enables the protocol, but rather server to quickly
   determine whether a discussion of implementation features
   we feel the implementor should consider during implementation.

14.1. Primary Interface

   Since configuration parameters acquired through DHCP can be
   interface-specific Request is a retransmission or more general, a new Request
   without the client cost of a database lookup.  If an implementor chooses to
   implement this cache, then they SHOULD provide a mechanism by which the client implementation can be
   configured configuration knob
   to specify which interface is tune the primary interface.  The
   client SHOULD always query lifetime of the cache entries.

16. DHCP data associated with the primary
   interface for non-interface specific configuration parameters.  An Relay Implementor Notes

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

   If a relay receives an ICMP message in order response to satisfy the general request.  In either case, the
   first interface scanned is considered the primary interface.

   By allowing the specification of a primary interface, DHCP message it
   has forwarded, it SHOULD log this event.

17. Open Issues for Working Group Discussion

   This section contains some items for discussion by the client
   implementor identifies which interface working group.

17.1. Authentication

   Authentication is authoritative for
   non-interface specific parameters, not discussed in this document.

17.2. DHCP-DNS interaction

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

17.3. Release vs.  Decline

   Should there be a separate Decline message through which prevents configuration
   information ambiguity within the client implementation.
14.2. Advertise Message and Configuration Parameter Caching

   If the hardware
   informs the client server that it has discovered an address that is running on permits it, in use
   by some other host?

17.4. Request messages

   In DHCPv4, there has been much confusion about overloading
   DHCPREQUEST with the implementor
   SHOULD provide a cache actions of initial address allocation
   (INIT), address confirmation (INIT-REBOOT), and extending leases
   (RENEW/REBIND).

   The model for Advertise DHCPv6 messages and a cache described in section 11 also uses one
   type of message, Request, in each of
   configuration parameters received through DHCP. Providing these
   caches prevents unnecessary DHCP traffic and the subsequent load scenarios in sections 11.4.8
   through 11.4.10.  The DHCPv6 specification in this generates on document does not
   differentiate the servers.  The implementor SHOULD provide actions taken by a
   configuration knob for setting server based on different times
   at which a client might initiate a Request/Reply exchange with a
   server.  That is, the amount description of time the cache(s) are
   valid.
14.3. Time out and retransmission variables

   Note that the client time out and retransmission variables outlined server actions in section 3.5 can be configured 11.6.1
   does not differentiate among Requests received from clients based on
   the server and sent to the client behavior described in sections 11.4.8 through the use 11.4.10.

   It may be necessary to define different server behaviors for each of
   the ``DHCP Retransmission Parameter Extension'',
   which is documented client scenarios.  For example, in the ``extensions document'' [2].  A client
   implementation SHOULD be able address-reconfirmation
   scenario (section 11.4.9), servers cannot safely assign new addresses
   to reset these variables using a client.  The reconfirmation Request is broadcast to multiple
   servers, which cannot coordinate the
   values from assignment of any addresses.
   Therefore, in this extension.
14.4. Server Preference

   A client MUST wait for SRVR_PREF_WAIT seconds after sending a DHCP
   Solicit message scenario, servers can only acknowledge or deny the
   validity of addresses but cannot allocate any new addresses.

17.5. Use of term ``agent''

   The term ``agent'', taken to collect Advertise messages and compare their
   preferences (see section 15.3), unless it receives an Advertise
   message with a preference mean ``relay agent or server'', may be
   confusing.  ``relay agent or server'' might be clearer.

17.6. Use of 255.  If terms ``subnet'' and ``network''

   The term ``subnet'' has been eliminated from the client receives an
   Advertise message with document.  The term
   ``network'' is no longer used to describe a preference link, collection of 255, then the client MAY act
   immediately on that Advertise without waiting for any more additional
   Advertise messages.

15. DHCP Server Implementator Notes links
   or collection of IPv6 addresses.

18. Security

   This section provides helpful information for document references an ``authentication option'' which is TBD.

   DISCUSSION:

      Based on the server implementor.
15.1. Client Bindings

   A server implementation can use discussion of security issues at the client's link-local address
      8/31/00 design team teleconference and subsequent
      DHC WG mailing list discussion, DHCPv6 will use
      the subnet prefix specification security model from which the client sent its
   Request message(s) DHCPv4, as an index for finding configuration parameters
   assigned described in
      draft-ietf-dhc-authentication-15.txt.

19. Year 2000 considerations

   Since all times are relative to the client.  While it isn't critical to keep track current time of which clients were given information (resources) that isn't
   releasable, it IS critical for the server transaction,
   there is no problem within the DHCPv6 protocol related to keep track any
   hardcoded dates or two-digit representation of which
   client it has assigned releasable resources.  The server MUST
   include the transaction-ID from the client's Request along with the releasable resource identifier(s) within current year.

20. IANA Considerations

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

   Section 3.1 lists several multicast addresses used by DHCP.

   This is
   done so document also defines several status codes that are to
   be returned with the server can detect whether a client Request is a
   retransmission of an earlier Request or an entirely new Request. Reply and Reconfigure-reply messages (see
   sections 9.4 and 9.7).  The server should periodically scan its bindings non-zero values for releasable
   resources whose leases have expired.  When the server finds expired
   resource assignments, it MUST delete these assignments, thereby
   making these resources available to other clients.

   The client bindings MUST be stored status codes
   which are currently specified are shown in non-volatile storage.

   The server implementation should provide policy knobs to control
   whether or not the lease on a releasable resource table in section 3.4.

   There is renewable, a DHCPv6 option described in section 22.6, which allows
   clients and servers to exchange values for some of the timing
   and retransmission parameters defined in section 3.5.  Adding new
   parameters in the future would require extending the values by how long.
15.2. Reconfigure Considerations

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

   A server implementation may provide parameters are indicated in the DHCP option.  Since there needs
   to be a mechanism for allowing list kept, the
   specification default values for each parameter should also
   be stored as part of how many clients comprise a reconfigure multicast
   group.  This enables the administrator list.

   All of these protocol elements may be specified to control the hit a server
   takes when a reconfigure event occurs.
15.3. Server Preference

   The server implementation SHOULD allow assume new values
   at some point in the setting of a server
   preference value future.  New values should be approved by the administrator.  The server preference
   variable is an unsigned single octet value (0--255), with
   process of IETF Consensus [10].

21. Acknowledgments

   Thanks to the lowest
   preference being 0 DHC Working Group for their time and input into the highest 255.  Clients will choose higher
   preference servers over those with lower preference values.  If you
   don't choose to implement this feature
   specification.  Ralph Droms and Thomas Narten have had a major
   role in your server, you MUST set shaping the server preference field to 0 in continued improvement of the Advertise messages generated protocol by your server.
15.4. Request Message Transaction-ID Cache

   In order their
   careful reviews.  Many thanks to improve performance, a server implementation MAY include
   an in memory transaction-ID cache.  This cache is indexed Matt Crawford, Erik Nordmark, Gerald
   Maguire, and Mike Carney for their studied review as part of the
   Last Call process.  Thanks also for the consistent input, ideas, and
   review by client
   binding (in alphabetical order) Brian Carpenter, Jack McCann, Yakov
   Rekhter, Matt Thomas, Sue Thomson, and transaction-ID, Phil Wells.

   Thanks to Steve Deering and enables Bob Hinden, who have consistently
   taken the server time to quickly
   determine whether a Request is a retransmission or a new Request
   without discuss the cost more complex parts of a database lookup.  If an implementor chooses the IPv6
   specifications.

22. DHCP options

   Options are used to
   implement this cache, then they SHOULD provide carry additional information and parameters
   in DHCP messages.  Every option shares a configuration knob
   to tune common base format, as
   described in section 22.1.

   this document describes the lifetime DHCP options defined as part of the cache entries.
16. base
   DHCP Relay Implementator Notes

   A relay implementation SHOULD allow specification.  Other options may be defined in the specification of a list of
   destination addresses for Solicit messages.  This list MAY contain
   any mixture of unicast addresses and multicast addresses.

   If a relay receives an ICMP message future in response to a
   separate document.

22.1. Format of DHCP message it
   has forwarded, it SHOULD log this event.
17. Open Issues for Working Group Discussion

   This section contains some items for discussion by options

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          option-code          |           option-len          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          option-data                          |
     |                      (option-len octets)                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code
                An unsigned integer identifying the working group.
17.1. Trade-offs:  Optional fields specific option type
                carried in DHCP messages

   You'll notice that the message formats have changed.  In particular,
   some of the optional fields are now required.  This will increase this option.

      option-len
                An unsigned integer giving the
   size length of DHCP messages in some cases, consuming network bandwidth and
   memory on the DHCP client (an issue for small devices such as PDAs). data in
                this option in bytes.

      option-data
                The changes were made data for the following reasons:

     o Fields that were used most of the time were made required.

     o Some fields that were optional were either made required or added
       to messages which previously didn't have them.  This was done for
       robustness reasons (receivers can validate that option; the message is
       for them, and in format of this data depends
                on the case definition of clients, know which interface the
       message option.

22.2. Identity association option

   The identity association option is intended for).

     o Simplicity.

   Please look at the messages as they are now defined, and let us know
   your opinion.
17.2. Use DHCPv4 authentication or used to carry an identity
   association, the current DHCPv6 method?

   Now that parameters associated with the DHCPv4 authentication draft is in last call, should
   we use IA and the technique described in that document addresses
   assigned to provide
   authentication for DHCPv6, or should we continue with the
   authentication technique currently documented in IA.

   The format of the extensions
   draft?
17.3. IA option is:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              TBD              |            variable           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            IA UUID                            |
     |                          (8 octets)                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              T1                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              T2                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   num-addrs   |              IPv6 address                     |
     +-+-+-+-+-+-+-+-+              (16 octets)                      |
     |                                                               |
     |                                                               |
     +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |   pref. len   |      preferred lifetime       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | pref. lifetime (cont.)        |        valid lifetime         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | valid lifetime (cont.)        |         IPv6 address          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                              ...                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code
                TBD

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

      IA UUID
                The Reconfigure Message and Subnet Prefix Extensions unique identifier for this IA; chosen by the client

      T1        The drafts currently specify that Releasable resources (such as an IP
   address) can only be reconfigured using time at which the client contacts the Reconfigure-init trigger
   message.  This was done for simplicity (enables clients server from
                which the addresses in the IA were obtained to perform
   DAD on extend
                the new address and return lifetimes of the appropriate result addresses assigned to the
   server) using IA.

      T2        The time at which the same mechanism as a standard Request/Reply/Release
   exchange.  This method also makes no assumptions about client contacts any available
                server to extend the
   charactistics lifetimes of the releasable resource.

   However, for IP addresses with interface IDs, one could send out
   two IP assigned
                to the IA.

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

      IPv6 address extensions, one
                An IPv6 address assigned to this IA.

      preferred lifetime
                The preferred lifetime for the old prefix and one associated IPv6 address.

      valid lifetime
                The valid lifetime for the
   new, and cause clients to change the prefix associated IPv6 address.

   The ``IPv6 address'', ``preferred lifetime'' and thus renumber over
   time.  This scheme avoids the added DHCP Request traffic - clients
   acknowledge with a Reconfigure-reply message.
17.4. ``R'' bit ``valid lifetime''
   fields are repeated for each address in Request message not needed?

   Now that the transaction-ID is stored along with IA option (as determined
   by the releasable
   resource identifier in a client's binding, ``num-addrs'' field).

   DISCUSSION:

      The details of the transaction-ID cache
   becomes format and the selection of an optional feature IA's UUID
      are TBD.

   DISCUSSION:

      An IA has no explicit ``lifetime'' or ``lease length'' of
      its own.  When the DHCP server implementation, not a
   requirement lifetimes of all of the protocol.  Should we do away with addresses in an
      IA have expired, the ``R'' bit?
18. Security Considerations

   Clients IA can be considered as having expired.
      T1 and servers often have T2 are included to authenticate the messages they
   exchange.  For instance, give servers explicit control over
      when a client recontacts the server may wish about a specific IA.

22.3. Option request option

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          option-code          |           option-len          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    requested-option-code-1    |    requested-option-code-2    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              ...                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      option-code TBD.

      option-len
                Variable; equal to be certain that a
   Request originated from twice the client identified by number of option codes
                carried in this option.

      option-data
                A list of the <link-local
   address, subnet-prefix> fields included within option codes for the Request options requested in
                this option.

22.4. Client message
   header.  Conversely, it is quite often essential for a option

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          option-code          |           option-len          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       DHCP client to
   be certain that the configuration parameters and addresses it has
   received were sent to it by an authoritative server.  Similarly, a
   server should only accept a Release message which seems                     |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code TBD

      option-len
                Variable; equal to be from
   one the length of its clients, if it has some assurance that the forwarded DHCP
                client actually
   did transmit the Release message.  Again, a client might wish to only
   accept Reconfigure or Reconfigure-init messages that are certain to
   have originated

      option-data
                The message received from a server with authority the client; forwarded verbatim
                to issue them.

   The IPv6 Authentication Header can provide security for DHCPv6
   messages when both endpoints have a suitable IP address.  However,
   a client often has only a link-local address, and such an address
   is not sufficient for a the server.

22.5. Server message option

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          option-code          |           option-len          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       DHCP server which is off-link.  In those
   circumstances message                     |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code TBD
      option-len
                Variable; equal to the relay is involved, so that length of the forwarded DHCP
                server message.

      option-data
                The message MUST
   have received from the relay's address in server; forwarded verbatim
                to the IP destination address field, even
   though client.

22.6. Retransmission parameter option

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          option-code          |           option-len          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          option-data                          |
     |                      (option-len octets)                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code
                An unsigned integer identifying the client aims to deliver specific option type
                carried in this option.

      option-len
                An unsigned integer giving the message to length of the server.  The
   DHCP Client-Server Authentication Extension [2] is intended to be
   used data in these circumstances.

   Note that, if a client receives a DHCP message which fails
   authentication, it should continue to wait
                this option in bytes.

      option-data
                The data for another message which
   might be correctly authenticated just as if the failed message had
   never arrived; however, receiving such failed messages SHOULD be
   logged.
19. Year 2000 considerations

   Since all times are relative to option; the current time format of this data depends
                on the transaction,
   there is no problem within the DHCPv6 protocol related to any
   hardcoded dates or two-digit representation definition of the current year.
20. IANA Considerations

   This document defines message types 1--8 to be received by UDP at
   port numbers 546 and 547.  Additional message types may be defined option.

22.7. Authentication option

   The authentication option is TBD.

23. Changes in
   the future.

   Section 3.1 lists several multicast addresses used by DHCP. this draft

   This document also defines several status codes that are to
   be returned with section describes the Reply and Reconfigure-reply messages (see
   sections 9.4 and 9.7).  The non-zero values for these status codes
   which are currently specified are shown in changes between this version of the table in section 3.4.

   There is a DHCPv6 extension [2] which allows clients
   specification and servers to
   exchange values for some draft-ietf-dhc-dhcpv6-15.txt.

23.1. Order of sections

   New sections have been added at the timing and retransmission parameters
   defined end of this document to minimize
   changes in section 3.5.  Adding new parameters numbering.  Those sections will be rearranged in the a
   future would
   require extending revision.

23.2. Reconfigure message

   DHCP Reconfigure and Reconfigure-reply messages and the values by which associated
   mechanisms have been removed from this draft of the parameters specification.

23.3. Releasable resources

   ``Releasable resources'' have been removed from this draft.

23.4. DHCP message header

   A common fixed DHCP message header has been defined.  Not all fields
   are indicated used in all messages.

23.5. Design goals

   The second sentence in the 8th design goal bullet has been removed.

23.6. Overview

   Section 8.2 (DHCP agents) has been removed.  DHCP extension.  Since there needs clients no longer
   need to be a list kept, the default
   values for each parameter should also be stored as part of the list.

   All of these protocol elements may be specified know about specific DHCP agents.

   Section 8.3 has been modified to assume new values
   at some point in the future.  New values should be approved by reflect the
   process of IETF Consensus [11].
21. Acknowledgements

   Thanks new encapsulating
   mechanism through which relays forward client messages to the DHC Working Group for their time servers.

   Section 8.6 and input into 8.7 have been modified to describe ``identity
   associations''.

   Section 8.8 has been modified to reflect the
   specification.  Ralph Droms deletion of
   ``reconfigure'' and Thomas Narten ``reconfigure-reply'' messages.

23.7. Message formats, 9

   Message formats have had been changed.  All messages share a major
   role common fixed
   message header followed by options.  The various control bits (``P'',
   ``C'') have been removed from the message header.

23.8. Solicit and Advertise messages, (section 10)

   The description of the message exchanges have been changed to
   reflect:

    -  New relay behavior - encapsulated client messages

    -  Use of IAs

23.9. Prefix advertisement

   Servers no longer advertise prefixes.

23.10. Identity Associations

   Section 9.11 describes IAs in shaping the continued improvement detail.  A definition of the protocol by their
   careful reviews.  Many thanks ``IA'' has
   been added to Matt Crawford, Erik Nordmark, Gerald
   Maguire, and Mike Carney for their studied review as part section 2.  The description of messages exchanges
   have been extended to include IAs.  The IA option is defined in
   section 22.2

23.11. Extensions renamed options; defined in this document

   ``extensions'' are now called ``options''; the
   Last Call process.  Thanks also for the consistent input, ideas, options referenced in
   this document are defined in section 22.

23.12. Transaction-ID ranges

   Solicit, Advertise, Request, Reply, Release and
   review Reconfigure-init
   messages all use an unsigned 16-bit integer ``Transaction-ID''.
   Transaction-IDs generated by (in alphabetical order) Brian Carpenter, Jack McCann, Yakov
   Rekhter, Matt Thomas, Sue Thomson, clients are considered to be chosen from
   a different namespace than those chosen by servers.  There is no
   need to restrict clients and Phil Wells.

   Thanks servers to Steve Deering select Transaction-IDs from
   specific ranges to avoid conflicts.

23.13. Release messages and Bob Hinden, who have consistently
   taken relays

   Release/Reply messages are forwarded through relays.  This mechanism
   eliminates the time to discuss need for an 'R' bit.

23.14. Discovering relay agents

   Clients no longer learn the more complex parts identity of relay agents.  When the IPv6
   specifications.
   client only has a link-local address (e.g., the client has no
   assigned addresses), it now multicasts Request message, which is then
   forwarded by a relay agent on the same link.

A. Comparison between DHCPv4 and DHCPv6

   This appendix is provided for readers who will find it useful to see
   a model and architecture comparison between DHCPv4 [7, [6, 1] and DHCPv6.
   There are three key reasons for the differences:

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

     o DHCPv6 benefits from the new IPv6 features.

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

   IPv6 Architecture/Model Changes:

     o The link-local address permits a node to have an address
       immediately when the node boots, which means all clients have a
       source IP address at all times to locate an on-link server or
       relay.

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

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

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

     o Multiple addresses per interface are inherently supported in
       IPv6.

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

   DHCPv6 Architecture/Model Changes:

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

     o IPv6 Address allocations are now handled in a message extension option as
       opposed to the message header.

     o Client/Server bindings are now mandatory and take advantage of
       the client's link-local address to always permit communications
       either directly from an on-link server, or from a off-link server
       through an on-link relay.

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

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

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

     o ACKs and NAKs are not used.

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

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

     o The function of DHCPINFORM is inherent in the new packet design;
       a client can request configuration parameters other than IPv6
       addresses in the optional extension option headers.

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

     o New extensions options have been defined.

   With the changes just enumerated, we can support new user features,
   including

     o Configuration of Dynamic Updates to DNS

     o Address deprecation, for dynamic renumbering.

     o Relays can be preconfigured with server addresses, or use of
       multicast.

     o Authentication

     o Clients can ask for multiple IP addresses.

     o Addresses can be reclaimed using the Reconfigure-init message.

     o Integration between stateless and stateful address
       autoconfiguration.

     o Enabling relays to locate off-link servers.

B. Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However,
   this document itself may not be modified in any way, such as by
   removing the copyright notice or references to the Internet Society
   or other Internet organizations, except as needed for the purpose
   of developing Internet standards in which case the procedures
   for copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

References

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

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

    [3] S. Bradner.  Key words for use in RFCs to Indicate Requirement
        Levels.  Request for Comments (Best Current Practice) 2119,
        Internet Engineering Task Force, March 1997.

    [4]

    [3] S. Bradner and A. Mankin.  The Recommendation for the IP Next
        Generation Protocol.  Request for Comments (Proposed Standard)
        1752, Internet Engineering Task Force, January 1995.

    [5]

    [4] W. J. Croft and J. Gilmore.  Bootstrap Protocol.  Request for
        Comments 951, Internet Engineering Task Force, September 1985.

    [6]

    [5] S. Deering and R. Hinden.  Internet Protocol, Version 6 (IPv6)
        Specification.  Request for Comments (Draft Standard) 2460,
        Internet Engineering Task Force, December 1998.

    [7]

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

    [8]

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

    [9]

    [8] S. Kent and R. Atkinson.  IP Authentication Header.  Request for
        Comments (Proposed Standard) 2402, Internet Engineering Task
        Force, November 1998.

   [10]

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

   [11]

   [10] T. Narten and H. Alvestrand.  Guidelines for Writing an IANA
        Considerations Section in RFCs.  Request for Comments (Best
        Current Practice) 2434, Internet Engineering Task Force, October
        1998.

   [12]

   [11] T. Narten, E. Nordmark, and W. Simpson.  Neighbor Discovery for
        IP Version 6 (IPv6).  Request for Comments (Draft Standard)
        2461, Internet Engineering Task Force, December 1998.

   [13]

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

   [14]

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

   [15]

   [14] S. Thomson and T. Narten.  IPv6 Stateless Address
        Autoconfiguration.  Request for Comments (Draft Standard) 2462,
        Internet Engineering Task Force, December 1998.

   [16]

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

   [17]

   [16] P. Vixie, Ed., S. Thomson, Y. Rekhter, and J. Bound.  Dynamic
        Updates in the Domain Name System (DNS UPDATE).  Request for
        Comments (Proposed Standard) 2136, Internet Engineering Task
        Force, April 1997.

Chair's Address

   The working group can be contacted via the current chair:

         Ralph Droms
      Computer Science Department
      323 Dana Engineering
      Bucknell University
      Lewisburg, PA 17837
         Cisco Systems
         300 Apollo Drive
         Chelmsford, MA 01824

         Phone:  (570) 577-1145  (978) 244-4733
         E-mail:  droms@bucknell.edu  rdroms@cisco.com

Author's Address

   Questions about this memo can be directed to:

        Jim Bound
        Compaq Computer Corporation
        Mail Stop:  ZK03-3/U14
        110 Spitbrook Road
        Nashua, NH 03062
        USA
        Phone:  +1-603-884-0400
        Email:  bound@zk3.dec.com

        Mike Carney
        Sun Microsystems, Inc
        Mail Stop:  UMPK17-202
        901 San Antonio Road
        Palo Alto, CA 94303-4900
        USA
        Phone:  +1-650-786-4171
        Email:  mwc@eng.sun.com

        Charles E. Perkins
        Communications Systems Lab
        Nokia Research Center
        313 Fairchild Drive
        Mountain View, California 94043
        USA
        Phone:  +1-650 625-2986
        EMail:  charliep@iprg.nokia.com
        Fax:  +1 650 625-2502