INTERNET-DRAFT                                                  J. Bound
DHC Working Group                                 Digital Equipment Corp
Obsoletes: draft-ietf-dhc-dhcpv6-01.txt                          July 95 draft-ietf-dhc-dhcpv6-02.txt                    November 1995

         Dynamic Host Configuration Protocol for IPv6

                      draft-ietf-dhc-dhcpv6-02.txt (DHCPv6)

                      draft-ietf-dhc-dhcpv6-03.txt

Status of this Memo

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

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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts 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 Internet- Drafts
   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   Distribution of this document is unlimited.

Abstract

   DHCPv6

   This document is an Internet application protocol protocol, for IP version 6
   (IPv6), that uses specifies a Client/Server client/server model to communicate for communications
   between hosts.  DHCPv6 executes over the UDP
   [RFC-768] transport protocol, hosts to dynamically configure parameters for a network, and
   autoconfigure addresses within a stateful model.  This document
   supports the Internet Protocol Version 6
   (IPv6) [IPv6-SPEC]. DHCPv6 is an IPv6 specification model for a statefull
   implementation of address autoconfiguration as referenced in IPv6 Stateless Address Configuration [IPv6-ADDRCONF].  DHCPv6 supports
   mechanisms to autoconfigure host IPv6 addresseses, autoregister host
   names dynamically in the Domain Name System (DNS), Autoconfiguration,
   where there are clear integration points between stateless and specifies the
   format to add future Configuration Parameter options to the protocol
   stateful address autoconfiguration for extensibility.

   The work on this protocol will take place in the 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-02.txt             July 1995 IPv6.

Table of Contents:

1.  Introduction................................................3
1.1 Requirements................................................3 Introduction.................................................3
1.1. Requirements...............................................3
2. Terminology and Definitions.................................5
2.1 Definitions..................................4
2.1. IPv6 Terminology............................................5
2.2 Terminology...........................................4
2.2. DHCPv6 Terminology..........................................6 Terminology.........................................6
3. Protocol Design Model.......................................8
3.1 Related Work in IPv6........................................8
3.2 Model........................................9
3.1. Design Goals................................................9
3.3 Goals...............................................9
3.2. Request/Response Model.....................................10
3.4 Model....................................10
3.3. Leased Address Model.......................................11
3.5 Model......................................11
3.3.1. Address Lifetimes.......................................11
3.3.2. Duplicate Address Detection.............................12
3.3.3. Releasing Infinite Lifetime Addresses...................13
3.4. DNS Host Name Autoregistration Model.......................12
3.6 Defining Optional Configuration-Data.......................13 Model......................13
4.  Datagram Request/Response Processing.................................13
4.1. Processing when Server Address is not Known...............14
4.2. Processing when Server Address is Known...................16
4.3. Retransmission and Data Formats..................................14
4.1 Datagram...................................................14
4.2 Data Formats...............................................14 Configuation Variables.................16
5. Datagram and Field Definitions..............................18
5.1. Datagram..................................................18
5.2. Field Definitions.........................................19
6. Client/Server Message Formats...............................21
6.1. Client/Server Processing...................................16
5.1 UDP Ports, Multicast Group, and Addresses...21
6.2. Client Transmission........................................16
5.2 DISCOVER and CONF-REQUEST Messages.................21
6.3. Server Transmission........................................16
5.3 Client/Server Bindings.....................................17
5.4 CONF-RESPONSE Message..............................23
6.4. Client Requests............................................17
5.5 ACCEPT Message.....................................24
6.5. Server Response............................................18
5.6 SERVER-ACK Message.................................25
6.6. Client Confirmations/Rejections............................19
6. RELEASE Message....................................27
7. Relay-Agent Processing.....................................19
Draft ***Open Issues***........................................21 Processing......................................28
8. Security Considerations.....................................29
Appendix A - Related Work in IPv6..............................29
Change History.................................................22
Acknowledgements...............................................23
References.....................................................23 History.................................................31
Acknowledgements...............................................33
References.....................................................33
Authors' Addresses.............................................24

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

1. Introduction

   DHCPv6 is an Internet application protocol protocol, for IP version 6 (IPv6),
   that uses specifies a Client/Server client/server model to communicate for communications between hosts.  DHCPv6 executes over the UDP
   [RFC-768] transport protocol, hosts
   to dynamically configure parameters for a network, and the Internet Protocol Version 6
   (IPv6) [IPv6-SPEC]. autoconfigure
   addresses within a stateful model.  DHCPv6 is an IPv6 specification supports the model for a statefull
   implementation of address autoconfiguration as referenced in
   IPv6 Stateless Address Configuration [IPv6-ADDRCONF]. Autoconfiguration [IPv6-ADDRCONF], where there
   are clear integration points between stateless and stateful address
   autoconfiguration for IPv6.

   DHCPv6 supports
   mechanisms uses a set of request/response messages to support a
   transaction processing model where a commit to autoconfigure host IPv6 addresseses, autoregister host
   names dynamically in the Domain Name System (DNS), data can be
   verified by both the client and specifies server.  This affords DHCPv6 the
   ability in the
   format to add future Configuration Parameter options to support dynamic updates to data located
   within a sites network.  In addition to the protocol
   for extensibility.

   The IPv6 new version capability of the Internet Protocol, verifying
   commits to transactions a recovery mechanism is specified, should
   commits need to be rolled back during the course of a DHCPv6
   transaction being developed
   with 128bit addresses. processed.

   DHCPv6 supports optional configuration parameters and processing for
   hosts through its companion document Options for the Dynamic Host
   Configuration Protocol for IPv6 [DHCPv6-OPT].

   The IPv6 addressing architecture Addressing Architecture [IPv6-ADDR] and stateless address configuration [IPv6-ADDRCONF] IPv6 Stateless
   Address Autoconfiguration specifications provide new functionality
   not present in the Internet Protocol IP version 4 (IPv4), which provide (IPv4).  This new IPv6 functionality
   provides inherent benefits to autoconfigure IPv6 addresses for host nodes.
   In addition the IETF DNS Working Group has work in progress defined a method to
   support Dynamic Updates to DNS [DYN-
   UPD], [DYN-UPD], which can be used by a node
   to add, delete, and change host node names dynamically.

   DHCPv6 uses the enhancements in IPv6 and DNS to define an efficient
   protocol, and is not required to support any IPv4 protocol for
   backward compatibility.  DHCPv6 does use many used several of the architectural architecture principles in DHCP for IPv4 (DHCPv4) [DHCP-v4].  It from DHCPv4
   [DHCP-v4], but it is not within beyond the scope of this document to compare and contrast DHCPv4
   and compare DHCPv6 with DHCPv6.

1.1 Requirements

   Throughout DHCPv4.

   Section 2 provides definitions for terminology used throughout this document,
   document.  Section 3 provides a review of the words protocol design model
   parts that are used to define inherent in the
   significance specification.  Section 4 provides the
   request/response model and interaction between the set of messages
   and the particular requirements are capitalized.  These
   words are:

      o "MUST"

      This word or semantics for those messages.  Section 5 provides the adjective "REQUIRED" means
   datagram packet format and field definitions for that datagram.
   Section 6 provides the item is an
      absolute requirement of this specification.

      o "MUST NOT"

      This phrase means message formats and field contents for
   processing the client and server messages.  Section 7 provides the
   specification of how relay-agents and servers interact with clients,
   when the server is not on the same link as the client.  Section 8
   provides the security specifications that can be used to support
   security in DHCPv6.  Appendix A provides a summary of related work in
   IPv6 that will help put DHCPv6 in the context of IPv6 for the reader,
   and is not part of this specification, but here for information
   purposes.

1.1. Requirements

   Throughout this document, the words that are used to define the
   significance of the particular requirements are capitalized.  These
   words are:

      o "MUST"

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

      o "MUST NOT"

      This phrase means the item is 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 ignore this
      item, but the full impliciations implications should be understood and the case
      carefully weighed before choosing a 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 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
      truly optional.  One vendor may choose to include the item because
      a particular marketplace requires it or because it enhances the
      product, for example, another vendor may omit the same item.

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

2. Terminology and Definitions

   Terminology and Definitions are critical to the understanding of any
   IETF specification.  This Section will provide the terms and
   definitions used throughout this specification.

   Relevant terminology from the IPv6
   specification Protocol [IPv6-SPEC], IPv6
   Addressing Architecture [IPv6-ADDR], Architecture, and IPv6 Statelss Stateless Address Configuration [IPv6-ADDRCONF] terminology Autoconfiguration
   will be provided, and then the DHCPv6 terminology.

2.1

2.1. IPv6 Terminology

   node:

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

   node         - A device that implements IPv6.

   router:

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

   host:

   host         - Any node that is not a router.

   link:

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

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

   neighbors:

   neighbors    - Nodes attached to the same link.

   interface:

   interface    - A nodes's node's attachment to the link.

   address:

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

   packet:

   packet       - An IPv6 IP header plus payload.

   link MTU: The maximum transmission unit, i.e., maximum

   communication
                - Any packet size in
   octets, exchange between nodes that requires
                  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 address of each node and used in the exchange
                  remain the same for the duration of the packet
                  exchange.  Examples are a destination node. TCP connection or UDP
                  request/response.

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

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

   link-local address: The link-local address is for use on

   link-layer identifier
                - a single
   link.  On initialization of link-layer identifier for an interface, a host forms a interface.  Examples
                  include IEEE 802 addresses for Ethernet links,
                  and E.164 addresses for ISDN links.

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

   preferred address
                - An address assigned to a token
   that an interface whose use by
                  upper layer protocols is unique per link.  For example, in unrestricted.  Preferred
                  addresses may be used as the case source or destination
                  address of a host attached packets sent from or to a link that uses IEEE 802 addresses, the token is an IEEE 802
   address associated with the interface.

   validation-lifetime: This is the

   deprecated address lifetime for a single
                - An address provided assigned to a host.  The validation-timer an interface whose use is
                  discouraged, but not forbidden.  A deprecated
                  address should no longer be used as a source address
                  in absolute time

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

   and in seconds (e.g. 3 hours would have the value 10800).

   deprecation-liftetime: This is the lifetime for new communications. but packets sent to a single
                  deprecated address the
   host uses are delivered as expected.
                  A deprecated address may continue to begin be used as a
                  source address for the deprecation duration of an existing
                  communications.

   valid address prior to the
   validation-lifetime expiring, so that the host can determine if
                - A preferred or deprecated address.  A valid address
                  may appear as the source or destination address can receive of a new validation-lifetime.  The deprecation-
   lifetime is in absolute time
                  packet, and in seconds (e.g. 3 hours would have the value 10800). internet routing system is expected to
                  be able to deliver packets sent to a valid address.

   invalid address
                - An address that is not assigned to any interface. A
                  valid address becomes invalid when its valid
                  lifetime expires.  Invalid addresses should not appear
                  as the source or destination of a packet.

   preferred lifetime
                - The length of time that a valid address is preferred.
                  When the preferred lifetime expires, the address
                  becomes deprecated.

   valid lifetime
                - The length of time the address remains in the valid
                  state. The deprecation-lifetime valid lifetime MUST be no greater than or
                  equal to the validation-lifetime.

   deprecated-address: This preferred lifetime.  When the valid
                  lifetime expires, the address becomes invalid.

   interface token
                - A link-dependent identifier for an interface that
                  is (at least) unique per link.  Stateless Address
                  Autoconfiguration combines an interface token with
                  a single prefix to form an address.  From an address that
                  autoconfiguration perspective, an interface token
                  is in the
   deprecated state on a host because bit string of known length.  The exact length
                  of an interface token and the deprecation-lifetime period
   has expired.

   invalid-address:  This way it is created is
                  defined in a single address whose validation-lifetime
   has expired.

2.2 separate link-specific document that
                  covers issues related to the transmission of IP
                  over a particular link type (e.g., [IPv6-ETHER]).
                  In many cases the token will be the same as the
                  link-layer address.

2.2. DHCPv6 Terminology

   configuration-type: Configuration Type defines an optional

   configuration parameters
                - Is any parameter in the DHCPv6 protocol.

   configuration-data: Configuration Data is information a host that can use be used by a node to
                  configure a host on a network, their network environment so that the host node can interoperate
   with other hosts
                  communicate on a network.  Configuration Data will vary in
   length depending link or on the configuration type.

   client: an internet.

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

   server:
                  other configuration parameters.

   server       - A Server server is a host node that responds to requests from
                  clients on a link to provide: addresses, DNS host name processing, dynamic
                  updates to DNS, or
   configuration-data.

   relay-agent: other configuration parameters.

   relay-agent  - A Relay-Agent relay-agent is a router node that listens on the a link for
   clients
                  client requests, and then forwards the request packet to a
                  server on the network.  The server will respond back
                  to the Relay-Agent, relay-agent, who will forward the reply response to
                  the client on the Relay-Agents relay-agents link.

   message-type:

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

   message-code:

   message-flag - The Message-Code message-flag defines a an optional processing
                  notification for a message-
   type DHCPv6.  The message-flag can also
                  be used by the Options for DHCPv6 specification.

   error-code   - The error-code specifies errors from a client or
                  server.

   name-length:  The Name-Length defines error-code can also be used by the length of
                  Options for DHCPv6 specification.

   total-addresses
                -  The total-addresses specifies the host name total number of
                   addresses being provided by a client or from a server for DNS Autoregistration of host
   names.

   interface-token: The Interface-Token to a client.
                   For each address there is specified by the client a preferred and valid
                   lifetime.

   completed-transaction
                -  A completed-transaction is a unique opaque identifer for communications exchange
                   between a clients interface, client and must be
   accessbile after a server, using the required set
                   of DHCPv6 request/response message-types, where the
                   final response message in the request/response set
                   has been received by the client reboots (e.g. IEEE 802 MAC address).

   address-count: and by the server.

   transaction-ID
                - The address-count transaction-ID is an integer identifier specified
                  by the client with any
   request sent to a server, and represents is used by the number client and server as
                  a transaction identifier to define the set of addresses
                  request/response messages between the client has received from a server and
                  server, for a specified interface-token.

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

   client-address: clients interface token.

   client-link address
                - The Client-Address is the field in the DHCPv6
   protocol that contains the client-link address for specifies the clients interface-token.

   server-address:
                  link-local address. The Server-Address client-link address
                  is the field in the DHCPv6
   protocol that contains used by a relay-agent to respond to a client
                  on a link, after receiving a server response.

   server address
                - The server address specifies the address of for the
                  server responding to the
   clients request.

   gateway-address: a client.

   gateway address
                - The Gateway-Address is the field in gateway address specifies the DHCPv6
   protocol that contains address of the relay-agents address, so
                  relay-agent for a server, that which may be multiple
                  relay-agent hops away from the orginal relay-agent,
   can respond directly to the relay-agent that forwarded the request,
   by extracting the Gateway- Address to be used as the server packets
   destination address.

   client-link-address: The client-link-address is the field in the
   DHCPv6 protocol the relay-agents use to save the clients source original relay-agent.

   client address in the IPv6 header, so they can respond back to the server on
   the link.

   transaction-ID:
                - The Transaction-ID is specified by the client as address specifies an
   opaque transaction identifier, which uniquely identifies the 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 address from a client who has multiple requests for the same interface-token.

   host-name:  The Host-Name is the name
                  server to be associated with an
   address.  If the name-length is zero then the Host-Name is not
   present in the DHCPv6 request or response.

   binding:  The Binding used by a client.

   binding      - A binding in DHCPv6 is a an N-tuple that a client
                  and server MUST maintain in DHCPv6 for each completed transaction, a
                  completed-transaction, where N is the number of configuration-data identifiers
                  configuration parameters for a client. An
                  implementation MUST support at least a 4-tuple Binding 5-tuple
                  binding consisting of
   the a clients interface-token, interface token,
                  client address, validation-lifetime, preferred lifetime and
   deprecation-lifetime valid
                  lifetime for that address.  An example of a completed
   transaction in DHCPv6 is when the each client requests an address for an
   interface-token and receives an address and lease for that token.  It
   is implementation defined if greater than a 4-tuple Binding is
   supported by an implementation, address, and is not prohibited by this
   specification.

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

3. Protocol Design Model

   This section is provided for implementors to understand the DHCPv6
   protocol design model from an architectural perspective.  It provides
   related work  Any
   conceptual models presented in IPv6 this specification that influenced the protocol design and the
   design goals.  The request/response protocol model is discussed and
   the objective provide
   implementation examples are not a requirement of this model in the design.  The leased address
   strategy and purpose is discussed. DHCPv6 protocol.

3.1. Design Goals

   The objective of the
   autoregistration following list gives general design goals for DNS Host Names is discussed and the capabilities
   that are possible in this specification.  The client/server model is
   discussed DHCPv6.

      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 prepare an implementor 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 client/server processing
   provided later in the specification.  Then the network manager should not
      have to enter any per-host configuration options
   are defined parameters.

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

      A DHCPv6 client must be prepared to build additional extensible
   configuration-data receive multiple responses to
      a request for DHCPv6.

3.1 Related Work in IPv6

   The related work in IPv6 that would best serve an implementor configuration parameters.  Some installations may
      include multiple, overlapping DHCPv6 servers to
   study is the IPv6 Specification [IPv6-SPEC], the IPv6 Addressing
   Architecture [IPv6-ADDR], 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
   [IPv6-ADDRCONF], Autoconfiguration.

      DHCPv6 must support the requirements of automated renumbering of
      IPv6 Neighbor Discovery Processing [IPv6-ND], and addresses.

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

      It is NOT a design goal of DHCPv6 to build upon the IPv6 work specify a server to provide both robust statefull
   autoconfiguration and autoregistration of DNS Host Names.  In
   addition related work for DHCP for IPv4 server
      protocol.

      It is directly related to
   DHCPv6.

   The IPv6 Specification provides the base architecture and NOT a design goal of
   IPv6.  A key point for DHCPv6 implementors to understand specify how a server
      configuration parameter database is that IPv6
   requires that every link in maintained or determined.

   The following list gives design goals specific to the internet have an MTU transmission of 576 octets or
   greater (in IPv4
   the requirement is 68 octets).  This means network layer parameters.

      Guarantee that a
   UDP datagram of 536 octets any specific network address 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 be in use by
      more than one host at routers and fragmentation must take place end-to-end
   between hosts.  If a time.

      Guarantee that client addresses that are not provided by DHCPv6 implementation needs
      will not be added to send a packet
   greater than 536 octets it can either fragment the UDP datagram in
   UDP servers configuration parameter database or use Path MTU Discovery [IPv6-SPEC] to determine the size of
      the packet that will traverse servers binding for a network path.  It is implementation
   defined how this is accomplished in DHCPv6.

   The IPv6 Addressing Architecture Specification provides the address
   scope that can clients interface token.

      Retain host configuration parameters across client reboots.  A
      client should, whenever possible, be used in an IPv6 implementation, and assigned the various same
      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 parameters in any manner on the link.  The response to a request.

      Retain host can then use configuration across server reboots, and, whenever
      possible, a well-known multicast address host should be assigned the same configuration
      parameters despite restarts of the DHCPv6 mechanism,

      Allow automatic assignment of configuration parameters to begin
   communications new
      hosts to discover neighbors on the link, avoid hand configuration for new hosts.

      Support fixed or as will be
   discussed later in permanent allocation of configuration parameters
      to specific hosts.

3.2. Request/Response Model

   DHCPv6 uses a message-type to define whether the specification locate packet originated
   from a DHCPv6 server or
   relay-agent. client.  The IPv6 Stateless Address Configuration Specification (addrconf)

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

   defines how set of packets used to complete
   a host can autoconfigure addresses based on neighbor
   discovery router advertisements, and DHCPv6 transaction are defined as the use of request and response set.

   The message types are as follows:

      01 DISCOVER

         The DISCOVER message is a validation-lifetime DHCPv6 multicast packet from a client
         to locate and request configuration parameters on a deprecation-lifetime for addresses.  In addition network,
         when the addrconf
   specification defines client does not know the protocol interaction for a host to begin
   stateless or statefull autoconfiguration.  DHCPv6 servers address.

      02 CONF-REQUEST

         The CONF-REQUEST is one vehicle an IPv6 unicast packet from a client to
   perform statefull autoconfiguration.  Compatibility with addrconf is a design goal of DHCPv6 where possible.

   IPv6 Neighbor Discovery (ND) is
         server, when the client knows 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 unicast address of a
         server, to DNS request configuration parameters on a network.

      03 CONF-RESPONSE

         The CONF-RESPONSE is an IPv6 unicast packet from a specification that supports the dynamic
   update of DNS records for both IPv4 and IPv6.  This will be discussed
   further later server in this section of the specification.  An implementor
   cannot implement DHCPv6 without understanding Dyanmic Updates
         response to DNS.

3.2 Design Goals a client DISCOVER or CONF-REQUEST, which provides
         the requested configuration parameters.

      04 ACCEPT

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

      DHCPv6 should be ACCEPT is a mechanism rather than client response to a policy.  DHCPv6 must
      allow local system administrators control over server CONF-RESPONSE. When
         the client used DISCOVER to locate a server and request
         configuration parameters where desired; e.g., local system administrators on a network, the ACCEPT should be able
         sent using the DHCPv6 multicast address, which also serves to enforce local policies concerning allocation and access
         inform other servers that responded to local resources where desired.

      Hosts should require no manual configuration.  Each host should be
      able the DISCOVER they were
         not selected.  When the client used CONF-RESPONSE to discover appropriate local request
         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, from a server whose address was known,
         the network manager ACCEPT should not
      have be sent as an IPv6 unicast packet.  The
         ACCEPT is also an implied acknowledgment to enter any per-host the server selected
         that the client has received the servers configuration parameters.

      DHCPv6 should not require
         parameters from the CONF-RESPONSE.

      05 SERVER-ACK

         The SERVER-ACK is an IPv6 unicast packet sent by 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
         inform 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 client that it received an ACCEPT. The SERVER-ACK is NOT a design goal of DHCPv6 to specify a
         used by the server to server

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

      protocol.

      It is NOT inform the client it has received an
         acknowledgment that the client has received the configuration
         parameters from the server, and denotes a design goal of DHCPv6 completed-transaction
         to specify how a server
      configuration database is maintained or determined. server.  The following list gives design goals specific to the transmission of
   the network layer parameters.

      Guarantee server at that point MUST commit its bindings
         and any specific network address will not be in use by
      more than one host at updates it may do for the client. The SERVER-ACK for
         the client denotes a time.

      Guarantee that completed-transaction. The client addresses at that are not provided
         point MUST commit its bindings.

      06 RELEASE

         The RELEASE is used by DHCPv6
      will not be added to a servers configuration database or the
      servers binding client for a clients interface-token.

      Retain host configuration across host reboot.  A two reasons:

            1. To inform the server that the client should,
      whenever possible, be assigned did not receive the same configuration-data in
      response
               SERVER-ACK required to each request.

      Retain host configuration across complete the client transaction,
               and the 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 delete that addresses are updated to binding and any
               updates it may have done on behalf of the DNS,
      unless client.

            2. To inform 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 that 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 is releasing a client
               particular address or server times out waiting
   for a response to a packet sent, set of addresses, even though the implementation MUST NOT commit
   any binding based on
               lifetimes for those addresses may not have become
               invalid.

      The processing and algorithms for the configuration-data sent request/response set of
      message-types will be discussed 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 section 4.0.

3.3. Leased Address Model

   An

   The leased address model specifies a set of lifetimes associated with
   addresses returned by the server.  These lifetimes are meant to a client has a validation-lifetime
   support site renumbering, and
   deprecation-lifetime. are completely compatible with the
   leasing model in IPv6 Stateless Address Autoconfiguration.

   The lifetimes represent DHCPv6 philosophy is that the client has the responsibility to
   renew a lease for a single an address for a client.  The server MUST provide a validation-lifetime
   and SHOULD provide a deprecation-lifetime that is about 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 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 address.
   The server MAY provide that address to another client requesting an address.

   If the
   address, after all other addresses available to the server have been
   exhausted.

3.3.1. Address Lifetimes

   An address returned to a client has a deprecation-lifetime preferred and valid lifetime.
   The lifetimes represent the lease for addresses provided to the
   client, from the server.

   The client MAY request a value for the lifetimes returned by a
   server, but the client MUST use the lifetimes provided by the server
   response.

   When an address for a client interface becomes deprecated the
   processing of the lease SHOULD MUST be as follows:

      When the deprecation-lifetime preferred lifetime of an address expires, the clients
      address becomes a deprecated-address. deprecated address.  A deprecated address SHOULD
      NOT can be
      used as a source address in new communications and existing
      communications. However, But a
      deprecated-address SHOULD continue to deprecated address means the node will soon
      have an address whose valid lifetime will expire, when this
      happens the address cannot be used as a source address
      if it is in use in existing any 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 deprecated until its invalidation-lifetime valid lifetime expires at
      which point the address becomes an invalid-address. invalid address. An
      invalid-address invalid
      address MUST NOT be used as a source address in outgoing
      communications, and MUST NOT be recognized as a valid destination
      address in for incoming communications.

      Once an address is deprecated an implementation SHOULD request a
      new lease or address for that interface.

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

      There address
   is no concept immediately deprecated.

   Implementors of DHCPv6 would find it beneficial to coordinate the use
   of the preferred lifetime and valid lifetime for layers below the
   DHCPv6 application layer with their implementation of Stateless
   Address Autoconfiguration.  It is suggested that implementations use
   the same modules to configure addresses for stateless and stateful
   address autoconfiguration.  Implementors might want to consider an
   option to stop all new communications for a deprecated-address for a client if deprecated address, to
   support a very robust renumbering strategy, but this cannot be the
      deprecation-lifetime
   default behavior.

3.3.2. Duplicate Address Detection

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

   It is zero when provided an option for a server to inform the client it does not have to
   perform Duplicate Address Detection by the server setting a value of
   01 in the message-flag in client responses.  In this case it is
   assumed that the server implementation is providing the guarantee
   that the client addresses returned are unique on the link.  It is
   implementation defined how a server response. verifies the uniqueness of client
   addresses on a link.

   A conceptual model of an implementation for DHCPv6 duplicate address
   detection is that the client DHCPv6 module, which supports updating
   the network interfaces for a host, would use the same application
   configuration interface for DHCPv6 as is used for IPv6 Stateless
   Address Autoconfiguration on an IPv6 conforming implementation.  An
   implementation can integrate and reuse the same modules in the
   network operating system kernel to spawn duplicate address detection,
   address lifetime processing, and the processing of deprecated and
   invalid addresses for existing and new connections.

3.3.3. Releasing Infinite Lifetime Addresses

   DHCPv6 specifies no behavior which would require a client to listen
   for asynchronous messages from servers on a well known UDP port.  The
   reason for this is that minimal implementations may not be able to
   support such a feature in a client.  But DHCPv6 does permit the
   client to request an infinite lease for addresses.  The problem in
   this case is that though the server has permitted an infinite lease
   for a client it may later be required that the client give up that
   lease or the addresses, for some organizational reason.

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

   One solution to the problem is to define an SNMP MIB for DHCPv6
   clients that when set by a network management agent causes a client
   to revalidate all of its addresses with the DHCPv6 server or issue a
   RELEASE to the server.

3.4. DNS Host Name Autoregistration Model

   It is important that DHCPv6 provide a server implementation set of
   options for Dynamic Updates to DNS (DYNDNS), to support the
   autoregistration of addresses to names in IPv6.  DYNDNS SHOULD be
   supported as a set of options in DHCPv6 as specified in the Options
   for DHCPv6 specification.  The minimum requirements to support DYNDNS
   in DHCPv6 are as follows:

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

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

      3.  If servers support DYNDNS then they MUST support the
          following:

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

          b)  Create, Update, and Delete of IPv6 IP6.INT Domain PTR
              records for any IPv6 AAAA addresses defined in a client
              DYNDNS request, or that the server automatically generated
              for a client.

4. Request/Response Processing

   The request/response processing for DHCPv6 is transaction based and
   uses a best-effort set of messages to guarantee a completed-
   transaction. The case where the client does not know the servers
   address is depicted, and then the case where the client does know the
   servers address is depicted.  Then the timeout and retransmission
   guidelines and configuration variables are discussed.

4.1. Processing when Server Address is not Known

   The processing for the DHCPv6 request/response model when the client
   does not know the server address is as follows:

                   Server          Client          Server
               (not selected)                    (selected)

                     v               v               v
                     |               |               |
                     |       Begin Transaction       |
                     |               |               |
                     | _____________ | _____________ |
                     |      DISCOVER | DISCOVER      |
                     |       (DHCPv6 Multicast)      |
                     |               |               |
      Determine Client Configuration | Determine Client Configuration
                     |           (Unicast)           |
                     |  ___________  | ____________  |
                     | CONF-RESPONSE | CONF-RESPONSE |
                     |               |               |
                     |       Collects replies        |
                     |               |               |
                     |     Selects configuration     |
                     |               |               |
                     | _____________ | _____________ |
                     |       ACCEPT  |   ACCEPT      |
                     |        (DHCPv6 Multicast)     |
                     |               |               |
                     |               |       Commits Client Bindings
                     |               |            (Unicast)
                     |               |               |
                     |               | _____________ |
                     |               |  SERVER-ACK   |
                     |               |               |
                     |       Transaction Complete    |
                     |       Client commits Bindings |
                     |               |               |
                     |       IF the Client did not   |
                     |       receive the SERVER-ACK  |
                     |       delete the Bindings     |
                     |            (Unicast)          |
                     |               |               |
                     |               | _____________ |
                     |               |  RELEASE      |
                     |               |               |
                     |               |    Server deletes the Bindings
                     |               |    and rolls back any updates that
                     |               |    that may have been done for the
                     |               |    client.
                     |               |               |
                     v               v               v

   DHCPv6 uses the UDP [RFC-768] protocol to communicate between clients
   and servers.  UDP is not reliable, but DHCPv6 must provide some
   reliabilty between clients and servers.  The network trade-off is
   time versus the reliability that the completed set of
   request/response messages were received by both the client and the
   server to define a completed-transaction.

   The request/response set is always started by a client either with a
   DISCOVER when the client does not know the servers address, or a
   CONF-REQUEST when the client does know the servers address.  The
   second message is from the server and is the CONF-RESPONSE.  The
   client then acknowledges the servers CONF-RESPONSE with an ACCEPT.
   At this point in the flow all data has been received and additional
   messages are defined to insure the transaction is completed, and to
   provide a method of recovery if either the client or server do not
   receive the messages to complete the transaction.

   The server after receiving the ACCEPT sends a SERVER-ACK, which is an
   acknowledgment to the client the server has received the clients
   ACCEPT.  At that point the time vs reliability trade-off in DHCPv6 is
   for the server to commit its bindings, and perform any updates as a
   result of the client messages (e.g. Update DNS).  If the client
   receives the SERVER-ACK, then the client can commit its bindings.
   But if the client does not receive the SERVER-ACK then it should send
   the server a RELEASE to inform the server that any bindings should be
   deleted and any updates for the client should be rolled back.  The
   client RELEASE provides the final recovery check in the DHCPv6
   request/response set to complete a transaction.

   Retransmission of messages is discussed in section 4.3.

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

4.2. Processing when Server Address is Known

   The processing for the DHCPv6 request/response model when the client
   does knows the server address is as follows (all packets are
   Unicast):

                                  Client          Server

                     v               v               v
                     |               |               |
                     |       Begin Transaction       |
                     |               |               |
                     |               | _____________ |
                     |               | CONF-REQUEST  |
                     |               |               |
                     |               |  Determine Client Configuration
                     |               |               |
                     |               | ____________  |
                     |               | CONF-RESPONSE |
                     |               |               |
                     |               | _____________ |
                     |               | ACCEPT        |
                     |               |               |
                     |               |  Commits Client Bindings
                     |               |               |
                     |               | _____________ |
                     |               |  SERVER-ACK   |
                     |               |               |
                     |       Transaction Complete    |
                     |       Client commits Bindings |
                     |               |               |
                     |       IF the Client did not   |
                     |       receive the SERVER-ACK  |
                     |               |               |
                     |               | _____________ |
                     |               |  RELEASE      |
                     |               |               |
                     |               |    Server deletes the Bindings
                     |               |    and rolls back any updates that
                     |               |    that may have been done for the
                     |               |    client.
                     |               |               |
                     v               v               v

The processing above is the same as was discussed in 4.1, except the
CONF-REQUEST is used by the client to request configuration parameters
from the server, and the CONF-REQUEST and ACCEPT are unicast packets.

4.3. Retransmission and Configuation Variables

   Configuration variables for a DHCPv6 implementation that MUST be
   configurable by a client or server are as follows:

      Retranstimer - The time in seconds that a DHCPv6 client or server
                     should wait before retransmitting a message.

                     Default: 3 seconds.

      Maxretrans   - The maximum retransmissions that a DHCPv6 client
                     or server should retransmit, before logging a
                     DHCPv6 System Error to the user.

                     Default: 3 retransmissions.

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

   To support informing a client or server that a retransmission is
   being done a second set of message-types are supported in DHCPv6 as
   follows:

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

   When a client or server retransmits a DHCPv6 packet at the
   application layer over UDP, they MUST change the message-type to the
   same message-type with the Retrans suffix.

   A response to a retransmission SHOULD be a duplicate of a previous
   response to the client or server.  It is implementation defined how
   this is accomplished.

   One method of retransmitting duplicates in an implementation
   conceptually is to use the 5-Tuple binding for a client or server to
   search for a previous response.  At a minimum the client interface
   token and transaction-ID will be present in all messages; hence a
   binding can be searched (whether committed or in process) to verify
   if a previous response has been sent.

5. Datagram and Field Definitions

5.1. Datagram

                              DHCPv6 Datagram

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  msg-type     |    msg-flag   |   error-code  | total-addrs   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            RESERVED           |      transaction-ID           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                     interface token                           |
        |                        (8 octets)                             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       server address                          |
        |                        (16 octets)                            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       gateway address                         |
        |                        (16 octets)                            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                   client-link address                         |
        |                        (16 octets)                            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                      preferred lifetime                       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                      valid lifetime                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                        client address                         |
        |                         (16 octets)                           |
        |        (can be multiple addresses and lifetimes present)      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |  options (variable number and length)                         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2. Field Definitions

   All fields in the datagram MUST be initialized to binary zeroes by
   both the client and server messages unless otherwise noted in Section
   6.

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

      Value        Description

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

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

      Value        Description

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

   error-code          - 1 octet integer value

      Value        Description

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

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

   RESERVED            - 2 octets Reserved for future use.

   transaction-ID      - 2 octets integer value

   interface token     - 8 octets link-dependent identifier

   server address      - 16 octets address

   gateway address     - 16 octets address

   client-link address - 16 octets link-local address

   preferred lifetime  - 4 octets integer value in seconds

   valid lifetime      - 4 octets integer value in seconds
   client address      - 16 octets address

   options             - variable number of octets [DHCPv6-OPT]

6. Client/Server Message Formats

6.1. Client/Server UDP Ports, Multicast Group, and Addresses

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

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

   A client MUST receive all messages over UDP using UDP Client Port 546.

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

   A server or relay-agent MUST join the DHCPv6 Server/Relay-Agent
   multicast group well-known multicast address for the client is valid until FF02:0:0:0:0:0:1:0.

   Servers on the
      validation-lifetime expires at which point same link as the address becomes an
      invalid-address.  An invalid-address client MUST NOT be used as a use the 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 IPv6 header from the client may provide to as the server in a request.  In addition a server
   may provide a DNS Host Name with an IPv6 destination address to a client in a
   response.

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

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

   If section 7.

   In the client provides cases where a Host Name (HN) client 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 must retransmit messages the name is found and
   msg-type codes in this section are used as stated in section 4.3 with
   the address does not match values that represent the clients
      address Retrans suffix for the name provided by msg-types.

6.2. Client DISCOVER and CONF-REQUEST Messages

   msg-type:

   If the client, client does not know the server SHOULD add
      this address or wants to locate a new
   server to receive configuration parameters the DNS name record (multiple addresses are
      supported for names at this time in DNS and client sets the msg-type
   to DISCOVER.  In this case the client may want to MUST use as the same name for multiple addresses on an interface). destination
   IP address the DHCPv6 Server/Relay-Agent multicast address
   FF02:0:0:0:0:0:1:0.

   If the name is not found client knows the server address the client supplied name SHOULD be added
      to sets the DNS. msg-type to
   CONF-REQUEST. In either condition above this case the server client MUST add the associated DNS
      inverse address mapping use as an IP6.INT domain PTR record [IPv6-DNS]
      for this clients the destination
   IP address and name.

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

   msg-flag:

   Set to binary zeroes.

   error-code:

   Set to binary zeroes.

   total-addrs:

   Set to the client.

   If number of addresses the client does not request a HN or FQDN from is requesting.

   transaction-ID:

   Set to an integer value.

   interface token:

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

   server
   MAY provide, in its response with the address address:

   Set to a client, a FQDN the
   client can use binary zeroes for that address.  The server MUST NOT provide a
   client with a DISCOVER.
   Set to server generated FQDN, unless the associated IPv6 AAAA
   record and IP6.INT domain PTR record exists in address for CONF-REQUEST.

   gateway address:

   Set to binary zeroes.

   client-link address:

   Set to the DNS.

   When a clients link-local address invalidation-lifetime expires for the link on which the server, client
   transmitted the server SHOULD delete packet.

   preferred lifetime:

   Set to binary zeroes if the clients IPv6 AAAA record and IP6.INT
   domain PTR record from client is not requesting a lifetime.
   Set to 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 number of 8 octets:

      option-type: 1 Octet

      This field permits 254 options for DHCPv6 and will represent seconds the
      tag client wants for the option. lifetime.
   Set to all 1's (oxffffffff) if the client wants an infinite lifetime.

   The values of 0 and 1 are used client must provide a preferred lifetime for pad
      options discussed below.

      option-length: 2 Octets

      This field specifies each address
   requested.

   valid lifetime:

   Set to binary zeroes if the client is not requesting a lifetime.
   Set to the length number of seconds the configuration-data not
      including client wants for the lifetime.
   Set to all 1's (oxffffffff) if the option-type and and option-length fields.

      option-data:  Variable number of Octets client wants an infinite lifetime.

   The option-data is the configuration-data that immediately follows client must provide a valid lifetime for each address
   requested.  The valid lifetime must be greater than or equal to the option-length field.

   If
   preferred lifetime.

   client address:

   Set to binary zeroes if the server does client is not support requesting a renewal for an option-type requested
   existing address it MUST
   return received from a server.
   Set to an address the option-type and client previously received from a server when the option-length
   client is requesting a new set to zero in the
   response to of lifetimes for the client. address.

   A server implementation client MUST start any options after the first option
   returned to NOT provide a client on an integer multiple of 8 octets.  This is server with an
   architectural REQUIREMENT, and address that was not given
   to 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 by a server.  DHCPv6 does not define any options.  DHCPv6 options are
   defined in XXXXXXXXX.  It is permissible for options permit a server to also create
   new message-types and message-codes as required.

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

4.  Datagram and Data Formats

4.1 Datagram

                           DHCPv6 Datagram

     0               8               16              24              31
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  msg-type     |    msg-code   |   name-lgth   | addr-count    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      transaction-ID                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     interface-token                           |
     |                       (8 Octets)                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       client-address                          |
     |                        (16 Octets)                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       server-address                          |
     |                        (16 Octets)                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       gateway-address                         |
     |                        (16 Octets)                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   client-link-address                         |
     |                        (16 Octets)                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      validation-lifetime                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      deprecation-lifetime                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         host-name                             |
     |                    (variable octets 0-255)                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  option-type  |  option-lgth  | option-data (variable octets) |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.2 Data Formats

  All fields in
   leases for manual configured addresses, or update leases for addresses
   created by IPv6 Stateless Address Autoconfiguration.

   options:

   See Options for DHCPv6 specification [DHCPv6-OPT].

6.3. Server CONF-RESPONSE Message

   msg-type:

   Set msg-type to CONF-RESPONSE.

   msg-flag:

   Set to 01 if the datagram MUST server knows addresses provided are verified to be initialized
   unique, otherwise set to binary zeroes
  by both zeroes.

   error-code:

   Set to 01 if the server cannot provide any addresses to the client and at
   this time.
   Set to 02 if the server messages unless otherwise noted
  in Section 5. Client and Server processing detects an address from the client it did not
   provide to the client.

   total-addrs:

   Set to the number of messages.

  msg-type              : 1  Octet integer addresses the server is returning the client.

   transaction-ID:

   Set to the value (message-type)

    Value    Description

     1    -  Client request the client provided in the DISCOVER or CONF-REQUEST
   msg-type.

   interface token:

   Set to a unique link dependent identifier for configuration data.
     2    -  Server response with configuration data.
     3    -  Client confirmation of the clients interface as
   provided in the clients DISCOVER or CONF-REQUEST msg-type.

   server response.
     4    -  Client rejection address:

   The address of the server response.

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

  msg-code              : 1  Octet integer value (message-code)

    Value    Description

     1    -  Server Response - Client address-count is in error.
     2    -  Server Response - Dynamic Updates responding.

   gateway address:

   Set to DNS not supported.

  name-lgth             : 1  Octet integer value (name-length)

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

  transaction-ID        : 4  Octets integer value

  interface-token       : 4  Octets integer value

  client-address        : 16 Octets address

  server-address        : 16 Octets address

  gateway-address       : 16 Octets address

  client-link-address   : 16 Octets address

  validation-lifetime   : 4  Octets integer value

  deprecation-lifetime  : 4  Octets integer the same value

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

  option-type           : 1  Octet integer that existed when the server received the packet.

   client-link address:

   Set to the same value

  option-length         : 1  Octet integer that existed when the server received the packet.

   preferred lifetime:

   Set to the value

  option-data           : Variable Octets variant value(s)

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

5.  Client/Server Processing

5.1 Client Transmission

   UDP DHCPv6 Server Port 546 MUST be used requested by the client to send UDP
   datagrams to or the value required by the
   server.

   If

   valid lifetime:

   Set to the value requested by the client knows its address it MUST be put in the source address
   field of or the IPv6 Header.  Otherwise value required by the clients link-local address
   server.

   The valid lifetime MUST be used as greater than or equal to the source preferred
   lifetime.

   client address:

   Set to an address field in provided by the IPv6 Header [IPv6-
   ADDRCONF].

   If server if the client knows is not attempting
   to renew existing addresses, meaning the address fields from the client
   have a value of binary zeroes.

   If the error-code is set to 02 the server on its link it MUST put will only return the addresses
   that address in the destination address field of server can verify were provided by the IPv6 Header.
   Otherwise server.  If no addresses
   could be verified the total-addrs field, lifetimes, and client MUST put the DHCP Server/Relay-Agent well-known
   multicast address FF02:0:0:0:0:0:1:0 using link-local scope [IPv6-
   ADDR]
   will be set to binary zeroes.  In the case as far as the destination address field in server is
   concerned the IPv6 Header.

   The client MUST set msg-type to 1 to transmit a request to DHCPv6 transaction is completed and the
   server.

   The server will not
   expect a client MUST set msg type ACCEPT message to 3 its CONF-RESPONSE message.

   options:

   See Options for DHCPv6 specification [DHCPv6-OPT].

6.4. Client ACCEPT Message

   msg-type:

   Set msg-type to confirm ACCEPT.

   If the acceptance of packet
   from a server response.

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

   The DISCOVER to request configuration parameters on the
   link, then the client MUST should use UDP DHCPv6 Client Port 546 as the UDP port to
   accept server responses in an implementation.

5.2 Server Transmission

   UDP IP destination address the DHCPv6 Client Port 546 MUST be used by
   Server/Relay-Agent multicast address FF02:0:0:0:0:0:1:0.

   If the server to send UDP
   datagrams client sent a CONF-REQUEST to the client.

   A server, request configuration parameters on
   the same link as link, then the client, MUST client should use as the IP destination address the source server
   address in the IPv6 Header CONF-RESPONSE from the client as server.

   If the destination address in client sees an error-code of 02 and the
   servers response packet.  Servers not on total-addrs field is
   zero, 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 Port 547 as cannot process any of the UDP port addresses requested and the
   client should not send an ACCEPT to
   accept the server.  If the client requests in sees an implementation.

   The
   error-code of 02 and total-addrs does not equal zero it means the server MUST join
   dropped addresses that it could not locate requested by 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], client.

   msg-flag:

   Set to listen for client requests, binary zeroes.

   error-code:

   Set to binary zeroes.

   total-addrs:

   Set to 1.

   transaction-ID:

   Set to the integer value that do not know the address of a server client used on its initial DISCOVER or
   CONF-REQUEST msg-type to the clients link.

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

5.3 Client/Server Bindings

   Client and server bindings MUST be maintained at least as a 4-tuple
   consisting of server.

   interface token:

   Set to the clients interface-token, address, validation-
   lifetime, and deprecation-lifetime in an implementaiton.  It is
   critical unique link dependent identifier for the interoperability of DHCPv6 clients interface
   that was used for the clients bindings
   remain consistent with initial DISCOVER or CONF-REQUEST msg-type
   to the server.

   server address:

   Set to the address provided by the servers bindings across reboots.

   When a CONF-RESPONSE.

   gateway address:

   Set to binary zeroes.

   client-link address:

   Set to the clients link-local address for the link on which the client sends a request it MUST enter in
   transmitted the addr-count field packet.

   preferred lifetime:

   Set to the number of addresses that it has first or only preferred lifetime returned for an address by
   the server.

   valid lifetime:

   Set to the first or only valid lifetime returned for a particular interface-token
   in the clients bindings.

   When an address by the server receives
   server.

   The valid lifetime MUST be greater than or equal to the preferred
   lifetime.

   client request, it MUST verify that address:

   Set to the
   addr-count field first or only address provided by the client matches the number of
   addresses server.

   If the server has for client did receive more than one address and lifetime, it MUST
   store this data in an implementation defined manner, so that clients binding, it can
   issue a complete RELEASE for the
   interface-token all addresses provided by the client.  If from the server has a
   different addr-count than
   CONF-RESPONSE, if necessary later.  But the client for a particular interface
   token, ACCEPT does not need to carry
   all those addresses to acknowledge the server MUST send a response servers CONF-RESPONSE packet in
   an ACCEPT.

   options:

   No options are present.

6.5. Server SERVER-ACK Message

   msg-type:

   Set msg-type to SERVER-ACK.

   If the client setting msg-code sent the ACCEPT to 1 informing acknowledge a servers CONF-RESPONSE
   message on the client addr-count DHCPv6 Server/Relay-Agent multicast address
   FF02:0:0:0:0:0:1:0, the server MUST look at the server is not address in synch
   with the client.

   Once the client receives a response with a msg-code set to 1 it MUST
   set addr-count to zero on subsequent requests
   packet to determine if the server, ACCEPT is for them or not.

   If the message is not for that
   interface-token.

   When a particular server receives a request from a client and the addr-count then this is
   set an indirect
   message to zero, but the client has a binding for that interface-token,
   the particular server MUST reissue the configuration-data in those bindings to the client.

5.4 Client Requests

   The client sets the following fields is not accepting them as
   their server for this transaction, and MUST NOT send a request for
   configuration-data:

      msg-type: SERVER-ACK to the
   clients ACCEPT.

   msg-flag:

   Set to 1.

      name-lgth: binary zeroes.

   error-code:

   Set to the length of the host-name if provided.

      addr-count: binary zeroes.

   total-addrs:

   Set to 1.

   transaction-ID:

   Set to the number of addresses integer value that the client has for the
      interface-token specified in this request.

      transaction-ID: Set used on its initial DISCOVER or
   CONF-REQUEST msg-type to a unqiue integer value.

      interface-token: the server.

   interface token:

   Set to a unqiue opaque identifier.

      client-address: Set ONLY if the client is requesting a host name unique link dependent identifier for a particular address, else not set.

      validation-lifetime: Set to the value clients interface
   that was used for the client would like clients initial DISCOVER or CONF-REQUEST msg-type
   to the server.

   server address:

   Set to use, else not set.

      deprecation-lifetime: the servers address.

   gateway address:

   Set to the same value the client would like that existed when the server to use, else not set.

      host-name: Set only if name-lgth is greater than zero otherwise

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

      this field is not present.

      option-type: received the packet.

   client-link address:

   Set to a future option request for configuration-
      data, otherwise the field is not present.  Multiple option-types
      may be set adjacent to each other.

5.5 Server Response

   The same value that existed when the server sets received the following fields for a response to a client for
   configuration-data:

      msg-type: packet.

   preferred lifetime:

   Set to 2.

      msg-code: the value provided by the client.

   valid lifetime:

   Set to 1 if addr-count not the value provided by the client.

   The valid lifetime MUST be greater than or equal to servers bindings for the clients specified interface-token. preferred
   lifetime.

   client address:

   Set to 2 if the address provided by the client.

   At this point the server
      cannot support Dynamic Updates MUST commit the configuration parameters
   provided to DNS because the client requested
      a host-name for an address provided, or from the servers set of
      addresses. CONF-RESPONSE.

   options:

   No options are present.

6.6. Client RELEASE Message

   msg-type:

   Set msg-type to RELEASE.

   If the client had sent an ACCEPT to the server determines and received a SERVER-ACK
   for that addr-count message then the client MUST commit the configuration
   parameters provided by the servers CONF-RESPONSE and a RELEASE message
   is not equal to its
         bindings it stops all other DHCPv6 processing, hence, required.  But if the
         server would client did not be receive a SERVER-ACK
   in response to the situation of setting msg-code clients ACCEPT, then the client MUST issue a RELEASE
   to
         both 1 and 2.  The server sets msg-code the server.

   If the client no longer needs an address or has been notified to return
   an address to 1 and MUST put all
         other values supplied by the clients request in server, then the response
         packet except client SHOULD issue a RELEASE to the msg-type and msg-code fields.

         Processing of msg-code set
   server.

   msg-flag:

   Set to 1 for binary zeroes.

   error-code:

   Set to binary zeroes.

   total-addrs:

   Set to the total number of addresses the client and server is
         done as specified in 5.3 Client/Server Bindings.

      name-lgth: Set to releasing.  In the length
   case of a RELEASE where the host-name if present.

      addr-count: Set to client did not receive the same SERVER-ACK this
   value specified by MUST equal the client. total number of addresses for the servers
   CONF-RESPONSE.

   transaction-ID:

   Set to the same integer value specified by that the client.

      interface-token: Set client used on its initial DISCOVER or
   CONF-REQUEST msg-type to the same value specified by server.

   interface token:

   Set to the client.

      client-address: If unique link dependent identifier for the client-address from clients interface
   that was used for the request packet is
      zero clients initial DISCOVER or CONF-REQUEST msg-type
   to the server.

   server sets the client-address address:

   Set to binary zeroes.

   gateway address:

   Set to binary zeroes.

   client-link address:

   Set to the next available clients link-local address for this interface-token. If there is a client-address in the request packet link on which the client is requesting a host-name for this
      address, and
   transmitted the server MUST return packet.

   preferred lifetime:

   Set to the valid lifetime returned for an address provided by the
      client if the server supports Dynmic Updates server.

   valid lifetime:

   Set to DNS, and has
      updated the DNS with a host-name valid lifetime returned for that address.

      server-address: an address by the server.

   The server valid lifetime MUST set this field be greater than or equal to its the preferred
   lifetime.

   client address:

   Set to the address in
      all response packets.

      validation-lifetime: provided by the server.

   The server sets this address to client will return the
      validation-lifetime number of addresses and associated lifetimes
   provided in the servers configuration database. It is
      implementation defined if the server will CONF-RESPONSE.

   options:

   No options are present.

7. Relay-Agent Processing

   The relay-agent MUST use UDP DHCPv6 Server Port 547 as the validiation-
      lifetime if specified by a UDP port to
   accept client request packet.

      deprecation-lifetime: responses in an implementation.

   The server sets this address to relay-agent MUST join the
      deprecation-lifetime of DHCP Server/Relay-Agent multicast group
   well-known multicast address FF02:0:0:0:0:0:1:0.

   When a DHCPv6 Relay-Agent hears a request from a DHCPv6 Client it MUST:

      If the servers configuration database. It gateway address is
      implementation defined if NOT zero then the server will use relay-agent MUST:

         Put the deprecation-

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

      lifetime if specified by a client request packet.

      host-name: The server returns a hostname or msg-code set to 2, if relay-agents IP address in the name-lgth gateway address field is greater than zero.  Processing of host-name
      is specified in Section 3.5 DNS Host Name Autoregistration Model.

      option-type: The server returns
         the same option-types specified by clients request packet.

   All relay-agents MUST:

      Put their relay-agent address as the client requests.

      option-lgth: The server returns source address for the length of IP
      header.

      Put the configuration-
      data next relay-agent or zeroes if the option is not supported.

      option-data: The known server returns the configuration-data requested
      by address as the client.

5.6 Client Confirmations/Rejections

   The client sets
      destination address in the following fields for a confirmation or rejection
   after receiving configuration-data from IP header.

      Forward the server. configuration-
   data:

      msg-type: Set packet to 3 if the client is confirming a servers response.
      Set to 4 if the client is rejecting a servers response. next hop relay-agent or
      known server.

   When the remote server receives a rejection msg-type 4 the client request from the relay-agent
   it will know its a remote client request (not on the server MUST assume the client servers link),
   because there is using another server.  The
         server then MUST remove any bindings for that client it may
         have created, and a gateway address in the request.  So servers MUST delete any DNS HN or FQDN records it may
         have added on behalf of
   verify the client.

      transaction-ID: Same value as specified in gateway address is not zero, to determine if the servers response.

      interface-token: Same value clients request
   is from a remote link.

   The server responds as specified in section 6.0, but uses the servers response.

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

6.  Relay-Agent Processing

   The IP header.

   When the relay-agent receives the remote servers response, it MUST use UDP DHCPv6 Server Port 547 as
   forward the UDP port packet to accept client responses in an 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 client, by using link-local
   scope [IPv6-ADDR], to listen for client requests.

   When a DHCPv6 Relay-Agent hears a request from a DHCPv6 Client it
   MUST:

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

         Put source address for the relay-agents IP Header.

8. Security Considerations

Security for DHCPv6 can be used as specified in [IPv6-SA], [IPv6-AUTH],
and [IPv6-ESP], which are implementation requirements for IPv6.

Appendix A - Related Work in IPv6 address

   The related work in IPv6 that would best serve an implementor to study
   is the gateway-address field
         of the clients request packet.

         Put the IPv6 Specification [IPv6-SPEC], the source address from IPv6 Addressing Architecture
   [IPv6-ADDR], IPv6 Stateless Address Autoconfiguration [IPv6-ADDRCONF],
   IPv6 Neighbor Discovery Processing [IPv6-ND], and Dynamic Updates to DNS
   [DYN-UPD].  These specifications afford DHCPv6 to build upon the IPv6 Header
   work to provide both robust stateful autoconfiguration and
   autoregistration of DNS Host Names.

   The IPv6 Specification provides the clients

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

         request packet base architecture and design of
   IPv6.  A key point for DHCPv6 implementors to understand is that IPv6
   requires that every link in the client-link-address.

      All relay-agents MUST:

         Put their relay-agent address as internet have an MTU of 576 octets or
   greater (in IPv4 the source address requirement is 68 octets).  This means that a
   UDP datagram of 536 octets will always pass through an internet (less 40
   octets for the IPv6 Header.

         Put the next relay-agent or known server address header), as long as there are no IP options prior to
   the
         destination address UDP datagram in the packet. But, IPv6 Header.

         Forward the packet to the 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 next hop relay-agent UDP datagram in UDP
   or known
         server.

   When the remote server receives use Path MTU Discovery [IPv6-SPEC] to determine the client request from size of the relay-
   agent it
   packet that will know its a remote client request (not on the servers
   link), because there is traverse a gateway-address in the request.  So servers
   MUST test the gateway-address network path.  It is not zero, to determine if the
   clients request implementation defined
   how this is from a remote link.

   The server responds as specified accomplished in 5.5 Server Response, but uses the
   gateway-address as DHCPv6.

   The IPv6 Addressing Architecture Specification provides the destination address
   scope that can be used in the an IPv6 Header.

   When implementation, and the relay-agent receives various
   configuration architecture guidelines for network designers of the remote servers response, it MUST
   forward 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 packet to nodes environment.  This means that a host immediately can configure
   an IPv6 address at initialization for an interface, before communicating in
   any manner on the client, by using link.  The host can then use a well-known multicast address
   to begin communications to discover neighbors on the client-link-address link, or as was
   discussed in 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 specification to locate a client request, DHCPv6 server
   response, and then client confirmation or rejection. relay-agent.

   The server will
   set state or remove state IPv6 Stateless Address Autoconfiguration Specification (addrconf)
   defines how a host can autoconfigure addresses based on this model.  There is always neighbor discovery
   router advertisements, and the
   possibility use of a validation lifetime to support
   renumbering of addresses on the classic transactional error when Internet. In addition the client-to-
   server response is not received by addrconf
   specification defines the server, protocol interaction for a host to begin stateless
   or stateful autoconfiguration.  DHCPv6 is one vehicle to perform stateful
   autoconfiguration.  Compatibility with addrconf is a design goal of DHCPv6
   where possible.

   IPv6 Neighbor Discovery (ND) is the client assumes
   the server received the response node discovery protocol in IPv6
   (replaces and enhances functions of IPv4 ARP Model).  To truly
   understand IPv6 and addrconf it did not (see is strongly recommended that
   implementors understand IPv6 ND.

   Dynamic Updates to DNS is a specification that supports the draft).

      This can be greatly alleviated by using TCP instead
   dynamic update of UDP DNS records for both IPv4 and IPv6.  DHCPv6 can use
   the
      transaction.  This would have great benefits such as:

         1.  Guranteed virtual link, hence if the dynamic updates to DNS to now integrate addresses and name space to
   not only support autoconfiguration, but also autoregistration in IPv6.

Change History

   Changes from July 95 to November 95 Drafts:

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

      Permit multiple addresses and lifetimes in a request and response.

      Moved Dynamic Updates to DNS as an Option to be defined in that
      specification.

      Settled on using UDP as it supports DHCP client know immediately upon return server model as opposed
      to the
         application.

         2.  PATH MTU Discovery for TCP is inherent in an implementation
         and the DHCPv6 application does not have to adjust which has overhead for IPv6
         fragmentation this model.

   We can also use UDP

      Reformatted specification to locate servers support analysis, packet formats, and TCP for the transaction.

   2.  Dynamic Updates
      processing in their own sections to DNS need careful review make it easier for clarity and what implementors to
      read.

      Removed address count as it is required not necessary for just host name processing in DHCPv6.

   3.  We need synchronization.

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

      Made transaction-ID 2 octets.

      Updated terminology to determine the integration required coordinate with IPv6 Stateless Address Configuration when both stateless and statefull is being used
   by a client host.

   4.  In the Design Goals section should the MUSTs, SHOULDs, etc be
   capitalized and REQUIRED?  Its not
      Autoconfiguration.

      Added more implementation notes.

      Moved IPv6 Related Work to an Appendix.

      Fixed various bugs in DHCPv4?

   5.  Charlie Perkins the spec from DHC WG input.

      Added Security reference pointers.

      Removed options format, which will be doing our option spec for DHCPv6. We need
   to make sure it synchs up with this in the options spec.

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

Change History

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

   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

      Redefined transaction-ID and interface-token.

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

      Added more terminology, definitions, and rationale.

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

      Reduced the request/response model to 3 packets by not doing
      a server confirm to a clients confirm to a servers response.

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

      Added model and processing definitions for future DHCPv6 Options
      Specification.

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

      Removed excessive use of the acroynym acronym DHCPv6 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-02.txt             July 1995

Acknowledgements

   The DHC Working Group for their time and input into the specification.
   A special thanks for the consistent input, ideas, and review by (in
   alphabetical order) Brian Carpenter, Ralph Droms, Thomas Narten, Jack
   Mccann, and Charlie
   Perkins.   A big warm and extended thanks to Perkins, Yakov Rekhter, Matt Thomas, Sue Thomson, Yakov
   Rehkter, and
   Phil Wells, who spent many hours in person and on the
   phone with the author to get the work done.

   Sue Thomson and Yakov Rehkter were co-authors on the first
   specification, and with the author have since March 1994 kept a
   consistent view and belief that autoregistration MUST be part of the
   Next Generation Internet Protocol version 6 and integrated into
   autoconfiguration. Wells.

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

   The author MUST also thank his employer for the opportunity and funding
   to work on DHCPv6 and IPv6 in general. general as an individual in the IETF.

References

   [DHCPv6-OPT]
       C. Perkins, "Options for the Dynamic Host Configuration
       Protocol for IPv6 (ODHCPv6)" Internet Draft, November 1995
       <draft TBD>

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

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

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

   [IPv6-ND]
       T. Narten, E. Nordmark, and W. A. Simpson, "IPv6 Neighbor Discovery"
       <draft-ietf-ipngwg-discovery-00.txt>
       <draft-ietf-ipngwg-discovery-02.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-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>

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

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

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

   [IPv6-SA]
       R. Atkinson, "Security Architecture for the Internet Protocol"
       RFC 1825, August 1995

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

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

Authors' Addresses Address

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