[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 RFC 3315

INTERNET-DRAFT                                                  J. Bound
DHC Working Group                                 Digital Equipment Corp
March 1995                                                    Y. Rekhter
                                    T.J. Watson Research Center IBM Corp
                                                             Sue Thomson
                                                                Bellcore



             Dynamic Host Configuration Protocol for IPv6

                      draft-ietf-dhc-dhcpv6-01.txt


Status of this Memo

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

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

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

   Discussion for this draft will take place on host-
   conf@sol.cs.bucknell.edu.

Abstract

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



















Expires September 1995                                          [Page 1]


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


Table of Contents:

1.  Introduction................................................3
2.  Terminology.................................................3
3.  DHCPv6 Protocol Design Model................................4
3.1 DHCPv6 Protocol Request/Response Model......................4
3.2 DHCPv6 Leased Address Model.................................4
3.3 DHCPv6 DNS Host Name Autoregistration Model.................5
3.4 DHCPv6 Client/Server Model..................................5
4.  DHCPv6 Protocol Format......................................7
5.  DHCPv6 Client/Server Processing.............................9
5.1 DHCPv6 Client Transmission..................................9
5.2 DHCPv6 Server Transmission..................................9
5.3 DHCPv6 Client Requests......................................9
5.4 DHCPv6 Client Responses....................................10
5.5 DHCPv6 Server Responses....................................11
5.6 DHCPv6 Server Lease Expiration.............................13
6.  DHCPv6 Relay-Agent Processing..............................13
Acknowledgements...............................................15
References.....................................................15
Authors' Addresses.............................................16







































Expires September 1995                                          [Page 2]


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


1.  Introduction

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

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

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


2.  Terminology

   Configuration Data: Configuration Data is information a Host can use
   to configure a Host on a network so that the Host can interoperate
   with other Hosts on a network.

   DHCPv6 Client: A DHCPv6 Client is a Host that initiates requests on a
   network to obtain Configuration Data from a DHCPv6 server.

   DHCPv6 Server: A DHCPv6 Server is a Host that responds to requests
   from DHCPv6 clients to provide Configuration Data.

   DHCPv6 Relay-Agent: A DHCPv6 Relay-Agent is a DHCPv6 Server that
   listens on the network for DHCPv6 Clients requesting Configuration
   Data, and then relays the request to a DHCPv6 Server and the reply
   back to the DHCPv6 Client.

   Transaction ID - This is used to uniquely identify a set of DHCPv6
   request/response messages between DHCPv6 Servers and Clients.  The
   Transaction ID is generated by the DHCPv6 Client requests.

   Interface-Token: An Interface Token is used to uniquely identify a
   DHCPv6 Client network interface.

   Lease: This is the address lifetime for a single address provided to
   a DHCPv6 Client.

   Expired Lease: An Expired Lease is one where the Lease duration of an
   address has ended or because it has been mandated by a DHCPv6 Server
   to a DHCPv6 Client.










Expires September 1995                                          [Page 3]


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


3.  DHCPv6 Protocol Design Model



3.1 DHCPv6 Protocol Request/Response Model

   DHCPv6 uses a message type to define whether the packet orginated
   from a DHCPv6 Server or Client, and a request message code to define
   the operation requested, and a message response to define either a
   response to a request or a confirmation/rejection to a response.

   The request/response model is as follows:

     1.  Request (Client)
     2.  Response with configuration data (Server).
     3.  Confirmation Response with accept or reject (Client).
     4.  Confirmation Response for accept (Server).

   The time out period for a DHCPv6 Host to wait for a response is
   implementation defined. When a DHCPv6 Host times out waiting for a
   response to a packet sent, the Host should not commit any state based
   on the content of the packet sent.  It is implementation defined if
   the packet is retransmitted.

   A DHCPv6 packet will only contain one address and one name, depending
   on the message type, request, and response codes in a packet.
   Because IPv6 supports multiple addresses per interface the DHCPv6
   Server may also inform the DHCPv6 Client that there are multiple
   addresses available for its use.  This may be conveyed to the DHCPv6
   Client in the Number of Address Fields provided in a response packet
   by the DHCPv6 Server.

   Multiple addresses and names may be specified as an extended
   configuration option [IPv6-DHCP-OPTIONS].  A design objective of
   DHCPv6 is to avoid fragmentation in IPv6, when possible.  If the
   DHCPv6 packet exceeds 576 octets then UDP must perform Path MTU
   Discovery [PMTU]. The support of multiple names and addresses can be
   a configuration option in DHCPv6.

   If the DHCPv6 Host cannot match up any of the specified parameters,
   as discussed in section 5 DHCPv6 Client/Server Processing, in this
   protocol specification the packet should be silently discarded.



3.2 DHCPv6 Leased Address Model

   A DHCPv6 address returned to a DHCPv6 Client has a Lease time. A
   design objective of DHCPv6 is to support Dynamic Readdressing.  To
   accomplish this objective, addresses must be able to be reclaimed by
   a network site.  Hence, all addresses must be Leased in DHCPv6.

   The DHCPv6 Client has the responsibility to renew a Lease for an
   address that is about to expire or request a new address with a Lease
   time.

   In the case where it is necessary to Expire a Lease because of a
   mandate in an organizations site, the DHCPv6 Server may send a Lease


Expires September 1995                                          [Page 4]


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


   Expired message with a grace period to a DHCPv6 Client.  This will be
   an asynchronous operation by the DHCPv6 Server to the DHCPv6 Client,
   and the only case where the DHCPv6 request/response model is not used
   in the protocol.

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


3.3 DHCPv6 DNS Host Name Autoregistration Model

   DHCPv6 supports the autoregistration of DNS Host names and providing
   DNS Host Names with addresses for DHCPv6 Clients.  Autoregistration
   is supported by fields in DHCPv6, which the DHCPv6 Client may provide
   to the DHCPv6 Server in a request.  In addition a DHCPv6 Server may
   provide a DNS Host Name with an IPv6 address to a DHCPv6 Client in a
   response.

   DHCPv6 only specifies the parameters and action to be taken, and not
   the actual protocol or primitives to interact with DNS.  The
   functions that the DHCPv6 Server uses to interact with the DNS to
   provide autoregistration is defined in Dynamic Updates to DNS [IPv6-
   DYN-UPD].

   This is not a Fully Qualified Domain Name (FQDN) but only the local-
   part label and then only the Host Name [RFC-1034&1035].  It is
   assumed the DHCPv6 Server implementation knows or can determine what
   the domain name part is for any IPv6 subnet prefix for which it is
   providing an address.  If a DHCPv6 Client wants to know its domain
   name then it will have to request this as specified in the DHCPv6
   Options Specification [IPv6-DHCP-OPTIONS].


3.4 DHCPv6 Client/Server Model

   DHCPv6 supports a Transaction ID to uniquely identify a set of
   request/response messages between DHCPv6 Clients and Servers.

   DHCPv6 supports an Interface Token to uniquely identify a network
   interface on a DHCPv6 Client.

   DHCPv6 can support an extensible set of options as defined by a
   Configuration Type.  These options are specified in a DHCPv6 Options
   specification [IPv6-DHCP-OPTIONS].

   The DHCPv6 Options provide a Configuration Type which defines the
   option requested and then returned.  A Next Type field is provided
   which can be used by an application to know if there is more than one
   option.  If the Next Type field is NULL then this is the last option
   present.  The Length field provides the length of the data present
   for that option.  The Variable Configuration Data is the data to
   provide that option.

   DHCPv6 does not specify whether the DHCPv6 Server Configuration Data
   provided to DHCPv6 Clients is synchronous across the sites network
   information database (e.g. DNS), whether the DHCPv6 Server


Expires September 1995                                          [Page 5]


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


   Configuration Data is duplicated across DHCPv6 Servers, or how the
   DHCPv6 Configuration Data is pre-configured on a DHCPv6 Server.

   DHCPv6 does not specify conditions or results when multiple DHCPv6
   Servers are located on an IPv6 subnet.  The DHCPv6 Client may respond
   to DHCPv6 Servers it does not want to communicate with by sending a
   REJECT_PACKET confirmation response to a DHCPv6 Server.

   DHCPv6 does not specify a DHCPv6 Server-to-Server protocol.



















































Expires September 1995                                          [Page 6]


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


4.  DHCPv6 Protocol Format


                           DHCPv6 Data Packet

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Msg Type      |             Msg Request                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                Msg Response                   | Addrs Avail   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Transaction ID                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Lease Time                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Interface Token                           |
     |                       (8 Octets)                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       IPv6 Address                            |
     |                        (16 Octets)                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Host Name                             |
     |                        (64 Octets)                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Server IPv6 Address                       |
     |                        (16 Octets)                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Config Type  |   Next Type   |  Length                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           Variable Configuration Data                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In the field definitions below bit position 0 is the high-order bit in
the sequence of Octets for each field.

  Msg Type : 1 Octet
    The field defines the operation to be performed by the packet.

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

  Msg Request : 3 Octets

      Bit 0  = ON: ADDRESS_REQUEST
      Bit 1  = ON: NAME_REQUEST
      Bit 2  = ON: CONFIG_REQUEST
      Bit 3  = ON: ADDRESS_SUPPLIED
      Bit 4  = ON: LEASE_EXPIRED
      Bit 5-24 RESERVED











Expires September 1995                                          [Page 7]


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


  Msg Response : 3 Octets
      Bit 0  = ON: ADDRESS_RETURNED
      Bit 1  = ON: ADDRESS_ACCEPTED
      Bit 2  = ON: ADDRESS_REJECTED
      Bit 3  = ON: NAME_ACCEPTED
      Bit 4  = ON: NAME_RETURNED
      Bit 5  = ON: NAME_REJECTED
      Bit 6  = ON: SERVER_ADDRESS
      Bit 7  = ON: CONFIG_ACCEPTED
      Bit 8  = ON: CONFIG_RETURNED
      Bit 9  = ON: CONFIG_REJECTED
      Bit 10 = ON: LEASE_ACCEPTED
      Bit 11 = ON: LEASE_REJECTED
      Bit 12 = ON: CONFIRM_PACKET
      Bit 13 = ON: REJECT_PACKET
      Bit 14-24 RESERVED

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

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

  Lease Time : 4 Octets
    This field is used to provide a Lease time for an address and a
    renewal time period for an address that is being reclaimed.
    Integer Number.  Absolute time in seconds.

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

  IPv6 Address : 16 Octets
    DHCPv6 Client IPv6 Address.

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

  Server IPv6 Address : 16 Octets
    DHCPv6 Server IPv6 Address.

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

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

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


Expires September 1995                                          [Page 8]


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


  Variable Configuration Data : 452 Octets
    This is a variable length field where configuration data will be
    supplied as options for DHCPv6 protocol.

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


5.  DHCPv6 Client/Server Processing



5.1 DHCPv6 Client Transmission

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

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

   If the DHCPv6 Client knows the address of a DHCPv6 Server it will put
   that address in the destination field of the IPv6 Header.  Otherwise
   a well known IPv6 multicast address using intra-link scope [IPv6-
   ADDR] is used as the destination address field in the IPv6 Header
   [This multicast address will have to be supplied by IANA for DHCPv6].


5.2 DHCPv6 Server Transmission

   The DHCPv6 Server will set Server Msg Type ON to transmit to DHCPv6
   Clients.  UDP DHCPv6 Client Port (TBD) must be used to build the
   sending packet in an implementation.  A DHCPv6 Server may provide
   multiple responses to a DHCPv6 Client in one packet.

   The DHCPv6 Server will use the source address of the IPv6 Header from
   the DHCPv6 Client as the destination address in the DHCPv6 Server
   IPv6 Header address.  The DHCPv6 Server IPv6 Header source addresses
   will be the IPv6 address of the DHCPv6 Server responding.


5.3 DHCPv6 Client Requests

   Msg Request field:

     If ADDRESS_REQUEST is set, then a request is being made for an IPv6
     address and Lease. If the Lease field does not equal zero then the
     DHCPv6 Client is supplying a Lease time to the DHCPv6 Server. The DHCPv6
     Client may also set ADDRESS_SUPPLIED and provide an IPv6 address to the
     DHCPv6 Server for verification.



Expires September 1995                                          [Page 9]


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


     A DHCPv6 Client must send an ADDRESS_REQUEST to the DHCPv6 Server
     to renew its Lease before it expires.  The DHCPv6 Client may request
     that the same address be used again by providing an IPv6 address and
     having ADDRESS_SUPPLIED set in the request.  If the DHCPv6 Clients
     Lease on an address expires, then the DHCPv6 Server will expire the
     Lease for that address.

     If NAME_REQUEST is set, then a request is being made for a DNS Host Name.
     supplied by the DHCPv6 Client.

     If CONFIG_REQUEST is set, then a request is being made for an IPv6
     Configuration Data return from the DHCPv6 Server.


   Msg Response field: must be NULL.

   Addrs Avail field: must be NULL.

   Transaction ID field: must contain a random number generated Integer
   determined by the DHCPv6 Client for this request packet.

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

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

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

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

   Server IPv6 Address field: must be NULL.

   Configuration Type field: must contain a valid Configuration Type as
   defined in the DHCPv6 Options specification [IPv6-DHCP-OPTIONS], if
   CONFIG_REQUEST is set, otherwise the Configuration fields are not
   present in the packet.

   Configuration Next Type field: If CONFIG_REQUEST set, and there is
   more than one, then the value of the next configuration type should
   be put into this field, otherwise NULL.

   Configuration Data Length field: NULL.

   Variable Configuration Data field: Not present in the packet.


5.4 DHCPv6 Client Responses

   The Transaction ID from the DHCPv6 Server response must match one of
   the DHCPv6 Clients Transaction IDs from a previous request.

   Msg Request field: must be NULL.

   Msg Response field:


Expires September 1995                                         [Page 10]


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


     If ADDRESS_ACCEPTED is set, the DHCPv6 Client is informing the DHCPv6
     Server that it has received the address returned.

     If CONFIG_ACCEPTED is set, the DHCPv6 Client is informing the DHCPv6
     Server that it has received the Configuration Data returned.

     If NAME_ACCEPT is set, the DHCPv6 Client is informing the DHCPv6
     Server that it received the NAME_RETURNED returned, when the DHCPv6
     Client supplied a Host Name with NAME_REQUEST set.

     If REJECT_PACKET is set, the DHCPv6 Client is rejecting a response
     from a DHCPv6 Server.

   Addrs Avail field: must be NULL.

   Transaction ID field: must contain a random number generated Integer
   matching the DHCPv6 Server request or response.

   Lease Time field: must be NULL.

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

   IPv6 Address field: must be NULL.

   Host Name field: must be NULL.

   Server IPv6 Address field: must be NULL.

   Configuration Data Fields not present in the packet.


5.5 DHCPv6 Server Responses

   The Transaction ID from a DHCPv6 Servers response must match one of
   the DHCPv6 Clients Transaction IDs from a previous request.

   Msg Request field: must be NULL.

   Msg Response field:

     If ADDRESS_RETURNED is set, the DHCPv6 Server is providing the DHCPv6
     Client with an IPv6 Address.

     If ADDRESS_ACCEPTED is set, the DHCPv6 Server has accepted the address
     supplied by the DHCPv6 Client.

     If ADDRESS_REJECTED is set, the DHCPv6 Server is not accepting the
     address provided by the DHCPv6 Client.

     Only one of the above settings must be present in a response to a DHCPv6
     Client request.  The IPv6 address provided will either be the one
     presented by the DHCPv6 Client or an address provided by the DHCPv6
     Server when ADDRESS_RETURNED is set.

     If NAME_RETURNED is set, the DHCPv6 Server is providing a Host Name with
     the address returned to the DHCPv6 Client either in response to a DHCPv6


Expires September 1995                                         [Page 11]


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


     Client NAME_REQUEST or because it is implementation defined to provide
     Host Names with ADDRESS_RETURNED set.

     If NAME_REJECTED is set, the DHCPv6 Server is informing the DHCPv6
     Client that the NAME_REQUEST was rejected by DNS. The DHCPv6 Server
     must also supply an address in the IPv6 Address field.

     If CONFIG_RETURNED is set, the DHCPv6 Server is providing the
     Configuration Data requested.

     If CONFIG_REJECTED is set, the DHCPv6 Server is informing the DHCPv6
     Client that the Configuration Data requested is not supported.

     If LEASE_ACCEPTED is set, the DHCPv6 Server is informing the DHCPv6
     Client that the Lease presented has been accepted.  The Lease Time field
     will contain the Lease requested by the DHCPv6 Client.

     If LEASE_REJECTED is set, the DHCPv6 Server is rejecting the Lease Time
     provided by the DHCPv6 Client and will return a Lease time specified
     by the DHCPv6 Server.

     If SERVER_ADDRESS is set, the DHCPv6 Server is returning its address
     in the response.  The DHCPv6 Server will do this when the destination
     address in the IPv6 Header is an intra-link Multicast address, or has
     a network prefix subnet value for which the DHCPv6 Server is
     not a member.

     If CONFIRM_PACKET is set, the DHCPv6 Server is informing the DHCPv6
     Client it has received a response to the DHCPv6 Server response to the
     DHCPv6 Clients initial request.  This will be the only msg response
     code set by the DHCPv6 Server in this response.

   Addrs Avail field: If ADDRESS_RETURNED is set, the DHCPv6 Server is
   informing the DHCPv6 Client that it has an integer number of
   addresses available for the DHCPv6 Client less the address being
   provided.  When the DHCPv6 Client responds to this response with
   ADDRESS_ACCEPTED the DHCPv6 Server must decrement the number of
   addresses available for the DHCPv6 Client.  If ADDRESS_ACCEPTED is
   set, the DHCPv6 Server is informing the DHCPv6 Client that it has a
   number of addresses available that can be used by the DHCPv6 Client.
   Otherwise the Addrs Avail field is NULL.

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

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

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

   IPv6 Address field: must contain an IPv6 Address.

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

   Server IPv6 Address field: must contain an IPv6 address if


Expires September 1995                                         [Page 12]


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


   SERVER_ADDRESS is set, otherwise NULL.

   Configuration Type field: must contain a valid Configuration Type as
   defined in the DHCPv6 Options [IPv6-DHCP-OPTIONS] if CONFIG_RETURN or
   CONFIG_REJECTED is set, otherwise the Configuration fields are not
   present in the packet.

   Configuration Next Type field: If CONFIG_RETURNED or CONFIG_REJECTED
   is set, and if there is more than one Congfiguration Type present,
   the value of the next configuration type should be put into this
   field, otherwise NULL.

   Configuration Data Length field: If CONFIG_RETURNED is set, then this
   is the length of the Configuration Data present.  If CONFIG_REJECTED
   is set, then the DHCPv6 Server will set length to zero.

   Variable Configuration Data field: Contains Configuration Data only
   if CONFIG_RETURNED is set, otherwise there is no Configuration Data
   present in the packet.


5.6 DHCPv6 Server Lease Expiration

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

   Msg Request field:

     LEASE_EXPIRED is set.

   Msg Response field: must be NULL.

   Addrs Avail field: must be NULL.

   Transaction ID field: NULL.

   Lease Time field: must contain a grace period for the DHCPv6 Client
   to renew a lease for an address.

   Interface Token field: must contain a random number generated Integer
   for the DHCPv6 Client IPv6 address.

   IPv6 Address field: must contain an IPv6 Address being used for an
   Interface Token by a DHCPv6 Client.

   Host Name field: must be NULL.

   IPv6 Server Address field: must be NULL.

   Configuration fields: not present in the packet.


6.  DHCPv6 Relay-Agent Processing

   When a DHCPv6 Relay-Agent hears a request from a DHCPv6 Client it
   should forward that request to a DHCPv6 Server as a DHCPv6 Client Msg
   Type.


Expires September 1995                                         [Page 13]


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


   The DHCPv6 Relay-Agent upon receiving a response from the DHCPv6
   Server should forward that response to the DHCPv6 Client.

   When the DHCPv6 Relay-Agent forwards the request to the DHCPv6 Server
   it puts the DHCPv6 Relay-Agent's IPv6 address in the source field of
   the IPv6 Header.






















































Expires September 1995                                         [Page 14]


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


Acknowledgements

Brian Carpenter, Alex Conta, Jack McCann, Ralph Droms for providing
input to the evolution of DHCPv6.



References

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

       Y. Rekhter, "An IPv6 Global Unicast Address Format"
       Internet Draft, March 1995
       <draft-ietf-ipngwg-address-format-01.txt>

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

   [IPv6-ICMP]
       A. Conta, S. Deering "ICMPv6 for the Internet Protocol
       Version 6 [IPv6]" Internet Draft, March 1995
       <draft-ietf-ipngwg-icmp-02.txt>

   [PMTU]
       J. Mogul, S. Deering "Path MTU Discovery"
       RFC 1191, 11/16/90

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

       W. A. Simpson "IPv6 Neighbor Discovery - Processing"
       Internet Draft, November 1994
       <draft-simpson-ipv6-discov-process-01.txt>

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

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

   [DYN-DNS-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>








Expires September 1995                                         [Page 15]


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


   [IPv6-DHCP-OPTIONS]
       <TBD>

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


Authors' Addresses

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

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

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






























Expires September 1995                                         [Page 16]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/