Internet Engineering Task Force                               C. Perkins
INTERNET DRAFT                                          Sun Microsystems
                                                        27 February
                                                             26 May 1997

                         Extensions for DHCPv6
                      draft-ietf-dhc-v6exts-05.txt
                      draft-ietf-dhc-v6exts-06.txt

Status of This Memo

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

   Distribution of this memo is unlimited.

   This document is an Internet-Draft.  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 Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), (North
   Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim),
   ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).

Abstract

   The Dynamic Host Configuration Protocol for IPv6 [3] [4] (DHCPv6)
   provides a framework for passing configuration information to hosts
   on a TCP/IP network.  Configuration parameters and other control
   information are carried in typed data items that are stored in the
   "extensions" field of the DHCPv6 message.  The data items themselves
   are also called "extensions."

   This document specifies the current set of DHCPv6 extensions.  This
   document will be periodically updated as new extensions are defined.
   Each superseding document will include the entire current list of
   valid extensions.

                                Contents

Status of This Memo                                                    i

Abstract                                                               i

 1. Introduction                                                       1

 2. DHCPv6 Extension Field Format                                      2
     2.1. Character Encoding and String Issues  . . . . . . . . . .    2

 3. Padding and End extension specifications                           3
     3.1. Pad Extension . . . . . . . . . . . . . . . . . . . . . .    3
     3.2. End Extension . . . . . . . . . . . . . . . . . . . . . .    3

 4. IPv6 Address Extension                                             3
     4.1.
     3.1. Client Considerations for the IPv6 Address extension  . .    6
           4.1.1.    5
           3.1.1. Address Lifetimes . . . . . . . . . . . . . . . .    6
           4.1.2.    5
           3.1.2. Use with the DHCP Request message . . . . . . . .    6
           4.1.3.
           3.1.3. Receiving as part of the DHCP Reply message . . .    7
           4.1.4.
           3.1.4. Use with the DHCP Release message . . . . . . . .    7
     4.2.
     3.2. Server Considerations for the IPv6 Address extension  . .    8
           4.2.1.    7
           3.2.1. Use with the DHCP Advertise message . . . . . . .    8
           4.2.2.    7
           3.2.2. Receiving a DHCP Request with the IPv6 Address
                          Extension  . . . . . . . . . . . . . . . .   8
           4.2.3.
           3.2.3. Use with the DHCP Reply message . . . . . . . . .    8
           4.2.4.
           3.2.4. Use with the DHCP Reconfigure message . . . . . .    9
     4.3.
           3.2.5. Receiving a DHCP Release with the IPv6 Address
                          Extension  . . . . . . . . . . . . . . . .   9
     3.3. DHCP Relay Considerations . . . . . . . . . . . . . . . .    9

 5.

 4. General Extensions                                                 9
     5.1.
     4.1. Time Offset . . . . . . . . . . . . . . . . . . . . . . .   10
     5.2.
     4.2. Domain Name Server Extension  . . . . . . . . . . . . . .   10
     5.3.
     4.3. Domain Name . . . . . . . . . . . . . . . . . . . . . . .   11

 6.

 5. Service Location Extensions                                       11
     6.1.

 6. Directory Agent Extension . . . . . . . . . . . . . . . .   11
     6.2.                                         12

 7. Service Scope Extension . . . . . . . . . . . . . . . . .   12

 7.                                           13

 8. IP Layer Parameters per Interface                                 13
     7.1.                                 14
     8.1. Static Route Extension  . . . . . . . . . . . . . . . . .   13

 8.   14

 9. TCP Parameters                                                    14
     8.1.                                                    15
     9.1. TCP Keepalive Interval Extension  . . . . . . . . . . . .   14
 9.   15

10. Vendor Specific Information                                       14

10.                                       15

11. DHCPv6 Extensions                                                 16
    10.1.
    11.1. Maximum DHCPv6 Message Size Extension . . . . . . . . . .   16
    10.2.
    11.2. Class Identifier  . . . . . . . . . . . . . . . . . . . .   16
    10.3.   17
    11.3. Reconfigure Multicast Address . . . . . . . . . . . . . .   17
    10.4.
    11.4. Renumber DHCPv6 Server Address  . . . . . . . . . . . . .   17
    10.5.   18
    11.5. Client-Server Authentication Extension  . . . . . . . . .   18

11.   19
    11.6. Client Key Selection Extension  . . . . . . . . . . . . .   20

12. End extension specification                                       20

13. Security Considerations                                           19
    11.1.                                           20
    13.1. Replay Protection . . . . . . . . . . . . . . . . . . . .   19
    11.2.   21
    13.2. Default Authentication Algorithm  . . . . . . . . . . . .   19

12.   21

14. Defining New Extensions                                                    20

13.                                           21

15. Acknowledgements                                                  20                                                  23

Chair's Address                                                       22                                                       25

Author's Address                                                      22                                                      25

1. Introduction

   This document specifies extensions for use with the Dynamic
   Host Configuration Protocol for IP version 6, DHVPv6.  The full
   description of DHCPv6 message formats may be found in the DHCPv6
   specification document [3]. [4].  In this document, several words are used
   to signify the requirements of the specification, in accordance with
   RFC 2119 [5].  These words (MUST, SHOULD, MAY, MUST NOT, etc) are
   often capitalized.

   This document defines the format of information in the last field
   of DHCPv6 messages ('extensions').  The extensions defined within
   this document specify a generalized use of this area for giving
   information useful to a wide class of machines, operating systems
   and configurations.  Sites with a single DHCPv6 server that is
   shared among heterogeneous clients may choose to define other, site-
   specific formats for the use of the 'extensions' field.

   Section 2 of this memo describes the formats of DHCPv6 extensions.
   Information on registering new extensions is contained in section 12. 14.
   The other sections organize the format descriptions of various
   extensions according to their general type, as follows:

    -  IP Address extension

    -  Miscellaneous host configuration

    -  Service Location configuration

    -  Miscellaneous network layer

    -  TCP

    -  Vendor Specific

    -  DHCPv6

   Future applications will make extensive use of an ever-increasing
   number and variety of network services.  It is expected that client
   needs for creating connections with these future network services
   will be satisfied by the Service Location Protocol [12], [15], and not
   DHCPv6.  DHCP is expected to be used for the kinds of configuration
   that enable clients to become fully functional as self-contained
   network entities, but not the kinds of configuration that might be
   required by applications running above the network or transport layer
   protocol levels.

2. DHCPv6 Extension Field Format

   DHCPv6 extensions have the same format as the BOOTP "vendor
   extensions" defined in RFC 1497 [9]. [2].  Extensions may be fixed length or variable length.
   All extensions except for the pad extension begin with a type field which is two octets long,
   which uniquely identifies the extension.  Fixed length extensions
   without data consist of only the two octet type field.  Only extensions 0 and
   extension 65535 are is fixed length.  All other extensions are variable
   length with a two octet length field following the type octets.  The
   value of the length octets field does not include the two octets specifying
   the type and length.  The length octet field is followed by "length" octets
   of data.  In the case of some variable length extensions the length
   field is a constant but must MUST still be specified.

   Any extensions defined subsequent to this document should contain a
   length field of two octets in length even if the length is fixed or
   zero.  Unknown options MAY be skipped by ignoring the number of bytes
   specified in the length octets. field.  All multi-octet quantities are in
   network byte-order.

   Extension types 32768 to 65534 (decimal) are reserved for
   site-specific extensions.

   All of the extensions described in this document will also have their
   default values specified, if any.

2.1. Character Encoding and String Issues

   Values for character encoding can be found in the Internet Assigned
   Numbers Authority's (IANA) database
         http://www.isi.edu/in-notes/iana/assignments/character-sets
   and have the values referred by the MIBEnum value.

   The encoding will determine the interpretation of all character data  Note that in some
   character sets, each character may require two or more octets of data
   for its representation.

   The encoding will determine the interpretation of all character data
   in the corresponding fields of particular extensions.  There is no
   way to mix ASCII and UNICODE, for example.  All responses must MUST be in
   the character set of the request or use US-ASCII. If a request is
   sent to a DHCP server, which is unable to manipulate or store the
   character set of the incoming message, the request will fail.  The
   server returns a CHARSET_NOT_UNDERSTOOD error (24) in a DHCP Reply
   message in this case.  Requests using US-ASCII (MIBEnum value == 3)
   will never fail for this reason, since all DHCP entities must MUST be able
   to accept this character set.  All DNS-related strings are presumed
   to be encoded in US-ASCII.

3. Padding and End extension specifications

3.1. Pad Extension

   The pad extension can be used to cause subsequent fields to align on
   word boundaries.

   The Type for the pad extension is 0, and its length is 1 octet.

    Type
   +-----+
   |  0  |
   +-----+

3.2. End Extension

   The end extension marks the end of valid information in the vendor
   field.  Subsequent octets should be filled with pad extensions.

   The Type for the end extension is 65535, and its length is 2 octets.

        Type
   +-----+-----+
   |   65535   |
   +-----+-----+

4. IPv6 Address Extension

   The IPv6 Address extension is the most essential of all the DHCPv6
   extensions.  It can be used by both client and server in various
   ways.  Since the IPv6 Address option can be used more than once in
   the same DHCP message, all information relevant to a particular IPv6
   allocation has to be collected together in the same extension.  Some
   of the fields within the IPv6 Address extension can specify how
   DNS [13] [16] may be updated.

   An IPv6 Address Extension can contain at most one IPv6 address.  To
   specify more than one IPv6 address, multiple extensions are used.  To
   ask for an IPv6 address in a DHCP Request message, a client includes
   an IPv6 Address Extension.  To renew or extend the lifetime of a
   particular IPv6 address, the client puts that address in the client
   address field.  To request the allocation of a new but unspecified
   IPv6 address, the client omits the client address field.  The IPv6
   address returned by the server in the latter case will be compatible
   with a subnet prefix of the link to which the client is currently
   attached.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   pfx-size    |  error-code   |C|L|Q|A|P|      reserved       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         (if present)                          |
   |                    client address (16 octets)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          (if present) preferred lifetime (4 octets)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            (if present) valid lifetime (4 octets)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         (if present) DNS name (variable length)  ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type     1

      Length   (variable) The length of the Extension.

      pfx-size
               If the client address is present (the 'C' bit is set),
               a nonzero pfx-size indicates the length of the routing
               prefix, counting the number of leading 1 bits to be
               applied to the client's IPv6 address to get the routing
               prefix.  Otherwise, if the 'C' bit is not set, pfx-size
               MUST be zero.

      error-code
               If the server is unable to honor the client's request,
               the reason is indicated in the error-code.  Current
               values are as follows:

                    0   request granted, no errors
                   16   dynDNS Not Available at this time
                   17   dynDNS Not Implemented
                   18   Authentication failed for this client
                   19   Authoritative DNS Server could not be found
                   20   Resource AAAA Record Parameter Problem
                   21   Resource PTR Record Parameter Problem
                   22   Unable to honor required extension parameters
                   23   DNS name string error

      C        If the 'C' bit is set, the field containing the IPv6
               address for the client is present in the extension.

      L        If the 'L' bit is set, the preferred and valid lifetimes
               are present in the extension.

      Q        If the 'Q' bit is set, the fields included by the client
               are required, and must be made available by the server or
               else the extension must be rejected.

      A        If the 'A' bit is set, the server MUST ensure client requests that that
               the the server updates DNS is updated with a new AAAA record, as
               specified by the client's FQDN, before responding with the
               corresponding DHCP Reply. FQDN.

      P        If the 'P' bit is set, the server MUST ensure client requests that that
               the the server updates DNS is updated with a new PTR record, as
               specified by the client's FQDN, before responding with the corresponding
               DHCP Reply. FQDN.

      reserved MUST be zero.

      client address
               The IPv6 address to be allocated by the server for use by
               the client (16 octets long).

      preferred lifetime
               The preferred lifetime of the IPv6 address in seconds

      valid lifetime
               The valid lifetime of the IPv6 address in seconds
      DNS name
               The DNS name (a zero-terminated string of ASCII octets)
               to be used by the client (variable length).

   The DNS name can be a host name, which does not contain the '.'
   ASCII character as a separator between DNS hierarchy components.  Any
   name containing the '.'  is treated as a Fully Qualified Domain Name
   (FQDN). The length of the DNS name may be determined by subtracting,
   from the Length, the length of those fixed length fields which are
   present.  If the last byte of the DNS name is not zero, the IPv6
   Address Extension MUST be rejected, with error code 23.

4.1. Client Considerations for

   If the IPv6 Address extension

4.1.1. Address Lifetimes

   An IPv6 address returned to a client has a preferred 'Q' bit is set, and valid
   lifetime.  The lifetimes represent if the lease for addresses provided
   to 'A' bit is set, the client, from server MUST
   ensure that the DNS is updated with a new AAAA record, as specified
   by the client's FQDN, before responding with the corresponding DHCP
   Reply.  Likewise, if the 'Q' bit is set, and if the 'P' bit is
   set, the server MUST ensure that the DNS is updated with a new PTR
   record, as specified by the client's FQDN, before responding with the
   corresponding DHCP Reply.

3.1. Client Considerations for the IPv6 Address extension

3.1.1. Address Lifetimes

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

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

   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 the preferred lifetime of an IPv6 address expires, the client's
   address becomes a deprecated address.  See [4] [7] for required handling
   of deprecated IPv6 addresses.  When an address for a DHCPv6 client's
   interface becomes deprecated, the processing of the lifetime client SHOULD request a new address
   for that interface, or make a new DHCP Request for the existing
   address (which can result in the address receiving an updated
   preferred lifetime).

   When the client requests an IPv6 address from the DHCPv6 server, the
   client MUST keep track of when the request was issued.  When the
   client receives a successful reply from the DHCPv6 server, it MUST
   decrement the received Lifetimes by the amount of time between the
   transmission of the DHCP Request and the reception of the DHCP Reply.
   In this way, the client is best assured that its address lifetimes
   will not expire at the DHCP Server before they expire at the client.

4.1.2.

3.1.2. Use with the DHCP Request message

   In a DHCP Request (for each address extension), a client may:

    -  include an IPv6 address and/or a DNS name and/or FQDN. (which may be a host
       name or a FQDN).

    -  set the 'A' bit to request that the server send updated update DNS with a new
       AAAA and/or PTR records record, as specified by the client's FQDN; if the 'Q' bit is
       also set, this update MUST be completed before responding with
       the corresponding DHCP Reply.

    -  set the 'P' bit to request that the server update DNS with a new
       PTR record, as specified by the client's FQDN; if the 'Q' bit is
       also set, this update MUST be completed before responding with
       the
       DNS. corresponding DHCP Reply.

    -  specify whether address and/or name and/or lifetime (if present)
       is advisory -or- mandatory;

    -  indicate the minimum preferred lifetime

   If the Request is advisory, a server may send different parameters
   than requested in the DHCP Reply.  Otherwise, if the Request is
   mandatory, the server must MUST reject the Request if it cannot be
   fulfilled.

   A client may include multiple IP Address extensions in a single DHCP
   Request.  The server that receives the Request is not absolutely
   required to honor the client's Request.  A DHCP client indicates that
   it cannot accept anything other than the configuration information
   (e.g., IP address) listed in the IP Address extension to the DHCP
   Request, by specifying the 'Q' (Required) bit.

   When a client requests an IP address, it MUST maintain a record for
   the server which allocates that address, so that the client can (if
   necessary) in the future

    -  Renew  Extend the lifetime with the same server, or
    -  Release the address, using DHCP Release.

4.1.3.

3.1.3. Receiving as part of the DHCP Reply message

   When the client receives an IP address extension as part of a DHCP
   Reply which it accepts (see [3]), [4]), it first inspects the error-code
   to see whether the requested information has been granted.  If the
   error-code is nonzero, the client should log the error, display
   the error condition for action by the user and/or the network
   administrator.  Nonzero error-codes almost always indicate that
   the client will be unable need to use DHCP services until the client's modify its request
   can before it could be modified,
   satisfied by the replying DHCP server, or until alternatively that the
   replying DHCP server can will need to be given updated configuration
   information for the client.

   Upon reception of a new IP address with a lifetime, the client must MUST
   perform Duplicate Address Detection (DAD) [11]; [14]; however, if the
   address has already been allocated to the client and it is merely
   renewing the lifetime of the address, the client does not have to
   perform DAD each time.  If the client receives a new IP address with
   zero valid lifetime, the client MUST immediately discontinue using
   that IP address.

4.1.4.

3.1.4. Use with the DHCP Release message

   In DHCP Release (for each address extension):

    -  Client can  the client may include an IPv6 address and/or a DNS name and/or FQDN. (which
       may be a host name or a FQDN).

    -  Server  the server MUST update DNS to delete the AAAA record if the
       server originally updated DNS when the address was allocated to
       the
       client.  Likewise client, and likewise for the PTR record.

    -  If record (regardless of the client, on
       setting of the other 'A' or 'P' bits in the address extension).

    -  If the client, on the other hand, took charge of the DNS updates,
       it MUST perform the corresponding deletions before issuing the
       DHCP Release.

4.2.

3.2. Server Considerations for the IPv6 Address extension

4.2.1.

3.2.1. Use with the DHCP Advertise message

   In DHCP Advertise (for each address extension), the Server can
   indicate:

    -  the FQDN or host name

    -  the preferred lifetime

    -  whether DNS will accept new names for the address (via the 'A'
       bit)

4.2.2.

   If the server sets the 'A' bit, it is willing to perform DNS updates
   to AAAA or PTR records on behalf of the client.

3.2.2. Receiving a DHCP Request with the IPv6 Address Extension

   If the client has requested that the server perform DNS updates as
   part of the IPv6 address allocation and configuration, the server
   must
   MUST maintain this fact as part of the client's binding.  Then, if
   the client eventually releases the IPv6 address (by including an
   appropriate IPv6 Address with the DHCP Release message), the server
   can perform the reverse service by updating DNS again as needed.

4.2.3.

3.2.3. Use with the DHCP Reply message

   In a DHCP Reply message (for each address extension) the server MUST
   indicate

    -  the preferred lifetime

    -  the valid lifetime

    -  the status of the request

   If the Reply is a response to a DHCP Release, the lifetimes MUST both
   be zero.

   In a DHCP Reply message (for each address extension) the server MAY
   indicate

    -  the DNS name

    -  whether AAAA has been DNS updated (by setting the 'A' bit)

    -  whether PTR has been DNS updated (by setting the 'P' bit)

   If the client requests updates, and sets the 'Q' bit, the server MUST
   NOT issue the DHCP Reply until after receiving positive indication
   that the DNS update has indeed been performed.  If the 'Q' bit has
   been set, and the server cannot honor the IP address extension, it
   MUST return a DHCP reply with the error code 22.

   Otherwise, the client can subsequently update DNS if needed (i.e.,
   the server didn't do it).

   If the server receives a DHCP Request from one of its clients
   whose address it wishes to invalidate, it can cause the client to
   discontinue use of the old address by including valid and preferred
   lifetimes with a value of zero.

   To perform renumbering, the server will include two IP address
   extensions, one to invalidate the old address, and another to give
   the client its new address.

4.2.4.

3.2.4. Use with the DHCP Reconfigure message

   In DHCP Reconfigure (for each address extension) the server MAY
   indicate the DNS name.

4.3.

3.2.5. Receiving a DHCP Release with the IPv6 Address Extension

   When a DHCP client releases its IPv6 address, by including an
   appropriate IPv6 Address Extension with the DHCP Release message, the
   server determines whether or not it was originally responsible for
   updating the DNS AAAA record or PTR record for the client.  If so,
   then the server must also perform the reverse service by updating DNS
   again to delete the client records.

3.3. DHCP Relay Considerations

   The DHCP Relay MUST NOT change any information in any DHCPv6
   Extension fields.  All Extension information flows between DHCPv6
   Server and DHCPv6 Client without modification by any Relay.

5.

4. General Extensions

   The following extensions are important for many DHCPv6 clients, and
   are not specific to any upper-level protocol.

5.1.

4.1. Time Offset

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Type              |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Time Offset                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Type for the time offset extension is 2, and its length is 4
   octets.  The time offset field specifies the offset of the client's
   subnet in seconds from Coordinated Universal Time (UTC). The offset
   is expressed as a signed 32-bit integer.

5.2.

4.2. Domain Name Server Extension

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Type              |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Domain Name System server addresses              |
   |                       (16 octets each)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The domain name server extension specifies a list of Domain Name
   System (STD 13, RFC 1035 [8]) [12] name servers available to the client.  Servers SHOULD be
   listed in order of preference.

   The Type for the domain name server extension is 6.  The minimum
   length for this extension is 16 octets, and the length MUST always be
   a multiple of 16.

5.3.

4.3. Domain Name

   This extension specifies the domain name that client should use when
   resolving hostnames via the Domain Name System.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Domain Name (variable length)  ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Type for this extension is 10.  Its minimum length is 1.

   The domain name is a null-terminated ASCII string, length octets in
   size, including the terminating zero octet.

   If the Domain Name extension is not specified, and the IPv6 Address
   extension received by a client contains a FQDN, then the client may
   take the part of the FQDN after the first '.'  octet as the Domain
   Name.

6.

5. Service Location Extensions

6.1.

   Entities using the Service Location Protocol [15] need to find out
   the address of Directory Agents in order to transact messages.  In
   certain other instances they may need to discover the correct scope
   to be used in conjunction with the service attributes which are
   exchanged using the Service Location Protocol.  The scope MAY be
   denoted in any standardized character set.

   Note that each extension listed below MAY be included multiple times
   in the same DHCP Request or DHCP Reply.  If so, then the extensions
   SHOULD be included in order of decreasing preference.

6. Directory Agent Extension

   This extension requests or specifies a Directory Agent (DA) [12], (DA), along
   with zero or more scopes supported by that DA. A scope, in the Service
   Location Protocol, is a way of restricting the accessibility of
   service entries (URLs) to User Agents or Service Agents who belong to
   a particular class.  For instance, in an academic institution, the
   math department may decide to allow their Directory Agents to provide
   service only for agents with the "math" scope.

   The Type for this extension is 16.  Each scope MUST be a
   null-terminated string of ASCII octets.  The lengths of the strings
   (measured in octets) are only indicated implicitly by their null
   termination and the overall length of the extension.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Char Encoding         |  scope count  |D|M| reserved   DA length   |D|M|F|S|  rsv  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         (if present)                          |
   |        Directory Agent address (16 octets)              | (variable length) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          scope list        (if present) Service Scope (variable length) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

      Code     16

      Length   (variable) The length of the Extension.

      Character Encoding
               The characters making up strings within the remainder of
               the message may be encoded in any standardized encoding
               (see section 2.1). extension.

      D        If the 'D' bit is set, the Directory Agent address field is
               present.

      F        If the 'F' bit is set, the Directory Agent is indicated
               by including its variable length host name or Fully
               Qualified Domain Name (FQDN) instead of its 4 octet IP
               address.

      M        If the 'M' bit is set, the Directory Agent address is
               the only one that may be used, and multicast methods for
               discovering Directory Agents MUST NOT be used.

      S        If the 'S' bit is set, the scope count is present, encoded in
               the indicated character set.

      rsv      reserved; ignored upon reception; MUST be sent as zero

      DA Length The number length (in octets) of scopes the Directory Agent field.

      Directory Agent
               The Fully Qualified Domain Name (FQDN), host name, or IP
               address of the Directory Agent.

      Char Encoding
               The standardized encoding for the characters denoting the
               scope.

      Service Scope
               The characters denoting the scope.

   In order to simplify administration of the configuration of Directory
   Agents for Service Location Protocol clients, the Directory Agent
   can be indicated by strings in presenting its FQDN or host name instead of its
   IP address.  This allows renumbering to proceed more smoothly [6].
   When the scope
               list following.

      scope list
               A list FQDN or host name is used, the server sets the 'F' bit.  The
   host name can be distinguished from the FQDN by the presence of strings denoting scopes. a '.'
   character.  In any case, the DA length field is set to be the length
   of the Directory Agent field.  When the 'F' bit is not set, the DA
   Length MUST be 4.

   Note that more than one Directory Agent extension may be present in
   a DHCP message.  Each such extension may have the same or different
   lists of scopes.
   scope.  The client may request a any Directory Agent with a particular
   scope, by including the Directory Agent extension in a DHCP Request
   message with no Directory Agent address included (the 'D' bit set
   to zero), and the appropriate strings in characters denoting the scope.  The length of the
   scope list.

6.2. is only indicated implicitly by the overall length of the
   extension.

7. Service Scope Extension

   This extension indicates a scope that should be used by a Service
   Agent (SA) [15], when responding to Service Request messages as
   specified by the Service Location Protocol.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Char Encoding         |          scope         Service Scope ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

      Code     17

      Length   (variable) The length of the Extension.

      Character extension.

      Char Encoding
               The standardized encoding for the characters making up strings within denoting the remainder of
               scope.

      Service Scope
               the message characters denoting the scope.

   Note that more than one Service Scope extension may be encoded present in any standardized encoding
               (see section 2.1).

      scope    Scope is a zero-terminated string in the specified
               character encoding, of
   DHCP message.  The length 'Length - 2' octets
               including of the terminating zero octet.

   This extension indicates a scope that should be used by a Service
   Agent (SA) [12], when responding to Service Request messages as
   specified is only indicated implicitly
   by the Service Location Protocol.

7. overall length of the extension.

8. IP Layer Parameters per Interface

   This section details the extensions that affect the operation of the
   IP layer on a per-interface basis.  It is expected that a client can
   issue multiple requests, one per interface, in order to configure
   interfaces with their specific parameters.

7.1.

8.1. Static Route Extension

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Destination address 1                     |
   |                          (16 octets)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Router address 1                        |
   |                          (16 octets)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Destination address 2                     |
   |                          (16 octets)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Router address 2                        |
   |                          (16 octets)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |additional Destination/Router address pairs (32 octets each) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This extension specifies a list of static routes that the client
   should install in its routing cache.  If multiple routes to the same
   destination are specified, they are listed in the order in which the
   client should make use of them.

   The routes consist of a list of IP address pairs.  The first address
   is the destination address, and the second address is the router for
   the destination.

   Link-local addresses are illegal destinations for a static route.

   The Type for this extension is 24.  The minimum length of this
   extension is 24, 32, and the length MUST be a multiple of 32.

8.

9. TCP Parameters

   This section lists the extensions that affect the operation of the
   TCP layer on a per-interface basis.

8.1.

9.1. TCP Keepalive Interval Extension

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Keepalive Time Interval                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This extension specifies the interval (in seconds) that the
   client TCP should wait before sending a keepalive message on a TCP
   connection.  The time is specified as a 32-bit unsigned integer.
   A value of zero indicates that the client should not generate
   keepalive messages on connections unless specifically requested by an
   application.

   The Type for this extension is 32, and its length is 4.

9.

10. Vendor Specific Information

   This extension is used by clients and servers to exchange vendor-
   specific information.  The information is an opaque object collection of n
   octets,
   data, presumably interpreted by vendor-specific code on the clients
   and servers.  The definition of this information is vendor specific.
   The vendor is indicated in the class-identifier extension.  Servers
   not equipped to interpret the vendor-specific information sent by a
   client MUST ignore it (although it may be reported).  Clients which
   do not receive desired vendor-specific information SHOULD make an
   attempt to operate without it, although they may do so (and announce
   they are doing so) in a degraded mode.

   If a vendor potentially encodes more than one item of information in this
   extension, then the vendor SHOULD MUST encode the extension using
   "Encapsulated vendor-specific extensions" as described below:

   The Encapsulated vendor-specific extensions field SHOULD MUST be encoded
   as a sequence of type/length/value fields of identical syntax to
   the
   DHCPv6 extensions field with the following exceptions:

      -    Types other than 0 or 255 MAY be redefined by the vendor
           within the encapsulated vendor-specific extensions field, but
           SHOULD conform to the type-length-value syntax fields defined in
           section 2.

      -    Code 255 every other DHCPv6 extension.  Extension
   65535 (END), if present, signifies the end of the encapsulated
   vendor extensions, not the end of the vendor extensions field.

   If no code 255 extension 65535 is present, then the end of the enclosing
   vendor-specific information field is taken as the end of the
   encapsulated vendor-specific extensions field.

   The Type for this extension is 40 and its minimum length Length is 1. 4.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Vendor-specific extension information  ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   When encapsulated vendor-specific extensions are used, each one has
   the
   information bytes 1-n have the following format:

    Type   Len   Data item        Type   Len   Data item  Type
   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
   |  T1 |  n  |  d1 |  d2 | ... |  T2 |  n  |  D1 |  D2 | ... | ... |
   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ same format as just shown.  In other words, all vendor-specific
   extensions are encoded in Type-Length-Value (TLV) format.  More than
   one vendor-specific extension can, therefore, be included in the same
   DHCP "Vendor Specific Information" extension.

10.

11. DHCPv6 Extensions

   This section details the extensions that are specific to DHCPv6.

10.1.

11.1. Maximum DHCPv6 Message Size Extension

   This extension specifies the maximum size in octets of any DHCPv6
   message that the sender of the extension is willing to accept.  The
   size is specified as an unsigned 16-bit integer.  A client may use
   the maximum DHCPv6 message size extension in DHCP Request messages,
   but SHOULD NOT use the extension in DHCP Solicit messages(see [3]), [4]),
   and MUST NOT use the extension in other DHCP messages.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Max DHCPv6 Message Length   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Type for this extension is 64, and its length is 2.  The minimum
   legal value is 1500.

10.2.

11.2. Class Identifier

   This extension is used by a DHCP client to optionally identify the
   type or category of user or applications it represents.

   DHCP administrators may define specific user class identifiers to convey
   information about a client's software configuration or about its
   user's preferences.  For example, an identifier may specify that
   a particular DHCP client is a member of the class "accounting
   auditors", which have special service needs such as a particular
   database server.  Alternatively, the identifier may encode the
   client's hardware configuration.

   Servers not equipped to interpret the user class identifier specified by
   a client MUST ignore it (although it may be reported).  Otherwise,
   servers SHOULD respond with the set of extensions corresponding to
   the user class identifier specified by the client.  Further, if the server
   responds with the set of extensions corresponding to the given user
   class, class
   identifier, it MUST return this extension (with the given user class
   identifier value) to the client.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Char Encoding         |        Class Identifier ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The class identifier is a zero-terminated string of characters in the
   character set specified by the Char Encoding field (see section 2.1),
   of length 'n' "Length"-2 octets including the terminating null octet.
   The class identifier represents the user class identifier of which the
   client is a member.

10.3.

11.3. Reconfigure Multicast Address

   A DHCPv6 server can instruct its clients to join a multicast group
   for the purposes of receiving DHCPv6 Reconfigure messages.  This will
   allow a server to reconfigure all of its clients at once; such a
   feature will be useful when renumbering becomes necessary.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Reconfigure Multicast Address                |
   |                          (16 octets)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Type of the Reconfigure Multicast Address is 66, and the length
   is 16.

10.4.

11.4. Renumber DHCPv6 Server Address

   A DHCPv6 server can instruct its clients to change their internal
   records to reflect the server's newly renumbered IPv6 address, by
   using the "Renumber DHCPv6 Server Address" extension.  This extension
   may be sent with the DHCP Reconfigure message, and thus can be
   multicast to all of the server's clients instead of being unicast to
   each one individually.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   New DHCPv6 Server Address                   |
   |                          (16 octets)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Type of the Renumber DHCPv6 Server Address is 67, and the length
   is 16.

10.5.

11.5. Client-Server Authentication Extension

   Exactly one Client-Server Authentication Extension MAY be present
   in any any DHCPv6 message transmitted between a client and server (or
   vice-versa).  If present, it MUST be the last extension.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Security Parameters Index (SPI)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Replay Protection                      |
   |                           (8 octets)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Authenticator (variable length) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type     84

      Length   4 for the SPI, plus 8 for the replay protection, plus the
               number of bytes in the Authenticator.

      SPI      A Security Parameters index [3] identifying a security
               context between a pair of nodes among the contexts
               available in the security association defined between
               the DHCPv6 client and server.  SPI values 0 through 255
               are reserved and, if used, MUST conform to the security
               context defined by that value as defined in the most
               recent Assigned Numbers RFC (e.g., [8]).

      Replay Protection
               A 64-bit timestamp (in Network Time Protocol [11](NTP)
               format) (see section 13.1).

      Authenticator
               (variable length) (See Section 13.2.)

   This authentication extension remedies the inability of IPsec to
   provide for non end-to-end authentication, since authentication is
   needed even when the client needs has no valid IPv6 address.  The
   extension can be originated by either the DHCPv6 Client or DHCPv6
   server to authenticate the rest of the data in the DHCPv6 message.
   The default authentication algorithm is defined in section 13.2.

11.6. Client Key Selection Extension

   A DHCPv6 message transmitted between server may wish to indicate to a prospective client and server (or
   vice-versa).  If present, which
   SPI it MUST be must use to authenticate subsequent messages, using the last extension, except
   possibly for
   Client-Server Authentication Extension.  In such cases, the Pad extension 3. server
   includes the Client Key Selection Extension in its DHCP Advertise
   message.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Security Parameters Index (SPI)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Replay Protection                      |
   |                           (8 octets)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Authenticator (variable length) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type     84     85

      Length   4 for the SPI, plus 8 for the replay protection, plus the
               number of bytes in the Authenticator.

      SPI      A Security Parameters index [2] [3] identifying a security
               context between a pair of nodes among the contexts
               available in the security association defined between
               the DHCPv6 client and server.  SPI values 0 through 255
               are reserved and, if used, MUST conform to the security
               context defined by that value as defined in the most
               recent Assigned Numbers RFC (e.g., [5]).

      Replay Protection
               A 64-bit timestamp (in Network Time Protocol [7](NTP)
               format) (see section 11.1).

      Authenticator
               (variable length) (See Section 11.2.)

   This authentication [8]).

12. End extension remedies the inability of IPsec to
   provide for non end-to-end authentication, since authentication is
   needed even when the client needs has no valid IPv6 address. specification

   The end extension can be originated by either the DHCPv6 Client or DHCPv6
   server to authenticate marks the rest end of the data valid information in the DHCPv6 message. vendor
   field.  The default authentication algorithm Type for the end extension is defined in section 11.2.

11. 65535, and its length is 2
   octets; there is no Length field for the end extension.

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             65535             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

13. Security Considerations

   There is an urgent need to define some security protocol for use
   with DHCPv6, since otherwise malicious parties could create numerous
   denial-of-service style attacks based on depleting available server
   resources or providing corrupted or infected data to unsuspecting
   clients.  The following sections discuss aspects of security relevant
   for users of the Client-Server Authentication extension 10.5.

11.1. 11.5.

13.1. Replay Protection

   A 64-bit timestamp, in Network Time Protocol [7](NTP) [11](NTP) format, is
   used to protect against replay of previous authenticated messages
   by malicious agents.  The NTP timestamp value used in the extension
   MUST be chosen, and verified, to be larger than values used by the
   originator in previous Client-Server Authentication extensions.
   On the other hand, the timestamp value MUST also be chosen (and
   verified) to be no greater than one year more than the last known
   value (if any) used by the originator.

11.2.

13.2. Default Authentication Algorithm

   The default authentication algorithm is HMAC [6], [10], using
   keyed-MD5 [10]. [13].  Given a secret key K, and "data" the information to
   be authenticated, HMAC_result is computed as follows:

    1. opad := 0x36363636363636363636363636363636 (128 bits)

    2. ipad := 0x5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C (128 bits)

    3. zero_extended_key := K extended by zeroes to be 128 bits long

    4. opadded_key := zero_extended_key XOR opad

    5. ipadded_key := zero_extended_key XOR ipad

    6. HMAC_result := MD5 (opadded_key , MD5 (ipadded_key, data))

   The key K is the shared secret defined by the security association
   between the client and server and by the SPI value specified in
   the Authentication Extension.  The "data" is the stream of bytes
   in all previous fields in the DHCPv6 message and extensions. DHCPv6 message and extensions.  The
   authenticator is the 128-bit value HMAC_result.

14. Defining New Extensions

   Implementation specific use of undefined extensions (including those
   in the range 86-32767) may conflict with other implementations, and
   registration is required.

   The author of a new DHCP option MUST follow these steps to obtain
   acceptance of the option as a part of the DHCP Internet Standard:

    1. The
   authenticator is author devises the 128-bit value HMAC_result.

12. New Extensions

   Additional extensions may be registered new option.

    2. The author requests a number for the new option from IANA by
       contacting:

          Internet Assigned Numbers Authority (IANA)
          USC/Information Sciences Institute
          4676 Admiralty Way
          Marina del Rey, California 90292-6695
          or by email as:  iana@isi.edu

   Implementation specific use of undefined extensions (including those

    3. The author documents the new option, using the newly obtained
       option number, as an Internet Draft.

    4. The author submits the Internet Draft for review through the
       IETF standards process as defined in "Internet Official Protocol
       Standards" [9].  The new option will be submitted for eventual
       acceptance as an Internet Standard.

    5. The new option progresses through the range 85-32767) may conflict with other implementations, IETF standards process; the
       new option will be reviewed by the Dynamic Host Configuration
       Working Group (if that group still exists), or as an Internet
       Draft not submitted by an IETF working group.

    6. If the new option fails to gain acceptance as an Internet
       Standard, the assigned option number will be returned to IANA for
       reassignment.

   This procedure for defining new extensions will ensure that:

     * allocation of new option numbers is coordinated from a single
       authority,

     * new options are reviewed for technical correctness and
   registration
       appropriateness, and

     * documentation for new options is required.

13. complete and published.

15. Acknowledgements

   Thanks to Jim Bound for his frequent review, helpful suggestions, and
   design assistance.  Ralph Droms has also made many, many suggestions
   which have been incorporated into this draft.  The original form of
   this internet draft was copied directly from RFC1533 [1], written
   by Steve Alexander and Ralph Droms, Droms.  Thanks to whom thanks are again due. Erik Guttman for his
   helpful suggestions for the Service Location extensions.

References

    [1] S. Alexander and R. Droms.  DHCP Options and BOOTP Vendor
        Extensions.  RFC 1533, October 1993.

    [2] S. Alexander and R. Droms.  DHCP Options and BOOTP Vendor
        Extensions.  RFC 2132, March 1997.

    [3] R. Atkinson.  IP Authentication Header.  RFC 1826, August 1995.

    [3]

    [4] J. Bound and C. Perkins.  Dynamic Host Configuration Protocol
        for IPv6.  draft-ietf-dhc-dhcpv6-09.txt, February  draft-ietf-dhc-dhcpv6-10.txt, May 1997.  (work in
        progress).

    [4]

    [5] S. Bradner.  Key words for use in RFCs to Indicate Requirement
        Levels.  RFC 2119, March 1997.

    [6] B. Carpenter and Y. Rekhter.  Renumbering needs work.  RFC 1900,
        February 1996.

    [7] S. Deering and R. Hinden.  Internet Protocol, Version 6 (IPv6)
        Specification.  RFC 1883, December 1995.

    [5]

    [8] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina.  Generic
        Routing Encapsulation (GRE).  RFC 1701, October 1994.

    [6]

    [9] Editor J. Postel.  INTERNET OFFICIAL PROTOCOL STANDARDS.  STD 1,
        February 1997.

   [10] H. Krawczyk, M. Bellare, and R. Cannetti.  HMAC: Keyed-Hashing
        for Message Authentication.  RFC 2104, February 1997.

    [7]

   [11] David L. Mills.  Network Time Protocol (Version 3):
        Specification, Implementation and Analysis.  RFC 1305, March
        1992.

    [8]

   [12] P. Mockapetris.  DOMAIN NAMES  Domain Names - IMPLEMENTATION AND
        SPECIFICATION.  RFC 1035, Concepts and Facilities.  STD
        13, November 1987.

    [9] J. Reynolds.  BOOTP Vendor Information Extensions.  RFC 1497,
        August 1993.

   [10]

   [13] Ronald L. Rivest.  The MD5 Message-Digest Algorithm.  RFC 1321,
        April 1992.

   [11]

   [14] S. Thomson and T. Narten.  IPv6 stateless address
        autoconfiguration.  RFC 1971, August 1996.

   [12]

   [15] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan.  Service
        Location Protocol.  draft-ietf-svrloc-protocol-15.txt, November
        1996. Protocol, April 1997. draft-ietf-svrloc-protocol-17.txt
        (work in progress).

   [13]

   [16] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound.  Dynamic Updates
        in the Domain Name System (DNS).
        draft-ietf-dnsind-dynDNS-11.txt, November 1996.  (work
        in progress).  RFC 2136, April 1997.

Chair's Addresses

   The working group can be contacted via the current chair:

          Ralph Droms
          Computer Science Department
          323 Dana Engineering
          Bucknell University
          Lewisburg, PA 17837

          Phone: (717) 524-1145
          EMail: droms@bucknell.edu

Author's Address

   Questions about this memo can be directed to:

          Charles Perkins
          Mail Stop UPAL01-550
          Netcentricity Group
          Sun Microsystems, Inc.
          2550 Garcia Avenue
          Mountain View, CA  94043

          Work:   +1-415-336-7153
          Fax:    +1-415-336-0673
          E-mail: cperkins@corp.sun.com