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

Versions: 00 01 02 03 04 05 06 07 08 09 10 11

Internet Engineering Task Force                               C. Perkins
INTERNET DRAFT                                          Sun Microsystems
                                                           13 March 1998


    Extensions for the Dynamic Host Configuration Protocol for IPv6
                      draft-ietf-dhc-v6exts-09.txt


Status of This Memo

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

   Distribution of this memo is unlimited.

   This document is an Internet-Draft.  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 view the entire list of current Internet-Drafts, please check
   the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

   Distribution of this memo is unlimited.


Abstract

   The Dynamic Host Configuration Protocol for IPv6 [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






Perkins                Expires 13 September 1998                [Page i]


Internet Draft              DHCPv6 Extensions              13 March 1998


   valid extensions.  The method for specifying new extensions is also
   included in this document.


















































Perkins               Expires 13 September 1998                [Page ii]


Internet Draft              DHCPv6 Extensions              13 March 1998




                                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
     2.2. Typed Scope Lists . . . . . . . . . . . . . . . . . . . .    3

 3. IP Address Extension                                               4
     3.1. Client Considerations for the IP Address extension  . . .    7
           3.1.1. Address Lifetimes . . . . . . . . . . . . . . . .    7
           3.1.2. Use with the DHCP Request message . . . . . . . .    8
           3.1.3. Receiving as part of the DHCP Reply message . . .    9
           3.1.4. Use with the DHCP Release message . . . . . . . .   10
     3.2. Server Considerations for the IP Address extension  . . .   10
           3.2.1. Use with the DHCP Advertise message . . . . . . .   10
           3.2.2. Receiving a DHCP Request with the IP Address
                          Extension  . . . . . . . . . . . . . . . .  10
           3.2.3. Use with the DHCP Reply message . . . . . . . . .   11
           3.2.4. Use with the DHCP Reconfigure message . . . . . .   12
           3.2.5. Receiving a DHCP Release with the IP Address
                          Extension  . . . . . . . . . . . . . . . .  12
     3.3. DHCP Relay Considerations . . . . . . . . . . . . . . . .   12

 4. General Extensions                                                12
     4.1. Time Offset . . . . . . . . . . . . . . . . . . . . . . .   13
     4.2. IEEE 1003.1 POSIX Timezone extension  . . . . . . . . . .   13
           4.2.1. IEEE 1003.1 POSIX Timezone specifier  . . . . . .   13
           4.2.2. An Example  . . . . . . . . . . . . . . . . . . .   15
           4.2.3. Timezone Extension Precedence . . . . . . . . . .   15
     4.3. Domain Name Server Extension  . . . . . . . . . . . . . .   15
     4.4. Domain Name . . . . . . . . . . . . . . . . . . . . . . .   16

 5. Application and Service Parameters                                16
     5.1. Directory Agent Extension . . . . . . . . . . . . . . . .   16
     5.2. Service Scope Extension . . . . . . . . . . . . . . . . .   18
     5.3. Network Time Protocol Servers Extension . . . . . . . . .   19
     5.4. Network Information Service Domain Extension  . . . . . .   19
     5.5. Network Information Servers Extension . . . . . . . . . .   20
     5.6. Network Information Service+ Domain Extension . . . . . .   20
     5.7. Network Information Service+ Servers Extension  . . . . .   20




Perkins               Expires 13 September 1998               [Page iii]


Internet Draft              DHCPv6 Extensions              13 March 1998


 6. TCP Parameters                                                    21
     6.1. TCP Keepalive Interval Extension  . . . . . . . . . . . .   21

 7. DHCPv6 Extensions                                                 21
     7.1. Maximum DHCPv6 Message Size Extension . . . . . . . . . .   21
     7.2. Platform Specific Information . . . . . . . . . . . . . .   22
     7.3. Platform Class Identifier . . . . . . . . . . . . . . . .   23
     7.4. Class Identifier  . . . . . . . . . . . . . . . . . . . .   24
     7.5. Reconfigure Multicast Address . . . . . . . . . . . . . .   25
     7.6. Renumber DHCPv6 Server Address  . . . . . . . . . . . . .   25
     7.7. DHCP Relay ICMP Error Message Format  . . . . . . . . . .   25
           7.7.1. ICMP Extension Client Considerations  . . . . . .   26
           7.7.2. ICMP Extension Relay Considerations . . . . . . .   26
     7.8. Client-Server Authentication Extension  . . . . . . . . .   26
     7.9. Client Key Selection Extension  . . . . . . . . . . . . .   27

 8. End extension specification                                       28

 9. Security Considerations                                           28
     9.1. Replay Protection . . . . . . . . . . . . . . . . . . . .   29
     9.2. Default Authentication Algorithm  . . . . . . . . . . . .   29

10. Defining New Extensions                                           29

11. Acknowledgements                                                  31

Chair's Address                                                       33

Author's Address                                                      33























Perkins               Expires 13 September 1998                [Page iv]


Internet Draft              DHCPv6 Extensions              13 March 1998


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






Perkins                Expires 13 September 1998                [Page 1]


Internet Draft              DHCPv6 Extensions              13 March 1998


2. DHCPv6 Extension Field Format

   Extensions may be fixed length or variable length.  All extensions
   begin with a type field, which is two octets long and uniquely
   identifies the extension.  Fixed length extensions without data
   consist of only the two octet type field.  Only extension 65535 is
   fixed length.  All other extensions are variable length with a two
   octet unsigned integer Length field following the type octets.  The
   value of the Length field does not include the four octets specifying
   the type and length.  The Length field is followed by "length" octets
   of data.  In the case of some extensions the length field is a
   constant but MUST still be specified.  In each case, unless otherwise
   specified, the length field specifies the length of the extension in
   octets.  Any extensions defined subsequent to this document should
   contain a Length field even if the length is fixed or zero.  There
   is no particular requirement for alignment of the data fields within
   existing DHCPv6 extensions.

   Unrecognized extensions SHOULD be skipped by ignoring the number of
   octets specified in the length field, and processing continued for
   subsequent extensions.  Unless and until specified otherwise by use
   of extension type 64 (see section 7.1), DHCP entities MUST assume
   that that the maximum DHCP message size including extensions is 1500
   octets.

   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.  Whenever an extension is received
   as part of a DHCP message, any reserved fields of the message MUST
   be ignored, and processing continued as if the reserved fields were
   zero.


2.1. Character Encoding and String Issues

   Certain extensions (e.g., type 16 described in section 5.1) have
   fields which can use various character encodings.  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.  Note that in some
   character sets, each character may require two or more octets of data
   for its representation.





Perkins                Expires 13 September 1998                [Page 2]


Internet Draft              DHCPv6 Extensions              13 March 1998


   The encoding will determine the interpretation of all character data
   in the corresponding fields of particular extensions.  There is no
   way to mix US-ASCII and UNICODE, for example.  All responses 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 status code of 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 be able to accept this
   character set.  All DNS-related strings are presumed to be encoded in
   US-ASCII.


2.2. Typed Scope Lists

   In Service Location Protocol, multiple service types can be hosted on
   the same network node.  However, DHCP typically configures computers
   based on their IP address.  It is possible that different service
   types on the same computer would be administered from different
   scopes.  Thus, extensions 16 and 17 have additional syntax to allow
   this more detailed style of service configuration.

   In particular, the list of scopes contained in the extensions is
   syntactically separated into lists pertaining to each service type.

   Grammatically, a typed-scope-list in a DHCPOFFER is structured as
   follows:

     typed-scope-list = one or more maybe-typed-scope-items,
                        separated by commas
     maybe-typed-scope-item = typed-scope-item, or scope-list
     typed-scope-item = '(' service-type '=' scope-list ')'
     scope-list = one or more scope-items, comma-separated

   A typed-scope-list in a DHCPREQUEST is structured as follows:

     typed-scope-list = one or more maybe-typed-scope-items,
                        separated by commas
     maybe-typed-scope-item = typed-scope-item, or
                                 maybe-empty-scope-list
     typed-scope-item = '(' service-type '=' maybe-empty-scope-list ')'
     maybe-empty-scope-list = zero or more scope-items, comma-separated

   A service type has the format defined in [10], and a scope-item has
   the format defined in [11] for "strval".  Basically, a scope-item is
   a character string that has alphanumeric characters not including
   control characters or `(',`)',`,', \',`!',`<',`=',`>', or `~' Service
   schemes are special cases of schemes as defined for general URLs [3].




Perkins                Expires 13 September 1998                [Page 3]


Internet Draft              DHCPv6 Extensions              13 March 1998


   The typed-scope-list MAY contain both untyped-scope-lists and
   typed-scope-lists.  Each scope-item in each untyped-scope-list
   applies to every service type on the node.

   As an example, the scope-list ``A,B,C'' denotes scopes A, B and C
   for all service types on the client.  In a DHCPREQUEST, this scope
   string would indicate that the client wishes a directory agent which
   supports ANY of these three scopes.  In a DHCPOFFER, the scope
   indicates that the directory agent supports ALL of the three scopes.

   Suppose instead that service types "netman" and "proxystuff" are
   residing on a DHCP client.  Then, the typed-scope-list in a DHCPOFFER
   could be,

        (netman=mgmt),(proxystuff=math-dept,labs)

   Assuming the DHCP client with two service types "netman" and
   "proxystuff" did not make any scope restriction, a corresponding
   typed-scope-list in a DHCPREQUEST could be,

        (netman=),(proxystuff=)

   asking for scopes for those service types.


3. IP Address Extension

   The IP 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 IP Address extension 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 IP Address extension can specify how DNS may
   be updated [25].

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








Perkins                Expires 13 September 1998                [Page 4]


Internet Draft              DHCPv6 Extensions              13 March 1998



    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    status     |C|L|Q|A|P|       reserved      |   pfx-size    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         (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   (unsigned integer, variable) The length of the Extension
               in octets.

      status   If the server is unable to honor the client's request,
               the reason is indicated in the status.

      C        If the 'C' bit is set, the field containing the IP
               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 client requests that that
               the the server updates DNS with a new AAAA record, as
               specified by the client's FQDN.

      P        If the 'P' bit is set, the client requests that that
               the the server updates DNS with a new PTR record, as
               specified by the client's FQDN.

      reserved MUST be zero.

      pfx-size
               If the client address is present (the 'C' bit is set), a
               nonzero pfx-size is the number of leftmost bits of the



Perkins                Expires 13 September 1998                [Page 5]


Internet Draft              DHCPv6 Extensions              13 March 1998


               client's IPv6 address which make up the routing prefix.
               Otherwise, if the 'C' bit is not set, pfx-size MUST be
               zero.

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

      preferred lifetime
               The preferred lifetime of the IP address in seconds

      valid lifetime
               The valid lifetime of the IP address in seconds

      DNS name
               The DNS name (a string of ASCII octets) to be used by the
               client (variable length).

   The following values for the status field are defined within this
   document:

        0   request granted, no errors
       18   Security parameters failed for this client
       20   Resource AAAA Record Parameter Problem
       21   Resource PTR Record Parameter Problem
       22   Unable to honor required extension parameters
       23   DNS name string error
       24   dynDNS Not Implemented
       25   Authoritative DNS Server could not be found
       33   The name server was unable to interpret the request
          due to a format error.
       34   dynDNS Not Available at this time (SERVFAIL)
       35   Some name that ought to exist, does not exist
          (NXDOMAIN)
       36   The name server does not support the specified Opcode
          (NOTIMP)
       37   The name server refuses to perform the specified
          operation for policy or security reasons (REFUSED)
       38   Some name that ought not to exist, does exist
          (YXDOMAIN)
       39   Some RRset that ought not to exist, does exist
          (YXRRSET)
       40   Some RRset that ought to exist, does not exist
          (NXRRSET)
       41   The server is not authoritative for the zone named in
          the Zone Section (NOTAUTH)
       42   A name used in the Prerequisite or Update Section
          is not within the zone denoted by the Zone Section
          (NOTZONE)



Perkins                Expires 13 September 1998                [Page 6]


Internet Draft              DHCPv6 Extensions              13 March 1998


   Status values 33 through 42 are described more fully within RFC
   2136 [25].  Up-to-date values for the values of the status field are
   specified in the most recent "Assigned Numbers" [20].  To inform the
   client of the DYNDNS [25] error return codes (i.e., nonzero return
   codes) received by the DHCPv6 server the client MUST assume the
   status codes 32 through 42 are formed as follows:

      status code = 32 + DYNDNS Error Code

   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 'Q' bit is set, the values or actions requested by the C, L,
   A, and P bits are required, and MUST be provided, or the extension
   MUST be rejected with status code 22.

   If the 'Q' bit is set, and if the 'A' bit is set, the 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.

   A DHCP client can include an IP address in its IP Address extension
   and set the 'A' bit and/or 'P' bit to ask the DHCP Server to use that
   address for updating DNS. This can be done even with IP addresses
   obtained by Stateless Address Autoconfiguration [23].  If the client
   wishes to have its FQDN associated with one of several existing IP
   addresses which it has received from the DHCP Server, the client MUST
   supply that IP address in the IP address extension along with the
   FQDN.


3.1. Client Considerations for the IP Address extension

3.1.1. Address Lifetimes

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

   The client SHOULD make a new Request for any 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



Perkins                Expires 13 September 1998                [Page 7]


Internet Draft              DHCPv6 Extensions              13 March 1998


   for an address, the server SHOULD assume the client does not want
   that address.  The server MAY provide that address to another client
   requesting an address.

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

   When the preferred lifetime of an IP address expires, the client's
   address becomes a deprecated address.  See [9] for required handling
   of deprecated IP addresses.  Before an address for a DHCPv6 client's
   interface becomes deprecated, the 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 IP 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
   corresponding 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.


3.1.2. Use with the DHCP Request message

   In a DHCP Request (for each address extension), a client MUST set the
   status code to zero.

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

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

    -  set the 'A' bit to request that the server update DNS with a new
       AAAA 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 corresponding DHCP Reply.

    -  indicate the minimum preferred (and/or valid) lifetime, by
       supplying a value for the field(s).





Perkins                Expires 13 September 1998                [Page 8]


Internet Draft              DHCPv6 Extensions              13 March 1998


    -  specify whether address, name and lifetimes (if present) are
       advisory -or- mandatory, by setting the 'Q' bit.

   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 reject the Request if it cannot be
   fulfilled.  A server can always supply a greater value for the
   lifetimes than that requested by the client, even if the 'Q' bit is
   set.  If the client wishes to have a smaller lifetime than the server
   supplies, the client MAY use the DHCP Release mechanism to relinquish
   it.

   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

    -  Extend the lifetime with the same server, or

    -  Release the address, using DHCP Release.


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 [4]), it first inspects the status to see
   whether the requested information has been granted.  If the status is
   nonzero, the client should log the error, display the error condition
   for action by the user and/or the network administrator.  Nonzero
   status almost always indicates that the client will be need to modify
   its request before it could be satisfied by the replying DHCP server,
   or alternatively that the replying DHCP server will need to be given
   updated configuration information for the client.

   Upon reception of a new IP address with a lifetime, the client MUST
   perform Duplicate Address Detection (DAD) [23]; 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 an IP address with
   zero valid lifetime, the client MUST immediately discontinue using
   that IP address.





Perkins                Expires 13 September 1998                [Page 9]


Internet Draft              DHCPv6 Extensions              13 March 1998


3.1.4. Use with the DHCP Release message

   In DHCP Release (for each address extension):

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

    -  the server MUST update DNS to delete the AAAA record or records
       that the server originally used when updating DNS when the
       address was allocated to the client, and likewise for the PTR
       record (regardless of the setting of the '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.

   The client MUST provide a specific IP address in the extension.


3.2. Server Considerations for the IP Address extension

3.2.1. Use with the DHCP Advertise message

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

    -  the client's FQDN or host name

    -  the preferred lifetime

    -  the valid lifetime

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

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


3.2.2. Receiving a DHCP Request with the IP Address Extension

   When a server receives a request for an IP address, it consults its
   allocation tables and determines an IP address appropriate for the
   requesting client and the link to which the client is attached.
   The link can be determined by the Agent address prefix in the DHCP
   Request message header, or, when there is no relay, by the link of



Perkins               Expires 13 September 1998                [Page 10]


Internet Draft              DHCPv6 Extensions              13 March 1998


   the interface on which the request was received.  This is true in the
   latter case because the client and the server have to be on the same
   link when there is no server address included in the message header.

   If the client has requested that the server perform DNS updates as
   part of the IP address allocation and configuration, the server
   MUST maintain this fact as part of the client's binding.  Then, if
   the client eventually releases the IP address (see the DHCP Releas
   message in [4]), the server MUST perform the reverse service by
   updating DNS again as needed.


3.2.3. Use with the DHCP Reply message

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

    -  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

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

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

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




Perkins               Expires 13 September 1998                [Page 11]


Internet Draft              DHCPv6 Extensions              13 March 1998


   To perform renumbering, the server will include two IP address
   extensions, one to reduce the the preferred lifetime and reduce the
   valid lifetime for the old address, and another to give the client
   its new address.

   On a practical note, if the DHCP administrator uses site-local
   addresses for IP address allocation to clients, there will be less
   need for renumbering whenever the site moves to a new site prefix or
   set of site prefixes.  Of course, this only works when the site does
   not need global addresses.


3.2.4. Use with the DHCP Reconfigure message

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


3.2.5. Receiving a DHCP Release with the IP Address Extension

   When a DHCP client releases its IP address, by including an
   appropriate IP 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.


4. General Extensions

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













Perkins               Expires 13 September 1998                [Page 12]


Internet Draft              DHCPv6 Extensions              13 March 1998


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
   clock in seconds from Coordinated Universal Time (UTC). The offset is
   expressed as a signed (two's complement) 32-bit integer.


4.2. IEEE 1003.1 POSIX Timezone extension

   DHCP includes an extension for the specification of the Universal
   Coordinated Time Offset (type 2, defined in section 4.1), which is
   defined as a two's complement 32-bit integer representing the offset
   in seconds from UTC. Unfortunately, the UTC offset extension does not
   provide enough information for an Internet client to determine such
   timezone-related details as the timezone names, daylight savings time
   start and end times in addition to the timezone UTC offsets.  This
   extension (analogous to that proposed for DHCPv4 [6]) allows delivery
   of timezone information in the form of a IEEE 1003.1 POSIX Timezone
   specifier [13].

    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    IEEE 1003.1 POSIX Timezone string (variable length) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The extension type is 3.  This IEEE 1003.1 POSIX Timezone is detailed
   next, in section 4.2.1.


4.2.1. IEEE 1003.1 POSIX Timezone specifier

   .

   The format of the IEEE 1003.1 POSIX timezone string is specified as

      StdOffset[Dst[Offset],[Start[/Time],End[/Time]]]




Perkins               Expires 13 September 1998                [Page 13]


Internet Draft              DHCPv6 Extensions              13 March 1998


   where '[' and ']' enclose optional fields, '|' indicates choice
   of exactly one of the alternatives, ',' and '/' represent literal
   characters present in the string, and:

      Std      three or more octets for the standard timezone (Std).
               Any characters (or case) except a leading colon, digits,
               comma, minus or plus sign are allowed.

      Offset   Indicates the value one must add to local time to
               arrive at UTC, of the form:  [+|-]hh[:mm[:ss]].  Offset
               following Std is required.  Digits are always interpreted
               as decimal number.  If preceded by a '-', the timezone is
               east of the Prime Meridian, otherwise it is west ('+' is
               optional) The permissible values for hh[:mm[:ss]] are as
               follows:

                  hh       0 <= hh <= 23

                  mm       0 <= mm <= 60

                  ss       0 <= ss <= 60

               Offset has no default value.

      Dst      three or more octets for the daylight savings timezone.
               If Dst is missing, then daylight savings time does not
               apply in this locale.  If no Offset follows Dst, then
               Dst is assumed to be one hour ahead of standard time.
               Any characters (or case) except a leading colon, digits,
               comma, minus or plus sign are allowed.

      Start    Indicates the day of the year, in one of the formats
               indicated below, when to change to daylight savings time.
               The 'Time' field (which follows immediately after a '/'
               character, if present) indicates when the change is made,
               in local time.

      End      Indicate the day of the year, in one of the formats
               indicated below, when to change back from daylight
               savings time.  The 'Time' field (which follows
               immediately after a '/' character, if present) indicates
               when the change is made, in local time.

      Time     Time has the same format as Offset, except that no
               leading '-' or '+' is permitted.  The default is
               02:00:00.

   The day of the year can be given in one of the following formats:




Perkins               Expires 13 September 1998                [Page 14]


Internet Draft              DHCPv6 Extensions              13 March 1998


      Jn       The julian day n, (1 <= n <= 365).  Leap days are not
               counted.

      n        zero-based julian day, (0 <= n <= 365).  Leap days are
               counted so it is possible to refer to Feb 29.

      Mm.n.d   The 'd'th day, (0 <= d <= 6) of week 'n' of month 'm' of
               the year (1 <= n <= 5, 1 <= m <= 12, where week 5 means
               last 'd' day in month 'm' which may occur in either the
               fourth or the fifth week.  Week '1' is the first week in
               which the 'd' day occurs.


4.2.2. An Example

   For Eastern USA time zone, 1986, the Posix timezone string is as
   follows:

      EST5EDT4,116/02:00:00,298/02:00:00


4.2.3. Timezone Extension Precedence

   If a DHCP client receives both the Time Offset (type 2) and the POSIX
   Timezone (type 3) extension in a DHCP reply message, the client MUST
   discard the value of the Time Offset (type 2) extension and utilize
   the POSIX Timezone Extension.  The DHCP client MAY notify the user
   that it is resolving the conflict by discarding the Time Offset (type
   2) extension.

   If a DHCP client finds that the POSIX Timezone extension value is
   misformatted, it SHOULD notify the the user of the problem and MUST
   discard the entire extension value.


4.3. 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 [19] name servers available to the client.  Servers SHOULD be
   listed in order of preference.



Perkins               Expires 13 September 1998                [Page 15]


Internet Draft              DHCPv6 Extensions              13 March 1998


   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.


4.4. Domain Name

   This extension specifies the default 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 ASCII string, Length octets in size.

   If the Domain Name extension is not specified, and the IP 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.


5. Application and Service Parameters

   This section details some miscellaneous extensions used to configure
   miscellaneous applications and services.


5.1. Directory Agent Extension

   Entities using the Service Location Protocol [24] need to find out
   the address of Directory Agents in order to transact messages.  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.

   This extension requests or specifies a Directory Agent (DA), along
   with zero or more scopes supported by that DA. Note that this
   extension 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.




Perkins               Expires 13 September 1998                [Page 16]


Internet Draft              DHCPv6 Extensions              13 March 1998



    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |D|F|M|S|        reserved       |           DA length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Directory Agent (variable length) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        (if present) Typed-Scope-List (variable length) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type     16

      Length   (unsigned integer, variable) The length of the Extension
               in octets.

      D        If the 'D' bit is set, the Directory Agent field and the
               DA Length fields are 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 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 is present.

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

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

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

      Typed Scope List
               The characters denoting the scope (see Section reftsl).

   In order to simplify administration of the configuration of Directory
   Agents for Service Location Protocol clients, the Directory Agent
   can be indicated by presenting its FQDN or host name instead of its
   IP address.  This allows renumbering to proceed more smoothly [7].
   When the 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 a '.'
   character.  In any case, the DA length field is set to be the length



Perkins               Expires 13 September 1998                [Page 17]


Internet Draft              DHCPv6 Extensions              13 March 1998


   of the Directory Agent field.  When the 'F' bit is not set, the DA
   Length MUST be 16.

   Note that more than one Directory Agent extension may be present in
   a DHCP message.  Each such extension may have the same or different
   scope.

   The client may request 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 characters denoting the scope.

   The length of the Typed Scope List is only indicated implicitly
   by the overall length of the extension.  This string is NOT null
   terminated.

   The format of the Typed Scope List field is described in section 2.2.

   Extension 16 MUST include one or more scopes if a DA address is
   returned.  Using extension 16, it is not possible for different
   service types on the same node to be configured with different
   directory agents.  In other words, all service types on the same node
   will be configured with the same directory agent.


5.2. Service Scope Extension

   This extension indicates a scope that should be used by a Service
   Agent (SA) [24], when responding to Service Request messages as
   specified by the Service Location Protocol.  This extension MAY be
   included multiple times in the same DHCP Request or DHCP Reply.

    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Typed-Scope-List ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type     17

      Length   (unsigned integer, variable) The length of the Extension
               in octets.

      Typed-Scope-List
               see Section 2.2.





Perkins               Expires 13 September 1998                [Page 18]


Internet Draft              DHCPv6 Extensions              13 March 1998


   The Typed-Scope-List is described in Section 2.2.  The DHCP
   client (i.e., user agent or service agent) which receives this
   extension will use the indicated scope for in all SLP requests and
   registrations.  The scope string must be UTF8 character encoded.
   This string is not null terminated.

   DHCP clients MAY use extension 79 to request scopes for one or more
   particular service types.  Note that more than one Service Scope
   extension may be present in a DHCP message.  The length of the scope
   is only indicated implicitly by the overall length of the extension.


5.3. Network Time Protocol Servers Extension

   This extension specifies a list of IP addresses indicating NTP [17]
   servers available to the client.  Servers SHOULD be listed in order
   of preference.

    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     NTP server addresses                      |
   |                       (16 octets each)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The type for this extension is 18.  Its minimum Length is 16, and the
   Length MUST be a multiple of 16.


5.4. Network Information Service Domain Extension

   This extension specifies the name of the client's NIS [16] domain.
   The domain is formatted as a character string consisting of
   characters from the US-ASCII character set.

   The type for this extension is 19.  Its minimum Length is 1.

    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              NIS Domain Name (variable length)  ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+






Perkins               Expires 13 September 1998                [Page 19]


Internet Draft              DHCPv6 Extensions              13 March 1998


5.5. Network Information Servers Extension

   This extension specifies a list of IP addresses indicating NIS [16]
   servers available to the client.  Servers SHOULD be listed in order
   of preference.

    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     NIS server addresses                      |
   |                       (16 octets each)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The type for this extension is 20.  Its minimum Length is 16, and the
   Length MUST be a multiple of 16.


5.6. Network Information Service+ Domain Extension

   This extension specifies the name of the client's NIS+ [16]
   domain.  The domain is formatted as a character string consisting of
   characters from the US-ASCII character set.

   The type for this extension is 21.  Its minimum Length is 1.

    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              NIS+ Client Domain Name (variable length)  ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


5.7. Network Information Service+ Servers Extension

   This extension specifies a list of IP addresses indicating NIS+ [16]
   servers available to the client.  Servers SHOULD be listed in order
   of preference.











Perkins               Expires 13 September 1998                [Page 20]


Internet Draft              DHCPv6 Extensions              13 March 1998



    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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     NIS+ server addresses                     |
   |                       (16 octets each)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The code for this extension is 22.  Its minimum Length is 16, and the
   Length MUST be a multiple of 16.


6. TCP Parameters

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


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


7. DHCPv6 Extensions

   This section details the extensions that are specific to DHCPv6.


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



Perkins               Expires 13 September 1998                [Page 21]


Internet Draft              DHCPv6 Extensions              13 March 1998


   size is specified as an unsigned 16-bit integer.  A client may use
   the maximum DHCPv6 message size extension in DHCP Request messages,
   but MUST NOT use the extension in other DHCP messages (see [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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Max DHCPv6 Message Length   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Type for this extension is 40, and its Length is 2.  The minimum
   permissible value is 1500.


7.2. Platform Specific Information

   A platform is defined as the combination of hardware and operating
   system (OS).

   This extension is used by clients and servers to exchange
   client-platform-specific information.  The information is an opaque
   collection of data, presumably interpreted by platform-specific code
   on the clients.  The definition of this information is platform
   specific.  Clients identify their platform through the use of the
   Platform Class identifier extension (see Section 7.3).  Clients which
   do not receive platform specific information SHOULD make an attempt
   to operate without it, although they may do so (and announce that
   they are doing so) in a degraded mode.

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

   The Encapsulated platform-specific extensions field MUST be
   encoded as a sequence of type/length/value fields of identical
   syntax to the form defined for DHCPv6 extensions.  Extension
   65535 (END), if present, signifies the end of the encapsulated
   platform extensions, not the end of the platform extensions field.
   If no extension 65535 is present, then the end of the enclosing
   platform-specific information field is taken as the end of the
   encapsulated platform-specific extensions field.









Perkins               Expires 13 September 1998                [Page 22]


Internet Draft              DHCPv6 Extensions              13 March 1998


   The Type for this extension is 48 and its minimum Length is 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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Platform-specific extension information  ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   When encapsulated platform-specific extensions are used, each one has
   the same format as just shown.  In other words, all platform-specific
   extensions are encoded in Type-Length-Value (TLV) format.  More than
   one platform-specific extension can, therefore, be included in the
   same DHCP "Platform Specific Information" extension.

   DHCP servers which support the configuration of Platform Specific
   Information extensions, and which have been configured with
   configuration information specific to some number of Platform Class
   Identifiers MUST select and return only those platform-specific
   extensions which match the Platform Class Identifier provided by the
   DHCP client.


7.3. Platform Class Identifier

   This extension is used by a DHCP client to identify the hardware type
   and operating system platform it is hosted on.  The extension value
   itself is an opaque value to a DHCP server, and is only used by the
   DHCP server to "lookup" Platform Specific Extensions associated with
   clients of a certain platform class.

   Servers not equipped to interpret the platform 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 platform class identifier specified by the
   client.

   Note that unlike the User Class Identifier, the Platform Class
   Identifier does not need to be echoed back to the DHCP client because
   there can be one and only one Platform Class Identifier for a 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         |  Platform Class Identifier ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Perkins               Expires 13 September 1998                [Page 23]


Internet Draft              DHCPv6 Extensions              13 March 1998


   The Type for this extension is 49.  The platform class identifier is
   a string of characters in the character set specified by the Char
   Encoding field (see section 2.1), of length "Length"-2 octets.  The
   platform class identifier represents the hardware and Operating
   system class of which the client is a member.

   In order to prevent collisions in the Platform Class Identifier
   namespace, we recommend that platform vendors prefix their Platform
   Class Identifiers with their Stock symbol or some other globally
   recognized authority.  For example, Platform Class Identifiers for
   Sun Microsystems Inc platforms would be prefaced by "SUNW", the
   NASDAQ stock symbol for Sun.


7.4. 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 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 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 class identifier specified by the client.  Further, if the server
   responds with the set of extensions corresponding to the given class
   identifier, it MUST return this extension (with the given 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 Type for this extension is 64.  The class identifier is a string
   of characters in the character set specified by the Char Encoding
   field (see section 2.1), of length "Length"-2 octets.  The class
   identifier represents the class identifier of which the client is a
   member.




Perkins               Expires 13 September 1998                [Page 24]


Internet Draft              DHCPv6 Extensions              13 March 1998


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


7.6. Renumber DHCPv6 Server Address

   A DHCPv6 server can instruct its clients to change their internal
   records to reflect the server's newly renumbered IP 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.


7.7. DHCP Relay ICMP Error Message Format

   A DHCP Relay ICMP Message extension is used to inform a client of
   an ICMP Error message the relay received after forwarding a client
   Solicit or Request message.





Perkins               Expires 13 September 1998                [Page 25]


Internet Draft              DHCPv6 Extensions              13 March 1998



      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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      ICMP Error Message                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Type of the DHCP Relay ICMP Message extension is 68, and the
   Length is the length of the ICMP error message received by the
   relay [8].


7.7.1. ICMP Extension Client Considerations

   When a client sends a Solicit or Request message it can be forwarded
   by a relay.  When the relay forwards messages for a client the
   network may return an ICMP error [8] message to the relay.  If the
   relay can determine the client's link-local address within the
   UDP payload of the ICMP returned error message payload, the relay
   will send the client a DHCP Relay ICMP Error message as defined in
   section 7.7.2.

   The client MAY record these messages based on the ICMP type and
   reason codes provided in the ICMP Error payload [8], for future use
   or for system logging purposes.  How the client uses this information
   is implementation dependent.


7.7.2. ICMP Extension Relay Considerations

   If the relay receives an ICMP error message after forwarding a client
   Solicit or Request message, it should look in the payload of the
   ICMP message [8], to see if it can determine the clients link-local
   address in the server Advertise or Reply message.  If it can the
   relay should forward a DHCP Relay ICMP Error message received to the
   client as specified in section 7.7.1, by using the clients link-local
   address from the ICMP error message as the IP source address in the
   IP header sent to the client.  If the relay cannot determine the
   clients link-local address in the ICMP error message the packet MUST
   be silently discarded.


7.8. Client-Server Authentication Extension

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



Perkins               Expires 13 September 1998                [Page 26]


Internet Draft              DHCPv6 Extensions              13 March 1998



    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   (unsigned integer, variable) 4 for the SPI, plus 8 for
               the replay protection, plus the number of octets in the
               Authenticator.

      SPI      A Security Parameters index [2] identifying which
               security context among those available between the DHCPv6
               client and server.

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

      Authenticator
               (variable length) (See Section 9.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 has no IPv6 address of large enough scope
   to reach the DHCP server.  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 9.2.

   Note that SPI values 0 through 255 are reserved and, if used, MUST
   conform to the security context defined by that value in the most
   recent Assigned Numbers RFC (e.g., [21]).


7.9. Client Key Selection Extension

   A DHCPv6 server may wish to indicate to a prospective client which
   SPI it must use to authenticate subsequent messages, using the
   Client-Server Authentication Extension.  In such cases, the server



Perkins               Expires 13 September 1998                [Page 27]


Internet Draft              DHCPv6 Extensions              13 March 1998


   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)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type     85

      Length   4

      SPI      A Security Parameters index [2] 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., [12]).


8. End extension specification

   The end extension marks the end of valid information in the vendor
   field.  The Type for the end extension is 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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


9. 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 7.8.  See
   also the Security Considerations in the companion specification [4].






Perkins               Expires 13 September 1998                [Page 28]


Internet Draft              DHCPv6 Extensions              13 March 1998


9.1. Replay Protection

   A 64-bit timestamp, in Network Time Protocol [18](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.


9.2. Default Authentication Algorithm

   The default authentication algorithm is HMAC [15], using
   keyed-MD5 [22].  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 octets
   in all previous fields in the DHCPv6 message and extensions.  The
   authenticator is the 128-bit value HMAC_result.


10. 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 extension MUST follow these steps to obtain
   acceptance of the extension as a part of the DHCP Internet Standard:

    1. The author devises the new extension.





Perkins               Expires 13 September 1998                [Page 29]


Internet Draft              DHCPv6 Extensions              13 March 1998


    2. The author requests a number for the new extension 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

    3. The author documents the new extension, using the newly obtained
       extension 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" [14].  The new extension will be submitted for
       eventual acceptance as an Internet Standard.

    5. The new extension progresses through the IETF standards
       process; the new extension 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 extension fails to gain acceptance as an Internet
       Standard, the assigned extension number will be returned to IANA
       for reassignment.

   This procedure for defining new extensions will ensure that:

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

     * new extensions are reviewed for technical correctness and
       appropriateness, and

     * documentation for new extensions is complete and published.

















Perkins               Expires 13 September 1998                [Page 30]


Internet Draft              DHCPv6 Extensions              13 March 1998


11. 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.  Thanks to Mike Carney for his
   many helpful comments, as well as contributing the design of the
   Platform Specific Information and Platform Class Identifier.  Thanks
   to Erik Guttman for his helpful suggestions for the Service Location
   extensions.  Thanks to Matt Crawford and Erik Nordmark for their
   careful review as part of the Last Call process.  Jim Bound also
   provided all the necessary design and text for the DHCP Relay ICMP
   Error Message Extension.


References

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

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

    [3] T. Berners-Lee, L. Masinter, and M. McCahill.  Uniform Resource
        Locators (URL).  RFC 1738, December 1994.

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

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

    [6] M. W. Carney.  DHCP Option for IEEE 1003.1 POSIX Timezone
        Specifications.  draft-ietf-dhc-timezone-01.txt, January 1997.
        (work in progress).

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

    [8] A. Conta and S. Deering.  Internet Control Message Protocol
        (ICMPv6) for the Internet Protocol Version 6 (IPv6).  RFC 1885,
        December 1995.

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






Perkins               Expires 13 September 1998                [Page 31]


Internet Draft              DHCPv6 Extensions              13 March 1998


   [10] E. Guttman, C. Perkins, and J. Kempf.  Service Templates and
        service:  Schemes.  draft-ietf-svrloc-service-scheme-05.txt,
        November 1997.  (work in progress).

   [11] E. Guttman, C. Perkins, J. Veizades, and M. Day.  Service
        Location Protocol version 2.  draft-ietf-svrloc-protocol-v2-04.txT,
        March 1998.  (work in progress).

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

   [13] IEEE.  1003.1 POSIX Timezone Specification, 1988.

   [14] Editor J. Postel.  INTERNET OFFICIAL PROTOCOL STANDARDS.  STD 1,
        July 1997.

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

   [16] Sun Microsystems.  System and Network Administration, March
        1992.

   [17] D. Mills.  Simple Network Time Protocol (SNTP) Version 4 for
        IPv4, IPv6 and OSI.  RFC 2030, October 1996.

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

   [19] P. Mockapetris.  Domain Names - Concepts and Facilities.  IETF
        STD 13, November 1987.

   [20] Joyce K. Reynolds and Jon Postel.  Assigned Numbers.  STD 2,
        October 1994.

   [21] Joyce K. Reynolds and Jon Postel.  Assigned Numbers.  RFC 1700,
        October 1994.

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

   [23] S. Thomson and T. Narten.  IPv6 Stateless Address
        Autoconfiguration.  RFC 1971, August 1996.

   [24] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan.  Service
        Location Protocol.  RFC 2165, July 1997.

   [25] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound.  Dynamic Updates
        in the Domain Name System (DNS).  RFC 2136, April 1997.



Perkins               Expires 13 September 1998                [Page 32]


Internet Draft              DHCPv6 Extensions              13 March 1998


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 E. Perkins
      Technology Development Group
      Mail Stop MPK15-214
      Room 2682
      Sun Microsystems, Inc.
      901 San Antonio Road
      Palo Alto, California 94303
      USA

      Phone:  +1-650-786-6464
      Fax:  +1-650-786-6445
      email:  charles.perkins@Sun.COM





















Perkins               Expires 13 September 1998                [Page 33]


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