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

Versions: (draft-johnson-dhc-subnet-alloc) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 RFC 6656

Network Working Group                                         R. Johnson
Internet-Draft                                             J. Jumarasamy
Expires: December 31, 2005                                    K. Kinnear
                                                                M. Stapp
                                                     Cisco Systems, Inc.
                                                           June 29, 2005


                        Subnet Allocation Option
                   draft-ietf-dhc-subnet-alloc-03.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 31, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document defines a new DHCP option which is passed between the
   DHCP Client to the DHCP Server to request dynamic allocation of a
   subnet, give specifications of subnet(s) allocated, and report usage
   statistics.  The option number currently in use is 220.  This memo
   documents the current usage of the option in agreement with RFC-
   3942[7] , which declares that any pre-existing usages of option



Johnson, et al.         Expires December 31, 2005               [Page 1]


Internet-Draft          Subnet Allocation Option               June 2005


   numbers in the range 128 - 223 should be documented and the working
   group will try to officially assign those numbers to those options.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Subnet Allocation Option format  . . . . . . . . . . . . . . .  5
     3.1   Request Suboption format . . . . . . . . . . . . . . . . .  5
     3.2   Subnet Information Suboption format  . . . . . . . . . . .  7
     3.3   Subnet Prefix Information Suboption format . . . . . . . .  7
       3.3.1   Subnet Usage Statistics  . . . . . . . . . . . . . . .  8
     3.4   Subnet Name Suboption format . . . . . . . . . . . . . . .  9
     3.5   Subnet Suggested Lease Time Suboption format . . . . . . . 10
   4.  Requesting allocation of a subnet  . . . . . . . . . . . . . . 11
     4.1   Client DISCOVER message  . . . . . . . . . . . . . . . . . 11
     4.2   Server OFFER message . . . . . . . . . . . . . . . . . . . 11
     4.3   Client DHCP REQUEST message  . . . . . . . . . . . . . . . 12
     4.4   Server DHCP ACK message  . . . . . . . . . . . . . . . . . 12
   5.  Client renewal of subnet lease . . . . . . . . . . . . . . . . 14
     5.1   Client RENEW REQUEST message . . . . . . . . . . . . . . . 14
     5.2   Server RENEW response  . . . . . . . . . . . . . . . . . . 14
     5.3   Client RELEASE message . . . . . . . . . . . . . . . . . . 15
     5.4   Server RECONFIGURE message . . . . . . . . . . . . . . . . 15
   6.  Client requesting subnet allocation information  . . . . . . . 16
     6.1   Client DISCOVER message  . . . . . . . . . . . . . . . . . 16
     6.2   Server OFFER response  . . . . . . . . . . . . . . . . . . 16
     6.3   Client additional DISCOVER messages  . . . . . . . . . . . 16
     6.4   Server additional OFFER messages . . . . . . . . . . . . . 17
   7.  DHCP Server Subnet Allocation method . . . . . . . . . . . . . 18
   8.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     8.1   Example 1: . . . . . . . . . . . . . . . . . . . . . . . . 19
     8.2   Example 2: . . . . . . . . . . . . . . . . . . . . . . . . 20
   9.  Differences with DHCPv6 Prefix Delegation  . . . . . . . . . . 24
   10.   Security Considerations  . . . . . . . . . . . . . . . . . . 25
   11.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 26
   12.   Intellectual Property Rights . . . . . . . . . . . . . . . . 27
   13.   References . . . . . . . . . . . . . . . . . . . . . . . . . 27
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27
       Intellectual Property and Copyright Statements . . . . . . . . 29











Johnson, et al.         Expires December 31, 2005               [Page 2]


Internet-Draft          Subnet Allocation Option               June 2005


1.  Introduction

   There is a need for a DHCP Client to be able to allocate a subnet
   from a DHCP Server.  Alternate methods of allocation, such as AAA are
   not appropriate for various reasons and the most straight-forward way
   to accomplish this allocation is via DHCP.  A DHCP option to support
   this may be utilized by a simple Dialin Aggregation box, or even to
   implement a Hierarchical chain of DHCP Servers, each one in turn
   leasing one or more subnets to the next DHCP Server down the chain.

   This new DHCP option [3], the Subnet Allocation option is specified
   in such a way as to use one DHCP Option number, while using suboption
   numbers for each function.  The Subnet-Request suboption tells what
   types of subnets are needed and how many.  The "Subnet Information"
   suboption gives the actual subnet number(s) and allows for extra
   flags to convey additional information about each subnet.  The
   "Subnet Name" suboption allows a method of passing additional
   information about the requested subnet(s), such as department name,
   user name, customer number, etc.  The DHCP Server has the option of
   not supplying all subnets requested or even returning smaller subnets
   than was requested.  The "Subnet Usage Statistics" suboption is used
   to report usage information from the DHCP Client back to the DHCP
   Server.




























Johnson, et al.         Expires December 31, 2005               [Page 3]


Internet-Draft          Subnet Allocation Option               June 2005


2.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].

   This document also uses the following terms:

   DHCP Client: DHCP Client or "Client" is an Internet host using DHCP
      to obtain configuration parameters such as a network address.

   DHCP Server: A DHCP Server or "Server" is an Internet host that
      returns configuration parameters to DHCP Clients.






































Johnson, et al.         Expires December 31, 2005               [Page 4]


Internet-Draft          Subnet Allocation Option               June 2005


3.  Subnet Allocation Option format

   0                   1                   2
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |     Len       |     Flags     | Suboptions ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Code = Subnet Allocation option code (1 octet) 220

   Len = Length of the entire option including all sub-options and
      excluding the "Code" and "Len" fields above (1 octet)

   Flags = Various flags:  (None currently defined)

   One or more sub-options may be specified as described below.

3.1  Request Suboption format

   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 2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       1       |     Len       |     Flags |i|h|    Prefix     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Len = Length of the suboption excluding the subcode and Len fields (1
      octet)

   Flags = Flags field. (all unused bits MBZ)

      'h'

         '1' = Client will be allocating addresses from this subnet.

         '0' = Client will be relaying DHCP requests to the Server from
            this subnet.

      'i'

         '1' = Client is seeking information about previously allocated
            subnets.

         '0' = Client is seeking a new subnet allocation.








Johnson, et al.         Expires December 31, 2005               [Page 5]


Internet-Draft          Subnet Allocation Option               June 2005


   Prefix = Size of the subnet needed [6] (number of bits in subnet
      prefix) (zero (0) means no suggested size is given) (1 octet)

   The DHCP Server SHOULD NOT include the Subnet Request suboption in
   any replies to the DHCP Client.  Enough information will be present
   in the Subnet Information suboption, such that the Subnet Request
   suboption is not needed in replies to the Client.

   The DHCP Server SHOULD allocate a subnet with prefix size less than
   or equal to the size P specified in the request.  In other words, a
   subnet at least the size requested and possibly bigger.

   A size P of zero (0) MAY be specified by the DHCP Client.  In this
   case, no suggested size is given and the Server is free to return
   subnet(s) of whatever size is deemed appropriate by the Server.

   Multiple Subnet Request suboptions in a DHCP packet indicate that
   multiple sizes of subnets are being requested.

   Each Subnet Request suboption MUST result in no more than one (1)
   Subnet Information suboption in the DHCP OFFER message from the
   Server, and may result in zero (0) Subnet Information suboptions.

   The Client MAY also include the Subnet Information suboption
   (described below) in order to request a particular subnet.  In this
   case, the Client SHOULD only include one (1) Subnet Request
   suboption, since it would otherwise be unclear which Subnet
   Information suboption refered to which Subnet Request suboption.
   Multiple subnet requests can be made by sending multiple DHCP
   DISCOVER packets.

   Setting the "h" flag to "1" indicates the Client will be allocating
   addresses from the allocated subnet(s) itself.  This can be thought
   of as a "Hierarchial DHCP" design in that control of allocation for
   the subnet(s) will be passed to the Client.

   Setting the "h" flag to "0" indicates the Client wants the DHCP
   Server to retain control over allocation of addresses from the
   subnet(s).  In this case, the Server should simply mark the subnet(s)
   as "used" by this Client and not return the subnet(s) in any Subnet
   Information suboptions to any other client.  (Any address allocation
   requests on the subnet will be relayed back to the DHCP Server.)

   Setting the "i" flag to "1" indicates the Client is NOT seeking
   allocation of any subnets, but is simply seeking information from the
   Server as to what subnet(s) have been allocated (or reserved) for
   this Client.  If the "i" flag is set to "1", then the "P" field
   SHOULD be set to "0" and MUST be ignored by the Server.



Johnson, et al.         Expires December 31, 2005               [Page 6]


Internet-Draft          Subnet Allocation Option               June 2005


3.2  Subnet Information Suboption format

   0                   1                   2
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       2       |     Len       | Flags     |c|s| SP1, SP2, ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Len = Length of the sub-option excluding the Subcode and Len fields
      (1 octet)

   Flags = Various flags which apply to ALL Subnet Prefix Information
      fields specified in this suboption

      'c' = Client flag (explained below)

      's' = Server flag (explained below)

   SP1,SP2 = Subnet Prefix information as specified below (variable
      sized)

   The "Client flag" ("c") is set to "1" if this Subnet Information
   suboption is in response to a Client request for information from the
   Server as to what subnet(s) have been allocated.  This flag is only
   used in response to a Subnet Request suboption with the "i" flag set
   and should be zero (0) otherwise.

   The "Server flag" ("s") is set to "1" if the Server has additional
   subnet information for the Client.

3.3  Subnet Prefix Information Suboption format

   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 2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Address                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Prefix     |     Flags |h|d|   Stat-len    |  Optional stats...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Addr = IPv4 address (4 octets)

   Prefix = Specifying number of prefix bits in the subnet (1 octet)

   Flags = Flags field  (Undefined bits must be zero) (1 octet)






Johnson, et al.         Expires December 31, 2005               [Page 7]


Internet-Draft          Subnet Allocation Option               June 2005


      'd' Flag

         '1' = Deprecate this subnet

      'h' Flag

         '1' = Client will be allocating addresses from this subnet.

         '0' = Client will be relaying DHCP requests to the Server from
            this subnet.

   Stat-len = Length of the optional statistics information field

   The "d" flag may only be returned by the Server to the Client.  It's
   presensce means that the Client should prepare to give up the subnet.
   For example, if the Client is assigning addresses from this subnet to
   other clients, it should cease doing so immediately and should not
   renew any leases when client's ask for renewal.  As soon as all
   addresses in the subnet are unallocated, the Client should send a
   DHCP RELEASE message to the Server, including a Subnet Prefix
   Information suboption for the subnet in order to release the Subnet.
   The format of this message is described below.

   The "h" flag tells the Client how the Server intends the Client to
   use the allocated subnet.  It is interpreted in the same manner as
   that in the Subnet Request suboption.  In response to a Subnet
   Request, the Server should normally specify the "h" flag in the same
   mannor was it was in the Subnet Request suboption from the Client.
   The Server MAY, however, change the "h" flag from that specified in
   the Subnet Request suboption if it has been configured to override
   the Client's request.

   If any usage statistics information is to be included, then the
   "Stat-len" field specifies the number of bytes of statistics
   information which is included.  See below for more information.  If
   no statistics information is included, then this byte MUST be zero.

3.3.1  Subnet Usage Statistics

   The Subnet Information suboption may also include usage statistics
   information.  If this information is included, then the "Stat-len"
   (Statistics length) field MUST be set to the number of bytes of
   statistics information which is being included.  The statistics
   information MUST be in the following form and order:







Johnson, et al.         Expires December 31, 2005               [Page 8]


Internet-Draft          Subnet Allocation Option               June 2005


   0                   1
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           High water          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Currently in use      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Unusable            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   "High water" refers the to "high water mark" of allocated addresses
   within the subnet.  I.e., the largest number of addresses which were
   ever allocated at one time from the subnet.

   "Currently in use" refers to the number of addresses currently
   allocated in the subnet.

   "Unusable" refers to the number of addresses which are currently
   unusable for any reason (such as a client returning a DHCP DECLINE,
   or finding the address already in use).

   Additional statistics may be added to this option in the future.  If
   so, they MUST be appended to the end of the option.  All statistics
   fields MUST remain in the same order.  Use the all ones value
   (0xFFFF) in order to skip reporting a number for a particular field.
   Fewer fields may be included than what is specified in any current
   RFC, but all fields which are included MUST remain in order specifed
   here.

3.4  Subnet Name Suboption format

   0                   1
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       3       |     Len       | Name ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Len = length of the sub-option excluding the Subcode and Len fields
      (1 octet)

   The Subnet Name suboption may be used in order to pass a subnet name
   to the server for use during allocation.  This name may be used for
   any purpose but is intended to tell the server something extra about
   the needed subnet; for example, "sales department", "customer 1002",
   "address pool FOO", or some such.  The "name" should NOT be NULL
   terminated since the "len" field already specifies the length of the
   name.




Johnson, et al.         Expires December 31, 2005               [Page 9]


Internet-Draft          Subnet Allocation Option               June 2005


3.5  Subnet Suggested Lease Time Suboption format

   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 2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       4       |     Len (4)   |       t1      |       t2      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       t3      |       t4      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Len = length of the sub-option excluding the Subcode and Len fields
      (always 4 for this suboption) (1 octet)

   The Subnet Suggested Lease Time suboption MAY be included by the
   Server in order to suggest the lease time to be used by the Client
   when allocating addresses from the subnet allocated.  The four (4)
   octet value of the lease time is in the same format as that of the
   "IP Address Lease Time" option (option 51), as described in [3].

   If included, this suboption may appear only once.  (Multiple such
   suboptions would make things ambiguous as to which applied to which
   subnet.)  If different suggested lease times are needed, the Server
   SHOULD, instead, reply with only one offered subnet and should set
   the "Server flag" in the Subnet Information suboption to indicate to
   the Client that it should send another subnet request to gather the
   others.

   If this suboption is not included, the Client is free to use whatever
   lease time it wants for addresses allocated from this subnet.

   In all cases, the Client should, at each address allocation time, use
   a lease time which is the lesser of the remaining lease time of the
   subnet itself and the Server Suggested Lease Time suboption.


















Johnson, et al.         Expires December 31, 2005              [Page 10]


Internet-Draft          Subnet Allocation Option               June 2005


4.  Requesting allocation of a subnet

4.1  Client DISCOVER message

   The DHCP Client creates a DHCP DISCOVER message including the Subnet
   Allocation option, and its set of suboptions, to request allocation
   of a subnet.  The DHCP Client should include the Subnet Request
   suboption, specifying the prefix size of the subnet requested.  The
   "h" bit should be set to "1" if the Client intends to control
   allocation of addresses within the subnet itself, or "0" if the
   Server should retain control of addresses within the subnet.  More
   than one Subnet Allocation option may appear in a DHCP DISCOVER
   message, however the client SHOULD limit the number of requests,
   noting that the DHCP replies will need to include the Subnet
   Information suboption, which takes up more space.

   If more than one subnet size is being requested, multiple Subnet
   Request suboptions MAY be included or multiple DHCP DISCOVER messages
   MAY be sent instead.  The prefix size field of each Subnet Request
   suboption MUST be either zero (0), or in the range of 1 to 30
   inclusive.

   The DHCP "IP address lease time" option (code 51) MAY be included in
   the DHCP DISCOVER message to specify the lease time the Client is
   requesting.  If not present, no suggested lease time is given.

   The DHCP "Client ID" option (code 61) MAY be included in the DHCP
   DISCOVER message as it may be used by the Server in performing the
   subnet allocation.

4.2  Server OFFER message

   Upon receiving a DHCP DISCOVER containing the Subnet Allocation
   option, the DHCP Server should respond with a DHCP OFFER message
   including the Subnet Information suboption in order to specify the
   subnet(s) which it is willing to allocate to the Client in order to
   fill the request(s).

   The Server need not reserve the subnets which are being OFFERed, but
   SHOULD strive to not OFFER the same subnets to another DHCP Client
   until a reasonable time period (implementation independent) has
   passed.

   The Server MUST NOT include the Subnet Request suboption in the
   OFFER.  The same information is already present in the Subnet
   Information suboption(s) which SHOULD be included in the OFFER.

   The Server SHOULD also include the IP address lease time option



Johnson, et al.         Expires December 31, 2005              [Page 11]


Internet-Draft          Subnet Allocation Option               June 2005


   (option 51) in the DHCP OFFER message.  This gives the lease time for
   all subnets given in all Subnet Request suboptions contained in the
   DHCP OFFER message.  The Server MAY also include the Renewal and/or
   Rebinding options in order to further control the "T1" and "T2" lease
   timers of the client.  There MUST be only one IP address lease time,
   rebind, and/or renew option in the DHCP OFFER message.  If different
   lease times are required for some of the allocated subnets, then the
   server should only return Subnet Information suboption(s) for those
   subnets with the same lease time.  If the Client requires more
   subnets, another DHCP DISCOVER message will need to be issued to
   collect the other needed subnets.  Also see the "s" flag described
   below.

   The Server MAY set the "Server flag" ("s") to "1" to indicate that it
   would like to allocate one or more additional subnet(s) to the
   Client.  This indicates that the Client should send another DISCOVER
   message specifying a zero prefix size field, P, in order to request
   the additional subnet allocation(s) information.  This may be
   necessary if the subnets are to be allocated with different lease
   times, for example.

   The "Client flag" ("c") MUST be set to zero (0) to indicate this is a
   response to a client request for a new subnet allocation and not a
   request for information about already allocated subnets.

   The Server SHOULD set the DHCP yiaddr value to all zeros (0.0.0.0)
   and the Client MUST ignore fields having to do with address
   assignment if the packet contains a Subnet Allocation option.  In
   other words, a DHCP packet exchange can not provide subnet allocation
   and address assignment simultaneously.

4.3  Client DHCP REQUEST message

   When sending a DHCP REQUEST, the Client MUST NOT modify any fields of
   all Subnet Information suboptions received from the Server.  However,
   the Client MAY choose to not include some Subnet Information
   suboptions when issuing the DHCP REQUEST.  Subnet Request suboptions
   MUST NOT be included in the DHCP REQUEST message, only the Subnet
   Information suboption(s) should be included.

4.4  Server DHCP ACK message

   The DHCP Server, upon receipt of the Client's REQUEST message, MAY
   refuse allocation of any subnets (for example, if they have been
   allocated elsewhere in the meantime), however since the Server should
   have set aside the subnets offered for a short period of time, and
   since the Client should have requested the subnets within a short
   period of time after receiving the offer(s) from the server(s), this



Johnson, et al.         Expires December 31, 2005              [Page 12]


Internet-Draft          Subnet Allocation Option               June 2005


   last minute rejection should be rare.  The DHCP Server MAY NOT change
   the subnet address(es) or prefix size(s), however it MAY remove some
   Subnet Information suboptions from the list.

   The Server SHOULD include the IP address lease time option specifying
   the lease period for all subnet(s) in the ACK.  All subnets allocated
   in one DHCP message will have the same lease time and only one IP
   address lease time option must appear in the DHCP message.

   If the Server has internal information which states that the Client
   should be allocated more subnets than were requested, the Server MAY
   set the "s" bit in the Subnet Information suboption to indicate that
   the Client needs to request more subnets (as described above).

   The allocatable unit is the tuple (subnet address, prefix size).
   Multiple subnets may be allocated in one DHCP ACK, however since
   there can be only one Lease-time option, each subnet allocated is
   assigned the same lease time.  Each subnet lease MAY be RENEWed or
   RELEASEd individually.
































Johnson, et al.         Expires December 31, 2005              [Page 13]


Internet-Draft          Subnet Allocation Option               June 2005


5.  Client renewal of subnet lease

5.1  Client RENEW REQUEST message

   The Client MUST renew all subnets allocated with a lease time in much
   the same manner as renewing an allocated IP address.  Renewal timers
   need not be set in exactly the same manner, however.  If Renewal
   and/or Rebinding options were included in the ACK of the subnet
   allocation, then these "T1" and "T2" timers should be used just as
   they would be in the case of address allocation timers.

   The REQUEST message MUST include a Subnet Information suboption for
   which the Client is seeking renewal of the lease.  This Subnet
   Information suboption may optionally include subnet usage statistics,
   as described above w.r.t. the Subnet Information suboption format.

   The subnet IP address field (Address) and subnet prefix field
   (Prefix) MUST agree with the values as they were originally allocated
   to the Client by the Server.  In any of the statistics fields (High,
   Current, Ususable), a value of all ones (0xffff) SHOULD be used if
   the Client has no information to report for a statistic.

5.2  Server RENEW response

   The Server MAY respond to a subnet RENEW request with either an ACK
   or NAK response.  If a NAK response is given the Client MUST
   immediately stop using the subnet(s) specified and, if possible,
   notify all Clients with addresses allocated from this subnet that
   their addresses are no longer valid.  The Client MAY, of course, send
   a DHCP DISCOVER message containing the Subnet Allocation option and
   the Subnet Request suboption in order to acquire another subnet for
   use.  In general, the Server should ask the Client to "free" subnets
   by using the "Deprecate" bit of the Subnet Information suboption in
   an ACK message (see below).

   If an ACK response is given, the "Deprecate" ("d") bit of the flags
   field in the Subnet Information suboption may also be set.  This
   indicates the DHCP Client should "prepare to stop using this subnet".
   If the Client is allocating IP addresses for other clients out of
   this subnet (probably via DHCP), the Client SHOULD immediately stop
   allocating such addresses.  Once all allocated addresses in the
   subnet have been released, the Client SHOULD send a DHCP RELEASE
   message, including the Subnet Information suboption (with optional
   usage statistics) in order to release the subnet(s) back to the
   Server.






Johnson, et al.         Expires December 31, 2005              [Page 14]


Internet-Draft          Subnet Allocation Option               June 2005


5.3  Client RELEASE message

   The DHCP Client should send a DHCP RELEASE message in order to
   release allocated subnet(s) back to the Server when it is finished
   using them.  This message MUST NOT include the Subnet Request
   suboption, but MUST include one or more Subnet Information
   suboptions, and optionally including usage statistics.

   The Client MUST release the same subnet(s) of the same prefix size
   (Prefix), as was originally allocated.  The Client MAY release a
   subset of the subnets which were allocated originally.  In other
   words, the allocatable unit is the tuple (subnet address, prefix
   size).  Multiple subnets may be allocated in one DHCP ACK, however
   each subnet MAY be released individually.

5.4  Server RECONFIGURE message

   The DHCP Server may issue a DHCP RECONFIGURE message containing the
   Subnet Allocation option and the Subnet Information suboption.  This
   message effectively immediately times out the Client's lease(s) for
   the allocated subnet(s).  Upon receiving this message, the DHCP
   Client MUST issue a DHCP REQUEST message to the DHCP Server in order
   to renew the lease on the subnet mentioned.  No other subnets
   allocated to the Client are effected.  As is the case with all DHCP
   Renewal messages, the Client may include subnet usage information in
   the Subnet Information suboption in order to report subnet usage
   statistics, or set the "Stat-len" field to zero (0) if no statistics
   are to be reported.

   If the Server responds to this REQUEST with a DHCP NAK message, then
   the Client MUST immediately stop using the subnet(s) and, if
   possible, notify all Clients with addresses allocated from this/these
   subnet(s) that their addresses are no longer valid.  The Client MAY,
   of course, send a DHCP DISCOVER message containing the Subnet
   Allocation option and the Subnet Request suboption in order to
   acquire another subnet for use.















Johnson, et al.         Expires December 31, 2005              [Page 15]


Internet-Draft          Subnet Allocation Option               June 2005


6.  Client requesting subnet allocation information

   The DHCP Client may request from the DHCP Server a list of what
   subnets are currently allocated to Client.  This may be used to
   recover from a restart if the Client does not have local storage in
   order to retain the information itself.

6.1  Client DISCOVER message

   The DHCP Client DISCOVER message, in order to discover already
   allocated subnet information, should contain a Subnet Request
   suboption, with the "Prefix" field set to zero (0) and with the "i"
   flag set to "1" to indicate that the Client is seeking already
   allocated subnet information from the Server.  No Subnet Information
   suboptions should be included in this message.

   This DISCOVER message MAY be unicast to a particular DHCP Server, or
   broadcast in the normal fashion.

6.2  Server OFFER response

   Any DHCP Server which has allocated subnets to the Client should
   respond to the DISCOVER message with a DHCP OFFER message The OFFER
   message should contain one or more Subnet Information suboption(s)
   telling the subnet address(es) and prefix(es) of the subnet(s)
   allocated to the Client.

   The Server SHOULD, internally, retain an ordered list of subnets
   which are allocated to each Client.  The subnet(s) information
   returned in the OFFER message are the first subnet(s) from this list.
   If the end of the list has been reached, then the "s" bit should be
   set to "0".  If there are more subnets in the list, the "s" bit
   should be set to "1". to indicate to the Client that more information
   is available.  If this is the initial OFFER to the client, the "c"
   flag should be set to "1".

6.3  Client additional DISCOVER messages

   The Client, upon receiving any Server OFFER messages containing
   Subnet Information suboption information with the "c" ("Client") bit
   set, should gather the subnet address and prefix information from the
   message.

   If the "s" bit is set in the Subnet Information suboption, then the
   client MUST construct a new DHCP DISCOVER message containing the
   Subnet Allocation option and the Subnet Information suboption, and
   send this message back to the same DHCP Server originating the OFFER
   message.  The "c" and "s" bits MUST retain the same settings they had



Johnson, et al.         Expires December 31, 2005              [Page 16]


Internet-Draft          Subnet Allocation Option               June 2005


   in the Server's OFFER message and the subnet address ("A") and prefix
   size ("P") fields MUST be unaltered as well.

   If the "s" bit in the Subnet Information suboption from the Server
   was "0", then it indicates the Server has no more information about
   subnets allocated to the Client.  In this case, the Client MUST NOT
   send a REQUEST response to the Server.

6.4  Server additional OFFER messages

   The Server, upon receiving a DISCOVER message from a Client
   containing a Subnet Information suboption with the "c" and the "s"
   bits set, MUST use the subnet address ("A") and prefix size ("P")
   fields in order to locate the position in the internal table of
   allocated subnets for this Client, and then return an OFFER message
   containing a Subnet Information suboption giving information about
   the next set of subnets allocated to this Client.  If this finishes
   the list in the table for this Client, then the "s" bit MUST be set
   to "0" to indicate there is no more information.
































Johnson, et al.         Expires December 31, 2005              [Page 17]


Internet-Draft          Subnet Allocation Option               June 2005


7.  DHCP Server Subnet Allocation method

   The actual method of allocating subnets on the DHCP Server, as well
   as the configuration of what networks may be subnetted and how, is
   left up to the implementation.














































Johnson, et al.         Expires December 31, 2005              [Page 18]


Internet-Draft          Subnet Allocation Option               June 2005


8.  Examples

   Only the Subnet Allocation option and accompanying suboptions are
   displayed in these examples.  All other fields in the DHCP messages
   are described in [2].  For the purposes of these examples, "SAC"
   stands for the actual code number allocated for the "Subnet
   Allocation option Code".

8.1  Example 1:

   DHCP Client requesting a subnet with prefix size 24 from which the
   Client will allocate addresses to other clients.  The Server responds
   with allocation of exactly the size requested:

   Client sends DHCP DISCOVER including the Subnet Allocation option
   with the Subnet-Request suboption:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   SAC         |       5       |       0       |       1       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       2       |     0     |0|0|       24      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Server responds with DHCP OFFER including Subnet Allocation option
   with a Subnet Information suboption:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      SAC      |      11       |       0       |       2       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       8       |     0     |0|0|      10       |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       1       |       0       |      24       |           |0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0       |
   +-+-+-+-+-+-+-+-+

   Client sends DHCP REQUEST including Subnet Allocation option with
   Subnet Information suboption:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      SAC      |      11       |       0       |       2       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       8       |     0     |0|0|      10       |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       1       |       0       |      24       |           |0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0       |
   +-+-+-+-+-+-+-+-+



Johnson, et al.         Expires December 31, 2005              [Page 19]


Internet-Draft          Subnet Allocation Option               June 2005


   Server responds with DHCP ACK including Subnet Allocation option with
   Subnet-Info suboption:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      SAC      |      11       |       0       |       2       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       8       |     0     |0|0|      10       |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       1       |       0       |      24       |           |0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0       |
   +-+-+-+-+-+-+-+-+

   Later Client sends DHCP RELEASE including Subnet Allocation option
   with Subnet Information suboption:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      SAC      |      11       |       0       |       2       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       8       |     0     |0|0|      10       |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       1       |       0       |      24       |           |0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0       |
   +-+-+-+-+-+-+-+-+


8.2  Example 2:

   DHCP Client requesting a subnet with prefix size 24 and a subnet with
   prefix size 30:

   Client sends DHCP DISCOVER including the Subnet Allocation option
   with the Subnet-Request suboption:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     SAC       |       9       |       0       |       1       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       2       |     0     |0|0|       24      |       1       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       2       |     0     |0|0|       30      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Server responds with DHCP OFFER including Subnet Allocation option
   with Subnet Information suboption:

   Offer includes 1 subnet of size 24 and 1 subnet of size 28.




Johnson, et al.         Expires December 31, 2005              [Page 20]


Internet-Draft          Subnet Allocation Option               June 2005


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     SAC       |      18       |       0       |       2       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      15       |           |0|0|      10       |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       2       |      0        |      24       |           |0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0       |     10        |       0       |       3       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0       |     28        |           |0|0|       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Client sends DHCP REQUEST including Subnet Allocation option with
   Subnet Information suboption:

   Client decides that the subnet of size 28 is not sufficient so
   doesn't include it into the request message.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     SAC       |      11       |       0       |       2       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       8       |           |0|0|      10       |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       2       |      0        |      24       |           |0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0       |
   +-+-+-+-+-+-+-+-+

   Server responds with DHCP ACK including Subnet Allocation option with
   Subnet Information suboption:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     SAC       |      11       |       0       |       2       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       8       |           |0|0|      10       |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       2       |      0        |      24       |           |0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0       |
   +-+-+-+-+-+-+-+-+

   Later Client sends DHCP REQUEST message in order to renew the lease
   on the one subnet, including subnet usage information.  It reports
   that a maximum of 10 addresses were allocated from the subnet since
   the last report, 7 addresses are currently allocated, and 2 addresses
   were found to be unusable.





Johnson, et al.         Expires December 31, 2005              [Page 21]


Internet-Draft          Subnet Allocation Option               June 2005


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     SAC       |      17       |       0       |       2       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      14       |           |0|0|      10       |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       2       |      0        |      24       |           |0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       6       |       0       |      10       |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       7       |       0       |       2       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Server responds with ACK, however signals Client that the subnet
   should be deprecated.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     SAC       |      11       |       0       |       2       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       8       |           |0|0|      10       |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       2       |      0        |      24       |           |0|1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0       |
   +-+-+-+-+-+-+-+-+

   Client crashes at this point and upon recovery sends a DISCOVER
   asking for information about all subnets which were allocated to it.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     SAC       |       5       |       0       |       1       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       2       |           |1|0|       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Server responds with an OFFER, giving the subnet information of the
   one subnet which is allocated to the Client.  Also the Server
   specifies that the one allocated subnet should be immediately
   deprecated.  Note that the "s" ("Server") bit is zero (0) thus
   indicating that there is no more information available for this
   Client.











Johnson, et al.         Expires December 31, 2005              [Page 22]


Internet-Draft          Subnet Allocation Option               June 2005


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     SAC       |       11      |       0       |       2       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       8       |           |1|0|       10      |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       2       |      0        |       24      |           |0|1|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0       |
   +-+-+-+-+-+-+-+-+

   Client responds with RELEASE message after having deprecated the
   subnet:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     SAC       |       11      |       0       |     SIS       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       8       |           |0|0|       10      |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       2       |      0        |       24      |           |0|0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0       |
   +-+-+-+-+-+-+-+-+





























Johnson, et al.         Expires December 31, 2005              [Page 23]


Internet-Draft          Subnet Allocation Option               June 2005


9.  Differences with DHCPv6 Prefix Delegation

   The following differences may be noticed between Subnet Allocation as
   described in this document and DHCPv6 Prefix Delegation as described
   in [5]:

   o  This option does not use anything like an "IA_PD" as is used in
      DHCPv6.

   o  If the Server can not allocate a subnet, it remains silent,
      instead of returning a special saying nothing is available.

   o  DHCPv6 Prefix Delegation has no mechanism for returning subnet/
      prefix usage statistics.

   o  DHCPv6 has no equivalent to the "subnet deprecation" flag as
      described here.

   o  DHCPv6 Prefix Delegation makes no mention of what Client actions
      should result from receiving a NAK during a RENEW of a delegation.

   o  DHCPv6 has no equivalent of the subnet allocation "Network name"
      suboption, which may be used by the Server for various purposes,
      such as to specify a pool to use when allocating a subnet.

   o  DHCPv6 Prefix Delegation corresponds to "Hierarchical Subnet
      Allocation" (setting the "h" flag in the Prefix Information
      suboption).  There is no V6 equivalent of clearing the "h" flag,
      in which the Server retains authority over allocation of addresses
      from the subnet.

   o  DHCPv6 Prefix Delegation has nothing to correspond to the
      Suggested Lease Time suboption.


















Johnson, et al.         Expires December 31, 2005              [Page 24]


Internet-Draft          Subnet Allocation Option               June 2005


10.  Security Considerations

   Potential exposures to attack are discussed in section 7 of the DHCP
   protocol specification [2].  The Subnet Allocation option can be used
   to hoard all allocatable subnets on a network.

   It is suggested that DHCP Authentication be used with this option.
   Message authentication in DHCP for intradomain use where the out-of-
   band exchange of a shared secret is feasible is defined in RFC 3118
   [4].  Potential exposures to attack are discussed in section 7 of the
   DHCP protocol specification in RFC 2131 [2].








































Johnson, et al.         Expires December 31, 2005              [Page 25]


Internet-Draft          Subnet Allocation Option               June 2005


11.  IANA Considerations

   This option is in current usage with the number 150.  As per RFC-
   3942, this already existing number assignment should simply be made
   "official" by IANA, unless there is a conflict with some other usage.

   No assignment of values for the suboption codes need be made at this
   time.  New values may only be defined by IETF Consensus, as described
   in [5].  Basically, this means that they are defined by RFCs approved
   by the IESG.









































Johnson, et al.         Expires December 31, 2005              [Page 26]


Internet-Draft          Subnet Allocation Option               June 2005


12.  Intellectual Property Rights

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.

13.  References

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

   [2]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
        March 1997.

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

   [4]  Droms, R., "Authentication for DHCP Messages", RFC 3118,
        June 2001.

   [5]  Troan, O. and R. Droms, "IPv6 Prefix Options for DHCPv6",
        RFC 3633, February 2003.

   [6]  Pummill, T. and B. Manning, "Variable Length Subnet Table For
        IPv4", RFC 1878, December 1995.

   [7]  Volz, B., "Reclassifying Dynamic Host Configuration Protocol
        version 4 (DHCPv4) Options", RFC 3942, November 2004.


Authors' Addresses

   Richard A. Johnson
   Cisco Systems, Inc.
   170 W. Tasman Dr.
   San Jose, CA  95134
   US

   Phone: +1 408 526 4000
   Email: raj@cisco.com










Johnson, et al.         Expires December 31, 2005              [Page 27]


Internet-Draft          Subnet Allocation Option               June 2005


   Jay Kumarasamy
   Cisco Systems, Inc.
   170 W. Tasman Dr.
   San Jose, CA  95134
   US

   Phone: +1 408 526 4000
   Email: jayk@cisco.com


   Kim Kinnear
   Cisco Systems, Inc.
   170 W. Tasman Dr.
   San Jose, CA  95134
   US

   Phone: +1 408 526 4000
   Email: kkinnear@cisco.com


   Mark Stapp
   Cisco Systems, Inc.
   170 W. Tasman Dr.
   San Jose, CA  95134
   US

   Phone: +1 408 526 4000
   Email: mjs@cisco.com























Johnson, et al.         Expires December 31, 2005              [Page 28]


Internet-Draft          Subnet Allocation Option               June 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Johnson, et al.         Expires December 31, 2005              [Page 29]


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