[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

Internet Engineering Task Force                               R. Johnson
Internet Draft                                            Jay Kumarasamy
Expiration: January 2005                                     Kim Kinnear
File: draft-ietf-dhc-subnet-alloc-01.txt                      Mark Stapp
                                                     Cisco Systems, Inc.



                      Subnet Allocation using DHCP
                  <draft-ietf-dhc-subnet-alloc-01.txt>

                             July 15, 2004


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

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.






Johnson, et. al.                                                [Page 1]


Internet Draft        Subnet Allocation using DHCP             July 2004


1.0 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 [2], 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.


1.1 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 [3].

   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.                                                [Page 2]


Internet Draft        Subnet Allocation using DHCP             July 2004


2.0 Option Formats:


   2.1 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) TBD

      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.



   2.2 Subnet 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.                                                [Page 3]


Internet Draft        Subnet Allocation using DHCP             July 2004


      Prefix  = size of the subnet needed [4] (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 qis 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



Johnson, et. al.                                                [Page 4]


Internet Draft        Subnet Allocation using DHCP             July 2004


      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.



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












Johnson, et. al.                                                [Page 5]


Internet Draft        Subnet Allocation using DHCP             July 2004


   2.4 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 statistics...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      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)
                 "d" = "1" = Deprecate this subnet
                 "h" = "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



      Subnet Prefix suboption format:

      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



Johnson, et. al.                                                [Page 6]


Internet Draft        Subnet Allocation using DHCP             July 2004


      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.



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


      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



Johnson, et. al.                                                [Page 7]


Internet Draft        Subnet Allocation using DHCP             July 2004


      MUST remain in order specifed here.


















































Johnson, et. al.                                                [Page 8]


Internet Draft        Subnet Allocation using DHCP             July 2004


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


   2.6 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 [2].

      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



Johnson, et. al.                                                [Page 9]


Internet Draft        Subnet Allocation using DHCP             July 2004


      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.




3.0 Requesting allocation of a subnet


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




Johnson, et. al.                                               [Page 10]


Internet Draft        Subnet Allocation using DHCP             July 2004


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



Johnson, et. al.                                               [Page 11]


Internet Draft        Subnet Allocation using DHCP             July 2004


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


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



4.0 Client renewal of subnet lease


   4.1 Client RENEW REQUEST message



Johnson, et. al.                                               [Page 12]


Internet Draft        Subnet Allocation using DHCP             July 2004


      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.


   4.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.                                               [Page 13]


Internet Draft        Subnet Allocation using DHCP             July 2004


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


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



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





Johnson, et. al.                                               [Page 14]


Internet Draft        Subnet Allocation using DHCP             July 2004


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


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


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



Johnson, et. al.                                               [Page 15]


Internet Draft        Subnet Allocation using DHCP             July 2004


      about subnets allocated to the Client.  In this case, the Client
      MUST NOT send a REQUEST response to the Server.


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



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


7.0 Examples

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


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



Johnson, et. al.                                               [Page 16]


Internet Draft        Subnet Allocation using DHCP             July 2004


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


































Johnson, et. al.                                               [Page 17]


Internet Draft        Subnet Allocation using DHCP             July 2004


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


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








Johnson, et. al.                                               [Page 18]


Internet Draft        Subnet Allocation using DHCP             July 2004


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


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











Johnson, et. al.                                               [Page 19]


Internet Draft        Subnet Allocation using DHCP             July 2004


      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.


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



Johnson, et. al.                                               [Page 20]


Internet Draft        Subnet Allocation using DHCP             July 2004


      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.


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







Johnson, et. al.                                               [Page 21]


Internet Draft        Subnet Allocation using DHCP             July 2004


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


8.0 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 [6]:

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

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

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

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

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

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

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

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



Johnson, et. al.                                               [Page 22]


Internet Draft        Subnet Allocation using DHCP             July 2004


9.0 Security Considerations


   Potential exposures to attack are discussed in section 7 of the DHCP
   protocol specification [1]. 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
   [5].  Potential exposures to attack are discussed in section 7 of the
   DHCP protocol specification in RFC 2131 [1].

10.0 IANA Considerations

   IANA has assigned a value of TBD for the DHCP option code described
   in this document.  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 [6].  Basically, this means that they are
   defined by RFCs approved by the IESG.

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

References

   [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
       Bucknell University, March 1997.

   [2] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor
       Extensions", RFC 2132, Silicon Graphics, Inc., Bucknell
       University, March 1997.

   [3] Bradner, S., "Key words for use in RFCs to indicate requirement
       levels", RFC 2119, Harvard University, March 1997.

   [4] Pummill, T., Manning, B., "Variable Length Subnet Table For
       IPv4", RFC1878, Alantec, USC/Information Sciences Institute,
       December, 1995

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

   [6] Troan, O., Droms, R., "IPv6 Prefix Options for DHCPv6",



Johnson, et. al.                                               [Page 23]


Internet Draft        Subnet Allocation using DHCP             July 2004


       draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt,
       February, 2003



Author Information:

Richard Johnson
Cisco Systems, Inc.
San Jose, Ca.
email: raj@cisco.com


Jay Kumarasamy
Cisco Systems, Inc.
San Jose, Ca.
email: jayk@cisco.com


Kim Kinnear
Cisco Systems, Inc.
San Jose, Ca.
email: kkinnear@cisco.com


Mark Stapp
Cisco Systems, Inc.
San Jose, Ca.
email: mjs@cisco.com






















Johnson, et. al.                                               [Page 24]


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