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

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

Status of This Memo

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

   Distribution of this memo is unlimited.

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

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

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

Abstract

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

                                Contents

Status of This Memo                                                    i

Abstract                                                               i

 1. Introduction                                                       1

 2. Requirements                                                       1

 3. Background                                                         1

 4. Design Goals                                                       3

 5. Non-Goals                                                          3

 6. Terminology                                                        2
     2.1.                                                        4
     6.1. IPv6 Terminology  . . . . . . . . . . . . . . . . . . . .    2
     2.2.    4
     6.2. DHCP Terminology  . . . . . . . . . . . . . . . . . . . .    3

 3.    5

 7. DHCP Constants                                                     4
     3.1.                                                     6
     7.1. Multicast Addresses . . . . . . . . . . . . . . . . . . .    5
     3.2.    7
     7.2. UDP ports . . . . . . . . . . . . . . . . . . . . . . . .    5
     3.3.    7
     7.3. DHCP message types  . . . . . . . . . . . . . . . . . . .    5
     3.4.    7
     7.4. Error Values  . . . . . . . . . . . . . . . . . . . . . .    7
           3.4.1.    9
           7.4.1. Generic Error Values  . . . . . . . . . . . . . .    7
           3.4.2.    9
           7.4.2. Server-specific Error Values  . . . . . . . . . .    7
     3.5.    9
     7.5. Configuration Variables . . . . . . . . . . . . . . . . .    8

 4. Requirements                                                       8

 5. Background                                                         9

 6. Design Goals   10

 7. Non-Goals                                                         11

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

 9. Message Formats and Identity Associations                         14                                                   13
     9.1. DHCP Solicit Message Format . . . . . . . . . . . . . . .   14   13
     9.2. DHCP Advertise Message Format . . . . . . . . . . . . . .   15   14
     9.3. DHCP Request Message Format . . . . . . . . . . . . . . .   16   14
     9.4. DHCP Reply Confirm Message Format . . . . . . . . . . . . . . . .   17   14
     9.5. DHCP Release Renew Message Format . . . . . . . . . . . . . . .   18 .   15
     9.6. DHCP Reconfigure Rebind Message Format  . . . . . . . . . . . . .   18 . .   15
     9.7. DHCP Reconfigure-reply Reply Message Format . . . . . . . . . .   18 . . . . . .   16
     9.8. DHCP Reconfigure-init Release Message Format . . . . . . . . . .   19
     9.9. Relay-forward message . . . . .   16
     9.9. DHCP Decline Message Format . . . . . . . . . . . . . .   20 .   16
    9.10. Server-forward DHCP Reconfigure-init Message Format  . . . . . . . . . .   17

10. Relay messages                                                    17
    10.1. Relay-forward message . . . . . . . . . . . . . . . . .   20
    9.11. Identity association .   17
    10.2. Relay-reply message . . . . . . . . . . . . . . . . .   21

10. . .   18

11. Identity association                                              18

12. DHCP Server Solicitation                                          21
    10.1.                                          19
    12.1. Solicit Message Validation  . . . . . . . . . . . . . . .   21
    10.2.   19
    12.2. Advertise Message Validation  . . . . . . . . . . . . . .   21
    10.3.   19
    12.3. Client Behavior . . . . . . . . . . . . . . . . . . . . .   22
          10.3.1.   19
          12.3.1. Creation and sending of the Solicit message . . .   22
          10.3.2.   19
          12.3.2. Time out and retransmission of Solicit Messages .   22
          10.3.3.   20
          12.3.3. Receipt of Advertise messages . . . . . . . . . .   23
    10.4. Relay   20
    12.4. Server Behavior . . . . . . . . . . . . . . . . . . . . .   23
          10.4.1. Relaying   21
          12.4.1. Receipt of Solicit messages . . . . . . . . . .   23
          10.4.2. Relaying .   21
          12.4.2. Creation and sending of Advertise messages  . . .   21

13. DHCP Client-Initiated Configuration Exchange                      22
    13.1. Client Message Validation . . . . . .   24
    10.5. Server Behavior . . . . . . . . . .   22
    13.2. Server Message Validation . . . . . . . . . . .   24
          10.5.1. Receipt of Solicit messages . . . . . . . . . . .   24
          10.5.2. Creation and sending of Advertise messages  . . .   24

11. DHCP Client-Initiated Configuration Exchange                      25
    11.1. Request Message Validation  . . .   23
    13.3. Client Behavior . . . . . . . . . . . .   25
    11.2. Reply Message Validation  . . . . . . . . . . . . . . . .   26
    11.3. Release Message Validation  . .   23
          13.3.1. Creation and sending of Request messages  . . . .   24
          13.3.2. Creation and sending of Confirm messages  . . . .   24
          13.3.3. Creation and sending of Renew messages  . . . . .   26
    11.4. Client Behavior . . . . . . . . . . .
          13.3.4. Creation and sending of Rebind messages . . . . .   27
          13.3.5. Receipt of Reply message in response to a Reply,
                          Confirm, Renew or Rebind message . . . . .   26
          11.4.1.  28
          13.3.6. Creation and sending of Request Release messages  . . . .   27
          11.4.2.   29
          13.3.7. Time out and retransmission of Request Release Messages .   27
          11.4.3. Receipt of Reply message in response to a Request   28
          11.4.4.   29
          13.3.8. Creation and sending of Release Decline messages  . . . .   28
          11.4.5.   30
          13.3.9. Time out and retransmission of Release Decline Messages .   29
          11.4.6.   30
         13.3.10. Receipt of Reply message in response to a Release   29
          11.4.7. When a client should send a Request
                          message  . . .   29
          11.4.8. Initialization . . . . . . . . . . . . . .  31
    13.4. Server Behavior . . .   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 . . . . . . . . . .   31
          13.4.1. Receipt of Request messages . . . . . . . . . . .   31
          11.5.1. Relaying
          13.4.2. Receipt of Request or Release Confirm messages . . . . .   31
    11.6. Server Behavior . . . . . . . . .   32
          13.4.3. Receipt of Renew messages . . . . . . . . . . . .   31
          11.6.1.   32
          13.4.4. Receipt of Request Rebind messages  . . . . . . . . . . .   31
          11.6.2.   33
          13.4.5. Receipt of Release messages . . . . . . . . . . .   31
          11.6.3. Creation and sending   34
          13.4.6. Sending of Reply messages . . . . .   32

12. DHCP Server-Initiated Configuration Exchange                      33
    12.1. Reconfigure Message Validation  . . . . . . . . . . . . .   33
    12.2. Reconfigure-reply Message Validation  . . . . . . . . . .   33
    12.3.   35

14. DHCP Server-Initiated Configuration Exchange                      35
    14.1. Reconfigure-init Message Validation . . . . . . . . . . .   33
    12.4.   35
    14.2. Server Behavior . . . . . . . . . . . . . . . . . . . . .   33
          12.4.1.   35
          14.2.1. Creation and sending of Reconfigure Reconfigure-init messages  . .   34
          12.4.2.   36
          14.2.2. Time out and retransmission of Reconfigure unicast
                          Reconfigure-init messages  . . . . . . . .  37
          14.2.3. Time out and retransmission of multicast
                          Reconfigure-init messages  . . . . . . . . .  34
          12.4.3.  37
          14.2.4. Receipt of Reconfigure-reply Request messages . . . . . .   34
          12.4.4. Creation and sending of Reconfigure-init messages   34
          12.4.5. Time out and retransmission of Reconfigure-init
                          messages . . . . .   37
    14.3. Client Behavior . . . . . . . . . . . .  35
          12.4.6. Receipt of Request messages . . . . . . . . . . .   35
    12.5. Client Behavior . . . . . . . . . . . . . . . . . . . . .   35
          12.5.1.   37
          14.3.1. Receipt of Reconfigure-init messages  . . . . . .   35
          12.5.2.   37
          14.3.2. Creation and sending of Request messages  . . . .   36
          12.5.3.   38
          14.3.3. Time out and retransmission of Request messages .   36
          12.5.4.   38
          14.3.4. Receipt of Reply messages . . . . . . . . . . . .   36

13. Using DHCP for network renumbering                                36

14. DHCP Client Implementor Notes                                     37
    14.1. Primary Interface   38

15. Relay Behavior                                                    38
    15.1. Relaying of Solicit messages  . . . . . . . . . . . . . .   39
    15.2. Relaying of Advertise messages  . . . . . .   37
    14.2. Advertise Message and Configuration Parameter Caching . .   37
    14.3. Time out and retransmission variables . . . . .   39

16. DHCP options                                                      39
    16.1. Format of DHCP options  . . . . .   37
    14.4. Server Preference . . . . . . . . . . . .   40
    16.2. Identity association option . . . . . . . .   38

15. DHCP Server Implementor Notes                                     38
    15.1. Client Bindings . . . . . . .   40
    16.3. Option request option . . . . . . . . . . . . . .   38
    15.2. Reconfigure-init Considerations . . . .   42
    16.4. Client message option . . . . . . . . . .   38
    15.3. Server Preference . . . . . . . .   43
    16.5. Server message option . . . . . . . . . . . .   39
    15.4. Request Message Transaction-ID Cache . . . . . .   43
    16.6. Retransmission parameter option . . . . . .   39

16. DHCP Relay Implementor Notes                                      39

17. Open Issues for Working Group Discussion                          39
    17.1. Authentication . . . . . . .   44
    16.7. Authentication option . . . . . . . . . . . . . . .   39
    17.2. DHCP-DNS interaction . . .   44
    16.8. Reconfigure-delay option  . . . . . . . . . . . . . . .   39
    17.3. Release vs.  Decline .   44
    16.9. DSTM Global IPv4 Address Option . . . . . . . . . . . . .   44

17. DHCP Client Implementor Notes                                     45
    17.1. Primary Interface . . . .   40
    17.4. Request messages . . . . . . . . . . . . . . . .   45
    17.2. Advertise Message and Configuration Parameter Caching . .   46
    17.3. Time out and retransmission variables . .   40
    17.5. Use of term ``agent'' . . . . . . . .   46
    17.4. Server Preference . . . . . . . . . .   40
    17.6. Use of terms ``subnet'' and ``network'' . . . . . . . . .   40 .   46

18. Security                                                          40

19. Year 2000 considerations                                          41

20. IANA Considerations                                               41

21. Acknowledgments                                                   41

22. DHCP options                                                      42
    22.1. Format of DHCP options Server Implementor Notes                                     46
    18.1. Client Bindings . . . . . . . . . . . . . . . . .   42
    22.2. Identity association option . . . .   46
    18.2. Reconfigure-init Considerations . . . . . . . . . . .   43
    22.3. Option request option . .   47
          18.2.1. Reliable transmission of multicast Reconfigure-init
                          messages . . . . . . . . . . . . . . . .   44
    22.4. Client message option .  47
    18.3. Server Preference . . . . . . . . . . . . . . . . .   45
    22.5. Server message option . . .   47
    18.4. Request Message Transaction-ID Cache  . . . . . . . . . .   47

19. DHCP Relay Implementor Notes                                      48

20. Open Issues for Working Group Discussion                          48
    20.1. Authentication  . . . . .   45
    22.6. Retransmission parameter option . . . . . . . . . . . . .   46
    22.7. Authentication option . . .   48
    20.2. Identification of IAs by servers  . . . . . . . . . . . .   48
    20.3. DHCP-DNS interaction  . . .   46

23. Changes in this draft                                             46
    23.1. Order of sections . . . . . . . . . . . . . . .   48
    20.4. Anonymous addresses . . . . . .   47
    23.2. Reconfigure message . . . . . . . . . . . . .   48
    20.5. Use of term "agent" . . . . . .   47
    23.3. Releasable resources . . . . . . . . . . . . .   48
    20.6. Client behavior when response to Rebind is not received .   49
    20.7. Additional options  . . . .   47
    23.4. DHCP message header . . . . . . . . . . . . . . .   49
    20.8. Operational parameters  . . . .   47
    23.5. Design goals . . . . . . . . . . . . .   49

21. Security                                                          49

22. Year 2000 considerations                                          49

23. IANA Considerations                                               49

24. Acknowledgments                                                   50

 A. Comparison between DHCPv4 and DHCPv6                              50

 B. Full Copyright Statement                                          52

 C. Changes in this draft                                             53
     C.1. New messages for confirming addresses and extending the lease
             on an IA . . . . . . . . . . . . . . . . . . . . .   47
    23.6. Overview . .   53
     C.2. New message formats . . . . . . . . . . . . . . . . . . .   53
     C.3. Renamed Server-forward message  . . .   47
    23.7. Message formats, 9 . . . . . . . . . .   53
     C.4. Clarified relay forwarding of messages  . . . . . . . . .   47
    23.8. Solicit   53
     C.5. Addresses and options in Advertise messages, (section 10) messages . . . . . .   48
    23.9. Prefix advertisement .   53
     C.6. Clarification of IA option format . . . . . . . . . . . .   53
     C.7. Specification of transaction ID in Solicit message  . . .   54
     C.8. Edits to definitions  . . . . . .   48
   23.10. Identity Associations . . . . . . . . . . . .   54
     C.9. Relay agent messages  . . . . . . . . . .   48
   23.11. Extensions renamed options; defined in this document . .   48
   23.12. Transaction-ID ranges . . . . . .   54
    C.10. Relay agent behavior  . . . . . . . . . . . .   48
   23.13. Release . . . . . .   54
    C.11. Transmission of all client messages and through relays  . . .   54
    C.12. Reconfigure-init messages . . . . . . . . . . . .   48
   23.14. Discovering relay agents . . . .   54
    C.13. Ordering of sections  . . . . . . . . . . . . . . . . . .   48

 A. Comparison between DHCPv4 and DHCPv6                              49

 B. Full Copyright Statement                                          51

Chair's Address   54

Author's Address
    C.14. DSTM option . . . . . . . . . . . . . . . . . . . . . . .   54

Chair's Address                                                       57

Author's Address                                                      57

1. Introduction

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

   DHCP reduces the cost of ownership by centralizing the management
   of network resources such as IP addresses, routing information, OS
   installation information, directory service information, and other
   such information on a few DHCP servers, rather than distributing such
   information in local configuration files among each network node.
   DHCP is designed to be easily extended to carry new configuration
   parameters through the addition of new DHCP ``options'' "options" defined to
   carry this information.  (What were called ``extensions'' in the -15
   draft are now called ``options''; see section 23.11.)

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

2. Requirements

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

   This document also makes use of internal conceptual variables
   to describe protocol behavior and external variables that an
   implementation must allow system administrators to change.  The
   specific variable names, how their values change, and how their
   settings influence protocol behavior are provided to demonstrate
   protocol behavior.  An implementation is organized not required to have them in
   the exact form described here, so long as follows.  Section 2 defines terminology
   used throughout its external behavior is
   consistent with that described in this document.  Section 3 defines constant values
   used by DHCP. Section 4 briefly discusses requirement levels.
   Section 5 points

3. Background

   Related work in IPv6 that would best serve an implementor to study
   is the IPv6 Specification [5], the reader IPv6 Addressing Architecture [7],
   IPv6 Stateless Address Autoconfiguration [13], IPv6 Neighbor
   Discovery Processing [10], and Dynamic Updates to helpful background DNS [15].  These
   specifications
   covering related IPv6 protocols.  Section 6 discusses enable DHCP to build upon the design
   goals that influenced DHCP. Section 7 identifies some IPv6 work to provide
   both robust stateful autoconfiguration and autoregistration of DNS
   Host Names.

   The IPv6 Specification provides the
   non-goals of this specification.  Section 8 gives a high level
   overview of DHCP, its message types, base architecture and identifies design of
   IPv6.  A key point for DHCP functional
   entities (client, relay, server).  Section 9 describes implementors to understand is that IPv6
   requires that every link in detail the format Internet have an MTU 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 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 1280 octets
   or greater (in IPv4 the changes between this version requirement is 68 octets).  This means that
   a UDP packet of 536 octets will always pass through an internetwork
   (less 40 octets for the DHCPv6
   specification and draft-ietf-dhc-dhcpv6-15.txt.

2. Terminology

2.1. IPv6 Terminology IPv6 terminology relevant header), as long as there are no IP
   options prior to this specification from the UDP header in the packet.  But, IPv6
   Protocol [5], IPv6 Addressing Architecture [7], and IPv6 Stateless
   Address Autoconfiguration [14] is included below.

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

      unicast address
                 An identifier for does not
   support fragmentation at routers, so that fragmentation takes place
   end-to-end between hosts.  If a single interface.  A packet sent DHCP implementation needs to send a unicast address is delivered
   packet greater than 1500 octets it can either fragment the UDP packet
   into fragments of 1500 octets or less, or use Path MTU Discovery [8]
   to determine the interface
                 identified by size of the packet that address.

      multicast address
                 An identifier for will traverse a set network
   path.

   DHCP clients use Path MTU discovery when they have an address of interfaces (typically
                 belonging to different nodes).  A packet sent
   sufficient scope to reach the DHCP server.  If a
                 multicast address is delivered to all interfaces
                 identified by that address.

      host       Any node DHCP client does not
   have such an address, that client MUST fragment its packets if the
   resultant message size is not 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 router.

      IP         Internet Protocol Version 6 (IPv6).
   destination.

   The terms IPv4 and IPv6 are Addressing Architecture specification [7] defines the
   address scope that can be 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 an IPv6 implementation, and the link layer, i.e.,
   various configuration architecture guidelines for network designers
   of 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 address space.  Two advantages of IPv6 are that support
   for Ethernet or Token Ring
                 network interfaces, multicast is required, and E.164 nodes can create link-local addresses for ISDN links.
   during initialization.  This means that a client can immediately use
   its link-local address
                 An IP and a well-known multicast address having link-only scope, indicated by
                 having the prefix (FE80::0000/64), that can be used to reach neighboring nodes attached begin
   communications to discover neighbors on the same link.
                 Every interface has  For instance, a link-local address.

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

      neighbor   A node attached to the same link. locate a server or relay.

   IPv6 Stateless Address Autoconfiguration [13] (Addrconf) specifies
   procedures by which a 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. may autoconfigure addresses based on
   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 advertisements [10], and the application that has
                 invoked a DHCP client operation, indicating anything
                 other than success.

      agent address
                 The address use of a neighboring DHCP Agent valid lifetime to
   support renumbering of addresses on the same
                 link as Internet.  In addition the
   protocol interaction by which a node begins stateless or stateful
   autoconfiguration is specified.  DHCP client.

      binding    A binding (or, client binding) is one vehicle to perform
   stateful autoconfiguration.  Compatibility with addrconf is a group design
   requirement of server
                 data records indexed by <prefix, UUID> containing the
                 server's information about DHCP (see Section 4).

   IPv6 Neighbor Discovery [10] is the addresses node discovery protocol in IPv6
   which replaces and other
                 information assigned to the IA.

      DHCP       Dynamic Host Configuration Protocol for IPv6.  The
                 terms DHCPv4 enhances functions of ARP [11].  To understand
   IPv6 and DHCPv6 are used only in contexts where Addrconf it is necessary strongly recommended that implementors
   understand IPv6 Neighbor Discovery.

   Dynamic Updates to avoid ambiguity.

      configuration parameter

                 An element of the configuration information set on DNS [15] is a specification that supports the
                 server and delivered to
   dynamic update of DNS records for both IPv4 and IPv6.  DHCP can use
   the client using DHCP. Such
                 parameters may be used to carry information dynamic updates to be used
                 by a node DNS to configure its network subsystem integrate addresses and enable
                 communication on a link or internetwork, for example. name space to
   not only support autoconfiguration, but also autoregistration in
   IPv6.

4. Design Goals

    -  DHCP client (or client)
                 A node that initiates requests on is a link to obtain mechanism rather than a policy.  Network administrators
       set their administrative policies through the configuration
       parameters from one or more they place upon the DHCP servers. servers in the DHCP domain
                 A chunk of network topology managed by DHCP and
                 operated by a single administrative entity.
       they're managing.  DHCP server (or server)
                 A server is a node that responds simply used to deliver parameters
       according 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 policy to deliver each of the DHCP
                 messages between clients and servers, and is on within the
                 same link as a client.
       domain.

    -  DHCP agent (or agent)
                 Either a is compatible with IPv6 stateless autoconf [13].

    -  DHCP server does not require manual configuration of network parameters
       on the same link as a client, or a DHCP relay.

      Identity association (IA) clients, except in cases where such configuration is
       needed for security reasons.  A collection of addresses assigned to node configuring itself using
       DHCP should require no user intervention.

    -  DHCP does not require a client.  Each
                 IA has an associated UUID. A server identifies an IA by
                 the tuple (prefix, UUID), where ``prefix'' is 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 prefix
                 assigned to the link to which without IPv6 routers present.

    -  DHCP will provide the client is attached,
                 An IA may have 0 or more addresses associated with it.

      Releasable resource
                 (Removed; see section 23.3.)

      transaction-ID
                 An unsigned integer ability to match responses with replies
                 initiated either renumber network(s) when
       required by a client or server.

      UUID network administrators [3].

    -  A universally unique identifier for a client.

                 DISCUSSION:

                    Rules DHCP client can make multiple, different requests for choosing a UUID are TBD.

3.
       configuration parameters when necessary from one or more DHCP Constants

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

3.1. Multicast Addresses
       servers at any time.

    -  DHCP makes use of will contain the following multicast addresses:

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

      All DHCP Servers address:  FF05::1:3 low bandwidth characteristics.

5. Non-Goals

   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 specification explicitly does not know cover the server(s) unicast address(es).
                 Note that in order for following:

    -  Specification of a client DHCP server to use this address,
                 it must have an address of sufficient scope server protocol.

    -  How a DHCP server stores its DHCP data.

    -  How to be
                 reachable by the server(s).  All servers within the
                 site are members manage a DHCP domain or DHCP server.

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

6. Terminology

6.1. IPv6 Terminology

   IPv6 terminology relevant to this multicast group.

3.2. UDP ports

   DHCP uses specification from the following destination UDP IPv6
   Protocol [5], IPv6 Addressing Architecture [7], and IPv6 Stateless
   Address Autoconfiguration [13] port numbers.  While
   source ports MAY be arbitrary, client implementations SHOULD permit
   their specification through is included below.

      address                 An IP layer identifier for an interface or
                              a local configuration parameter to
   facilitate the use set of DHCP through firewalls.

      546        Client port.  Used by agents interfaces.

      unicast address         An identifier for a single interface.
                              A packet sent to send messages a unicast address is
                              delivered to
                 clients.  Also used the interface identified by servers to send messages
                              that address.

      multicast address       An identifier for a set of interfaces
                              (typically belonging to
                 relays.

      547        Agent port.  Used by clients different nodes).
                              A packet sent to send messages a multicast address is
                              delivered to
                 agents.  Also used all interfaces identified by relays
                              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 send messages avoid
                              ambiguity.

      interface               A node's attachment to
                 servers.

3.3. DHCP message types

   DHCP defines a link.

      link                    A communication facility or medium over
                              which nodes can communicate at the following message types.  More detail on these
   message types can be found in Section 9.  Message types 0 and 9--255 link
                              layer, i.e., the layer immediately below
                              IP. Examples are reserved Ethernet (simple or
                              bridged); Token Ring; PPP links, X.25,
                              Frame Relay, or ATM networks; and MUST be silently ignored.

      01 DHCP Solicit

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

         Section 9.1 contains more details about
                              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 Solicit message.

      02 DHCP Advertise

         The DHCP Advertise (or Advertise) message is prefix
                              (FE80::0000/64), that can be used by servers
         responding to Solicits.  This message is unicast reach
                              neighboring nodes attached to the
         client's same
                              link.  Every interface has a link-local address (if the server
                              address.

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

      neighbor                A node attached to the same link) link.

      node                    A device that implements IP.

      packet                  An IP header plus payload.

      prefix                  The initial bits of an address, or unicast to the relay through which a set
                              of IP address that share the
         Solicit was sent for final delivery same initial
                              bits.

      prefix length           The number of bits in a prefix.

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

         Section 9.2 contains more details about the Advertise message.

      03 itself.

6.2. DHCP Request

         The DHCP Request (or Request) message is used by clients Terminology

   Terminology specific to
         request configuration parameters from servers.  This message is
         multicast using the All-DHCP-Agents address.  Relay(s) forward
         Requests as necessary DHCP can be found below.

      abort status              A status value returned to off-link servers.

         Section 9.3 contains more details about the Request message.

      04
                                application that has invoked a DHCP Reply
                                client operation, indicating anything
                                other than success.

      agent address             The DHCP Reply (or Reply) message is used by servers responding
         to Request and Release messages.  In the case address of responding to a Request message, neighboring DHCP Agent
                                on the Reply contains configuration parameters
         destined for same link as the DHCP client.  This message

      binding                   A binding (or, client binding) is unicast to a
                                group of server data records containing
                                the client
         if server's information about the client has
                                addresses in an address of sufficient scope that IA and any other
                                configuration information assigned to
                                the client.  A binding is
         reachable indexed by the server.  Otherwise, it
                                tuple <prefix, DUID>, where the 'prefix'
                                is unicast a prefix assigned to the relay
         through link to
                                which the Request or Release message was sent for final
         delivery to client is attached and 'DUID'
                                is the client.

         Section 9.4 contains more details about DUID from the Reply message.

      05 DHCP Release IA in the binding.

                                DISCUSSION:

                                   The DHCP Release (or Release) message indexing of an IA by <prefix,
                                   DUID> is still under discussion.

      DHCP                      Dynamic Host Configuration Protocol
                                for IPv6.  The terms DHCPv4 and DHCPv6
                                are used by clients to
         return one or more IP addresses only in contexts where it is
                                necessary to servers.  The server will
         acknowledge the receipt avoid ambiguity.

      configuration parameter   An element of the Release message by sending configuration
                                information set on the server and
                                delivered to the client a Reply message.

         Section 9.5 contains 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 details about the Release message.

      06 DHCP Reconfigure

      07 servers.

      DHCP Reconfigure-reply

         Removed; see section 23.2.

      08 domain               A set of links managed by DHCP Reconfigure-init

         The and
                                operated by a single administrative
                                entity.

      DHCP Reconfigure-init server (or Reconfigure-init) message server)   A server is set
         by server(s) to inform client(s) a node that the server(s) has new or
         updated configuration parameters, 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 client(s) same link as
                                a client.

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

      DUID                      A DHCP unique identifier for a client.

                                DISCUSSION:

                                   Rules for choosing a DUID are TBD.

      Identity association (IA) A collection of addresses assigned to initiate
                                a Request/Reply transaction client.  Each IA has an associated
                                DUID. An IA may have 0 or more addresses
                                associated with the server(s) in
         order it.

      transaction-ID            An unsigned integer to receive the updated information.

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

3.4. Error Values match responses
                                with replies initiated either by a
                                client or server.

7. DHCP Constants

   This section describes error values exchanged between various program and networking constants used
   by DHCP.

7.1. Multicast Addresses

   DHCP
   implementations.

3.4.1. Generic Error Values

   The makes use of the following symbolic names are multicast addresses:

      All DHCP Agents address:  FF02::1:2 This link-scoped multicast
                 address is used between client and server
   implementations by clients to convey error conditions.  The following table
   contains the actual numeric values for each name.  Note that communicate with the
   numeric values
                 on-link agent(s) when they do not start at 1, nor are they consecutive.  The
   errors are organized in logical groups.

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

3.4.2. Server-specific Error Values

   The following symbolic names 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-scoped multicast
                 address is used by server implementations clients or relays to
   convey error conditions communicate
                 with server(s), either because they want to clients.  The following table contains send
                 messages to all servers or because they do not know
                 the
   actual numeric values server(s) unicast address(es).  Note that in order
                 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 to use this address, it must have an
                 address of sufficient scope to be reachable by the default or initial values
                 server(s).  All servers within the site are members of
                 this multicast group.

   DISCUSSION:

      Is there a requirement for these variables.  The
   client-specific variables MAY a site-scoped "All DHCP Clients"
      multicast address, to be configured on used as the server and default in sending
      Reconfigure messages.

7.2. UDP ports

   DHCP uses the following destination UDP [12] port numbers.  While
   source ports MAY be
   delivered to the arbitrary, client implementations SHOULD permit
   their specification through the ``DHCP Retransmission Parameter
   Option'' in a Reply message.  This option is 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 keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are local configuration parameter to be interpreted as described in [2].

   This document also makes
   facilitate the use of internal conceptual variables
   to describe protocol behavior and external variables that an
   implementation must allow system administrators DHCP through firewalls.

      546        Client port.  Used by servers as the destination port
                 for messages sent to change.  The
   specific variable names, how their values change, clients and how their
   settings influence protocol behavior are provided to demonstrate
   protocol behavior.  An implementation is not required to have them in
   the exact form described here, so long relays.  Used by relay
                 agents as its external behavior is
   consistent with that described in this document.

5. Background

   Related work in IPv6 that would best serve an implementor the destination port for messages sent to study
   is
                 clients.

      547        Agent port.  Used as the IPv6 Specification [5], destination port by clients
                 for messages sent to agents.  Used as the IPv6 Addressing Architecture [7],
   IPv6 Stateless Address Autoconfiguration [14], IPv6 Neighbor
   Discovery Processing [11], and Dynamic Updates destination
                 port by relays for messages sent to DNS [16].  These
   specifications enable servers.

7.3. DHCP to build upon message types

   DHCP defines the IPv6 work to provide
   both robust stateful autoconfiguration following message types.  More detail on these
   message types can be found in Section 9.  Message types 0 and autoregistration of DNS
   Host Names.

   The IPv6 Specification provides the base architecture
   TBD--255 are reserved and design of
   IPv6.  A key point MUST be silently ignored.  The message code
   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 each message type is shown with the requirement message name.

      TBD DHCP Solicit            The DHCP Solicit (or Solicit) message
                                  is 68 octets).  This means used by clients to locate servers.

      TBD DHCP Advertise          The DHCP Advertise (or Advertise)
                                  message is used by servers responding
                                  to Solicits.

      TBD DHCP Request            The DHCP Request (or Request)
                                  message is used by clients to request
                                  configuration parameters from servers.

      TBD DHCP Confirm            The DHCP Confirm (or Confirm) message
                                  is used by clients to confirm that
   a UDP packet of 536 octets will always pass through
                                  the addresses assigned to an internetwork
   (less 40 octets for IA and
                                  the IPv6 header), lifetimes for those addresses,
                                  as long well as there are no IP
   options prior to the UDP header in current configuration
                                  parameters assigned by the packet.  But, IPv6 does not
   support fragmentation at routers, so that fragmentation takes place
   end-to-end between hosts.  If a server to
                                  the client are still valid.

      TBD DHCP implementation needs Renew              The DHCP Renew (or Renew) message
                                  is used by clients to send a
   packet greater than 1500 octets it can either fragment obtain the UDP packet
   into fragments of 1500 octets or less, or use Path MTU Discovery [9]
                                  addresses assigned to determine an IA and the size of
                                  lifetimes for those addresses, as
                                  well as the packet that will traverse a network
   path.

   DHCP clients use Path MTU discovery when they have an address of
   sufficient scope current configuration
                                  parameters assigned by the server to reach
                                  the DHCP server.  If a DHCP client.  A client does not
   have such an address, sends a Renew
                                  message to the server that client MUST fragment its packets if originally
                                  assigned the
   resultant IA when the lease on an
                                  IA is about to expire.

      TBD DHCP Rebind             The DHCP Rebind (or Rebind) message size
                                  is greater than used by clients to obtain the minimum 1280 octets.

   Path MTU Discovery for IPv6 is supported for both UDP and TCP
                                  addresses assigned to an IA and
   can cause end-to-end fragmentation when the PMTU changes
                                  lifetimes for those addresses, as
                                  well as the current configuration
                                  parameters assigned by the server to
                                  the client.  A clients sends a
   destination.

   The IPv6 Addressing Architecture specification [7] defines Rebind
                                  message to all available DHCP servers
                                  when the
   address scope that can be used in lease on an IPv6 implementation, IA is about to
                                  expire.

      TBD DHCP Reply              The DHCP Reply (or Reply) message is
                                  used by servers responding to Request,
                                  Confirm, Renew, Rebind, Release and
                                  Decline messages.  In the
   various configuration architecture guidelines for network designers case of
                                  responding to a Request, Confirm,
                                  Renew or Rebind message, the IPv6 address space.  Two advantages of IPv6 are that support Reply
                                  contains configuration parameters
                                  destined for multicast the client.

      TBD DHCP Release            The DHCP Release (or Release) message
                                  is required, and nodes can create link-local used by clients to return one or
                                  more IP addresses
   during initialization.  This means to servers.

      TBD DHCP Decline            The DHCP Decline (or Decline) message
                                  is used by clients to indicate that a
                                  the client can immediately has determined that one or
                                  more addresses in an IA are already in
                                  use
   its link-local address and a well-known multicast address to begin
   communications to discover neighbors on the link.  For instance, a link to which the client can send a Solicit is
                                  connected.

      TBD DHCP Reconfigure-init   The DHCP Reconfigure-init (or
                                  Reconfigure-init) message and locate a server or relay.

   IPv6 Stateless Address Autoconfiguration [14] (Addrconf) specifies
   procedures is set by which a node may autoconfigure addresses based on
   router advertisements [11], and the use of a valid lifetime
                                  server(s) to
   support renumbering of addresses on the Internet.  In addition inform client(s) that
                                  the
   protocol interaction by which a node begins stateless server(s) has new or stateful
   autoconfiguration is specified.  DHCP is one vehicle updated
                                  configuration parameters, and that
                                  the client(s) are to perform
   stateful autoconfiguration.  Compatibility with addrconf is initiate a design
   requirement of DHCP (see Section 6).

   IPv6 Neighbor Discovery [11] is
                                  Request/Reply transaction with the node discovery protocol
                                  server(s) in IPv6
   which replaces and enhances functions of ARP [12].  To understand
   IPv6 and Addrconf it is strongly recommended that implementors
   understand IPv6 Neighbor Discovery.

   Dynamic Updates order to DNS [16] is a specification that supports receive the
   dynamic update of DNS records for both IPv4 and IPv6.
                                  updated information.

7.4. Error Values

   This section describes error values exchanged between DHCP can use
   the dynamic updates to DNS to integrate addresses
   implementations.

7.4.1. Generic Error Values

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

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

7.4.2. Server-specific Error Values

   The security model to be following symbolic names are used with DHCPv6 should conform
   as closely as possible by server implementations to
   convey error conditions to clients.  The following table contains the 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
   actual numeric values for each name.
   _______________________________________________________________
   |Error_Name____|Error_ID|_Description________________________|_
   |NoBinding_____|20______|_Client_record_(binding)_unavailable|_
   |ConfNoMatch___|21______|_Client_record_Confirm_not_match_IA_|_

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

7.5. Configuration Variables

   This section presents a table of client and server configuration
       parameters they place upon
   variables and the DHCP servers in default or initial values for these variables.  The
   client-specific variables MAY be configured on the DHCP domain
       they're managing.  DHCP is simply used to deliver parameters
       according to that policy server and MAY be
   delivered to each the client through the "DHCP Retransmission Parameter
   Option" in a Reply message.

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

8. Overview

   This section provides a general overview of the DHCP clients within interaction between
   the
       domain.

    -  DHCP functional entities of DHCP. The overview is compatible with IPv6 stateless autoconf [14].

    -  DHCP does not require manual configuration organized as a
   series of questions and answers.  Details of network parameters
       on DHCP clients, except in cases where such configuration as message
   formats and retransmissions can be found in later sections of this
   document.

8.1. How does a node know to use DHCP?

   An unconfigured node determines that it is
       needed to use DHCP for security reasons.  A
   configuration of an interface by detecting the presence (or absence)
   of routers on the link.  If router(s) are present, the node configuring itself using examines
   router advertisements to determine if DHCP should require be used to
   configure the interface.  If there are no user intervention.

    - routers present, then
   the node MUST use DHCP does not require a server to configure the interface.  Detail 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
   this process can operate on a link without IPv6 routers present.

    -  DHCP will provide be found in neighbor discovery [10] and stateless
   autoconfiguration [13].

8.2. What if the ability to renumber network(s) when
       required by network administrators [3].

    -  A DHCP client can make multiple, and server(s) are on different requests for
       configuration parameters when necessary from links?

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

    -  DHCP will contain relays
   be set up on the appropriate time out and retransmission
       mechanisms to efficiently operate in environments with high
       latency client's link, because a client may only have a
   link-local address.  Relays receive the Solicit and low bandwidth characteristics.

7. Non-Goals

   This specification explicitly does not cover Request messages
   from the following:

    -  Specification client and forward them to some set of a servers within the
   DHCP server to server protocol.

    -  How domain.  The client message is forwarded verbatim as the payload
   in a DHCP server stores its DHCP data.

    -  How message from the relay to manage a DHCP domain or DHCP the server.

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

8. Overview

   This section provides a general overview will include
   one of its own addresses (of sufficient scope) from the interaction
   between interface
   on the functional entities of DHCP. The overview is organized same link 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 [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 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 may only have a
   link-local address.  Relays receive the Solicit and Request messages
   from the client and forward them to some set of servers within the
   DHCP domain.  The client message is forwarded verbatim as the payload
   in a message from the relay to the server.  A relay will include
   one of its own addresses (of sufficient scope) from the interface
   on the same link as the client, the client, as well as the prefix length of
   that address, in its message to the server.  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 messages to servers using some combination
   of the FF05::1:3(All Servers) All DHCP 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 relay configuration decisions based upon the topological
   requirements (scope) of the DHCP domain they are managing.  Note
   that if the DHCP domain spans more than the site-local scope, then
   the relays MUST be configured with global addresses for the client's
   link so as to be reachable by servers outside the relays' site-local
   environment.

8.4.

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

   To request configuration parameters, the client forms a Request
   message, and sends it to the server either directly (client has an
   address of sufficient scope) or indirectly (through the on-link
   relay).  The client MAY include a Option Request Option 22.3 16.3 (ORO)
   along with other options to request specific information from the
   server.  Note that the client MAY form multiple Request messages
   and send each of them to different servers to request potentially
   different information (perhaps based upon what was advertised) in
   order to satisfy its 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 the requested
   configuration parameters, which can include status information
   regarding the information requested by the client.  The Reply MAY
   also include additional information, such as a reconfiguration event
   multicast group for the client to join to monitor reconfiguration
   events, as described in section 8.8.

8.5. 8.7.

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

   Servers and clients manage addresses in groups called ``identity
   associations.'' "identity
   associations." Each identity associations is identified using a
   unique identifier.  An identity association may contain one or
   more IPv6 addresses.  DHCP servers assign addresses to identity
   associations.  DHCP clients use the addresses in an identity
   association to configure interfaces.  There is always at least one
   identity association per interface that a client wishes to configure.
   Each address in an IA has its own preferred and valid lifetime.  Over
   time, the server may change the characteristics of the addresses in
   an IA; for example, by changing the preferred or valid lifetime for
   an address in the IA. The server may also add or delete addresses
   from an IA; for example, deleting old addresses and adding new
   addresses to renumber a client.  A client can request the current
   list of addresses assigned to an IA from a server through an exchange
   of protocol messages.

8.6.

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

   A client forms a Release message, including options identifying
   the IA to be released.  The client sends the Release to the server
   which assigned the addresses to the client initially.  If that
   server cannot be reached after a certain number of attempts (see
   section 3.5), 7.5), the 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.

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

   If the client determines through a mechanism like Duplicate Address
   Detection [14] [13] that the address it was assigned by the server is
   already in use by another client, the client will form a Release
   message, including the option carrying the in-use address.  The
   option's status field MUST be set to the value reflecting the ``in
   use'' "in
   use" status of the address.

8.8.

8.7. How are clients notified of server configuration changes?

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

   The reconfiguration feature of DHCP offers network administrators
   the opportunity to update configuration information on DHCP clients
   whenever necessary.  To signal the need for client reconfiguration,
   the server will unicast a Reconfigure-init message to each
   client individually.  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 actually performs a reconfiguration in response to a
   multicast reconfigure-init message.)  A Reconfigure-init is a trigger
   which will cause the client(s) to initiate a standard Request/Reply
   exchange with the server in order to acquire the 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 receiver of the message.

   DISCUSSION:

   Each DHCP message has an identical fixed format header; some messages
   also allow a variable format area for options.  Not all fields in
   the header are used in every message.  In this section, every field
   is included in described for every message format
      diagram and fields that are not used in a
   message are marked as ``unused''.  As an alternative, the "unused".  All unused fields could
      be labeled ``unused'' in the format diagram.

9.1. a message MUST
   be transmitted as zeroes and ignored by the receiver of the message.

   The DHCP Solicit Message Format message header:

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

9.1. DHCP Solicit Message Format

      msg-type                    TBD

      preference                  (unused) MUST be 0

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

      client-link-local-address   The link-local address of the
                                  interface for which the client is
                                  using DHCP.

      server-address              (unused) MUST be 0
      options                     See section 16.

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

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

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

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

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

      options      Options are described elsewhere in this document                     See Sections 14.4 and 15.3 for information about how clients and
   servers handle the preference field. section 16.

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

      preference                  (unused) MUST be 0

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

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

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

      options
                 Options are described elsewhere in this document.                     See section 16.

9.4. DHCP Reply Confirm Message Format

      msg-type                    TBD

      preference                  (unused) MUST be 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
      transaction-ID              An unsigned integer generated by the
                                  client used to identify this Confirm
                                  message.

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

      server-address              MUST be zero.

      options                     See section 16.

9.5. DHCP Renew Message Format

      msg-type                    TBD

      preference                  (unused) MUST be 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |

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

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

      server-address              The IP address of the server to which
                                  this Renew message is directed, which
                                  MUST be the address of the server from
                                  which the IAs in this message were
                                  originally assigned.

      options                     See section 16.

9.6. DHCP Rebind Message Format

      msg-type = 4 |                    TBD

      preference   |                  (unused) MUST be 0

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

      client-link-local-address                 |
     |                           (16 octets)                         |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |   The link-local address of the client
                                  interface from which the client will
                                  issue the Request message.

      server-address                        |
     |                          (16 octets)                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              MUST be zero.

      options (variable number and length)   ....        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                     See section 16.

9.7. DHCP Reply Message Format

      msg-type                    TBD

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

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

      client-link-local-address   The link-local address of the
                                  interface for which the client is
                                  using DHCP.

      server-address              The IP address of the server.
                                  If the DHCP domain crosses site
                                  boundaries, then this address MUST be
                                  globally-scoped.

      options
                 Options are described elsewhere in this document.

9.5.                     See section 16.

9.8. DHCP Release Message Format

      msg-type                    TBD

      preference                  (unused) MUST be 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         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |              An unsigned integer generated by the
                                  client used to identify this Release
                                  message.

      client-link-local-address                   |
     |                          (16 octets)                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |   The client's link-local address for
                                  the interface from which the client
                                  issued the Release message.

      server-address                        |
     |                          (16 octets)                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              The IP address of the server that
                                  assigned the addresses.

      options (variable number and length)   ....        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                     See section 16.

9.9. DHCP Decline Message Format

      msg-type                    TBD

      preference                  (unused) MUST be 0

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

      P          (unused) MUST be 0

      client-link-local-address   The client's link-local address for
                                  the interface from which the client
                                  issued the Release message.

      server-address              The IP address of the server that
                                  assigned the addresses.

      options                     See section 22.

9.6. 16.

9.10. DHCP Reconfigure Reconfigure-init Message Format

   The Reconfigure

      preference                  (unused) MUST be 0

      transaction-ID              An unsigned integer generated
                                  by the server to identify this
                                  Reconfigure-init message has been deleted (see section 23.2).

9.7. DHCP Reconfigure-reply Message Format

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

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

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

      options                     See section 16.

10. Relay messages

   Relay agents exchange messages with servers to forward messages
   between clients and servers that are not connected to the same link.

10.1. Relay-forward message

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

      preference (unused) MUST be 0

      transaction-ID
                 An unsigned integer generated by the server to identify
                 this Reconfigure-init message

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

      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.

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

      msg-type   TBD

      prefix-length
                 The length of

      msg-type        TBD
      prefix-length   The length of the prefix in the address in the
                 ``relay-address''
                      "relay-address" field.

      relay-address   An address assigned to the interface through which
                      the message from the client was received.

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

9.10. Server-forward 16.4.

10.2. Relay-reply message

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

      msg-type        TBD

      prefix-length   The length of the prefix in the address in the
                 ``relay-address''
                      "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'' "client-forward" message.

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

9.11. 16.5.

11. Identity association

   An ``identity-association'' "identity-association" (IA) is a construct through which a server
   and a client can identify, group and manage IPv6 addresses.  Each IA
   consists of a UUID DUID and a list of associated IPv6 addresses (the list
   may be empty).  A client associates an IA with one of its interfaces
   and uses the IA to obtain IPv6 addresses for that interface from a
   server.

10.

   See section 16.2 for the representation of an IA in a DHCP message.

12. DHCP Server Solicitation

   This section describes how a client locates servers.  The behavior of
   client, server, and relay implementations is discussed, along with
   the messages they use.

   (Prefix advertisements have been deleted; see 23.9.)

10.1.

12.1. Solicit Message Validation

   Clients MUST silently discard any received Solicit messages.

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

10.2.

12.2. Advertise Message Validation

   Servers MUST discard any received Advertise messages.

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

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

     o The ``client-link-local-address'' "client-link-local-address" field value does not match the
       link-local address of the interface upon which the client sent
       the Solicit message.

10.3.

12.3. Client Behavior

   Clients use the Solicit message to discover DHCP servers configured
   to serve addresses on the link to which the client is attached.

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

10.3.1.

12.3.1. Creation and sending of the Solicit message

   The client sets the ``msg-type'' "msg-type" field to 1, TBD, and places the
   link-local address of the interface it wishes to configure in the
   ``client-link-local-address''
   "client-link-local-address" field.

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

   The client MAY include an Option Request Option in the Solicit
   message.  The client MUST NOT include any other
   fields to zero. options except those
   specifically allowed as defined by specific options.

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

10.3.2.

12.3.2. Time out and retransmission of Solicit Messages

   The client's first Solicit message on the interface MUST be delayed
   by a random amount of time between the interval of MIN_SOL_DELAY and
   MAX_SOL_DELAY. This random delay desynchronizes clients which start
   at 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 the ADV_MSG_TIMEOUT value.  This process
   continues until either one or more Advertise messages are received or
   ADV_MSG_TIMEOUT reaches the ADV_MSG_MAX value.  Thereafter, Solicits
   are retransmitted every ADV_MSG_MAX until SOL_MAX_ATTEMPTS have been
   made, at which time the client stops trying to DHCP configure the
   interface.  An event external to DHCP is required to restart the DHCP
   configuration process.

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

10.3.3. 7.5.

12.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 preference
       value (see section 14.4) 17.4) are preferred over all other Advertise
       messages.

    -  Within a group of Advertise messages with 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 be advertising the
       availability of IP addresses which have an address scope of
       interest to the client.

   Once a client has selected Advertise message(s), the client will
   typically store information about each server, such as server
   preference value, addresses advertised, when the advertisement was
   received, and so on.  Depending on the requirements 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,

   If the Relay may be configured client needs to use select an alternate server in the case that a list of
   chosen server destination addresses, which may include unicast addresses, does not respond, the FF05::1:3 (All DHCP Servers) multicast address, or other
   multicast addresses selected by client choose the network administrator.  If server with 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.
   next highest preference value.

   The client Solicit message is carried as the
   payload of MAY choose a ``client-message'' option.  The relay places an address
   from the interface on which the Solicit message was received in the
   ``relay-address'' field and the prefix length for that address in
   the ``prefix-length'' field.  The Relay then sends the Relay-forward
   message to the list of less-preferred server destination addresses if that it server has been
   configured with.

10.4.2. Relaying of Advertise messages

   When the relay receives a Relay-reply message, it extracts the server
   message from the ``server-message'' option and forwards the server
   message to the address in the client-link-local-address field in
   the server message.  The relay forwards the server message through
   the interface identified in the ``relay-address'' field in the
   Relay-reply message.

10.5.
   better set of advertised parameters.

12.4. Server Behavior

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

10.5.1.

12.4.1. Receipt of Solicit messages

   If the server receives a Solicit message, the client must be on the
   same link as the server.  If the server receives a Relay-forward
   message containing a Solicit message, the client must be on the
   link to which the prefix identified by the ``relay-address'' "relay-address" and
   ``prefix-length''
   "prefix-length" fields in the Relay-forward message is assigned.
   The server records the ``relay-address'' "relay-address" field from the Relay-forward
   message and extracts the solicit message from the ``client-message'' "client-message"
   option.

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

10.5.2.

12.4.2. Creation and sending of Advertise messages

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

     o transaction-ID

     o client-link-local-address

   The server places one of its IP addresses (determined through
   administrator setting) in the ``server-address'' "server-address" field of the Advertise
   message.  The server sets the ``preference'' "preference" field according to its
   configuration information.  See section 15.3 18.3 for a description of
   server preference.

   The server MUST include options to the Advertise message containing
   any addresses that would be assigned to IAs contained in the Solicit
   message from the client.  The server MAY include other options the
   server will return to the client in a subsequent Reply message.
   The information in these options will be used by the client in the
   selection of a server if the client receives more than one Advertise
   message.

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

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

   DISCUSSION:

      (From Ted Lemon) There is a danger in using Solicit versus
      DHCPDISCOVER: in the Solicit paradigm, the client has to
      choose the

13. DHCP server before it knows if Client-Initiated Configuration Exchange

   A client initiates a message exchange with the DHCP server
      will give it an IP address, or which addresses the server is
      willing to assign to the client.  It may be that there are
      two or more DHCP servers owned by the same administrative
      domain, and both are theoretically willing to give the
      client addresses, but only one actually has any addresses to
      give.

11. DHCP Client-Initiated Configuration Exchange

   A client uses the Request-Reply message exchange to acquire
   or update configuration information of interest.  The client may
   initiate the configuration exchange as part of the operating system
   configuration process or when requested to do so by the application
   layer.

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

      Request   Obtain initial configuration information when the client
                has no assigned addresses

      Confirm   Confirm the validity of assigned addresses and other
                configuration changes when the client's assigned
                addresses may not be valid; for example, when the client
                reboots or loses its connection to a link

      Renew     Extend the lease on an IA through the server that
                originally assigned the IA

      Rebind    Extend the lease on an IA through any server willing to
                extend the lease

   A client uses the Release-Reply message exchange to indicate to the
   DHCP server that the client will no longer be using the addresses in
   the released IA.

11.1. Request

   A client uses the Decline-Reply message exchange to indicate to the
   DHCP server that the client has detected that one or more addresses
   assigned by the server is already in use on the client's link.

13.1. Client Message Validation

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

   Agents MUST discard any Request received client messages in which the
   ``client-link-local-address''
   "client-link-local-address" field does not contain a valid link-local
   address.

   Servers MUST discard any received Request message client messages in which meets any of
   the following criteria:

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

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

11.2. Reply

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

13.2. Server Message Validation

   Servers MUST silently discard any received Reply messages. server messages (Reply
   messages).

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

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

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

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

   Relays MUST discard any Relay-reply message in which the
   ``client-link-local-address''
   "client-link-local-address" in the encapsulated Reply message 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 message in which the
   ``client-link-local-address'' field does not contain a valid
   link-local address.

   Servers MUST discard any received Release message in which the
   ``options'' field contains an authentication option, and the server
   cannot successfully authenticate the client.

11.4.

13.3. Client Behavior

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

   A client uses the Release message in the management of IAs when:

     o The when
   the client has been instructed to release the IA prior to the IA
   expiration time since it is no longer needed.

   A client uses the Decline message when the client has determined
   through DAD or some other method that one or more of the addresses
   assigned by the server in the IA is already in use by a different
   client.

     o The client has been instructed to release the IA prior to the IA
       expiration time since it is no longer needed.

11.4.1.

13.3.1. Creation and sending of Request messages

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

   The client sets the ``msg-type'' "msg-type" field to 3, TBD, and places the
   link-local address of the interface it wishes to acquire
   configuration information for in the ``client-link-local-address'' "client-link-local-address"
   field.

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

   The client places the address of the destination server in the
   ``server-address''
   "server-address" field.

   The client adds any appropriate options, including one or more IA
   options (if the client is requesting that the server assign it some
   network addresses).  If the client does include any IA options,
   it MUST include the  The list of addresses the in each included IA MUST
   be empty.

   The client currently has
   associated with that IA. If sends the Request message to the All DHCP Agents
   multicast address, destination port 547.  The source port selection
   can be arbitrary, although it SHOULD be possible using a client is requesting
   configuration of facility to set a new IA, the list of addresses MUST be empty.

11.4.2. Time out and retransmission of Request Messages specific source port value.

   The server will respond to the Request message with a Reply
   message.  If no Reply message is received within REP_MSG_TIMEOUT
   milliseconds, the client retransmits the 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 REQUEST_MSG_ATTEMPTS unsuccessful attempts have been made, at
   which time the client MUST abort the configuration attempt.  The
   client SHOULD report the abort status to the application layer.

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

11.4.3. Receipt of Reply message in response to a Request

   Upon the receipt 7.5.

13.3.2. Creation and sending of Confirm messages

   Whenever a valid Reply message, the client extracts the
   configuration information contained in the Reply.  If the ``status''
   field contains may have moved to a new link, its IPv6 addresses
   may no longer be valid.  Examples of times when a non-zero value, the client reports the error status may have
   moved to the application layer. a new link include:

     o The client records the T1 and T2 times for each IA in the Reply
   message. reboots

     o The client records any addresses included with IAs in
   the Reply message. is physically disconnected from a wired connection

     o The client updates the preferred and valid
   lifetimes for the addresses in the IA returns from the lifetime information
   in the IA option. sleep mode

     o The client leaves using a wireless technology changes cells

   In any addresses that situation when a client may have moved to a new link, the
   client
   has associated MUST initiate a Confirm/Reply message exchange.  The client
   includes any IAs, along with the IA that are not included in the IA option
   unchanged.

   Management of the specific configuration information is detailed addresses associated with those IAs,
   in its Request message.  The server returns the definition IAs with updated list
   of each option, in section 22.

11.4.4. Creation addresses and sending of Release messages associated lifetimes.

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

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

   The client includes options containing the IAs it is releasing in sets the
   ``options'' field.  The appropriate ``status'' "server-address" field in the options
   MUST be set to indicate the reason for the release. 0.

   The client places adds any appropriate options, including one or more IA
   options (if the IP address of the server client is requesting that allocated the
   address(es) in server confirm the ``server-address'' field.
   validity of some network addresses).  If the client is configured to use authentication, does include
   any IA options, it MUST include the list of addresses the client
   generates
   currently has associated with that IA.

   The client sends the appropriate authentication option, and adds this option Confirm message to the ``options'' field.  Note that the authentication option MUST All DHCP Agents
   multicast address, destination port 547.  The source port selection
   can be the last option in the ``options'' field.  See section  22.7 for
   more details about the authentication option.

   (The arbitrary, although it SHOULD be possible using a client always forwards Release messages
   configuration facility to set a specific source port value.

   Servers will respond to the server through Confirm message with a
   relay; see section 11.5.)

11.4.5. Time out and retransmission of Release Messages Reply message.  If
   no Reply Confirm message is received within REP_MSG_TIMEOUT milliseconds,
   the client retransmits the Release, Confirm 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 QRY_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 QRY_MSG_ATTEMPTS
   are documented in section 3.5.

   Note that if 7.5.

   If the client fails to release the IA, the addresses
   assigned receives no response to its Confirm message, it MAY
   restart the IA will be reclaimed configuration process by the locating a different DHCP server when the lease
   associated
   with it expires.

11.4.6. Receipt of Reply an Advertise message in response to and sending a Release

   Upon receipt Request to that server, as
   described in section 13.3.1.

13.3.3. Creation and sending of Renew messages

   IPv6 addresses assigned to a valid Reply message, the client can consider through an IA use the
   Release event successful, same
   preferred and SHOULD return the successful status valid lifetimes as IPv6 addresses obtained through
   stateless autoconfiguration.  The server assigns preferred and valid
   lifetimes to the application layer, if IPv6 addresses it assigns to an application initiated IA. To extend those
   lifetimes, the release.

11.4.7. When a client should send sends a Request message to the server containing an
   "IA option" for the IA and its associated addresses.  The description of server
   determines new lifetimes for the Request/Reply message exchange addresses in this section
   makes no assumptions about the timing or state of IA according to
   the client when
   it initiates a Request/Reply message exchange.  Sections 11.4.8
   through 11.4.10 describe when a client MAY initiate a Request/Reply
   message exchange. server's administrative configuration.  The procedures for timeout server may also add
   new addresses to the IA. The server remove addresses from the IA by
   setting the preferred and retransmission of
   Request messages are described in section 11.4.2.

11.4.8. Initialization

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

   The client includes one or more IAs in server controls the Request
   message, to time at which the client contacts the server assigns new addresses.  The
   to extend the lifetimes on assigned addresses through the T1 and
   T2 parameters assigned to an IA. If the server then
   returns does not assign an
   explicit value to IA(s) T1 or T2 for an IA, T1 defaults to 0.5 times the
   shortest preferred lifetime of any address assigned to the IA and
   T2 defaults to 0.875 times the shortest preferred lifetime of any
   address assigned to the IA.

   At time T1 for an IA, the client in initiates a Reply message.

11.4.9. Confirming Request/Reply message
   exchange to extend the validity of IPv6 lifetimes on any addresses

   Whenever a in the IA. The
   client may have moved to a new link, its IPv6 includes an IA option with all addresses
   may no longer be valid.  Examples of times when a client may have
   moved to a new link include:

     o The client reboots

     o The client is physically disconnected from a wired connection

     o The client returns from sleep mode

     o The client using a wireless technology changes cells

   In any situation when a client may have moved currently assigned
   to a new link, the
   client MUST initiate a Request/Reply message exchange.  The client
   includes any IAs, along with the addresses associated with those IAs, IA in its Request message.  The server returns the IAs with updated list
   of addresses and associated lifetimes.

11.4.10. Extending the lifetimes on IPv6 addresses

   IPv6 addresses assigned to a client through an IA use unicasts this Request
   message to the same
   preferred and valid lifetimes as IPv6 addresses obtained through
   stateless autoconfiguration.  The server assigns preferred and valid
   lifetimes to that originally assigned the IPv6 addresses it assigns to an IA. To extend those
   lifetimes, the
   IA.

   The client sends a Request to the server containing an
   ``IA option'' for sets the IA "msg-type" field to TBD, and its associated addresses.  The server
   determines new lifetimes for places the addresses in
   link-local address of the IA according interface it wishes to acquire
   configuration information for in the server's administrative configuration. "client-link-local-address"
   field.

   The server may also add
   new addresses to client generates a transaction ID inserts this value in the IA.
   "transaction-ID" field.

   The server remove addresses from the IA by
   setting client places the preferred and valid lifetimes address of those addresses to zero.

   The the destination server controls in the time at which
   "server-address" field.

   The client adds any appropriate options, including one or more IA
   options (if the client contacts is requesting that the server
   to extend the lifetimes lease
   on assigned addresses through some IAs; note that the T1 and
   T2 client may check the status of other
   configuration parameters assigned to an IA. without asking for lease extensions).  If
   the server client does not assign an
   explicit value to T1 or T2 for an IA, T1 defaults to 0.5 times the
   shortest preferred lifetime of include any address assigned to the IA and
   T2 defaults to 0.875 times options, it MUST include the shortest preferred lifetime list of any
   address assigned to
   addresses the client currently has associated with that IA.

   At time T1 for an IA, the

   The client initiates a Request/Reply sends the Renew message
   exchange to extend the lifetimes on any addresses in the IA. All DHCP Agents multicast
   address, destination port 547.  The source port selection can
   be arbitrary, although it SHOULD be possible using a client includes an IA option with all addresses currently assigned
   configuration facility to set a specific source port value.

   The server will respond to the IA in its Request Renew message with a Reply message.  The client unicasts this Request
   If no Reply message to is received within REP_MSG_TIMEOUT milliseconds,
   the server that originally assigned client retransmits the addresses to Renew with the
   IA. same transaction-ID, and
   doubles the REP_MSG_TIMEOUT value, and waits again.  The client
   continues this process until a Reply is received or until time T2 is
   reached (see section 13.3.4).

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

13.3.4. Creation and sending of Rebind messages

   At time T2 for an IA (which will only be reached if the server to
   which the Request message was sent at time T1 has not responded),
   the client initiates a Request/Reply message exchange.  The client
   includes an IA option with all addresses currently assigned to the IA
   in its Request message.  The client multicasts this message to the FF02::1:2 (All
   All DHCP Agents) Agents multicast address.

11.5. Relay Behavior

11.5.1. Relaying of Request or Release messages

   When a Relay receives a valid Request or Release message, it
   constructs a Relay-forward message.

   The client message is carried
   as sets the payload of a ``client-message'' option.  The relay "msg-type" field to TBD, and places an the
   link-local address from of the interface on which it wishes to acquire
   configuration information for in the "client-link-local-address"
   field.

   The client message was received generates a transaction ID inserts this value in the ``relay-address''
   "transaction-ID" field.

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

   The client adds any appropriate options, including one or more IA
   options.  If the prefix length for client does include any IA options (if the client is
   requesting that
   address in the ``prefix-length'' field.  The Relay then forwards server extend the
   Relay-forward message to lease on some IAs; note that
   the client may check the status of other configuration parameters
   without asking for lease extensions), it MUST include the list of server destination
   addresses
   that it the client currently has been configured with.

11.6. Server Behavior

   For this discussion, associated with that IA.

   The client sends the Server is assumed Rebind message to have been configured in
   an implementation specific manner with the All DHCP Agents multicast
   address, destination port 547.  The source port selection can
   be arbitrary, although it SHOULD be possible using a client
   configuration of interest facility to
   clients.

11.6.1. Receipt of Request messages

   Upon the receipt of set a valid Request specific source port value.

   The server will respond to the Rebind message from with a Reply message.
   If no Reply message is received within REP_MSG_TIMEOUT milliseconds,
   the client retransmits the server
   can respond to, (implementation-specific administrative policy
   satisfied) Rebind with the server scans same transaction-ID, and
   doubles the options field. REP_MSG_TIMEOUT value, and waits again.  The server then constructs client
   continues this process until a Reply message is received.

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

   DISCUSSION:

      The client has several alternatives to choose from if it
      receives no response to its Rebind message.

       -  When the
   client.

   DISCUSSION:

      This section needs text about managing IAs and determining
      options lease on the IA expires, the client may choose
          to be returned use a Solicit message to client.

11.6.2. Receipt of Release messages

   Upon the receipt of locate a valid Release message, the new DHCP server examines the
   IAs and
          send a Request for the expired IA to the new server

       -  Some addresses in the IAs for validity.  If IA may have lifetimes that extend
          beyond the IAs in lease of the
   message are in a binding for IA, so the client and may choose
          to continue to use those addresses; once all of the
          addresses in the IAs have been assigned by expired, the server client may choose to those IA, the locate
          a new DHCP server deletes
   the

       -  The client may have other addresses from the IAs and makes in other IAs, so the addresses available for
   assignment
          client may choose to other clients.

   The server then generates a Reply message.  If all of discard the IAs were
   valid expired IA and use the
          addresses successfully released,, the server sets the
   ``status'' field to ``Success''.  If any of in the other IAs were invalid or
   if any

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

   Upon the addresses were not successfully released, the server
   releases none receipt of a valid Reply, Confirm, Renew or Rebind message,
   the addresses client extracts the configuration information contained in the message and sets
   Reply.  If the ``status'' "status" field to ``NoBinding''(section 3.4).

   DISCUSSION:

      What is contains a non-zero value, the behavior of client
   reports the server relative error status to a ``partially
      released'' IA; i.e., an IA for which some but not all
      addresses are released?

      Can a the application layer.

   The client send an empty records the T1 and T2 times for each IA to release all addresses in the IA?

      If the IA becomes empty - all addresses are released - can
      the server discard Reply
   message.  The client records any record of addresses included with IAs in
   the IA?

11.6.3. Creation and sending of Reply messages

   DISCUSSION:

      XXX - This section needs to be fixed (see section 11.6.1). message.  The server sets client updates the ``msg-type'' field to 4 preferred and copies valid
   lifetimes for the values
   of addresses in the following fields IA from the client's Request or Release to lifetime information
   in the
   Reply message:

     o transaction-ID

     o client's link-local address

     o server-address IA option.  The server sets client leaves any addresses that the ``status'' field appropriately (see client
   has associated with the table IA that are not included in section 3.4) based upon the results IA option
   unchanged.

   Management of processing the client's
   request.

   If specific configuration information is detailed in
   the Request or Release message from definition of each option, in section 16.

   When the client was originally
   received by the server, receives an Unavail error status in an IA from the
   server unicasts the Reply for a Request message the client will have to find a new
   server to create an IA Association.

   When the
   link-local address client receives a NoBinding error status in an IA from the ``client-link-local-address'' field.

   If the message was originally received in
   server for a Forward-request or
   Forward-release Confirm message from the client can assume it needs to send a relay,
   Request to reestablish an IA Association with the server places server.

   When the Reply
   message client receives a Conf_NoMatch error status in an IA from
   the options field of server for a Response-reply Confirm message and unicasts the client can send a Renew message
   to the relay's address server to extend the lease for the addresses.

   When the client receives a NoBinding error status in an IA from the original message.

12. DHCP Server-Initiated Configuration Exchange

   A
   server initiates for a configuration exchange on behalf of the
   administrator of Renew message the DHCP domain.  An administrator may initiate such
   an exchange when new links are added client can assume it needs to the domain or existing links
   are send a
   Request to be renumbered.  Other examples include changes in reestablish an IA Association with the 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 server.

   When the client receives 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 Renw_NoMatch error status in an authentication option or that fail the client's
   authentication check.

12.4. Server Behavior

   For this discussion, IA from
   the server is assumed for a Renew message the client can assume it needs to have send
   a
   implementation-specific interface by which Request to reestablish an administrator
   may initiate a reconfiguration event IA Association with some set of clients.

   A the server.

   When the client receives an Unavail error status in an IA from the
   server sends for a Reconfigure-init Renew message to trigger a the client can assume it needs to
   initiate immediately send a Request/Reply message exchange
   Request to reestablish an IA Association set of addresses with the
   server.  A

   When the client receives a NoBinding error status in an IA from the
   server for a Rebind message the client can assume it needs to send Reconfigure-init messages only
   a Request to those
   clients who have reestablish an address of sufficient scope to be reachable by IA Association with the server or try
   another server.  Thus, those clients who have not requested

   When the client receives a Rebd_NoMatch error status in an IP address
   and are off-link cannot be reconfigured by IA from
   the server.

   DISCUSSION:

      It would be possible server for a Rebind message the client can assume it needs to forward Reconfigure-init messages
      through relays if
   send a Request to reestablish an IA Association with the server records the client's link-local
      address and or
   try another server.

   When the relay's address client receives an Unavail error status in an IA from the client's
   server for a Rebind message the client can assume it needs to send a
   Request
      message.

12.4.1. Creation and sending of Reconfigure messages

   Reconfigure messages have been deleted; see section 23.2.

12.4.2. Time out and retransmission of Reconfigure messages

12.4.3. Receipt to reestablish an IA Association set of Reconfigure-reply messages

12.4.4. addresses with the
   server or try another server.

13.3.6. Creation and sending of Reconfigure-init Release messages

   The server client sets the ``msg-type'' "msg-type" field to 8. TBD, and places the
   link-local address of the interface associated with the configuration
   information it wishes to release in the "client-link-local-address"
   field.

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

   The server client places its the IP address (of appropriate scope) of the server that allocated the
   address(es) in the
   ``server-address'' "server-address" field.

   The server MAY include an ORO option to inform the client of what
   information has been changed or new information that has been added. includes options containing the IAs it is releasing in the
   "options" field.  The server appropriate "status" field in the options MUST include an authentication option with
   be set to indicate the reason for the release.

   If the client is configured to use authentication, the client
   generates the appropriate
   settings authentication option, and add adds this option
   to the "options" field.  Note that the authentication option as MUST be
   the last option in the ``options''
   field of "options" field.  See section  16.7 for more
   details about the Reconfigure-init message.

   Typically, the server will not provide more than an ORO authentication option.

13.3.7. Time out and / or
   Authentication option, since it will provide the new configuration
   information as part retransmission of Release Messages

   If no Reply message is received within REP_MSG_TIMEOUT milliseconds,
   the Request/Reply transaction triggered by client retransmits the
   Reconfigure-init message.

   The server may either unicast Release, doubles the Reconfigure-init message to one REP_MSG_TIMEOUT
   value, and waits again.  The client continues this process until a
   Reply is received or multicast REL_MSG_ATTEMPTS unsuccessful attempts have been
   made, at which time the message to one or more Reconfigure Multicast
   Addresses previously sent as options to client SHOULD abort the clients. release attempt.

   The server
   may unicast Reconfigure-init messages to more than one client
   concurrently; for example, to reliably reconfigure all clients, SHOULD return the
   server will unicast a Reconfigure-init message abort status to each client.

   If the server unicasts to one or more clients, it waits for a Request
   message from those clients confirming that it has received application, if an
   application initiated the
   Reconfigure-init release.

   Default and initial values for REP_MSG_TIMEOUT and REL_MSG_ATTEMPTS
   are thus initiating a Request/Reply transaction
   with the server.  The server can determine that a Request message is documented in response section 7.5.

   Note that if the client fails to a Reconfigure-init because release the transaction-ID in IA, the
   Request addresses
   assigned to the IA will be the same value as was used in the Reconfigure-init
   message.

   If reclaimed by the server multicasts when the Reconfigure-init message, lease
   associated with it must use
   some TBD authentication mechanism that can authenticate expires.

13.3.8. Creation and sending of Decline messages

   The client sets the server "msg-type" field to
   multiple clients.  There is no reliability mechanism for multicast
   Reconfigure-init messages.  A server might use multicast in TBD, and places the
   case where it does not have a list
   link-local address of its clients; for example, a
   server that distributes the interface associated with the configuration
   information it wishes to clients using
   stateless autoconfiguration might not keep decline in the "client-link-local-address"
   field.

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

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

   The client includes options containing the IAs it has
   communicated with.

12.4.5. is declining in the
   "options" field.  The appropriate "status" field in the options MUST
   be set to indicate the reason for declining the address.

   If the client is configured to use authentication, the client
   generates the appropriate authentication option, and adds this option
   to the "options" field.  Note that the authentication option MUST be
   the last option in the "options" field.  See section  16.7 for more
   details about the authentication option.

13.3.9. Time out and retransmission of Reconfigure-init messages

   It the server does not receive a Request Decline Messages

   If no Reply message from the client
   in RECREP_MSG_TIMEOUT is received within REP_MSG_TIMEOUT milliseconds,
   the server client retransmits the Reconfigure-init message, Decline, doubles the RECREP_MSG_TIMEOUT
   value REP_MSG_TIMEOUT
   value, and waits again.  The server client continues this process until
   REC_MSG_ATTEMPTS a
   Reply is received or REL_MSG_ATTEMPTS unsuccessful attempts have
   been made, at which point time the server client SHOULD abort the reconfigure process. attempt to
   decline the address.  The client SHOULD return the abort status to
   the application, if an application initiated the release.

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

12.4.6. 7.5.

13.3.10. Receipt of Request messages

   The server generates and sends Reply message(s) message in response to a Release message

   Upon receipt of a valid Reply message, the client as
   described in section 11.6.3, including in can consider the ``option'' field new
   values for configuration parameters.

12.5. Client Behavior

   A client MUST always monitor UDP port 546 for Reconfigure-init
   messages on interfaces upon which it has acquired DHCP parameters.
   Since the results of a reconfiguration
   Release event may affect successful, and SHOULD return the successful status to
   the application
   layer programs, layer, if an application initiated the client SHOULD log these events, and MAY notify
   these programs of release.

13.4. Server Behavior

   For this discussion, the change through Server is assumed to have been configured in
   an implementation-specific
   interface.

12.5.1. implementation specific manner with configuration of interest to
   clients.

13.4.1. Receipt of Reconfigure-init Request messages

   Upon the receipt of a valid Reconfigure-init message, the client
   initiates a Request/Reply transaction with the server.

12.5.2. Creation and sending of Request messages

   When responding to message from a Reconfigure-init, the client creates the server
   can respond to, (implementation-specific administrative policy
   satisfied) the server scans the options field.

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

   The server SHOULD process each option for the same manner as outlined client in
   section 11.4.1 with an
   implementation-specific manner.  The server MUST construct a Reply
   message containing the following differences: values:

      msg-type                    TBD

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

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

      IAs
                The client includes IA options containing

      client-link-local address   Enter the addresses client-link-local address
                                  from the client currently has assigned to those IAs for Request message.

      server address              Enter the
                interface through which IP address of the Reconfigure-init message was
                received.

      Pause before sending Request
                The client pauses before sending server.

   When the Request for server receives a random value within the range REC_REP_MIN Request and
                REC_REP_MAX seconds.  This delay helps reduce IA option is included the
                load on
   client is requesting the server generated by processing large
                numbers configuration of triggered Request messages from a multicast
                Reconfigure-init message.

12.5.3. Time out and retransmission of Request messages new IA by the server.
   The client uses server MUST take the same variables clients IA and retransmission algorithm as associate a binding for
   that client in an implementation-specific manner within the servers
   configuration parameter database for DHCP clients.

   If the server cannot provide addresses to the client it
   does SHOULD send
   back an empty IA to the client with Request messages generated as part the status field set to Unavail.

   If the server can provide addresses to the client it MUST send back
   the IA to the client with all fields entered and a status of Success,
   and add the IA as a client-initiated
   configuration exchange.  See section 11.4.2 for details.

12.5.4. new client binding.

13.4.2. Receipt of Reply Confirm messages

   Upon the receipt of a valid Reply message, the Confirm message from a client extracts the
   contents of server
   can respond to, (implementation-specific administrative policy
   satisfied) the ``option'' field, and sets (or resets) configuration
   parameters appropriately. server scans the options field.

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

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

      msg-type                    TBD

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

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

      client-link-local address   Enter the configuration parameters changed were requested by client-link-local address
                                  from the
   application layer, Confirm message.

      server address              Enter the server's address.

   When the server receives a Confirm and an IA option is included the
   client notifies is requesting confirmation that the application layer of addresses in the IA are
   valid.  The server SHOULD locate the clients binding and verify the
   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 in the client implementor
   regarding their implementations.  The text described here is not part
   of IA from the protocol, but rather a discussion of implementation features
   we feel client matches the implementor should consider during implementation.

14.1. Primary Interface

   Since configuration parameters acquired through DHCP can be
   interface-specific or more general, information stored
   for that client.

   If the server cannot find a client implementor entry for this IA the server
   SHOULD
   provide a mechanism by which return an empty IA with status set to NoBinding.

   If the server finds that the information for the client implementation can be
   configured to specify which interface does not
   match what is in the primary interface.  The servers records for that client SHOULD always query the DHCP data associated server
   should send back an empty IA with status set to Conf_NoMatch.

   If the primary
   interface for non-interface specific configuration parameters.  An
   implementation MAY implement server finds a list of interfaces which would be
   scanned in order match to satisfy the general request.  In either case, Confirm then the
   first interface scanned is considered server should
   send back the primary interface.

   By allowing IA to the specification client with status set to success.

13.4.3. Receipt of a primary interface, Renew messages

   Upon the receipt of a valid Renew message from a client
   implementor identifies which interface is authoritative for
   non-interface specific parameters, which prevents configuration
   information ambiguity within the client implementation.

14.2. Advertise Message and Configuration Parameter Caching

   If server
   can respond to, (implementation-specific administrative policy
   satisfied) the hardware server scans the client is running on permits it, options field.

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

   The server SHOULD provide a cache process each option for Advertise messages and the client in an
   implementation-specific manner.  The server MUST construct a cache of
   configuration parameters received through DHCP. Providing these
   caches prevents unnecessary DHCP traffic and Reply
   message containing the subsequent load
   this generates on following values:

      msg-type                    TBD

      preference                  Enter the servers.  The implementor SHOULD servers preference to
                                  provide a
   configuration knob for setting services to the amount of time client.

      transaction-ID              Enter the cache(s) are
   valid.

14.3. Time out and retransmission variables

   Note that transaction-ID from the client time out and retransmission variables outlined
   in section 3.5 can be configured on
                                  Confirm message.

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

      server and sent to address              Enter the server's address.

   When the server receives a Renew and IA option from a client
   through it
   SHOULD locate the use of clients binding and verify the ``DHCP Retransmission Parameter Option'',
   which is documented information in section 22.6.  A client implementation SHOULD
   be able to reset these variables using the values
   IA from this option.

14.4. Server Preference

   A the client MUST wait matches the information stored for SRVR_PREF_WAIT seconds after sending that client.

   If the server cannot find a DHCP
   Solicit message to collect Advertise messages and compare their
   preferences (see section 15.3), unless it receives client entry for this IA the server
   SHOULD return an Advertise
   message empty IA with a preference of 255. status set to NoBinding.

   If the server finds that the addresses in the IA for the client receives do
   not match the clients binding the server should return an
   Advertise message empty IA
   with a preference of 255, then status set to Renw_NoMatch.

   If the server cannot Renew addresses for the 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 it SHOULD send
   back an empty IA to the client with the status field set to Unavail.

   If the server implementor.

15.1. Client Bindings

   A server implementation MUST use finds the IA's UUID and addresses in the prefix
   specification from which IA for the client sent its Request message(s) as an
   index for finding configuration parameters assigned then the
   server SHOULD send back the IA to the client.
   While it isn't critical client with new lease times
   and T1/T2 times if the default is not being used, and set status to keep track
   Success.

13.4.4. Receipt of Rebind messages

   Upon the other parameters
   assigned to receipt of a client, valid Rebind message from a client the server MUST keep track of
   can respond to, (implementation-specific administrative policy
   satisfied) the addresses it
   has assigned to an IA.

   The server should periodically scan its bindings for addresses whose
   leases have expired.  When scans the options field.

   The server finds expired addresses, then constructs a Reply message and sends it
   MUST delete the assignment of those addresses, thereby making these
   addresses available to other clients. the
   client.

   The server SHOULD process each option for the client bindings MUST be stored in non-volatile storage. an
   implementation-specific manner.  The server implementation should provide policy knobs to control
   whether or not the lifetimes on assigned addresses are renewable, and
   by how long.

15.2. Reconfigure-init Considerations

   A server implementation MUST construct a Reply
   message containing the following values:

      msg-type                    TBD
      preference                  Enter the servers preference to
                                  provide an interface services to the
   administrator for initiating reconfigure-init events.

   A server implementation may provide a mechanism for allowing client.

      transaction-ID              Enter the
   specification of how many clients comprise a reconfigure multicast
   group.  This enables transaction-ID from the administrator to control
                                  Confirm message.

      client-link-local address   Enter the hit a server
   takes when a reconfigure-init event occurs.

15.3. Server Preference

   The server implementation SHOULD allow client-link-local address
                                  from the setting of a Confirm message.

      server
   preference value by address              Enter the server's address.

   When the administrator.  The server preference
   variable is an unsigned single octet value (0--255), with receives a Renew and IA option from a client it
   SHOULD locate the lowest
   preference being 0 clients binding and verify the highest 255.  Clients will choose higher
   preference servers over those with lower preference values. information in the
   IA from the client matches the information stored for that client.

   If you
   don't choose to implement the server cannot find a client entry for this feature in your server, you MUST set IA the server preference field
   SHOULD return an empty IA with status set to 0 in NoBinding.

   If the Advertise messages generated
   by your server.

15.4. Request Message Transaction-ID Cache

   In order to improve performance, a server implementation MAY include
   an finds that the addresses in memory transaction-ID cache.  This cache is indexed by the IA for the client do
   not match the clients binding and transaction-ID, and enables the server should return an empty IA
   with status set to quickly
   determine whether a Request is a retransmission or a new Request
   without the cost of a database lookup. Rebd_NoMatch.

   If the server cannot Rebind addresses for the client it SHOULD send
   back an implementor chooses empty IA to
   implement this cache, the client with the status field set to Unavail.

   If the server finds the addresses in the IA for the client then they the
   server SHOULD provide a configuration knob send back the IA to tune the lifetime of client with new lease times
   and T1/T2 times if the cache entries.

16. DHCP Relay Implementor Notes

   A relay implementation SHOULD allow default is not being used, and set status to
   Success.

13.4.5. Receipt of Release messages

   Upon the specification receipt of a list of
   destination valid Release message, the server examines the
   IAs and the addresses in the IAs for forwarded messages.  This list MAY contain
   any mixture of unicast addresses and multicast addresses. validity.  If a relay receives an ICMP the IAs in the
   message are in response to a DHCP message it
   has forwarded, it SHOULD log this event.

17. Open Issues for Working Group Discussion

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

17.1. Authentication

   Authentication is not discussed in this document.

17.2. DHCP-DNS interaction

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

17.3. Release vs.  Decline

   Should there be a separate Decline message through which the client
   informs IAs
   have been assigned by the server that it has discovered an address that is in use
   by some other host?

17.4. Request messages

   In DHCPv4, there has been much confusion about overloading
   DHCPREQUEST with to those IA, the actions of initial address allocation
   (INIT), address confirmation (INIT-REBOOT), server deletes
   the addresses from the IAs and extending leases
   (RENEW/REBIND).

   The model for DHCPv6 messages described in section 11 also uses one
   type of message, Request, in each of makes the scenarios in sections 11.4.8
   through 11.4.10. addresses available for
   assignment to other clients.

   The DHCPv6 specification in this document does not
   differentiate the actions taken by a server based on different times
   at which a client might initiate a Request/Reply exchange with then generates a
   server.  That is, Reply message.  If all of the IAs were
   valid and the addresses successfully released,, the description of server actions in section 11.6.1
   does not differentiate among Requests received from clients based on sets the client behavior described in sections 11.4.8 through 11.4.10.

   It may be necessary
   "status" field to define different server behaviors for each "Success".  If any of the client scenarios.  For example, in IAs were invalid or if
   any of the address-reconfirmation
   scenario (section 11.4.9), servers cannot safely assign new addresses
   to a client.  The reconfirmation Request is broadcast to multiple
   servers, which cannot coordinate were not successfully released, the assignment server
   releases none of any addresses.
   Therefore, in this 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 mean ``relay agent or server'', may be
   confusing.  ``relay agent or server'' might be clearer.

17.6. Use of terms ``subnet'' in the message and ``network''

   The term ``subnet'' has been eliminated from sets the document.  The term
   ``network'' is no longer used "status"
   field to describe a link, collection of links
   or collection of IPv6 addresses.

18. Security

   This document references an ``authentication option'' which is TBD. "NoBinding"(section 7.4).

   DISCUSSION:

      Based on

      What is the discussion behavior of security issues at the
      8/31/00 design team teleconference and subsequent
      DHC WG mailing list discussion, DHCPv6 will use the security model from DHCPv4, as described in
      draft-ietf-dhc-authentication-15.txt.

19. Year 2000 considerations

   Since server relative to a "partially
      released" IA; i.e., an IA for which some but not all times
      addresses are relative released?
      Can a client send an empty IA to release all addresses in
      the current time of IA?

      If the transaction,
   there is no problem within IA becomes empty - all addresses are released - can
      the DHCPv6 protocol related to server discard any
   hardcoded dates or two-digit representation record of the current year.

20. IANA Considerations

   This document defines IA?

13.4.6. Sending of Reply messages

   If the Request or Release message types 1--8 to be from the client was originally
   received by UDP at
   port numbers 546 and 547.  Additional message types may be defined in the future.

   Section 3.1 lists several multicast addresses used by DHCP.

   This document also defines several status codes that are to
   be returned with server, the server unicasts 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 message to the
   link-local address in the table "client-link-local-address" field.

   If the message was originally received in section 3.4.

   There is a DHCPv6 option described Forward-request or
   Forward-release message from a relay, the server places the Reply
   message in section 22.6, which allows
   clients and servers to exchange values for some of the timing options field of a Response-reply message and retransmission parameters defined in section 3.5.  Adding new
   parameters in unicasts
   the future would require extending message to the values by which relay's address from the parameters are indicated original message.

14. DHCP Server-Initiated Configuration Exchange

   A server initiates a configuration exchange to force DHCP clients
   to obtain new addresses and other configuration information.  For
   example, an administrator may use a server-initiated configuration
   exchange when links in the DHCP option.  Since there needs domain are to be a list kept, renumbered.  Other
   examples include changes in the default values for each parameter should also
   be stored as part location of the list.

   All directory servers,
   addition of these protocol elements may be specified to assume new values
   at some point in the future.  New values should be approved by the
   process services such as printing, and availability of IETF Consensus [10].

21. Acknowledgments

   Thanks to the DHC Working Group for their time and input into new
   software (system or application).

14.1. Reconfigure-init Message Validation

   Agents MUST silently discard any received Reconfigure-init messages.

   Clients MUST discard any Reconfigure-init messages that do
   not contain an authentication option or that fail the
   specification.  Ralph Droms and Thomas Narten have had client's
   authentication check.

   Clients MUST discard any Reconfigure-init messages that contain a major
   role
   transaction-ID that matches the transaction-ID in shaping a Reconfigure-init
   message previously received from the continued improvement of same DHCP server.

14.2. Server Behavior

   A server sends a Reconfigure-init message to trigger a client to
   initiate immediately a Request/Reply message exchange with the protocol by their
   careful reviews.  Many thanks
   server.  A server may unicast a Reconfigure-init message directly
   to Matt Crawford, Erik Nordmark, Gerald
   Maguire, a single client or use multicast to deliver a Reconfigure-init
   message to multiple clients.

14.2.1. Creation and Mike Carney for their studied review as part sending of Reconfigure-init messages

   The server sets the
   Last Call process.  Thanks also for the consistent input, ideas, and
   review by (in alphabetical order) Brian Carpenter, Jack McCann, Yakov
   Rekhter, Matt Thomas, Sue Thomson, and Phil Wells.

   Thanks "msg-type" field to Steve Deering TBD. The server generates
   a transaction-ID and Bob Hinden, who have consistently
   taken inserts it in the time "transaction-ID" field.
   The server places its address (of appropriate scope) in the
   "server-address" field.

   The server MAY include an ORO option to discuss inform the more complex parts client of the IPv6
   specifications.

22. DHCP options

   Options are used to carry additional what
   information and parameters
   in DHCP messages.  Every option shares a common base format, as
   described in section 22.1.

   this document describes has been changed or new information that has been added.

   The server MUST include an authentication option with the DHCP options defined appropriate
   settings and add that option as part of the base
   DHCP specification.  Other options may be defined in the future in a
   separate document.

22.1. Format of DHCP options

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

      option-code
                An unsigned integer identifying the specific last option type
                carried in this option.

      option-len
                An unsigned integer giving the length "options"
   field of the data Reconfigure-init message.

   The server MAY include a Reconfigure-delay option in
                this a
   Reconfigure-init message to be unicast to a client, and MUST
   include a Reconfigure-delay option in bytes.

      option-data a Reconfigure-init message to
   be multicast to a group of clients.

   The data for the option; server MUST NOT include any other options in the format of this data depends
                on Reconfigure-init
   except as specifically allowed in the definition of the option.

22.2. Identity association option individual
   options.

   The identity association option is used to carry an identity
   association, the parameters associated with server may either unicast the IA and Reconfigure-init message to one
   client or multicast the addresses
   assigned message to one or more Reconfigure Multicast
   Addresses previously sent as options to the IA. clients.  The format of server
   may unicast Reconfigure-init messages to more than one client
   concurrently; for example, to reliably reconfigure all clients, the 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
   server will unicast a Reconfigure-init message to 17 + num-addrs*25

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

      T1        The time at which the client contacts each client.

   If the server unicasts to one or more clients, it waits for a Request
   message from
                which those clients confirming that it has received the addresses in
   Reconfigure-init and are thus initiating a Request/Reply transaction
   with the IA were obtained server.  The server can determine that a Request message is
   in response to extend a Reconfigure-init because the lifetimes of transaction-ID in the addresses assigned to
   Request will be the IA.

      T2        The time at which same value as was used in the Reconfigure-init
   message.

   If the client contacts any available server to extend multicasts the lifetimes of Reconfigure-init message, it must use
   some TBD authentication mechanism that can authenticate the addresses assigned server to
   multiple clients.  There is no reliability mechanism for multicast
   Reconfigure-init messages.  A server might use multicast in the IA.

      num-addrs
                An unsigned integer giving the number
   case where it does not have a list of addresses
                carried in this IA option (MAY be zero).

      IPv6 address
                An IPv6 address assigned to this IA.

      preferred lifetime
                The preferred lifetime its clients; for the associated IPv6 address.

      valid lifetime
                The valid lifetime example, a
   server that distributes configuration information to clients using
   stateless autoconfiguration might not keep a list of clients it has
   communicated with.

   DISCUSSION:

      Authentication of multicast reconfigure-init is still an
      open issue.

   See section 18.2 for recommendations on the associated IPv6 address.

   The ``IPv6 address'', ``preferred lifetime'' use of multicast
   and ``valid lifetime''
   fields are repeated unicast Reconfigure-init messages for each address reliable client
   reconfiguration.

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

   If the server does not receive a Request message from the client
   in RECREP_MSG_TIMEOUT milliseconds, the IA option (as determined
   by server retransmits
   the ``num-addrs'' field).

   DISCUSSION:

      The details of Reconfigure-init message, doubles the format RECREP_MSG_TIMEOUT
   value and waits again.  The server continues this process until
   REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which point
   the selection of an IA's UUID server SHOULD abort the reconfigure process.

   Default and initial values for RECREP_MSG_TIMEOUT and
   REC_MSG_ATTEMPTS are TBD.

   DISCUSSION:

      An IA has no explicit ``lifetime'' or ``lease length'' documented in section 7.5.

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

   After the lifetimes of all of server transmits the addresses in an
      IA have expired, initial Reconfigure-init message,
   the IA can be considered as having expired.
      T1 and T2 are included to give servers explicit control over
      when a client recontacts server waits RECREP_MSG_TIMEOUT milliseconds.  The server
   then retransmits the Reconfigure-init message, doubles the
   RECREP_MSG_TIMEOUT value and waits again.  The server about repeats this
   process until 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 twice the number total of option codes
                carried REC_MSG_ATTEMPTS Reconfigure-init messages
   have been transmitted.

   Default and initial values for RECREP_MSG_TIMEOUT and
   REC_MSG_ATTEMPTS are documented in this option.

      option-data
                A list section 7.5.

14.2.4. Receipt of Request messages

   The server generates and sends Reply message(s) to the option codes for the options requested client as
   described in
                this option.

22.4. section 13.4.6, including in the "option" field new
   values for configuration parameters.

14.3. Client 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 Behavior

   A client message                     |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code TBD

      option-len
                Variable; equal to MUST always monitor UDP port 546 for Reconfigure-init
   messages on interfaces upon which it has acquired DHCP parameters.
   Since the length results of a reconfiguration event may affect application
   layer programs, the forwarded DHCP client message.

      option-data
                The message received from SHOULD log these events, and MAY notify
   these programs of the client; forwarded verbatim
                to change through an implementation-specific
   interface.

14.3.1. Receipt of Reconfigure-init messages

   Upon receipt of a valid Reconfigure-init message, the client
   initiates a Request/Reply transaction with the server.

22.5. Server message option

      0                   1                   2

14.3.2. Creation and sending of Request messages

   When responding to a Reconfigure-init, the client creates and
   sends the Request message in exactly the same manner as outlined in
   section 13.3.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.

14.3.3. Time out and retransmission of Request messages

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

14.3.4. Receipt of Reply messages

   Upon the receipt of a valid Reply message, the client extracts the
   contents of the "option" field, and sets (or resets) configuration
   parameters appropriately.  The client records and updates the
   lifetimes for any addresses specified in IAs in the Reply message.
   If the configuration parameters changed were requested by the
   application layer, the client notifies the application layer of the
   changes using an implementation-specific interface.

15. Relay Behavior

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

15.1. Relaying of Solicit messages

   When a Relay receives a valid Solicit message, it constructs
   a Relay-forward message.  The relay places an address from
   the interface on which the Solicit message was received in the
   "relay-address" field and the prefix length for that address in the
   "prefix-length" field.  This address will be used by the server to
   identify the link to which the client is connected and will be used
   by the relay to forward the Advertise message from the server back to
   the client.

   The relay constructs a "relay-message" option 16.4 that contains
   the entire Solicit message from the client in the data field of the
   option.  The relay places the "relay-message" option along with any
   "relay-specific" options in the options field of the Relay-forward
   message.  The Relay then sends the Relay-forward message to the list
   of server destination addresses that it has been configured with.

15.2. Relaying of Advertise messages

   When the relay receives a Relay-reply message, it extracts the
   Advertise message from the "server-message" option and forwards the
   server message to the address in the client-link-local-address field
   in the Advertise message.  The relay forwards the server message
   through the interface identified in the "relay-address" field in the
   Relay-reply message.

16. DHCP options

   Options are used to carry additional information and parameters
   in DHCP messages.  Every option shares a common base format, as
   described in section 16.1.

   this document describes the DHCP options defined as part of the base
   DHCP specification.  Other options may be defined in the future in a
   separate document.

16.1. Format of DHCP options

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

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

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

      option-data The data for the option; the format of this data
                depends on the definition of the option.

16.2. Identity association option

   The identity association option is used to carry an identity
   association, the parameters associated with the IA and the addresses
   assigned to the IA.

   The format of the 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              |          option-len           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            IA DUID                            |
     |                          (8 octets)                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              T1                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              T2                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   IA status   |   num-addrs   |  addr status  | prefix length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         IPv6 address                          |
     |                          (16 octets)                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      preferred lifetime                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        valid lifetime                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  addr status  | prefix length |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                         IPv6 address                          |
     |                          (16 octets)                          |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |      preferred lifetime       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | pref. lifetime (cont.)        |        valid lifetime         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | valid lifetime (cont.)        |         IPv6 address          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                              ...                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code TBD

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

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

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

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

      IA status Status of the IA in this option.

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

      addr status Status of this address.

      prefix length Prefix length for this address.

      IPv6 address An IPv6 address assigned to this IA.

      preferred lifetime The preferred lifetime for the associated IPv6
                address.

      valid lifetime The valid lifetime for the associated IPv6 address.

   The "IPv6 address", "preferred lifetime" and "valid lifetime" fields
   are repeated for each address in the IA option (as determined by the
   "num-addrs" field).

   DISCUSSION:

      The details of the format and the selection of an IA's DUID
      are TBD.

   Note that an IA has no explicit "lifetime" or "lease length" of
   its own.  When the lifetimes of all of the addresses in an IA have
   expired, the IA can be considered as having expired.  T1 and T2
   are included to give servers explicit control over when a client
   recontacts the server about a specific IA.

16.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 twice the number of option codes
                carried in this option.

      option-data A list of the option codes for the options requested
                in this option.

16.4. Client 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 client message                     |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code TBD

      option-len Variable; equal to the length of the forwarded DHCP
                client message.

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

16.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 message                     |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code TBD

      option-len Variable; equal to the length of the forwarded DHCP
                server message.

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

16.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 specific option
                type carried in this option.

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

      option-data The data for the option; the format of this data
                depends on the definition of the option.

16.7. Authentication option

   The authentication option is TBD.

16.8. Reconfigure-delay option

   The Reconfigure-delay option specifies the amount of time a client
   should delay before sending a Request message in response to a
   Reconfigure-init 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          option-code          |           option-len          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   minimum delay time (msec)   |   maximum delay time (msec)   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The client chooses a random number between the minimum delay time and
   the maximum delay time and delays that number of milliseconds before
   sending its Request message.

16.9. DSTM Global IPv4 Address Option

   The DSTM Global IPv4 Address Option informs a client or server that
   the Identity Association Option (IA) following this option will
   contain an IPv4-Mapped IPv6 Address [?] in the case of a Client
   receiving the option, or is a Request for an IPv4-Mapped IPv6 Address
   from a client in the case of a DHCPv6 Server receiving the option.
   The option can also provide an IPv6 address to be used as the Tunnel
   Endpoint (TEP) to encapsulate an IPv4 packet within IPv6.

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

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              option-code      |             option-length     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Tunnel End Point (TEP)               |
   |                           (If Present)                        |
   |                            (16 octets)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   option-code:            TBD
   option-length:          Variable: 0 or 16
   Tunnel End Point:       IPv6 Address if Present

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

17. DHCP Client Implementor Notes

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

17.1. Primary Interface

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

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

17.2. Advertise Message and Configuration Parameter Caching

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

17.3. Time out and retransmission variables

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

17.4. Server Preference

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

18. DHCP Server Implementor Notes

   This section provides helpful information for the server implementor.

18.1. Client Bindings

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

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

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

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

18.2. Reconfigure-init Considerations

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

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

18.2.1. Reliable transmission of multicast Reconfigure-init messages

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

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

18.3. Server Preference

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

18.4. Request Message Transaction-ID Cache

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

19. DHCP Relay Implementor Notes

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

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

20. Open Issues for Working Group Discussion

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

20.1. Authentication

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

20.2. Identification of IAs by servers

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

20.3. DHCP-DNS interaction

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

20.4. Anonymous addresses

   How does DHCPv6 interact with anonymous addresses?  If the server message                     |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      option-code TBD
      option-len
                Variable; equal
   assigns anonymous addresses (e.g., addresses with short lifetimes),
   how can a client application choose an anonymous address as a source
   address in preference to a non-anonymous address?

20.5. Use of term "agent"

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

20.6. Client behavior when response to Rebind is not received

   Section 13.3.4 describes several plausible ways in which a client
   might respond when it does not receive a Reply to a Rebind message.
   The acceptable client behaviors need to be defined and described
   in 13.3.4.

20.7. Additional options

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

20.8. Operational parameters

   Should servers have an option to set operational parameters -
   retransmission timeouts, number of retries - in clients?

21. Security

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

   DISCUSSION:

      Based on the discussion of security issues at the
      8/31/00 design team teleconference and subsequent
      DHC WG mailing list discussion, DHCPv6 will use
      the security model from DHCPv4, as described in
      draft-ietf-dhc-authentication-15.txt.

22. Year 2000 considerations

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

      option-data
                The current year.

23. IANA Considerations

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

   Section 7.1 lists several multicast addresses used by DHCP.

   This document also defines several status codes that are to be
   returned with the 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 Reply message (see section 9.7).  The non-zero
   values for these status codes which are currently specified are shown
   in the specific table in section 7.4.

   There is a DHCPv6 option type
                carried described in this option.

      option-len
                An unsigned integer giving the length section 16.6, which allows
   clients and servers to exchange values for some of the data timing
   and retransmission parameters defined in
                this option section 7.5.  Adding new
   parameters in bytes.

      option-data
                The data the future would require extending the values by which
   the parameters are indicated in the DHCP option.  Since there needs
   to be a list kept, the default values for each parameter should also
   be stored as part of the option; list.

   All of these protocol elements may be specified to assume new values
   at some point in the future.  New values should be approved by the format
   process of this data depends
                on IETF Consensus [9].

24. Acknowledgments

   Thanks to the definition of DHC Working Group for their time and input into the option.

22.7. Authentication option

   The authentication option is TBD.

23. Changes
   specification.  Ralph Droms and Thomas Narten have had a major
   role in this draft

   This section describes shaping the changes between this version continued improvement of the DHCPv6
   specification protocol by their
   careful reviews.  Many thanks to Matt Crawford, Erik Nordmark, Gerald
   Maguire, and draft-ietf-dhc-dhcpv6-15.txt.

23.1. Order Mike Carney for their studied review as part of sections

   New sections the
   Last Call process.  Thanks also for the consistent input, ideas, and
   review by (in alphabetical order) Brian Carpenter, Jack McCann, Yakov
   Rekhter, Matt Thomas, Sue Thomson, and Phil Wells.

   Thanks to Steve Deering and Bob Hinden, who have been added at consistently
   taken the end of this document time to minimize
   changes in section numbering.  Those sections discuss the more complex parts of the IPv6
   specifications.

A. Comparison between DHCPv4 and DHCPv6

   This appendix is provided for readers who will be rearranged in find it useful to see
   a
   future revision.

23.2. Reconfigure message

   DHCP Reconfigure model and Reconfigure-reply messages architecture comparison between DHCPv4 [6, 1] and the associated
   mechanisms have been removed from this draft of the 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 DHCPv6.
   There are used in all messages.

23.5. Design goals

   The second sentence in three key reasons for the 8th design goal bullet has been removed.

23.6. Overview

   Section 8.2 (DHCP agents) has been removed.  DHCP clients no longer
   need to know about specific DHCP agents.

   Section 8.3 has been modified to reflect differences:

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

     o DHCPv6 benefits from the new encapsulating
   mechanism through which relays forward client messages IPv6 features.

     o New features were added to servers.

   Section 8.6 support the expected evolution and 8.7 have been modified to describe ``identity
   associations''.

   Section 8.8 has been modified to reflect
       the deletion existence of
   ``reconfigure'' and ``reconfigure-reply'' messages.

23.7. Message formats, 9

   Message formats have been changed.  All messages share a common fixed
   message header followed by options. more complicated Internet network service
       requirements.

   IPv6 Architecture/Model Changes:

     o The various control bits (``P'',
   ``C'') link-local address permits a node to have been removed from an address
       immediately when the message header.

23.8. Solicit and Advertise messages, (section 10) node boots, which means all clients have a
       source IP address at all times to locate an on-link server or
       relay.

     o The description of need for BOOTP compatibility and the message exchanges broadcast flag 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
       removed.

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

     o Stateful autoconfiguration has
   been added to section 2.  The description of messages exchanges
   have been extended coexist and integrate with
       stateless autoconfiguration supporting Duplicate Address
       Detection and the two IPv6 lifetimes, to include IAs. facilitate the dynamic
       renumbering of addresses and the management of those addresses.

     o Multiple addresses per interface are inherently supported in
       IPv6.

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

   DHCPv6 Architecture/Model Changes:

     o The IA option message type is defined in
   section 22.2

23.11. Extensions renamed options; defined in this document

   ``extensions'' are now called ``options''; the options referenced first byte in
   this document the packet.

     o IPv6 Address allocations are defined now handled in section 22.

23.12. Transaction-ID ranges

   Solicit, Advertise, Request, Reply, Release and Reconfigure-init
   messages all use an unsigned 16-bit integer ``Transaction-ID''.
   Transaction-IDs generated by clients are considered to be chosen from a different namespace than those chosen by servers.  There is no
   need message option as
       opposed to restrict clients the message header.

     o Client/Server bindings are now mandatory and servers take advantage of
       the client's link-local address to select Transaction-IDs always permit communications
       either directly from
   specific ranges to avoid conflicts.

23.13. Release messages and relays

   Release/Reply messages are forwarded an on-link server, or from a off-link server
       through relays.  This mechanism
   eliminates the need for an 'R' bit.

23.14. Discovering relay agents

   Clients no longer learn on-link relay.

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

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

     o The on-link relay agents.  When may locate off-link server addresses from
       system configuration or by the
   client only has use of a link-local address (e.g., site-wide multicast
       packet.

     o ACKs and NAKs are not used.

     o The server assumes the client has no
   assigned addresses), receives its responses unless it now multicasts Request message, which is then
   forwarded by
       receives a relay agent on retransmission of the same link.

A. Comparison between DHCPv4 and DHCPv6 client request.  This appendix is provided for readers who will find it useful to see
   a model and architecture comparison between DHCPv4 [6, 1] and DHCPv6.
   There are three key reasons for
       permits recovery in the case where the differences: network has faulted.

     o IPv6 inherently supports a new model and architecture for
       communications and autoconfiguration of addresses. Clients can issue multiple, unrelated Request messages to the
       same or different servers.

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

     o New features were added Clients MUST listen to support the expected evolution and their UDP port for the existence of more complicated Internet network service
       requirements.

   IPv6 Architecture/Model Changes: new Reconfigure
       message from servers.

     o The link-local address permits a node to New options have an address
       immediately when been defined.

   With the node boots, which means all clients have a
       source IP address at all times changes just enumerated, we can support new user features,
   including

     o Configuration of Dynamic Updates to locate an on-link DNS

     o Address deprecation, for dynamic renumbering.

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

     o The need Authentication

     o Clients can ask for BOOTP compatibility and multiple IP addresses.

     o Addresses can be reclaimed using the broadcast flag have been
       removed. Reconfigure-init message.

     o Multicast Integration between stateless and stateful address scoping in IPv6 permit the design
       autoconfiguration.

     o Enabling relays to locate off-link servers.

B. Full Copyright Statement

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

   This document and translations of
       discovery packets 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 would inherently define their range by the
       multicast address for the function required.

     o Stateful autoconfiguration has to coexist above copyright notice and integrate with
       stateless autoconfiguration supporting Duplicate Address
       Detection 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 two IPv6 lifetimes, copyright notice or references to facilitate the dynamic
       renumbering of addresses and Internet Society
   or other Internet organizations, except as needed for the management purpose
   of those addresses.

     o Multiple addresses per interface are inherently supported developing Internet standards 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 [15].

   DHCPv6 Architecture/Model Changes:

     o The message type is which case the first byte procedures
   for copyrights defined in the packet.

     o IPv6 Address allocations are now handled in a message option Internet Standards process must be
   followed, or as
       opposed required to the message header.

     o Client/Server bindings translate it into languages other than
   English.

   The limited permissions granted above are now mandatory perpetual 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 be
   revoked by the client receives Internet Society or its responses unless it
       receives a retransmission of the same client request. successors or assigns.

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

C. Changes in this draft

   This section describes the case where changes between this version of the network has faulted.

     o Clients can issue multiple, unrelated Request DHCPv6
   specification and draft-ietf-dhc-dhcpv6-16.txt.

C.1. New messages to the
       same or different servers.

     o The function of DHCPINFORM is inherent in for confirming addresses and extending the lease on an
   IA

   Four new packet design;
       a client can request configuration parameters other than IPv6
       addresses messages, DHCP Confirm, DHCP Renew, DHCP Rebind and DHCP
   Decline, have been added and are described in the optional option headers.

     o Clients MUST listen section 13.  Client
   behavior - when and how to their UDP port for the send these new Reconfigure messages - and server
   behavior - how to respond to each - has been defined.  The message from servers.

     o New options
   type codes for these messages have been defined.

   With added to section 7.3.

C.2. New message formats

   Section 9 has been restructured to include only one copy of the changes just enumerated, we can support new user features,
   including

     o Configuration DHCP
   message header, because now all the messages have the same header
   format.  Descriptions of the use of Dynamic Updates header fields in the Confirm,
   Renew, Rebind and Decline messages have been added to DNS

     o Address deprecation, 9.

C.3. Renamed Server-forward message

   Section 10.2 has been renamed "relay-reply" for dynamic renumbering.

     o Relays can be preconfigured consistency with server addresses, or use the
   rest 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

C.4. Clarified relay forwarding of messages

   Added text to sections on relay behavior to clarify encapsulation and translations
   decapsulation of it may be copied client messages in Relay-forward and furnished to
   others, Relay-reply
   messages.

C.5. Addresses and derivative works that comment on or otherwise explain it
   or assist options in its implementation may Advertise messages

   Modified section 12.4.2 so that servers include addresses to be prepared, copied, published
   assigned and distributed, other options in whole or Advertise messages.  Also added text to
   section 12.3.1 to disallow option values (except as noted in part, without restriction option
   definitions) in Solicit messages.

C.6. Clarification of any
   kind, provided that IA option format

   Changed the above copyright notice label of the prefix length field in an IA option to
   "prefix length" in the option format diagram, and this paragraph
   are included on all such copies moved the prefix
   before the address for consistency with relay messages and derivative works.  However,
   this document itself may not be modified other IPv6
   protocols.

C.7. Specification of transaction ID in any way, such as by
   removing Solicit message

   Add text (which was missing) to specify the copyright notice or references insertion of a
   transaction ID in Solicit messages.

C.8. Edits to definitions

   Some of the Internet Society
   or other Internet organizations, except as needed definitions in section 6 have been edited for the purpose clarity.

C.9. Relay agent messages

   The formats of developing Internet standards relay agent messages are now described in which case the procedures a separate
   section, 10.

C.10. Relay agent behavior

   The behavior of relay agents for copyrights defined all client and server messages is
   now described in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above a single section, 15.

C.11. Transmission of all client messages through relays

   All client messages are perpetual now multicast to the All Agents multicast
   address and will not be
   revoked forwarded by the Internet Society or its successors relays as appropriate.

C.12. Reconfigure-init messages

   Client behavior in response to a Reconfigure-init messages has
   been extended to accommodate receipt of multiple copies of a
   Reconfigure-init message due to duplicate messages or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis retransmission.

   Server use of multicast Reconfigure-init has been specified.

   Hints about use of multicast 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. unicast for reliable reconfiguration
   have been added to server implementor's hints.

C.13. Ordering of sections

   Several sections have been re-ordered for clarity.

C.14. DSTM option

   The DSTM option has been added (section 16.9).

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] S. Bradner.  Key words for use in RFCs to Indicate Requirement
        Levels.  Request for Comments (Best Current Practice) 2119,
        Internet Engineering Task Force, March 1997.

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

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

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

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

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

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

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

   [10]

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

   [11]

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

   [12]

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

   [13]

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

   [14]

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

   [15]

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

   [16]

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

Chair's Address

   The working group can be contacted via the current chair:

         Ralph Droms
         Cisco Systems
         300 Apollo Drive
         Chelmsford, MA 01824

         Phone:  (978) 244-4733
         E-mail:  rdroms@cisco.com

Author's Address

   Questions about this memo can be directed to:

        Jim Bound
        Compaq Computer Corporation
        Mail Stop:  ZK03-3/U14
        110 Spitbrook
        Nokia Networks
        5 Wayside Road
        Nashua, NH 03062
        Burlington, MA 01803
        USA
        Phone:  +1-603-884-0400  +1-781-492-6010
        Email:  bound@zk3.dec.com  jim.bound@nokia.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