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

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

Internet Engineering Task Force                               C. Perkins
INTERNET DRAFT                                                       IBM
                                                        22 February 1996


                         Extensions for DHCPv6
                      draft-ietf-dhc-v6exts-00.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
   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).


Abstract

   The Dynamic Host Configuration Protocol for IPv6 [3] (DHCPv6)
   provides a framework for passing configuration information to hosts
   on a TCP/IP network.  Configuration parameters and other control
   information are carried in tagged 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.







Perkins                 Expires 22 August 1996                  [Page i]


Internet Draft            DHCPv6 Extensions             22 February 1996




                                Contents



Status of This Memo                                                    i

Abstract                                                               i

 1. Introduction                                                       1

 2. DHCPv6 Extension Field Format                                      1

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

 4. IPv6 Address extension specification                               2
     4.1. Client Considerations for the IPv6 Address extension  . .    4
           4.1.1. Address Lifetimes . . . . . . . . . . . . . . . .    4
           4.1.2. Use with the DHCP Request message . . . . . . . .    5
           4.1.3. Use with the DHCP Release message . . . . . . . .    6
     4.2. Server Considerations for the IPv6 Address extension  . .    6
           4.2.1. Use with the DHCP Advertise message . . . . . . .    6
     4.3. Receiving a DHCP Request with the IPv6 Address Extension     6
           4.3.1. Use with the DHCP Reply message . . . . . . . . .    6
           4.3.2. Use with the DHCP Reconfigure message . . . . . .    7
     4.4. DHCP Relay Considerations . . . . . . . . . . . . . . . .    7
     4.5. Alternate Design possibility  . . . . . . . . . . . . . .    7

 5. General Extensions                                                 8
     5.1. Time Offset . . . . . . . . . . . . . . . . . . . . . . .    8
     5.2. Router Extension  . . . . . . . . . . . . . . . . . . . .    8
     5.3. Domain Name Server Extension  . . . . . . . . . . . . . .    9
     5.4. Resource Location Server Extension  . . . . . . . . . . .    9
     5.5. Domain Name . . . . . . . . . . . . . . . . . . . . . . .    9

 6. IP Layer Parameters per Interface                                 10
     6.1. Static Route Extension  . . . . . . . . . . . . . . . . .   10

 7. TCP Parameters                                                    10
     7.1. TCP Default TTL Extension . . . . . . . . . . . . . . . .   10
     7.2. TCP Keepalive Interval Extension  . . . . . . . . . . . .   11

 8. Vendor Specific Information                                       11

 9. DHCPv6 Extensions                                                 12



Perkins                 Expires 22 August 1996                 [Page ii]


Internet Draft            DHCPv6 Extensions             22 February 1996


     9.1. Maximum DHCPv6 Message Size . . . . . . . . . . . . . . .   12
     9.2. Class-identifier  . . . . . . . . . . . . . . . . . . . .   13
     9.3. Mobile Home Address Extension . . . . . . . . . . . . . .   13

10. Neighbor Discovery Extensions                                     14

11. Extensions                                                        14

12. Acknowledgements                                                  14

13. Security Considerations                                           14

Chair's Address                                                       17

Author's Address                                                      17




































Perkins                Expires 22 August 1996                 [Page iii]


Internet Draft            DHCPv6 Extensions             22 February 1996


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

   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 11.
   Although extension numbers in this document correspond closely to the
   analogous numbers in the options specification for IPv4 [2], there is
   no requirement to keep numbering future extensions in any consistent
   manner except purely as a matter of editorial and cross-referencing
   convenience.


2. DHCPv6 Extension Field Format

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

   Any extensions defined subsequent to this document should contain a
   length octet even if the length is fixed or zero.

   All multi-octet quantities are in network byte-order.

   Extension codes 128 to 254 (decimal) are reserved for site-specific
   extensions.

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



Perkins                 Expires 22 August 1996                  [Page 1]


Internet Draft            DHCPv6 Extensions             22 February 1996


      DISCUSSION:    Should the DHCPv6 Extensions be put into a format
                     similar to IPv6 options?

      DISCUSSION:    Should individual Extensions in Request messages be
                     rejected individually?


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 code for the pad extension is 0, and its length is 1 octet.

    Code
   +-----+
   |  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 code for the end extension is 255, and its length is 1 octet.

    Code
   +-----+
   | 255 |
   +-----+


4. IPv6 Address extension specification

   The IPv6 Address extension is the most essential of all the DHCPv6
   extensions.  It is relatively complex and and 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, hence the added complexity.  Much of this
   added complexity also derives from various possible ways that
   updating DNS may be specified within the IPv6 Address extension.






Perkins                 Expires 22 August 1996                  [Page 2]


Internet Draft            DHCPv6 Extensions             22 February 1996


   An IPv6 Address Extension can contain at most one IPv6 address.  To
   specify more than one IPv6 address, multiple extensions are used.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    ext-type   |   ext-length  |C|P|V|N|D|Q|A|P|   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)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      ext-type             1

      ext-length           The length of the Extension.

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

      P                    If the 'P' bit is set, the preferred lifetime
                           is present in the extension.

      V                    If the 'V' bit is set, the valid lifetime is
                           present in the extension.

      N                    If the 'N' bit is set, the extension contains
                           the DNS name subfield.

      D                    If the 'D' bit is set, the client is not
                           required to perform Duplicate Address
                           Detection.

      M                    If the 'M' bit is set, the fields included by
                           the client are mandatory, 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 update
                           the DNS specified by the client's FQDN with




Perkins                 Expires 22 August 1996                  [Page 3]


Internet Draft            DHCPv6 Extensions             22 February 1996


                           a new AAAA record before responding with the
                           corresponding DHCP Reply.

      P                    If the 'P' bit is set, the server MUST update
                           the DNS specified by the client's FQDN with
                           a new PTR record before responding with the
                           corresponding DHCP Reply.

      pfx-size             If the client address is present (the 'C'
                           bit is set), then the 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.

      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

      valid lifetime       The valid lifetime of the IPv6 address

      DNS name             The DNS name (a zero-terminated character
                           string) to be used by the client (variable
                           length).

   The DNS name can be either a host name, which does not contain the
   '.'  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
   the length of those fixed-length fields which are present from the
   ext-length.


4.1. Client Considerations for the IPv6 Address extension

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



Perkins                 Expires 22 August 1996                  [Page 4]


Internet Draft            DHCPv6 Extensions             22 February 1996


   MUST assume the client does not want that address.  The server MAY
   provide that address to another client requesting an address, after
   all other addresses available to the server have been exhausted.

   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] for required handling
   of deprecated IPv6 addresses.  When an address for a DHCPv6 client's
   interface becomes deprecated, the processing of the lifetime 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).


4.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 name and/or FQDN.

    -  request that server DNS update AAAA and/or PTR record.

    -  specify whether address and/or name (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 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 address listed in the
   IP Address extension to the DHCP Request, by specifying the 'M'
   (Mandatory) bit.

   Note that to delete DNS information, a client can use a DHCP Release
   message.







Perkins                 Expires 22 August 1996                  [Page 5]


Internet Draft            DHCPv6 Extensions             22 February 1996


4.1.3. Use with the DHCP Release message

   In DHCP Release (for each address extension):

    -  Client can include an IPv6 address and/or name and/or FQDN.

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

    -  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. Server Considerations for the IPv6 Address extension

4.2.1. Use with the DHCP Advertise message

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

    -  the FQDN

    -  the preferred lifetime

    -  whether DNS will accept new names for the address


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




Perkins                 Expires 22 August 1996                  [Page 6]


Internet Draft            DHCPv6 Extensions             22 February 1996


   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

    -  whether PTR has been DNS updated

   If the client requests updates, and sets the 'M' bit, the server MUST
   NOT issue the DHCP Reply until after receiving positive indication
   that the DNS update has indeed been performed.

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


4.3.2. Use with the DHCP Reconfigure message

   In DHCP Reconfigure (for each address extension) the server can
   indicate

    -  the DNS name


4.4. 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.5. Alternate Design possibility

      DISCUSSION:    Instead of trying to collect together everything
                     about IPv6 addresses in one single extension, it
                     would also be possible to break the DNS stuff into
                     separate Extensions.  Since there may be multiple
                     such IPv6 addresses allocated in a single DHCP
                     Reply, we would have to adopt the convention that
                     the subsequent extensons relevant to IPv6 addresses
                     apply always to the last IPv6 address in the
                     closest preceding IPv6 address extension.





Perkins                 Expires 22 August 1996                  [Page 7]


Internet Draft            DHCPv6 Extensions             22 February 1996


                     I find the above sort of context-sensitive
                     Extension processing is a cure worse than the
                     disease of a single mildly complicated IPv6 Address
                     Extension which has all the stuff an IPv6 address
                     needs.


5. General Extensions

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


5.1. Time Offset

   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.

   The code for the time offset extension is 2, and its length is 4
   octets.

    Code   Len        Time Offset
   +-----+-----+-----+-----+-----+-----+
   |  2  |  4  |  n1 |  n2 |  n3 |  n4 |
   +-----+-----+-----+-----+-----+-----+


5.2. Router Extension

   The router extension specifies a list of IP addresses for routers
   on the client's subnet.  Routers SHOULD be listed in order of
   preference.

   The code for the router extension is 3.  The minimum length for
   the router extension is 16 octets, and the length MUST always be a
   multiple of 16.

    Code   Len   Address 1               Address 2
   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
   |  3  |  n  |  a1 |  a2 | ... | a16 |  a1 |  a2 | ... | a16 | ...
   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----









Perkins                 Expires 22 August 1996                  [Page 8]


Internet Draft            DHCPv6 Extensions             22 February 1996


5.3. Domain Name Server Extension

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

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

    Code   Len   Address 1               Address 2
   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
   |  6  |  n  |  a1 |  a2 | ... | a16 |  a1 |  a2 | ... | a16 | ...
   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----


5.4. Resource Location Server Extension

   This extension specifies a list of Resource Location servers [8]
   available to the client.  Servers SHOULD be listed in order of
   preference.

   The code for this extension is 11.  The minimum length for this
   extension is 16 octets, and the length MUST always be a multiple of
   16.

    Code   Len   Address 1               Address 2
   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
   |  11 |  n  |  a1 |  a2 | ... | a16 |  a1 |  a2 | ... | a16 | ...
   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----


5.5. Domain Name

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

   The code for this extension is 15.  Its minimum length is 1.

    Code   Len        Domain Name
   +-----+-----+-----+-----+-----+-----+--
   |  15 |  n  |  d1 |  d2 |  d3 |  d4 |  ...
   +-----+-----+-----+-----+-----+-----+--








Perkins                 Expires 22 August 1996                  [Page 9]


Internet Draft            DHCPv6 Extensions             22 February 1996


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


6.1. Static Route Extension

   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 descending order of
   priority.

   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, and the default route (0.0.0.0) is an illegal
   destination for a static route.  See section 5.2 for information
   about the router extension.

   The code for this extension is 33.  The minimum length of this
   extension is 32, and the length MUST be a multiple of 16.

    Code   Len         Destination 1           Router 1
   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
   |  33 |  n  |  d1 |  d2 | ... | d16 |  r1 |  r2 | ... | r16 |
   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
           Destination 2           Router 2
   +-----+-----+-----+-----+-----+-----+-----+-----+---
   |  d1 |  d2 | ... | d16 |  r1 |  r2 | ... | r16 | ...
   +-----+-----+-----+-----+-----+-----+-----+-----+---


7. TCP Parameters

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


7.1. TCP Default TTL Extension

   This extension specifies the default TTL that the client should use
   when sending TCP segments.  The value is represented as an 8-bit
   unsigned integer.  The minimum value is 1.




Perkins                 Expires 22 August 1996                 [Page 10]


Internet Draft            DHCPv6 Extensions             22 February 1996


   The code for this extension is 37, and its length is 1.

    Code   Len   TTL
   +-----+-----+-----+
   |  37 |  1  |  n  |
   +-----+-----+-----+


7.2. TCP Keepalive Interval Extension

   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 code for this extension is 38, and its length is 4.

    Code   Len           Time
   +-----+-----+-----+-----+-----+-----+
   |  38 |  4  |  t1 |  t2 |  t3 |  t4 |
   +-----+-----+-----+-----+-----+-----+


8. Vendor Specific Information

   This extension is used by clients and servers to exchange vendor-
   specific information.  The information is an opaque object of n
   octets, 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 encode the extension using
   "Encapsulated vendor-specific extensions" as described below:

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

      -    Codes other than 0 or 255 MAY be redefined by the vendor
           within the encapsulated vendor-specific extensions field,



Perkins                 Expires 22 August 1996                 [Page 11]


Internet Draft            DHCPv6 Extensions             22 February 1996


           but SHOULD conform to the tag-length-value syntax defined in
           section 2.

      -    Code 255 (END), if present, signifies the end of the
           encapsulated vendor extensions, not the end of the vendor
           extensions field.  If no code 255 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 code for this extension is 43 and its minimum length is 1.

   Code   Len   Vendor-specific information
   +-----+-----+-----+-----+---
   |  43 |  n  |  i1 |  i2 | ...
   +-----+-----+-----+-----+---

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

    Code   Len   Data item        Code   Len   Data item       Code
   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
   |  T1 |  n  |  d1 |  d2 | ... |  T2 |  n  |  D1 |  D2 | ... | ... |
   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+


9. DHCPv6 Extensions

   This section details the extensions that are specific to DHCPv6.


9.1. Maximum DHCPv6 Message Size

   This extension specifies the maximum length DHCPv6 message that it
   is willing to accept.  The length 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]), and MUST NOT use the extension in other
   DHCP messages.

   The code for this extension is 57, and its length is 2.  The minimum
   legal value is 1500 octets.

    Code   Len     Length
   +-----+-----+-----+-----+
   |  57 |  2  |  l1 |  l2 |
   +-----+-----+-----+-----+





Perkins                 Expires 22 August 1996                 [Page 12]


Internet Draft            DHCPv6 Extensions             22 February 1996


9.2. Class-identifier

   This extension may be used by DHCPv6 clients to identify the type and
   configuration of a DHCPv6 client.  The information is a string of
   n octets, interpreted by servers.  Vendors and sites may choose to
   define specific class identifiers to convey particular configuration
   or other identification information about a client.  For example, the
   identifier may encode the client's hardware configuration.  Servers
   not equipped to interpret the class-specific information sent by a
   client MUST ignore it (although it may be reported).

   The code for this extension is 60, and its minimum length is 1.

   Code   Len   Class-Identifier
   +-----+-----+-----+-----+---
   |  60 |  n  |  i1 |  i2 | ...
   +-----+-----+-----+-----+---


9.3. Mobile Home Address Extension

   When this extension is present in a client request message, the
   DHCPv6 server is asked to send an appropriate home address to the
   mobile host.  The DHCPv6 server, in its corresponding offering
   message, will insert the requested address into the usual place for
   requested IP addresses.  The DHCPv6 server will typically notify the
   mobile host of (one of) its home agents' addresses, as configured by
   the local administration to be associated with the address given to
   the mobile host.  That home agent's IP address is inserted in the
   data field of the mobile home address extension.

   A mobile node with a known mobile home address can dynamically
   discover the location of a home agent serving the home address [1].
   In that case, the DHCPv6 server may be configured to send out mobile
   home addresses and expect that the mobile host discover the home
   agent's address by whichever method is approved by the working group.

   It is also anticipated that many installations will allow several
   home agents to serve the same mobile home addresses, for redundancy
   or load sharing.  For this reason, we have also allowed for the
   possibility that the DHCPv6 server may wish to insert multiple home
   agent addresses in the mobile home address extension.

   The format of the mobile home address extension is as follows:

            Code Len    Home Address
            +----+----+-----+-----+-----+-----+
            | 68 | n  |  a1 | a2  | ... | a16 |



Perkins                 Expires 22 August 1996                 [Page 13]


Internet Draft            DHCPv6 Extensions             22 February 1996


            +----+----+-----+-----+-----+-----+
            Home Agent Addresses (zero or more)
            +----+----+-----+-----+-----+ - --+ - -+ - -+ - -+
            | a1 | a2 | ... | a16 | ...
            +----+----+-----+-----+-----+ - --+ - -+ - -+ - -+

   The code for the mobile home address extension is 68.  The length is
   16, plus 16 octets multiplied by the number of home agents supplied
   in the extension, which may be zero or more.  It is expected that
   the usual length will be 32 octets, containing a single home agent's
   address.


10. Neighbor Discovery Extensions

   This section contains extension definitions for specifying parameters
   that are useful with IPv6 Neighbor Discovery [6].


11. Extensions

   Additional generic data fields may be registered 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 generic types (including
   those in the range 69-127) may conflict with other implementations,
   and registration is required.

      DISCUSSION:    Need to read Ralph's new draft and incorporate
                     those ideas here.


12. Acknowledgements

   Quite a bit of this internet draft is copied directly from
   RFC1533 [2], written by Steve Alexander and Ralph Droms.


13. Security Considerations

   Security issues are not discussed in this memo.  However, there
   is an urgent need to define some security protocol for use with



Perkins                 Expires 22 August 1996                 [Page 14]


Internet Draft            DHCPv6 Extensions             22 February 1996


   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.

      DISCUSSION:    SHOULD there be a DHCP Authentication Extension,
                     or should security be accomplished end-to-end by
                     IPSec, but with intermediary relays performing
                     encapsulation so as not to disturb the IPSec-style
                     end-to-end authentication.









































Perkins                 Expires 22 August 1996                 [Page 15]


Internet Draft            DHCPv6 Extensions             22 February 1996


References

   [1] IPv4 Mobility Support.  ietf-draft-mobileip-protocol-15.txt -
       work in progress, February 1996.

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

   [3] J. Bound and C. Perkins.  Dynamic Host Configuration Protocol for
       IPv6.  draft-ietf-dhc-dhcpv6-04.txt -- work in progress, February
       1995.

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

   [5] P. Mockapetris.  DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION.
       RFC 1035, November 1987.

   [6] T. Narten, E. Nordmark, and W. Simpson.  IPv6 Neighbor Discovery.
       draft-ietf-ipngwg-discovery-03.txt -- work in progress, November
       1995.

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

   [8] J. Veizades, S. Kaplan, E. Guttman, and C. Perkins.  Service
       Location Protocol.  draft-ietf-svrloc-protocol-09.txt - work in
       progress, February 1996.























Perkins                 Expires 22 August 1996                 [Page 16]


Internet Draft            DHCPv6 Extensions             22 February 1996


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
          Room J1-A25
          T. J. Watson Research Center
          IBM Corporation
          30 Saw Mill River Rd.
          Hawthorne, NY  10532

          Work:   +1-914-784-7350
          Fax:    +1-914-784-6205
          E-mail: perk@watson.ibm.com























Perkins                 Expires 22 August 1996                 [Page 17]


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