INTERNET-DRAFT                                                  J. Bound
DHC Working Group                                 Digital Equipment Corp
March 1995                                                    Y. Rekhter
                                    T.J. Watson Research Center IBM Corp
                                                             Sue Thomson
                                                                Bellcore
Obsoletes: draft-ietf-dhc-dhcpv6-01.txt                          July 95

             Dynamic Host Configuration Protocol for IPv6

                      draft-ietf-dhc-dhcpv6-01.txt

                      draft-ietf-dhc-dhcpv6-02.txt

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

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

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

   Discussion for

   Distribution of this draft will take place on host-
   conf@sol.cs.bucknell.edu. document is unlimited.

Abstract

   The Dynamic Host Configuration

   DHCPv6 is an Internet application protocol that uses a Client/Server
   model to communicate between hosts.  DHCPv6 executes over the UDP
   [RFC-768] transport protocol, and the Internet Protocol for Version 6
   (IPv6) [IPv6-SPEC]. DHCPv6 is an IPv6 (DHCPv6): provides specification for a
   mechanism statefull
   implementation of address autoconfiguration as referenced in IPv6
   Stateless Address Configuration [IPv6-ADDRCONF].  DHCPv6 supports
   mechanisms to autoconfigure inter-link Host host IPv6 addresseses [IPv6-
   ADDR], provides parameters to addresseses, autoregister [DYN-DNS-UPD] and receive host
   names dynamically in the Domain Name System (DNS) [RFC-1034&1035] Host names, (DNS), and provides a
   mechanism specifies the
   format to specify additional configuration add future Configuration Parameter options to the protocol
   for extensibility.

   The work on this protocol will take place in the
   protocol. Dynamic Host
   Configuration (DHC) Working group. One may join the Working Group
   mail list by sending mail to host-conf-request@sol.eg.bucknell.edu.

INETERNET-DRAFT       draft-ietf-dhc-dhcpv6-01.txt            March       draft-ietf-dhc-dhcpv6-02.txt             July 1995

Table of Contents:

1.  Introduction................................................3
1.1 Requirements................................................3
2.  Terminology.................................................3
3.  Terminology and Definitions.................................5
2.1 IPv6 Terminology............................................5
2.2 DHCPv6 Terminology..........................................6
3.  Protocol Design Model................................4 Model.......................................8
3.1 DHCPv6 Protocol Request/Response Model......................4 Related Work in IPv6........................................8
3.2 DHCPv6 Design Goals................................................9
3.3 Request/Response Model.....................................10
3.4 Leased Address Model.................................4
3.3 DHCPv6 Model.......................................11
3.5 DNS Host Name Autoregistration Model.................5
3.4 DHCPv6 Client/Server Model..................................5 Model.......................12
3.6 Defining Optional Configuration-Data.......................13
4.  DHCPv6 Protocol Format......................................7  Datagram and Data Formats..................................14
4.1 Datagram...................................................14
4.2 Data Formats...............................................14
5.  DHCPv6  Client/Server Processing.............................9 Processing...................................16
5.1 DHCPv6 Client Transmission..................................9 Transmission........................................16
5.2 DHCPv6 Server Transmission..................................9 Transmission........................................16
5.3 DHCPv6 Client Requests......................................9 Client/Server Bindings.....................................17
5.4 DHCPv6 Client Responses....................................10 Requests............................................17
5.5 DHCPv6 Server Responses....................................11 Response............................................18
5.6 DHCPv6 Server Lease Expiration.............................13 Client Confirmations/Rejections............................19
6.  DHCPv6  Relay-Agent Processing..............................13
Acknowledgements...............................................15
References.....................................................15 Processing.....................................19
Draft ***Open Issues***........................................21
Change History.................................................22
Acknowledgements...............................................23
References.....................................................23
Authors' Addresses.............................................16 Addresses.............................................24

INETERNET-DRAFT       draft-ietf-dhc-dhcpv6-01.txt            March       draft-ietf-dhc-dhcpv6-02.txt             July 1995

1.  Introduction

   The Dynamic Host Configuration Protocol for IPv6 (DHCPv6): provides a
   mechanism to autoconfigure inter-link Host IPv6 addresseses [IPv6-
   ADDR], provides parameters to autoregister [DYN-DNS-UPD] and receive
   Domain Name System (DNS) [RFC-1034&1035] Host names, and provides a
   mechanism to specify additional configuration options in the
   protocol.

   DHCPv6 is an Internet application protocol that uses a Client/Server
   model to communicate between Hosts. hosts.  DHCPv6 executes over the UDP
   [RFC-768] transport protocol, and the IPv6 Internet Protocol Version 6
   (IPv6) [IPv6-SPEC]. DHCPv6 will need to request Server and Client Ports
   from IANA.

   DHCPv6 is the an IPv6 specification for a statefull
   implementation of address autoconfiguration as defined referenced in IPv6
   Stateless Address Configuration [IPv6-ADDRCONF].

2.  Terminology

   Configuration Data: Configuration Data is information a Host can use  DHCPv6 supports
   mechanisms to configure a Host on a network so that autoconfigure host IPv6 addresseses, autoregister host
   names dynamically in the Host can interoperate
   with other Hosts on a network.

   DHCPv6 Client: A DHCPv6 Client is a Host that initiates requests on a
   network Domain Name System (DNS), and specifies the
   format to obtain add future Configuration Data from a DHCPv6 server.

   DHCPv6 Server: A DHCPv6 Server Parameter options to the protocol
   for extensibility.

   The IPv6 new version of the Internet Protocol, is being developed
   with 128bit addresses.  The IPv6 addressing architecture [IPv6-ADDR]
   and stateless address configuration [IPv6-ADDRCONF] specifications
   provide new functionality not present in the Internet Protocol
   version 4 (IPv4), which provide inherent benefits to autoconfigure
   IPv6 addresses for host nodes.  In addition the IETF DNS Working
   Group has work in progress to support Dynamic Updates to DNS [DYN-
   UPD], which can be used by a Host that responds node to requests
   from add, delete, and change host
   names dynamically.

   DHCPv6 clients uses the enhancements in IPv6 and DNS to provide Configuration Data.

   DHCPv6 Relay-Agent: A DHCPv6 Relay-Agent define an efficient
   protocol, and is a not required to support any IPv4 protocol for
   backward compatibility.  DHCPv6 Server that
   listens on does use many of the network architectural
   principles in DHCP for DHCPv6 Clients requesting Configuration
   Data, and then relays IPv4 (DHCPv4) [DHCP-v4].  It is not within the request
   scope of this document to a DHCPv6 Server compare and contrast DHCPv4 with DHCPv6.

1.1 Requirements

   Throughout this document, the reply
   back words that are used to define the DHCPv6 Client.

   Transaction ID -
   significance of the particular requirements are capitalized.  These
   words are:

      o "MUST"

      This word or the adjective "REQUIRED" means that the item is used to uniquely identify a set an
      absolute requirement of DHCPv6
   request/response messages between DHCPv6 Servers and Clients.  The
   Transaction ID is generated by this specification.

      o "MUST NOT"

      This phrase means the DHCPv6 Client requests.

   Interface-Token: An Interface Token item is used an absolute prohibition of this
      specification.

      o "SHOULD"

      This word or the adjective "RECOMMENDED" means that there may
      exist valid reasons in particular circumstances to uniquely identify ignore this
      item, but the full impliciations should be understood and the case
      carefully weighed before choosing a
   DHCPv6 Client network interface.

   Lease: different course.

      o "SHOULD NOT"

      This phrase means that there may exist valid reasons in particular
      circumstances when the listed behavior is acceptable or even

INETERNET-DRAFT       draft-ietf-dhc-dhcpv6-02.txt             July 1995

      useful, but the address lifetime for a single address provided to
   a DHCPv6 Client.

   Expired Lease: An Expired Lease full implications should be understood and the
      case carefully weighted before implementing any behavior described
      with this label.

      o "MAY"

      This word or the adjective "OPTIONAL" means that this item is one where
      truly optional.  One vendor may choose to include the Lease duration of an
   address has ended item because
      a particular marketplace requires it or because it has been mandated by a DHCPv6 Server
   to a DHCPv6 Client. enhances the
      product, for example, another vendor may omit the same item.

INETERNET-DRAFT       draft-ietf-dhc-dhcpv6-01.txt            March       draft-ietf-dhc-dhcpv6-02.txt             July 1995

3.  DHCPv6 Protocol Design Model

3.1 DHCPv6 Protocol Request/Response Model

   DHCPv6 uses a message type

2.  Terminology and Definitions

   Terminology and Definitions are critical to define whether the packet orginated
   from a understanding of any
   IETF specification.  This Section will provide the terms and
   definitions used throughout this specification.  Relevant IPv6
   specification [IPv6-SPEC], IPv6 Addressing Architecture [IPv6-ADDR],
   and IPv6 Statelss Address Configuration [IPv6-ADDRCONF] terminology
   will be provided, then the DHCPv6 Server terminology.

2.1 IPv6 Terminology

   node: A device that implements IPv6.

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

   host: Any node that is not a router.

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

   neighbors: Nodes attached to define the operation requested, same link.

   interface: A nodes's attachment to the link.

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

   packet: An IPv6 header plus payload.

   link MTU: The maximum transmission unit, i.e., maximum packet size in
   octets, that can be conveyed in one piece over a link.

   path MTU: The minimum link MTU of all the links in a path between a
   source node and a message response to define either destination node.

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

   multicast address: An identifier for a confirmation/rejection set of interfaces (typically
   belonging to different nodes).  A packet sent to a response.

   The request/response model multicast address
   is as follows:

     1.  Request (Client)
     2.  Response with configuration data (Server).
     3.  Confirmation Response with accept or reject (Client).
     4.  Confirmation Response for accept (Server). delivered to all interfaces identified by that address.

   link-local address: The time out period link-local address is for use on a DHCPv6 Host to wait for single
   link.  On initialization of an interface, a response is
   implementation defined. When host forms a DHCPv6 Host times out waiting for link-local
   address by concatenating a
   response well-known link-local prefix to a packet sent, the Host should not commit any state based
   on token
   that is unique per link.  For example, in the content case of a host attached
   to a link that uses IEEE 802 addresses, the packet sent.  It token is implementation defined if an IEEE 802
   address associated with the packet interface.

   validation-lifetime: This is retransmitted.

   A DHCPv6 packet will only contain one address and one name, depending
   on the message type, request, address lifetime for a single
   address provided to a host.  The validation-timer is in absolute time

INETERNET-DRAFT       draft-ietf-dhc-dhcpv6-02.txt             July 1995

   and response codes in a packet.
   Because IPv6 supports multiple addresses per interface seconds (e.g. 3 hours would have the DHCPv6
   Server may also inform value 10800).

   deprecation-liftetime: This is the DHCPv6 Client that there are multiple
   addresses available lifetime for its use.  This may be conveyed to a single address the DHCPv6
   Client in
   host uses to begin the Number deprecation of Address Fields provided in a response packet
   by the DHCPv6 Server.

   Multiple addresses and names may be specified as an extended
   configuration option [IPv6-DHCP-OPTIONS].  A design objective of
   DHCPv6 is address prior to avoid fragmentation in IPv6, when possible.  If the
   DHCPv6 packet exceeds 576 octets then UDP must perform Path MTU
   Discovery [PMTU].
   validation-lifetime expiring, so that the host can determine if the
   address can receive a new validation-lifetime.  The support of multiple names deprecation-
   lifetime is in absolute time and addresses can in seconds (e.g. 3 hours would have
   the value 10800).  The deprecation-lifetime MUST be no greater than
   the validation-lifetime.

   deprecated-address: This is a configuration option single address that is in DHCPv6.

   If the DHCPv6 Host cannot match up any of
   deprecated state on a host because the specified parameters,
   as discussed in section 5 deprecation-lifetime period
   has expired.

   invalid-address:  This is a single address whose validation-lifetime
   has expired.

2.2 DHCPv6 Client/Server Processing, Terminology

   configuration-type: Configuration Type defines an optional
   configuration parameter in this
   protocol specification the packet should be silently discarded.

3.2 DHCPv6 Leased Address Model

   A DHCPv6 address returned protocol.

   configuration-data: Configuration Data is information a host can use
   to configure a DHCPv6 host on a network, so that the host can interoperate
   with other hosts on a network.  Configuration Data will vary in
   length depending on the configuration type.

   client: A Client has is a Lease time. host that initiates requests on a link to
   obtain: addresses, DNS host name processing, or configuration-data.

   server: A
   design objective of DHCPv6 Server is a host that responds to support Dynamic Readdressing.  To
   accomplish this objective, addresses must be able requests from clients on
   a link to be reclaimed by provide: addresses, DNS host name processing, or
   configuration-data.

   relay-agent: A Relay-Agent is a network site.  Hence, all addresses must be Leased in DHCPv6. router that listens on the link for
   clients requests, and then forwards the request to a server on the
   network.  The DHCPv6 Client has server will respond back to the responsibility Relay-Agent, who will
   forward the reply to renew the client on the Relay-Agents link.

   message-type: The Message-Type defines the DHCPv6 protocol operation
   for this packet.

   message-code: The Message-Code defines a Lease notification for an
   address that is about to expire or request a new address with message-
   type from a Lease
   time.

   In client or server.

   name-length: The Name-Length defines the case where it is necessary to Expire a Lease because length of a
   mandate in an organizations site, the DHCPv6 Server may send host name
   provided by a Lease

INETERNET-DRAFT       draft-ietf-dhc-dhcpv6-01.txt            March 1995

   Expired message with client or a grace period to server for DNS Autoregistration of host
   names.

   interface-token: The Interface-Token is specified by the client and
   is a DHCPv6 Client.  This will unique opaque identifer for a clients interface, and must be
   an asynchronous operation
   accessbile after a client reboots (e.g. IEEE 802 MAC address).

   address-count: The address-count is specified by the DHCPv6 Server client with any
   request sent to the DHCPv6 Client, a server, and represents the only case where number of addresses the DHCPv6 request/response model
   client has received from a server for a specified interface-token.

INETERNET-DRAFT       draft-ietf-dhc-dhcpv6-02.txt             July 1995

   client-address: The Client-Address is not used the field in the protocol.

   When a DHCPv6 Clients address for a network interface Lease expires,
   it may attempt to complete all oustanding network connections using
   that address, but must not use
   protocol that contains the address for new network
   connections.

3.3 DHCPv6 DNS Host Name Autoregistration Model

   DHCPv6 supports the autoregistration of DNS Host names and providing
   DNS Host Names with addresses for DHCPv6 Clients.  Autoregistration clients interface-token.

   server-address: The Server-Address is supported by fields the field in DHCPv6, which the DHCPv6 Client may provide
   protocol that contains the address of the server responding to the DHCPv6 Server in a
   clients request.  In addition a

   gateway-address: The Gateway-Address is the field in the DHCPv6 Server may
   provide
   protocol that contains the relay-agents address, so a DNS Host Name with an IPv6 address server, that
   may be multiple relay-agent hops away from the orginal relay-agent,
   can respond directly to a DHCPv6 Client in a
   response.

   DHCPv6 only specifies the parameters and action relay-agent that forwarded the request,
   by extracting the Gateway- Address to be taken, and not used as the actual protocol or primitives to interact with DNS. server packets
   destination address.

   client-link-address: The
   functions that client-link-address is the field in the
   DHCPv6 Server uses to interact with protocol the DNS relay-agents use to
   provide autoregistration is defined save the clients source
   address in Dynamic Updates the IPv6 header, so they can respond back to DNS [IPv6-
   DYN-UPD].

   This is not a Fully Qualified Domain Name (FQDN) but only the local-
   part label and then only server on
   the Host Name [RFC-1034&1035].  It link.

   transaction-ID: The Transaction-ID is
   assumed specified by the DHCPv6 Server implementation knows or can determine what client as an
   opaque transaction identifier, which uniquely identifies the domain name part is for any IPv6 subnet prefix current
   operation between the client and the server.  The server may utilize
   this transaction identifier in order to detect duplicate transactions
   and to provide context between messages in a multi-message exchange
   with a client who has multiple requests for which it the same interface-token.

   host-name:  The Host-Name is
   providing the name to be associated with an
   address.  If a DHCPv6 Client wants to know its domain
   name the name-length is zero then it will have to request this as specified the Host-Name is not
   present in the DHCPv6
   Options Specification [IPv6-DHCP-OPTIONS].

3.4 DHCPv6 Client/Server Model request or response.

   binding:  The Binding in DHCPv6 supports is a Transaction ID to uniquely identify N-tuple that a set of
   request/response messages between DHCPv6 Clients client and Servers. server
   MUST maintain in DHCPv6 supports an Interface Token to uniquely identify a network
   interface on for each completed transaction, where N is
   the number of configuration-data identifiers for a DHCPv6 Client.

   DHCPv6 can client.  An
   implementation MUST support an extensible set at least a 4-tuple Binding consisting of
   the clients interface-token, address, validation-lifetime, and
   deprecation-lifetime for that address.  An example of options as defined by a
   Configuration Type.  These options are specified completed
   transaction in a DHCPv6 Options
   specification [IPv6-DHCP-OPTIONS].

   The DHCPv6 Options provide a Configuration Type which defines is when the
   option requested client requests an address for an
   interface-token and then returned.  A Next Type field is provided
   which can be used by receives an application to know if there address and lease for that token.  It
   is more implementation defined if greater than one
   option.  If the Next Type field a 4-tuple Binding is NULL then
   supported by an implementation, and is not prohibited by this
   specification.

INETERNET-DRAFT       draft-ietf-dhc-dhcpv6-02.txt             July 1995

3.  Protocol Design Model

   This section is provided for implementors to understand the last option
   present.  The Length field DHCPv6
   protocol design model from an architectural perspective.  It provides
   related work in IPv6 that influenced the length protocol design and the
   design goals.  The request/response protocol model is discussed and
   the objective of this model in the data present design.  The leased address
   strategy and purpose is discussed. The objective of the
   autoregistration for DNS Host Names is discussed and the capabilities
   that option. are possible in this specification.  The Variable Configuration Data client/server model is
   discussed to prepare an implementor for the data client/server processing
   provided later in the specification.  Then the configuration options
   are defined and how they are used to
   provide build additional extensible
   configuration-data for DHCPv6.

3.1 Related Work in IPv6

   The related work in IPv6 that option.

   DHCPv6 does not specify whether would best serve an implementor to
   study is the DHCPv6 Server IPv6 Specification [IPv6-SPEC], the IPv6 Addressing
   Architecture [IPv6-ADDR], IPv6 Stateless Address Configuration Data
   provided
   [IPv6-ADDRCONF], IPv6 Neighbor Discovery Processing [IPv6-ND], and
   Dynamic Updates to DNS [DYN-UPD].  These specifications afford DHCPv6 Clients is synchronous across
   to build upon the sites network
   information database (e.g. DNS), whether IPv6 work to provide both robust statefull
   autoconfiguration and autoregistration of DNS Host Names.  In
   addition related work for DHCP for IPv4 is directly related to
   DHCPv6.

   The IPv6 Specification provides the base architecture and design of
   IPv6.  A key point for DHCPv6 Server

INETERNET-DRAFT       draft-ietf-dhc-dhcpv6-01.txt            March 1995

   Configuration Data implementors to understand is duplicated across DHCPv6 Servers, that IPv6
   requires that every link in the internet have an MTU of 576 octets or how
   greater (in IPv4 the
   DHCPv6 Configuration Data requirement is pre-configured on a 68 octets).  This means that a
   UDP datagram of 536 octets will always pass through an internet (less
   40 octets for the IPv6 header), as long as there are no options prior
   to the UDP datagram in the packet. But, IPv6 does not support
   fragmentation at routers and fragmentation must take place end-to-end
   between hosts.  If a DHCPv6 implementation needs to send a packet
   greater than 536 octets it can either fragment the UDP datagram in
   UDP or use Path MTU Discovery [IPv6-SPEC] to determine the size of
   the packet that will traverse a network path.  It is implementation
   defined how this is accomplished in DHCPv6.

   The IPv6 Addressing Architecture Specification provides the address
   scope that can be used in an IPv6 implementation, and the various
   configuration architecture guidelines for network designers of the
   IPv6 address space. Two advantages of IPv6 is that multicast
   addressing is well defined and nodes can create link-local addresses
   during initialization of the nodes environment.  This means that a
   host immediately can ascertain an IPv6 address at initialization for
   an interface, before communicating in any manner on the link.  The
   host can then use a well-known multicast address to begin
   communications to discover neighbors on the link, or as will be
   discussed later in the specification locate a DHCPv6 server or
   relay-agent.

   The IPv6 Stateless Address Configuration Specification (addrconf)

INETERNET-DRAFT       draft-ietf-dhc-dhcpv6-02.txt             July 1995

   defines how a host can autoconfigure addresses based on neighbor
   discovery router advertisements, and the use of a validation-lifetime
   and a deprecation-lifetime for addresses.  In addition the addrconf
   specification defines the protocol interaction for a host to begin
   stateless or statefull autoconfiguration.  DHCPv6 is one vehicle to
   perform statefull autoconfiguration.  Compatibility with addrconf is
   a design goal of DHCPv6 where possible.

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

   Dynamic Updates to DNS is a specification that supports the dynamic
   update of DNS records for both IPv4 and IPv6.  This will be discussed
   further later in this section of the specification.  An implementor
   cannot implement DHCPv6 without understanding Dyanmic Updates to DNS.

3.2 Design Goals

   The following list gives general design goals for DHCPv6.  Most
   DHCPv4 Design Goals [DHCP-v4] are kept in this specification.

      DHCPv6 should be a mechanism rather than a policy.  DHCPv6 must
      allow local system administrators control over configuration
      parameters where desired; e.g., local system administrators should
      be able to enforce local policies concerning allocation and access
      to local resources where desired.

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

      Networks should require no hand configuration for individual
      hosts.  Under normal circumstances, the network manager should not
      have to enter any per-host configuration parameters.

      DHCPv6 should not require a server on each link.  To allow for
      scale and economy, DHCPv6 must work across relay agents.

      A DHCPv6 client must be prepared to receive multiple responses to
      a request for configuration parameters.  Some installations may
      include multiple, overlapping DHCPv6 servers to enhance
      reliability and increase performance.

      DHCPv6 must coexist with statically configured, non-participating
      hosts and with existing network protocol implementations.

      DHCPv6 should as much as possible be compatible with IPv6
      Stateless Address Configuration.

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

      It is NOT a design goal of DHCPv6 to specify a server to server

INETERNET-DRAFT       draft-ietf-dhc-dhcpv6-02.txt             July 1995

      protocol.

      It is NOT a design goal of DHCPv6 to specify how a server
      configuration database is maintained or determined.

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

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

      Guarantee that client addresses that are not provided by DHCPv6
      will not be added to a servers configuration database or the
      servers binding for a clients interface-token.

      Retain host configuration across host reboot.  A client should,
      whenever possible, be assigned the same configuration-data in
      response to each request.

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

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

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

      Clients must not assume that addresses are updated to the DNS,
      unless the server provides a host-name with an address to a
      client.

3.3 Request/Response Model

   DHCPv6 uses a message type to define whether the packet orginated
   from a DHCPv6 Server or Client.

   The message types are as follows:

      01 - client-configuration-request
      02 - client-confirm-response
      03 - client-reject-response
      04 - server-configuration-response

   Request/Response Model States

      1. Request (client)
      2. Response with configuration-data or error found (server).
      3. Confirmation Response or reject (client).

   The time out period for a client or server to wait for a response
   MUST NOT exceed 3 minutes.  When a client or server times out waiting
   for a response to a packet sent, the implementation MUST NOT commit
   any binding based on the configuration-data sent in the packet.  It
   is implementation defined if the client or server packet is

INETERNET-DRAFT       draft-ietf-dhc-dhcpv6-02.txt             July 1995

   retransmitted.

3.4 Leased Address Model

   An address returned to a client has a validation-lifetime and
   deprecation-lifetime.  The lifetimes represent the lease for a single
   address for a client.  The server MUST provide a validation-lifetime
   and SHOULD provide a deprecation-lifetime to a client in a server
   response packet to a clients request for an address.

   The client may suggest a value for the lifetimes in an address
   request to a server, or leave them as zero. The client MUST use the
   lifetimes provided by the server response if the values are different
   than the lifetimes requested by the client.

   The DHCPv6 philosophy is that the client has the responsibility to
   renew a lease for an address that is about to expire, or request a
   new address or the same address before the lease actually expires.
   If the client does not request a new lease for an address, the server
   MUST assume the client does not want a new lease for that address,
   and the server MAY provide that address to another client requesting
   an address.

   If the the client has a deprecation-lifetime for an address the
   processing of the lease SHOULD be as follows:

      When the deprecation-lifetime of an address expires, the clients
      address becomes a deprecated-address.  A deprecated address SHOULD
      NOT be used as a source address in new communications. However, a
      deprecated-address SHOULD continue to be used as a source address
      if it is in use in existing communications.  Implementors of
      DHCPv6 SHOULD coordinate the use of the validation-lifetime and
      deprecation-lifetime for layers below the DHCPv6 application layer
      with their implementation of IPv6 Stateless Address Configuration
      [IPv6-ADDRCONF].

      An address is a deprecated-address until its invalidation-lifetime
      expires at which point the address becomes an invalid-address. An
      invalid-address MUST NOT be used  as  a source address in outgoing
      communications, and MUST NOT be recognized as a valid destination
      address in incoming communications.

   If the clients deprecation-lifetime is zero for an address the
   processing for the lease SHOULD be as follows:

      There is no concept of a deprecated-address for a client if the
      deprecation-lifetime is zero when provided to the client in a
      server response.  The address for the client is valid until the
      validation-lifetime expires at which point the address becomes an
      invalid-address.  An invalid-address MUST NOT be used as a source
      address in outgoing communications, and MUST NOT be recognized as
      a valid destination address in incoming communications.

INETERNET-DRAFT       draft-ietf-dhc-dhcpv6-02.txt             July 1995

3.5 DNS Host Name Autoregistration Model

   DHCPv6 supports the autoregistration of DNS Host names and providing
   DNS Host Names with addresses for clients.  Autoregistration is
   supported by the presence of the name field in DHCPv6, which the
   client may provide to the server in a request.  In addition a server
   may provide a DNS Host Name with an IPv6 address to a client in a
   response.

   If the name-length field is zero, there is no name field contained in
   the packet.

   DHCPv6 Server. only specifies the name-field, and not the actual protocol or
   primitives to interact with DNS.  The functions that the server uses
   to interact with the DNS to provide autoregistration is defined in
   Dynamic Updates to DNS [DYN-UPD].  DHCPv6 servers SHOULD support
   Dynamic Updates to DNS.

   If the client provides a Host Name (HN) or a Fully Qualified Domain
   Name (FQDN) [RFC 1034&1035]:

      The server SHOULD perform a DNS query for the HN or FQDN IPv6 DNS
      AAAA resource record [IPv6-DNS]:

      If the name is found and the address does not specify conditions or results when multiple DHCPv6
   Servers match the clients
      address for the name provided by the client, the server SHOULD add
      this address to the DNS name record (multiple addresses are located
      supported for names at this time in DNS and the client may want to
      use the same name for multiple addresses on an IPv6 subnet.  The DHCPv6 Client may respond interface).

      If the name is not found the client supplied name SHOULD be added
      to DHCPv6 Servers the DNS.

      In either condition above the server MUST add the associated DNS
      inverse address mapping as an IP6.INT domain PTR record [IPv6-DNS]
      for this clients address and name.

      If the server returns a name after updating the DNS it MUST return
      a FQDN to the client.

   If the client does not want request a HN or FQDN from a server, the server
   MAY provide, in its response with the address to communicate a client, a FQDN the
   client can use for that address.  The server MUST NOT provide a
   client with by sending a
   REJECT_PACKET confirmation server generated FQDN, unless the associated IPv6 AAAA
   record and IP6.INT domain PTR record exists in the DNS.

   When a clients address invalidation-lifetime expires on the server,
   the server SHOULD delete the clients IPv6 AAAA record and IP6.INT
   domain PTR record from the DNS.

INETERNET-DRAFT       draft-ietf-dhc-dhcpv6-02.txt             July 1995

3.6 Defining Optional Configuration-Data

   Optional configuration-data MUST be specified for DHCPv6 as follows
   and aligned on an integer multiple of 8 octets:

      option-type: 1 Octet

      This field permits 254 options for DHCPv6 and will represent the
      tag for the option.  The values of 0 and 1 are used for pad
      options discussed below.

      option-length: 2 Octets

      This field specifies the length of the configuration-data not
      including the the option-type and and option-length fields.

      option-data:  Variable number of Octets

      The option-data is the configuration-data that immediately follows
      the option-length field.

   If the server does not support an option-type requested it MUST
   return the option-type and the option-length set to zero in the
   response to the client.

   A server implementation MUST start any options after the first option
   returned to a DHCPv6 Server.

   DHCPv6 client on an integer multiple of 8 octets.  This is an
   architectural REQUIREMENT, and the client when parsing options can
   assume the next option, if it exists will begin on the next integer
   multiple of 8 octets boundary.

   This specification does not specify a define any options.  DHCPv6 Server-to-Server protocol. options are
   defined in XXXXXXXXX.  It is permissible for options to also create
   new message-types and message-codes as required.

INETERNET-DRAFT       draft-ietf-dhc-dhcpv6-01.txt            March       draft-ietf-dhc-dhcpv6-02.txt             July 1995

4.  DHCPv6 Protocol Format

                           DHCPv6  Datagram and Data Packet Formats

4.1 Datagram

                           DHCPv6 Datagram

     0               8               16              24              31
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Msg Type      |             Msg Request  msg-type     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    msg-code   |                Msg Response   name-lgth   | Addrs Avail addr-count    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Transaction ID                      transaction-ID                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Lease Time                     interface-token                           |
     |                       (8 Octets)                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Interface Token                       client-address                          |
     |                       (8                        (16 Octets)                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       IPv6 Address                       server-address                          |
     |                        (16 Octets)                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Host Name                       gateway-address                         |
     |                        (64                        (16 Octets)                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Server IPv6 Address                   client-link-address                         |
     |                        (16 Octets)                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Config Type                      validation-lifetime                      |   Next Type
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Length                      deprecation-lifetime                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Variable Configuration Data                         host-name                             |
     |                    (variable octets 0-255)                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In
     |  option-type  |  option-lgth  | option-data (variable octets) |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.2 Data Formats

  All fields in the field definitions below bit position 0 is datagram MUST be initialized to binary zeroes
  by both the high-order bit client and server messages unless otherwise noted
  in
the sequence Section 5. Client and Server processing of Octets for each field.

  Msg Type messages.

  msg-type              : 1  Octet
    The field defines the operation to be performed by the packet.

    Bit 0 = ON: Server Message Operation
    Bit integer value (message-type)

    Value    Description

     1 = ON:    -  Client Message Operation
    Bit 2-7 RESERVED

  Msg Request : 3 Octets

      Bit 0  = ON: ADDRESS_REQUEST
      Bit 1  = ON: NAME_REQUEST
      Bit request for configuration data.
     2  = ON: CONFIG_REQUEST
      Bit    -  Server response with configuration data.
     3  = ON: ADDRESS_SUPPLIED
      Bit    -  Client confirmation of server response.
     4  = ON: LEASE_EXPIRED
      Bit 5-24 RESERVED    -  Client rejection of server response.

INETERNET-DRAFT       draft-ietf-dhc-dhcpv6-01.txt            March       draft-ietf-dhc-dhcpv6-02.txt             July 1995

  Msg Response

  msg-code              : 3 Octets
      Bit 0  = ON: ADDRESS_RETURNED
      Bit 1  = ON: ADDRESS_ACCEPTED
      Bit  Octet integer value (message-code)

    Value    Description

     1    -  Server Response - Client address-count is in error.
     2  = ON: ADDRESS_REJECTED
      Bit 3  = ON: NAME_ACCEPTED
      Bit 4  = ON: NAME_RETURNED
      Bit 5  = ON: NAME_REJECTED
      Bit 6  = ON: SERVER_ADDRESS
      Bit 7  = ON: CONFIG_ACCEPTED
      Bit 8  = ON: CONFIG_RETURNED
      Bit 9  = ON: CONFIG_REJECTED
      Bit 10 = ON: LEASE_ACCEPTED
      Bit 11 = ON: LEASE_REJECTED
      Bit 12 = ON: CONFIRM_PACKET
      Bit 13 = ON: REJECT_PACKET
      Bit 14-24 RESERVED

  Addrs Avail    -  Server Response - Dynamic Updates to DNS not supported.

  name-lgth             : 1  Octet
    Number of IPv6 addresses available to the DHCPv6 Client, that can be
    provided by the DHCPv6 Server.  Integer Number.

  Transaction ID integer value (name-length)

  addr-count            : 1  Octet integer value (address-count)

  transaction-ID        : 4  Octets
    Identifies request/response messages and is a 32bit random
    generated number by the DHCPv6 Client.  Integer Number.

  Lease Time integer value

  interface-token       : 4  Octets
    This field is used to provide a Lease time for an integer value

  client-address        : 16 Octets address and a
    renewal time period for an

  server-address        : 16 Octets address that is being reclaimed.
    Integer Number.  Absolute time in seconds.

  Interface Token

  gateway-address       : 8 16 Octets
    This field is determined by the DHCPv6 Client and is a 64bit random
    generated number.  An Interface Token is defined by the DHCPv6 Client for
    each network interface it configures on its Host.  Integer Number.

  IPv6 Address address

  client-link-address   : 16 Octets
    DHCPv6 Client IPv6 Address.

  Host Name address

  validation-lifetime   : 64 4  Octets
    DHCPv6 Host Name.  This is not the Fully Qualified Domain Name
    (FQDN).

  Server IPv6 Address integer value

  deprecation-lifetime  : 16 4  Octets
    DHCPv6 Server IPv6 Address.

  Configuration Type integer value

  host-name             : 0-255 Octets character(s) value(s)

  option-type           : 1  Octet
    This field defines the Configuration Data option in the packet.
    The configuation types are specified in DHCPv6 Options
    [IPv6-DHCP-OPTIONS].

  Configuration Next Type integer value

  option-length         : 1  Octet
    This field defines the Configuration Data Type that follows this
    Configuration Data if multiple configuration requests are present.
    A NULL integer value means that this is the only or last Configuration Data
    Type provided.

  Configuration Data Length

  option-data           : 2 Octets
    This field is the Length of the Configuration Data.

INETERNET-DRAFT       draft-ietf-dhc-dhcpv6-01.txt            March 1995 Variable Configuration Data : 452 Octets
    This is a variable length field where configuration data will be
    supplied as options for DHCPv6 protocol.

    If the Configuration Data provided causes the DHCPv6 packet to exceed
    576 Octets then the implementation should verify through Path MTU
    Discovery [IPv6-SPEC&ICMP,PMTU] that the packet will be able to reach its
    destination without Fragmentation, or use the IPv6 Fragmentation Extended
    Header [IPv6-SPEC].

5.  DHCPv6 Client/Server Processing

5.1 DHCPv6 Client Transmission

   The DHCPv6 Client will set Client Msg Type to ON to transmit to
   DHCPv6 Servers.  UDP DHCPv6 Server Port (TBD) must be used to build
   the sending packet in an implementation.  A DHCPv6 Client may provide
   multiple requests in a request packet and multiple responses in a
   response packet, to a variant value(s)

INETERNET-DRAFT       draft-ietf-dhc-dhcpv6-02.txt             July 1995

5.  Client/Server Processing

5.1 Client Transmission

   UDP DHCPv6 Server in one packet. Port 546 MUST be used by the client to send UDP
   datagrams to the server.

   If the DHCPv6 Client client knows its IPv6 address it will MUST be put in the source address
   field of the IPv6 Header.  Otherwise the DHCPv6
   Clients clients link-local address [IPv6-ADDR] is
   MUST be used as the source address field in the IPv6 Header. Header [IPv6-
   ADDRCONF].

   If the DHCPv6 Client client knows the address of a DHCPv6 Server the server on its link it will MUST put
   that address in the destination address field of the IPv6 Header.
   Otherwise
   a well known IPv6 the client MUST put the DHCP Server/Relay-Agent well-known
   multicast address FF02:0:0:0:0:0:1:0 using intra-link link-local scope [IPv6-
   ADDR] is used as the destination address field in the IPv6 Header
   [This multicast address will have to be supplied by IANA for DHCPv6].

5.2 DHCPv6 Server Transmission Header.

   The DHCPv6 Server will client MUST set Server Msg Type ON msg-type to 1 to transmit a request to DHCPv6
   Clients. the
   server.

   The client MUST set msg type to 3 to confirm the acceptance of packet
   from a server response.

   The client MUST set msg type to 4 to reject a packet from a server
   response.

   The client MUST use UDP DHCPv6 Client Port (TBD) must be used to build 546 as the
   sending packet UDP port to
   accept server responses in an implementation.  A DHCPv6

5.2 Server may provide
   multiple responses to a Transmission

   UDP DHCPv6 Client in one packet.

   The DHCPv6 Server will Port 546 MUST be used by the server to send UDP
   datagrams to the client.

   A server, on the same link as the client, MUST use the source address of
   in the IPv6 Header from the DHCPv6 Client client as the destination address in the DHCPv6 Server
   IPv6 Header address.
   servers response packet.  Servers not on the same link are discussed
   in Section 6 Relay-Agent Processing.

   The server MUST set msg type to 2 to transmit a response to a client.

   The server MUST use UDP DHCPv6 Server IPv6 Header source addresses
   will be Port 547 as the UDP port to
   accept client requests in an implementation.

   The server MUST join the DHCP Server/Relay-Agent mulicast group
   well-known multicast address FF02:0:0:0:0:0:1:0 using link-local
   scope [IPv6-ADDR], to listen for client requests, that do not know
   the IPv6 address of a server on the DHCPv6 Server responding. clients link.

INETERNET-DRAFT       draft-ietf-dhc-dhcpv6-02.txt             July 1995

5.3 DHCPv6 Client/Server Bindings

   Client Requests

   Msg Request field:

     If ADDRESS_REQUEST and server bindings MUST be maintained at least as a 4-tuple
   consisting of the clients interface-token, address, validation-
   lifetime, and deprecation-lifetime in an implementaiton.  It is set, then
   critical for the interoperability of DHCPv6 that the clients bindings
   remain consistent with the servers bindings across reboots.

   When a client sends a request is being made for an IPv6
     address and Lease. If it MUST enter in the Lease addr-count field does not equal zero then
   the
     DHCPv6 Client is supplying number of addresses that it has for a Lease time to particular interface-token
   in the DHCPv6 Server. The DHCPv6
     Client may also set ADDRESS_SUPPLIED and provide an IPv6 address to clients bindings.

   When the
     DHCPv6 Server for verification.

INETERNET-DRAFT       draft-ietf-dhc-dhcpv6-01.txt            March 1995

     A DHCPv6 Client must send an ADDRESS_REQUEST to server receives the DHCPv6 Server
     to renew its Lease before client request, it expires.  The DHCPv6 Client may request MUST verify that the same address be used again
   addr-count field provided by providing an IPv6 address and
     having ADDRESS_SUPPLIED set in the request.  If the DHCPv6 Clients
     Lease on an address expires, then client matches the DHCPv6 Server will expire number of
   addresses the
     Lease server has for that address.

     If NAME_REQUEST is set, then a request is being made clients binding, for a DNS Host Name.
     supplied the
   interface-token provided by the DHCPv6 Client. client.  If CONFIG_REQUEST is set, then a request is being made for an IPv6
     Configuration Data return from the DHCPv6 Server.

   Msg Response field: must be NULL.

   Addrs Avail field: must be NULL.

   Transaction ID field: must contain server has a random number generated Integer
   determined by
   different addr-count than the DHCPv6 Client client for this request packet.

   Lease Time field: may contain a Lease time requested by particular interface
   token, the DHCPv6
   Client or must be NULL.

   Interface Token field: must contain server MUST send a random number generated Integer response to identify addresses associated with a DHCPv6 Clients network
   interface.

   IPv6 Address field: must contain an IPv6 Address if ADDRESS_SUPPLIED
   or NAME_REQUEST is set, otherwise NULL.

   Host Name field: must contain a Host Name if NAME_REQUEST is set,
   otherwise NULL.

   Server IPv6 Address field: must be NULL.

   Configuration Type field: must contain a valid Configuration Type as
   defined in the DHCPv6 Options specification [IPv6-DHCP-OPTIONS], if
   CONFIG_REQUEST is set, otherwise client setting msg-code
   to 1 informing the Configuration fields are client addr-count at the server is not
   present in synch
   with the packet.

   Configuration Next Type field: If CONFIG_REQUEST set, client.

   Once the client receives a response with a msg-code set to 1 it MUST
   set addr-count to zero on subsequent requests to the server, for that
   interface-token.

   When a server receives a request from a client and there the addr-count is
   more than one, then
   set to zero, but the value of client has a binding for that interface-token,
   the next configuration type should
   be put into this field, otherwise NULL.

   Configuration Data Length field: NULL.

   Variable Configuration Data field: Not present server MUST reissue the configuration-data in those bindings to
   the packet. client.

5.4 DHCPv6 Client Responses Requests

   The Transaction ID from client sets the DHCPv6 Server response must match one following fields for a request for
   configuration-data:

      msg-type: Set to 1.

      name-lgth: Set to the length of the DHCPv6 Clients Transaction IDs from a previous request.

   Msg Request field: must be NULL.

   Msg Response field:

INETERNET-DRAFT       draft-ietf-dhc-dhcpv6-01.txt            March 1995

     If ADDRESS_ACCEPTED is set, host-name if provided.

      addr-count: Set to the DHCPv6 Client is informing number of addresses the DHCPv6
     Server that it client has received for the address returned.

     If CONFIG_ACCEPTED is set,
      interface-token specified in this request.

      transaction-ID: Set to a unqiue integer value.

      interface-token: Set to a unqiue opaque identifier.

      client-address: Set ONLY if the DHCPv6 Client client is informing requesting a host name
      for a particular address, else not set.

      validation-lifetime: Set to the DHCPv6
     Server that it has received value the Configuration Data returned.

     If NAME_ACCEPT is set, client would like the DHCPv6 Client is informing
      server to use, else not set.

      deprecation-lifetime: Set to the DHCPv6
     Server that it received value the NAME_RETURNED returned, when client would like the DHCPv6
     Client supplied a Host Name with NAME_REQUEST
      server to use, else not set.

     If REJECT_PACKET

      host-name: Set only if name-lgth is set, the DHCPv6 Client greater than zero otherwise

INETERNET-DRAFT       draft-ietf-dhc-dhcpv6-02.txt             July 1995

      this field is rejecting a response
     from a DHCPv6 Server.

   Addrs Avail field: must be NULL.

   Transaction ID field: must contain not present.

      option-type: Set to a random number generated Integer
   matching the DHCPv6 Server future option request or response.

   Lease Time field: must for configuration-
      data, otherwise the field is not present.  Multiple option-types
      may be NULL.

   Interface Token field: must contain a random number generated Integer set adjacent to identify addresses associated with a DHCPv6 Clients network
   interface.

   IPv6 Address field: must be NULL.

   Host Name field: must be NULL.

   Server IPv6 Address field: must be NULL.

   Configuration Data Fields not present in the packet. each other.

5.5 DHCPv6 Server Responses Response

   The Transaction ID from server sets the following fields for a DHCPv6 Servers response must match one of
   the DHCPv6 Clients Transaction IDs from to a previous request.

   Msg Request field: must be NULL.

   Msg Response field:

     If ADDRESS_RETURNED is set, the DHCPv6 Server is providing client for
   configuration-data:

      msg-type: Set to 2.

      msg-code: Set to 1 if addr-count not equal to servers bindings for
      the DHCPv6
     Client with an IPv6 Address.

     If ADDRESS_ACCEPTED is set, clients specified interface-token.  Set to 2 if the DHCPv6 Server has accepted server
      cannot support Dynamic Updates to DNS because the client requested
      a host-name for an address
     supplied by provided, or from the DHCPv6 Client. servers set of
      addresses.

         If ADDRESS_REJECTED is set, the DHCPv6 Server server determines that addr-count is not accepting equal to its
         bindings it stops all other DHCPv6 processing, hence, the
     address provided by
         server would not be in the DHCPv6 Client.

     Only one situation of setting msg-code to
         both 1 and 2.  The server sets msg-code to 1 and MUST put all
         other values supplied by the above settings must be present clients request in a the response
         packet except the msg-type and msg-code fields.

         Processing of msg-code set to a DHCPv6
     Client request.  The IPv6 address provided will either be 1 for the one
     presented client and server is
         done as specified in 5.3 Client/Server Bindings.

      name-lgth: Set to the length of the host-name if present.

      addr-count: Set to the same value specified by the DHCPv6 Client or an address provided client.

      transaction-ID: Set to the same value specified by the DHCPv6
     Server when ADDRESS_RETURNED client.

      interface-token: Set to the same value specified by the client.

      client-address: If the client-address from the request packet is set.
      zero the server sets the client-address to the next available
      address for this interface-token. If NAME_RETURNED there is set, a client-address in
      the DHCPv6 Server request packet the client is providing requesting a Host Name with host-name for this
      address, and the server MUST return the address returned provided by the
      client if the server supports Dynmic Updates to DNS, and has
      updated the DHCPv6 Client either DNS with a host-name for that address.

      server-address: The server MUST set this field to its address in
      all response packets.

      validation-lifetime:  The server sets this address to a DHCPv6

INETERNET-DRAFT       draft-ietf-dhc-dhcpv6-01.txt            March 1995

     Client NAME_REQUEST or because it the
      validation-lifetime of the servers configuration database. It is
      implementation defined if the server will use the validiation-
      lifetime if specified by a client request packet.

      deprecation-lifetime:  The server sets this address to provide
     Host Names with ADDRESS_RETURNED set.

     If NAME_REJECTED is set, the DHCPv6 Server
      deprecation-lifetime of the servers configuration database. It is informing
      implementation defined if the DHCPv6
     Client that server will use the NAME_REQUEST was rejected deprecation-

INETERNET-DRAFT       draft-ietf-dhc-dhcpv6-02.txt             July 1995

      lifetime if specified by DNS. a client request packet.

      host-name: The DHCPv6 Server
     must also supply an address in server returns a hostname or msg-code set to 2, if
      the IPv6 Address field.

     If CONFIG_RETURNED name-lgth field is set, the DHCPv6 Server greater than zero.  Processing of host-name
      is providing specified in Section 3.5 DNS Host Name Autoregistration Model.

      option-type: The server returns the
     Configuration Data requested.

     If CONFIG_REJECTED is set, same option-types specified by
      the DHCPv6 Server is informing client requests.

      option-lgth: The server returns the DHCPv6
     Client that length of the Configuration Data requested configuration-
      data or zeroes if the option is not supported.

     If LEASE_ACCEPTED is set,

      option-data: The server returns the DHCPv6 Server is informing configuration-data requested
      by the DHCPv6 client.

5.6 Client that the Lease presented has been accepted. Confirmations/Rejections

   The Lease Time field
     will contain client sets the Lease requested by following fields for a confirmation or rejection
   after receiving configuration-data from the DHCPv6 Client.

     If LEASE_REJECTED server. configuration-
   data:

      msg-type: Set to 3 if the client is set, confirming a servers response.
      Set to 4 if the DHCPv6 Server client is rejecting a servers response.

         When the Lease Time
     provided by server receives a rejection msg-type 4 from a client
         the DHCPv6 Client server MUST assume the client is using another server.  The
         server then MUST remove any bindings for that client it may
         have created, and will return a Lease time MUST delete any DNS HN or FQDN records it may
         have added on behalf of the client.

      transaction-ID: Same value as specified
     by in the DHCPv6 Server.

     If SERVER_ADDRESS is set, servers response.

      interface-token: Same value as specified in the DHCPv6 Server is returning its address servers response.

      client-address: Same value as specified in the servers response.

6.  Relay-Agent Processing

   The relay-agent MUST use UDP DHCPv6 Server will do this when Port 547 as the destination
     address UDP port
   to accept client responses in the IPv6 Header is an intra-link Multicast address, or has
     a network prefix subnet value implementation.

   The relay-agent MUST join the DHCP Server/Relay-Agent mulicast group
   well-known multicast address FF02:0:0:0:0:0:1:0 using link-local
   scope [IPv6-ADDR], to listen for which the client requests.

   When a DHCPv6 Server is
     not Relay-Agent hears a request from a member. DHCPv6 Client it
   MUST:

      If CONFIRM_PACKET is set, the DHCPv6 Server gateway-address is informing NOT zero then the DHCPv6
     Client it has received a response to relay-agent MUST:

         Put the DHCPv6 Server response to relay-agents IPv6 address in the
     DHCPv6 Clients initial request.  This will be gateway-address field
         of the only msg response
     code set by clients request packet.

         Put the the source address from the DHCPv6 Server IPv6 Header of the clients

INETERNET-DRAFT       draft-ietf-dhc-dhcpv6-02.txt             July 1995

         request packet in this response.

   Addrs Avail field: If ADDRESS_RETURNED is set, the DHCPv6 Server is
   informing client-link-address.

      All relay-agents MUST:

         Put their relay-agent address as the DHCPv6 Client that it has an integer number of
   addresses available source address for the DHCPv6 Client less
         IPv6 Header.

         Put the next relay-agent or known server address being
   provided.  When as the DHCPv6 Client responds
         destination address in the IPv6 Header.

         Forward the packet to this response with
   ADDRESS_ACCEPTED the DHCPv6 Server must decrement to the number of
   addresses available for next hop relay-agent or known
         server.

   When the DHCPv6 Client.  If ADDRESS_ACCEPTED is
   set, remote server receives the DHCPv6 Server is informing client request from the DHCPv6 Client that relay-
   agent it has will know its a
   number of addresses available that can be used by the DHCPv6 Client.
   Otherwise remote client request (not on the Addrs Avail field servers
   link), because there is NULL.

   Transaction ID field: must contain a random number generated Integer
   determined by gateway-address in the DHCPv6 Clients request packet.

   Lease Time field: must contain a Lease Time with any returned
   addresses that were requested, otherwise NULL.

   Interface Token field: must contain a random number generated Integer
   to identify addresses associated with a DHCPv6 Clients network
   interface.

   IPv6 Address field: must contain an IPv6 Address.

   Host Name field: must contain a Host Name if NAME_RETURNED request.  So servers
   MUST test the gateway-address is set
   otherwise NULL.

   Server IPv6 Address field: must contain an IPv6 address not zero, to determine if

INETERNET-DRAFT       draft-ietf-dhc-dhcpv6-01.txt            March 1995

   SERVER_ADDRESS the
   clients request is set, otherwise NULL.

   Configuration Type field: must contain from a valid Configuration Type remote link.

   The server responds as
   defined specified in 5.5 Server Response, but uses the DHCPv6 Options [IPv6-DHCP-OPTIONS] if CONFIG_RETURN or
   CONFIG_REJECTED is set, otherwise
   gateway-address as the Configuration fields are not
   present destination address in the packet.

   Configuration Next Type field: If CONFIG_RETURNED or CONFIG_REJECTED
   is set, IPv6 Header.

   When the relay-agent receives the remote servers response, it MUST
   forward the packet to the client, by using the client-link-address as
   the source address for the IPv6 Header.

INETERNET-DRAFT       draft-ietf-dhc-dhcpv6-02.txt             July 1995

Draft ***Open Issues***

   1.  The present model uses UDP with a client request, server
   response, and if there then client confirmation or rejection.  The server will
   set state or remove state based on this model.  There is more than one Congfiguration Type present, always the value
   possibility of the next configuration type should be put into this
   field, otherwise NULL.

   Configuration Data Length field: If CONFIG_RETURNED is set, then this classic transactional error when the client-to-
   server response is not received by the length server, or the client assumes
   the server received the response and it did not (see the draft).

      This can be greatly alleviated by using TCP instead of UDP for the Configuration Data present.  If CONFIG_REJECTED
   is set, then
      transaction.  This would have great benefits such as:

         1.  Guranteed virtual link, hence if the DHCPv6 Server will set length transaction completes
         the server and client know immediately upon return to zero.

   Variable Configuration Data field: Contains Configuration Data only
   if CONFIG_RETURNED is set, otherwise there the
         application.

         2.  PATH MTU Discovery for TCP is no Configuration Data
   present inherent in an implementation
         and the packet.

5.6 DHCPv6 Server Lease Expiration

   The DHCPv6 may send an asynchronous LEASE_EXPIRED message with a
   grace period if an organizations network site needs to reclaim
   addresses when their Lease has application does not expired.

   Msg Request field:

     LEASE_EXPIRED is set.

   Msg Response field: must be NULL.

   Addrs Avail field: must be NULL.

   Transaction ID field: NULL.

   Lease Time field: must contain a grace period have to adjust for IPv6
         fragmentation model.

   We can also use UDP to locate servers and TCP for the DHCPv6 Client transaction.

   2.  Dynamic Updates to renew a lease DNS need careful review for an address.

   Interface Token field: must contain a random number generated Integer clarity and what
   is required for just host name processing in DHCPv6.

   3.  We need to determine the DHCPv6 Client IPv6 address.

   IPv6 Address field: must contain an integration required with IPv6 Stateless
   Address Configuration when both stateless and statefull is being used for an
   Interface Token
   by a DHCPv6 Client.

   Host Name field: must be NULL.

   IPv6 Server Address field: must client host.

   4.  In the Design Goals section should the MUSTs, SHOULDs, etc be NULL.

   Configuration fields:
   capitalized and REQUIRED?  Its not present in DHCPv4?

   5.  Charlie Perkins will be doing our option spec for DHCPv6. We need
   to make sure it synchs up with this spec.

INETERNET-DRAFT       draft-ietf-dhc-dhcpv6-02.txt             July 1995

Change History

   Changes from March 95 to July 95 Drafts:

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

      Used message-type and message-code fields and rely on looking at
      the fields in the datagram instead of multiple over-lapping
      request/response codes.

      Added address-count field processing to be specified by the client
      as opposed to the server, and the processing for when client and
      server address-counts become disjoint.

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

      Added Design Goals section.

      Re-Defined transaction-ID and interface-token.

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

      Added more terminology, definitions, and rationale.

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

      Reduced the packet.

6.  DHCPv6 Relay-Agent Processing

   When a DHCPv6 Relay-Agent hears request/response model to 3 packets by not doing a request from
      server confirm to a DHCPv6 Client it
   should forward that request clients confirm to a servers response.

      Added model to support like lifetime fields for lease management
      to coordinate with IPv6 Stateless Address Configuration.

      Added model and processing definitions for future DHCPv6 Server as a Options
      Specification.

      Added gateway-address and client-link-address for relay-agent
      processing.

      Removed excessive use of the acroynym DHCPv6 Client Msg
   Type. for section titles
      and when referencing clients and servers.

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

      Added Change History.

INETERNET-DRAFT       draft-ietf-dhc-dhcpv6-01.txt            March       draft-ietf-dhc-dhcpv6-02.txt             July 1995

Acknowledgements

   The DHCPv6 Relay-Agent upon receiving a response from DHC Working Group for their time and input into the DHCPv6
   Server should forward that response to
   specification.  A special thanks for the DHCPv6 Client.

   When consistent input, ideas, and
   review by Ralph Droms, Thomas Narten, Jack Mccann, and Charlie
   Perkins.   A big warm and extended thanks to Sue Thomson, Yakov
   Rehkter, and Phil Wells, who spent many hours in person and on the DHCPv6 Relay-Agent forwards
   phone with the request author to get the DHCPv6 Server
   it puts work done.

   Sue Thomson and Yakov Rehkter were co-authors on the DHCPv6 Relay-Agent's IPv6 address in first
   specification, and with the source field author have since March 1994 kept a
   consistent view and belief that autoregistration MUST be part of the IPv6 Header.

INETERNET-DRAFT       draft-ietf-dhc-dhcpv6-01.txt            March 1995

Acknowledgements

Brian Carpenter, Alex Conta, Jack McCann, Ralph Droms for providing
input
   Next Generation Internet Protocol version 6 and integrated into
   autoconfiguration.

   The author would also like to thank Steve Deering and Bob Hinden, who
   have consistently taken the time to discuss the evolution more complex parts of DHCPv6.

References

   [IPv6-ADDR]
       R. Hinden, Editor, "IP Version 6 Addressing Architecture"
       <draft-ietf-ipngwg-ipv6-addr-arch-00.txt>

       Y. Rekhter, "An
   the IPv6 Global Unicast Address Format"
       <draft-ietf-ipngwg-address-format-01.txt> specifications.

   The author MUST also thank his employer for the opportunity to work
   on DHCPv6 and IPv6 in general.

References

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

   [IPv6-ICMP]
       A. Conta,
       <draft-ietf-ipngwg-ipv6-spec-02.txt>

   [IPv6-ADDR]
       R. Hinden, S. Deering "ICMPv6 for the Internet Protocol Deering, Editors, "IP Version 6 [IPv6]" Internet Draft, March 1995
       <draft-ietf-ipngwg-icmp-02.txt>

   [PMTU]
       J. Mogul, S. Deering "Path MTU Discovery"
       RFC 1191, 11/16/90 Addressing
   Architecture"
       <draft-ietf-ipngwg-ipv6-addr-arch-03.txt>

   [IPv6-ADDRCONF]
       S. Thomson, "IPv6 Stateless Address Configuration"
       Internet Draft, March June 1995 <draft-ietf-addrconf-ipv6-auto-01.txt> <draft-ietf-addrconf-ipv6-auto-02.txt>

   [IPv6-ND]
       T. Narten, E. Nordmark, and W. A. Simpson Simpson, "IPv6 Neighbor Discovery - Processing"
       <draft-simpson-ipv6-discov-process-01.txt>
   Discovery"
       <draft-ietf-ipngwg-discovery-00.txt>

   [IPv6-DNS]
       S. Thompson and C. Huitema, "DNS Extensions to support IP
       version 6", Internet Draft, March 1995
       <draft-ietf-ipngwg-dns-00.txt>

   [RFC-1034]
       P. Mockapetris, "Domain Names - implementation and specification"
       STD-13, 11/01/87

INETERNET-DRAFT       draft-ietf-dhc-dhcpv6-02.txt             July 1995

   [RFC-1035]
       P. Mockapetris, "Domain Names - concepts and facilities"
       STD-13, 11/01/87

   [DYN-DNS-UPD]

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

INETERNET-DRAFT       draft-ietf-dhc-dhcpv6-01.txt            March 1995

   [IPv6-DHCP-OPTIONS]
       <TBD>

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

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

Authors' Addresses

    Jim Bound
    Digital Equipment Corporation
    110 Spitbrook Road, ZKO3-3/U14
    Nashua, NH 03062
    Phone: (603) 881-0400
    Email: bound@zk3.dec.com

    Yakov Rekhter
    T.J. Watson Research Center, IBM Corporation
    P.O. Box 570
    Yorktown Heights, NY 10598
    Phone: (914) 784-7361
    Email: yakov@watson.ibm.com

    Sue Thomson
    Bellcore
    445 South Street
    Morristown, NJ 07960
    Phone: (201) 829-4514
    Email: set@thumper.bellcore.com