diff options
Diffstat (limited to 'doc/rfc/rfc6656.txt')
| -rw-r--r-- | doc/rfc/rfc6656.txt | 1347 |
1 files changed, 1347 insertions, 0 deletions
diff --git a/doc/rfc/rfc6656.txt b/doc/rfc/rfc6656.txt new file mode 100644 index 0000000..70f2751 --- /dev/null +++ b/doc/rfc/rfc6656.txt @@ -0,0 +1,1347 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Johnson +Request for Comments: 6656 K. Kinnear +Category: Informational M. Stapp +ISSN: 2070-1721 Cisco Systems, Inc. + July 2012 + + + Description of Cisco Systems' Subnet Allocation Option for DHCPv4 + +Abstract + + This memo documents a DHCPv4 option that currently exists and was + previously privately defined for the operation and usage of the Cisco + Systems' Subnet Allocation Option for DHCPv4. The option is passed + between the DHCPv4 Client and the DHCPv4 Server to request dynamic + allocation of a subnet, give specifications of the subnet(s) + allocated, and report usage statistics. This memo documents the + current usage of the option in agreement with RFC 3942, which + declares that any preexisting usages of option numbers in the range + 128-223 should be documented and that the working group will try to + officially assign those numbers to those options. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6656. + + + + + + + + + + + + + + +Johnson, et al. Informational [Page 1] + +RFC 6656 Cisco Systems' DHCP Subnet Alloc Option July 2012 + + +Copyright Notice + + Copyright (c) 2012 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + + + + + + + + + + + + + + + +Johnson, et al. Informational [Page 2] + +RFC 6656 Cisco Systems' DHCP Subnet Alloc Option July 2012 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Subnet Allocation Option Format . . . . . . . . . . . . . . . 5 + 3.1. Subnet-Request Suboption Format . . . . . . . . . . . . . 5 + 3.2. Subnet-Information Suboption Format . . . . . . . . . . . 7 + 3.2.1. Subnet Prefix Information Block Format . . . . . . . . 8 + 3.3. Subnet-Name Suboption Format . . . . . . . . . . . . . . . 9 + 3.4. Suggested-Lease-Time Suboption Format . . . . . . . . . . 10 + 4. Requesting Allocation of a Subnet . . . . . . . . . . . . . . 10 + 4.1. Client DHCPDISCOVER Message . . . . . . . . . . . . . . . 11 + 4.2. Server DHCPOFFER Message . . . . . . . . . . . . . . . . . 11 + 4.3. Client DHCPREQUEST Message . . . . . . . . . . . . . . . . 12 + 4.4. Server DHCPACK Message . . . . . . . . . . . . . . . . . . 13 + 5. Client Renewal of Subnet Lease . . . . . . . . . . . . . . . . 13 + 5.1. Client RENEW DHCPREQUEST Message . . . . . . . . . . . . . 13 + 5.2. Server RENEW DHCPREQUEST Response . . . . . . . . . . . . 14 + 5.3. Client DHCPRELEASE Message . . . . . . . . . . . . . . . . 14 + 5.4. Server DHCPFORCERENEW Message . . . . . . . . . . . . . . 15 + 6. Client Requesting Previously Allocated Subnet Information . . 15 + 6.1. Initial Client DHCPDISCOVER Message . . . . . . . . . . . 15 + 6.2. Initial Server DHCPOFFER Response . . . . . . . . . . . . 16 + 6.3. Additional Client DHCPDISCOVER Messages . . . . . . . . . 16 + 6.4. Additional Server DHCPOFFER Responses . . . . . . . . . . 16 + 7. DHCP Server Subnet Allocation Method . . . . . . . . . . . . . 17 + 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 8.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 17 + 8.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 19 + 9. Differences from DHCPv6 Prefix Delegation . . . . . . . . . . 21 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 23 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 23 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 23 + + + + + + + + + + + + + + + +Johnson, et al. Informational [Page 3] + +RFC 6656 Cisco Systems' DHCP Subnet Alloc Option July 2012 + + +1. Introduction + + This memo documents a DHCP option [RFC2132], the Subnet Allocation + option, that was developed by Cisco and allows a DHCP Client to + allocate a subnet given information from a DHCP Server. This + protocol makes use of DHCP option number 220, one of the option + numbers reclassified by [RFC3942]. That RFC specifies in Section 4, + procedure 2, "Vendors that currently use one or more of the + reclassified options have 6 months following this RFC's publication + date to notify the DHC WG and IANA that they are using particular + options numbers and agree to document that usage in an RFC". This + memo serves as that documentation. The DHC WG has had no input into + any of the details of the protocol operation and makes no statement + about the correctness or any other aspect of the protocol. The WG + also has seen no interest in further implementation or deployment of + this protocol other than privately, and therefore has decided to + publish this document solely for informational purposes. + + The Subnet Allocation option provides a straightforward way to + allocate a subnet from DHCP, useful for a simple Dial-in Aggregation + box, or 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 option is specified in such a way as to use one DHCP + option number, while using suboption numbers for each function. + +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 [RFC2119]. + + 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. Informational [Page 4] + +RFC 6656 Cisco Systems' DHCP Subnet Alloc Option July 2012 + + +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 suboptions + (1 octet) + Flags = Various flags: (None currently defined) + + One or more suboptions may be specified as described below. + +3.1. 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 1 | Len | Flags :i:h| Prefix | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Len = Length of the suboption (always 2 for this suboption) + (1 octet) + Flags = Flags field. (all unused bits must be zero) + + 'h' = Hierarchical flag + 1 : Client will be allocating addresses from this subnet. + 0 : Client will be relaying DHCP requests to the Server + from this subnet. + 'i' = Information flag + 1 : Client is seeking information about previously + allocated subnets. + 0 : Client is seeking a new subnet allocation. + + Prefix = Network prefix length requested + (0 means no suggested length 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 length [RFC4632] + less than or equal to the "Prefix" field length specified in the + request. In other words, a subnet containing a number of addresses + at least the size indicated by the prefix length requested and + + + +Johnson, et al. Informational [Page 5] + +RFC 6656 Cisco Systems' DHCP Subnet Alloc Option July 2012 + + + possibly more. The DHCP Server MAY allocate a subnet with a prefix + length greater than that specified in the request (or a subnet with a + number of addresses less than requested), but this is not encouraged. + + A "Prefix" field size of 0 MAY be specified by the DHCP Client. In + this case, no suggested prefix length is given. + + Multiple Subnet-Request suboptions in a DHCP packet indicate that + multiple subnets are being requested. Note that multiple occurrences + of this suboption MUST NOT be concatenated in the sense of [RFC3396]. + + Each Subnet-Request suboption MUST result in no more than one Subnet- + Information suboption in the DHCPOFFER message from the Server, and + may result in no Subnet-Information suboptions. + + The Client MAY also include the Subnet-Information suboption in order + to request a particular subnet. In this case, the Client SHOULD only + include one Subnet-Request suboption, since it would otherwise be + unclear which Subnet-Information suboption referred to which Subnet- + Request suboption. Multiple subnet requests can be made by sending + multiple DHCPDISCOVER 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 "Hierarchical 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). + 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 "Prefix" field + SHOULD be set to 0 and MUST be ignored by the Server. In this case, + the conversation between the Client and the Server will only progress + to the DHCPOFFER packet from the Server, giving the information, as + described in Section 6 below. + + Any undefined flags (those other than 'i' and 'h', mentioned above) + should be ignored by the DHCP Server. + + + + + + + + +Johnson, et al. Informational [Page 6] + +RFC 6656 Cisco Systems' DHCP Subnet Alloc Option July 2012 + + +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 suboption (min. length of 8) (1 octet) + Flags = Various flags that apply to ALL Subnet Prefix + Information fields specified in this suboption. + Unused flags must be zero. + + 'c' : Client flag (explained below) + 1 : This information is in response to a Client request + (or has been echoed back by the Client, when asking + for the next previously allocated subnet from the + Server). + 0 : Otherwise. + 's' : Server flag (explained below) + 1 : Server has additional subnet information for this + Client. + 0 : Otherwise. + + SP1, SP2, ... Subnet Prefix Information blocks as specified below + (variable size) + + Setting the 'c' flag to 1 indicates 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 used in response + to a Subnet-Request suboption with the 'i' flag set and should be 0 + in other Server responses. Note, the flag is echoed back from the + Client to the Server when requesting the "next previously allocated + subnet". Another way to think of the 'c' bit would be that it + indicates that the subnet information contained in this suboption + does not represent a new allocation by the Server or a new request + for allocation by the Client, but instead represents previously + allocated subnet information. + + Setting the 's' flag to 1 indicates the Server has additional subnet + information for the Client. + + Any undefined flags (those other than 'c' and 's', mentioned above) + should be ignored by the DHCP Server. + + + + + + +Johnson, et al. Informational [Page 7] + +RFC 6656 Cisco Systems' DHCP Subnet Alloc Option July 2012 + + + The Subnet-Information suboption is used by the DHCP Server in order + to return information as to what subnets are offered (in the case of + a DHCPOFFER packet) or allocated (in the case of a DHCPACK packet). + As is indicated above, multiple subnets may be returned in one + Subnet-Information suboption. + + The Subnet-Information suboption is also used by the DHCP Client in + order to request allocation of specific subnets in a DHCPREQUEST + packet. In this case, the "Network", "Prefix", and "Flags" fields + contained in the associated Subnet Prefix Information blocks MUST NOT + be changed from the information that was received in the DHCPOFFER + packet from the Server. The Client MAY, however, use multiple + Subnet-Information suboptions in order to request subnets that were + originally specified by the Server inside one Subnet-Information + suboption. + +3.2.1. Subnet Prefix Information Block 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Network | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Prefix | Flags :h:d| Stat-len | Optional stats... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Network = IPv4 network number (4 octets) + Prefix = Prefix length (1 octet) + Flags = Flags field (Undefined bits must be zero) (1 octet) + + 'd' = Deprecate flag (explained below) + 1 : Deprecation of this subnet is requested. + 0 : No deprecation is needed. + + 'h' = Hierarchical flag (explained below) + 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 + (zero if no statistics are included) (1 octet) + + The 'd' flag may only be returned by the Server to the Client (inside + a DHCPACK packet, in response to a DHCP RENEW). Its presence 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 + + + +Johnson, et al. Informational [Page 8] + +RFC 6656 Cisco Systems' DHCP Subnet Alloc Option July 2012 + + + any leases when Clients ask for renewal. As soon as all addresses in + the subnet are unallocated, the Client should send a DHCPRELEASE + message to the Server, including a Subnet Prefix Information block + for the subnet in order to release the subnet. The format of this + message is described farther below. + + The 'h' flag tells the Client how the Server intends for 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 + manner as 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. + + Any undefined flags (those other than 'd' and 'h', mentioned above) + should be ignored by the DHCP Server. + + If any usage statistics information is to be included, then the + "Stat-len" field specifies the number of bytes of statistics + information that is included. See below for more information. If no + statistics information is included, then this byte MUST be zero. The + "Stat-len" field SHOULD always be zero when this suboption is sent by + the DHCP Server. The usage statistics information is intended for + use only to report usage statistics from the Client to the Server. + +3.2.1.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 that 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | High water | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Currently in use | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Unusable | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + "High water" refers the to "high-water mark" of allocated addresses + within the subnet. That is, the largest number of addresses that + were ever allocated at one time from the subnet. + + + + +Johnson, et al. Informational [Page 9] + +RFC 6656 Cisco Systems' DHCP Subnet Alloc Option July 2012 + + + "Currently in use" refers to the number of addresses currently + allocated in the subnet. + + "Unusable" refers to the number of addresses that are currently + unusable for any reason (such as a Client returning a DHCPDECLINE, or + finding the address already in use). + + Additional statistics may be added to this option in the future. If + so, they MUST be appended immediately after the already defined + statistics fields. 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 above; for example, if "Stat-len" is "4", then the + "Unusable" field has not been included. All fields that are included + MUST remain in order specified here. + +3.3. 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 suboption (min. length of 1) (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. The "Name" in this suboption MUST be given using UTF-8 + [RFC3629]. + +3.4. 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 4 | Len (4) | t1 | t2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | t3 | t4 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Len = length of the suboption (always 4 for this suboption) (1 + octet) + + + + +Johnson, et al. Informational [Page 10] + +RFC 6656 Cisco Systems' DHCP Subnet Alloc Option July 2012 + + + The 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 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 [RFC2132]. + + If included, this suboption MUST appear only once. (Inclusion of + multiple such suboptions would result in ambiguity 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. + + The Client SHOULD use a lease time, when allocating addresses from + the subnet, that is the lesser of the remaining lease time of the + subnet itself and the Suggested-Lease-Time suboption. + +4. Requesting Allocation of a Subnet + +4.1. Client DHCPDISCOVER Message + + The DHCP Client creates a DHCPDISCOVER 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 length 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 DHCPDISCOVER 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 than the Subnet-Request + suboption. + + If more than one subnet is being requested, multiple Subnet-Request + suboptions MAY be included or multiple DHCPDISCOVER messages MAY be + sent instead. The prefix length field of each Subnet-Request + suboption MUST be either 0, or in the range of 1 to 30 inclusive. + + The DHCP "IP address lease time" option (code 51) MAY be included in + the DHCPDISCOVER message to specify the lease time the Client is + requesting for the subnet. If not present, no suggested lease time + is given. + + The DHCP "Client ID" option (code 61) MAY be included in the + DHCPDISCOVER message as it may be used by the Server in performing + the subnet allocation. + + + +Johnson, et al. Informational [Page 11] + +RFC 6656 Cisco Systems' DHCP Subnet Alloc Option July 2012 + + +4.2. Server DHCPOFFER Message + + Upon receiving a DHCPDISCOVER containing the Subnet Allocation + option, the DHCP Server SHOULD respond with a DHCPOFFER message + including the Subnet-Information suboption in order to specify the + subnet(s) that it is willing to allocate to the Client in order to + fulfill the request(s). + + The Server need not reserve the subnets that are being offered, but + SHOULD not offer the same subnets to another DHCP Client until a + reasonable time period (implementation dependent) has passed. (This + is similar to normal DHCP address allocation.) + + The Server MUST NOT include the Subnet-Request suboption in the + DHCPOFFER. The same information is already present in the Subnet + Information suboption(s) that SHOULD be included in the DHCPOFFER. + + The Server SHOULD also include the IP address lease time option + (option 51) in the DHCPOFFER message. This gives the lease time for + all subnets given in all Subnet-Request suboptions contained in the + DHCPOFFER 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 exactly one IP address lease + time (and optionally one Rebinding and/or one Renewal option) in the + DHCPOFFER message. + + 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 + DHCPDISCOVER message specifying a prefix length field, P, of zero 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 0 to indicate this is a Server + response to a Client request for a new subnet allocation and not a + response to a request for information about already allocated + subnets. + + If the packet contains a Subnet Allocation option, 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. In other words, + a DHCP packet exchange cannot provide subnet allocation and address + assignment simultaneously. + + + + + + + +Johnson, et al. Informational [Page 12] + +RFC 6656 Cisco Systems' DHCP Subnet Alloc Option July 2012 + + +4.3. Client DHCPREQUEST Message + + When sending a DHCPREQUEST, the Client MUST NOT modify any fields of + any Subnet-Information suboptions received from the Server. However, + the Client MAY choose not to include some Subnet-Information + suboptions when issuing the DHCPREQUEST. Subnet-Request suboptions + MUST NOT be included in the DHCPREQUEST message; only the Subnet- + Information suboption(s) should be included. + +4.4. Server DHCPACK Message + + The DHCP Server, upon receipt of the Client's DHCPREQUEST 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 MUST NOT + change the network number(s) or prefix length(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 DHCPACK. 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 that states that the Client + should be allocated more subnets than were requested, the Server MAY + set the 's' bit in the last Subnet-Information suboption to indicate + that the Client needs to request more subnets (as described above). + + The allocable unit is the tuple (network number, prefix length). + Multiple subnets may be allocated in one DHCPACK; however, since + there can be only one Lease-time option, each subnet allocated is + assigned the same lease time. Each subnet lease tuple (network + number, prefix length) MAY be renewed or released individually. + +5. Client Renewal of Subnet Lease + +5.1. Client RENEW DHCPREQUEST 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 DHCPACK 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. + + + + +Johnson, et al. Informational [Page 13] + +RFC 6656 Cisco Systems' DHCP Subnet Alloc Option July 2012 + + + The DHCPREQUEST 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 in Section 3.2 ("Subnet-Information Suboption + Format"). + + The subnet network number field ("Network") and subnet prefix length + 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 water, Currently in use, Unusable), a value of all ones + (0xffff) SHOULD be used if the Client has no information to report + for a statistic. + +5.2. Server RENEW DHCPREQUEST Response + + The Server MAY respond to a subnet RENEW with either a DHCPACK or + DHCPNAK response. If a DHCPNAK 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 DHCPDISCOVER 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 deprecate + subnets by using the 'd' bit of the Subnet-Information suboption in a + DHCPACK message (see below). + + If a DHCPACK 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 + from this subnet (e.g., 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 DHCPRELEASE + message, including the Subnet-Information suboption (with optional + usage statistics) in order to release the subnet(s) back to the + Server. + +5.3. Client DHCPRELEASE Message + + The DHCP Client SHOULD send a DHCPRELEASE 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 may + optionally include usage statistics. + + The Client MUST release the same subnet(s) of the same prefix length + ("Prefix"), as were originally allocated. The Client MAY release a + subset of the subnets that were allocated originally. In other + + + +Johnson, et al. Informational [Page 14] + +RFC 6656 Cisco Systems' DHCP Subnet Alloc Option July 2012 + + + words, the allocable unit is the tuple (network number, prefix + length). Multiple subnets may be allocated in one DHCPACK; however, + each subnet MAY be released individually. + +5.4. Server DHCPFORCERENEW Message + + The DHCP Server MAY issue a DHCPFORCERENEW [RFC3203] message + containing the Subnet Allocation option and the Subnet-Information + suboption. Upon receiving this message, the DHCP Client MUST issue a + DHCPREQUEST message to the DHCP Server in order to renew the lease on + the subnet mentioned. No other subnets allocated to the Client are + affected. As is the case with all DHCP RENEW 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 0 if no statistics are to be reported. + + If the Server responds to this DHCPREQUEST with a DHCPNAK 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 DHCPDISCOVER message containing the Subnet + Allocation option and the Subnet-Request suboption in order to + acquire another subnet for use. + +6. Client Requesting Previously Allocated Subnet Information + + A DHCP Client MAY request from the DHCP Server a list of what subnets + are currently allocated to the 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. (For an example of this, see + Section 8.2 below.) + +6.1. Initial Client DHCPDISCOVER Message + + The DHCP Client DHCPDISCOVER message, when used to discover already + allocated subnet information, SHOULD contain a Subnet-Request + suboption with the "Prefix" field set to 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. Note, no Subnet-Information suboption + is included in this message, since the Client would not know of any + subnet to request at that point. + + This DHCPDISCOVER message MAY be unicast to a particular DHCP Server, + or broadcast in the normal fashion. + + + + + + +Johnson, et al. Informational [Page 15] + +RFC 6656 Cisco Systems' DHCP Subnet Alloc Option July 2012 + + +6.2. Initial Server DHCPOFFER Response + + Any DHCP Server that has allocated subnets to the Client SHOULD + respond to the DHCPDISCOVER message with a DHCPOFFER message. The + DHCPOFFER message should contain one or more Subnet-Information + suboption(s) telling the prefix of the subnet(s) allocated to the + Client. + + The Server SHOULD, internally, retain an ordered list of subnets that + are allocated to each Client. In response to an initial DHCPDISCOVER + message requesting allocated subnet information (i.e., one with the + 'i' flag set to 1, but not carrying a Subnet-Information suboption), + the Server returns in the DHCPOFFER message the subnet information + for the first subnet(s) from this list. If the end of the list has + been reached, then the 's' bit of the last Subnet-Information + suboption included in the message MUST be set to 0. If there are + more subnets in the list, the 's' bit MUST be set to 1 to indicate to + the Client that more information is available. Since this + information is in response to a Client request for previously + allocated subnet information, the 'c' bit MUST be set to 1. + +6.3. Additional Client DHCPDISCOVER Messages + + The Client, upon receiving any Server DHCPOFFER messages containing + Subnet Information suboption information with the 'c' ("Client") bit + set, SHOULD gather the network number ("Network") and prefix length + ("Prefix") information from the message. + + If the 's' bit is set in the last of the Subnet-Information + suboptions included in the message, then the Client SHOULD construct + a new DHCPDISCOVER message containing the Subnet Allocation option + and the last Subnet-Information suboption from the Server's message. + This message SHOULD then be sent back to the same DHCP Server + originating the DHCPOFFER message. The 'c' and 's' bits MUST retain + the same settings they had from the Server's DHCPOFFER message and + the network number ("Network") and prefix length ("Prefix") fields + MUST be unaltered as well. + + If the 's' bit in all of the Subnet-Information suboptions from the + Server was 0, then it indicates the Server has no more information + about subnets allocated to the Client. + +6.4. Additional Server DHCPOFFER Responses + + The Server, upon receiving from a Client an additional DHCPDISCOVER + message for allocated subnet information retrieval, with the 'i' flag + set to 1 and containing one or more Subnet Information suboptions + with the 'c' and the 's' bits set, MUST use the network number + + + +Johnson, et al. Informational [Page 16] + +RFC 6656 Cisco Systems' DHCP Subnet Alloc Option July 2012 + + + ("Network") and prefix length ("Prefix") fields contained in the last + such Subnet Information suboption. This is in order to locate the + position in the internal table of allocated subnets for this Client. + Then, the Server MUST return an DHCPOFFER 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. Any Subnet Information suboptions + encountered without both the 'c' and 's' bits set should be ignored + by the Server. + +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. + +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 [RFC2131]. + +8.1. Example 1 + + A DHCP Client requesting a subnet with prefix length 24 from which + the Client will allocate addresses to other Clients. The Server + responds with an allocation of exactly the size requested: + + The Client sends a DHCPDISCOVER message including a Subnet Allocation + option with the Subnet-Request suboption: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 220 | 5 | 0 | 1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 2 | 0 |0|0| 24 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Server responds with a DHCPOFFER message including a Subnet + Allocation option with a Subnet-Information suboption, offering the + subnet 10.0.1.0/24. + + + + + + + + + + +Johnson, et al. Informational [Page 17] + +RFC 6656 Cisco Systems' DHCP Subnet Alloc Option July 2012 + + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 220 | 11 | 0 | 2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 8 | 0 |0|0| 10 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 1 | 0 | 24 | |0|0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | + +-+-+-+-+-+-+-+-+ + + The Client sends a DHCPREQUEST including a Subnet Allocation option + with a Subnet-Information suboption: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 220 | 11 | 0 | 2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 8 | 0 |0|0| 10 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 1 | 0 | 24 | |0|0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | + +-+-+-+-+-+-+-+-+ + + The Server responds with a DHCPACK message including a Subnet + Allocation option with a Subnet-Information suboption: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 220 | 11 | 0 | 2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 8 | 0 |0|0| 10 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 1 | 0 | 24 | |0|0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | + +-+-+-+-+-+-+-+-+ + + Later, the Client sends a DHCPRELEASE message including a Subnet + Allocation option with a Subnet-Information suboption: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 220 | 11 | 0 | 2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 8 | 0 |0|0| 10 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 1 | 0 | 24 | |0|0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | + +-+-+-+-+-+-+-+-+ + + + +Johnson, et al. Informational [Page 18] + +RFC 6656 Cisco Systems' DHCP Subnet Alloc Option July 2012 + + +8.2. Example 2 + + A DHCP Client requesting two subnets, each with prefix length 24: + + The Client sends a DHCPDISCOVER message including a Subnet Allocation + option with a Subnet-Request suboption: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 220 | 9 | 0 | 1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 2 | 0 |0|0| 24 | 1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 2 | 0 |0|0| 24 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Server responds with a DHCPOFFER message including a Subnet + Allocation option with a Subnet-Information suboption: + + The DHCPOFFER specifies one subnet of size 24 and one subnet of size + 28. + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 220 | 18 | 0 | 2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 15 | |0|0| 10 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 2 | 0 | 24 | |0|0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 10 | 0 | 3 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | 28 | |0|0| 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Client sends a DHCPREQUEST message including a Subnet Allocation + option with a Subnet-Information suboption: + + The Client decides that the subnet of size 28 is not sufficient so it + doesn't include that subnet in the DHCPREQUEST message. + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 220 | 11 | 0 | 2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 8 | |0|0| 10 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 2 | 0 | 24 | |0|0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | + +-+-+-+-+-+-+-+-+ + + + +Johnson, et al. Informational [Page 19] + +RFC 6656 Cisco Systems' DHCP Subnet Alloc Option July 2012 + + + The Server responds with a DHCPACK message including a Subnet + Allocation option with a Subnet-Information suboption: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 220 | 11 | 0 | 2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 8 | |0|0| 10 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 2 | 0 | 24 | |0|0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | + +-+-+-+-+-+-+-+-+ + + Later, the Client sends a DHCPREQUEST message in order to renew the + lease on the one subnet and includes 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. + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 220 | 17 | 0 | 2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 14 | |0|0| 10 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 2 | 0 | 24 | |0|0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 6 | 0 | 10 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 7 | 0 | 2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Server responds with a DHCPACK message; however, it signals to + the Client that the subnet should be deprecated. + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 220 | 11 | 0 | 2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 8 | |0|0| 10 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 2 | 0 | 24 | |0|1| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | + +-+-+-+-+-+-+-+-+ + + The Client reloads at this point and, upon completion of the reload, + sends a DHCPDISCOVER asking for information about all subnets that + were allocated to it. + + + + +Johnson, et al. Informational [Page 20] + +RFC 6656 Cisco Systems' DHCP Subnet Alloc Option July 2012 + + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 220 | 5 | 0 | 1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 2 | |1|0| 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Server responds with a DHCPOFFER, giving the subnet information + about the one subnet that 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 0, thus indicating + that there is no more information available for this Client. + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 220 | 11 | 0 | 2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 8 | |1|0| 10 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 2 | 0 | 24 | |0|1| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | + +-+-+-+-+-+-+-+-+ + + The Client responds with a DHCPRELEASE message after having + deprecated the subnet: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 220 | 11 | 0 | SIS | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 8 | |0|0| 10 | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 2 | 0 | 24 | |0|0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0 | + +-+-+-+-+-+-+-+-+ + +9. Differences from DHCPv6 Prefix Delegation + + The following differences may be noticed between Subnet Allocation as + described in this document and DHCPv6 Prefix Delegation as described + in [RFC3633]: + + o This option does not use anything like an "IA_PD" as is used in + DHCPv6. + + o If the Server cannot allocate a subnet, it remains silent, instead + of returning a special response saying nothing is available. + + + + + +Johnson, et al. Informational [Page 21] + +RFC 6656 Cisco Systems' DHCP Subnet Alloc Option July 2012 + + + 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 DHCPNAK 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 + block). 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. + +10. Security Considerations + + Potential exposures to attack are discussed in Section 7 of the DHCP + protocol specification [RFC2131]. The Subnet Allocation option can + be used to hoard all allocable subnets on a network. + + Implementations should consider using the DHCP Authentication option + [RFC3118] in order to provide a higher level of security if it is + deemed necessary in their environment. + +11. IANA Considerations + + IANA has assigned DHCP option number 220 for this option, in + accordance with [RFC3942]. + + 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 [RFC5226]. Basically, this means that they are defined by RFCs + approved by the IESG. + + + + + + + + + +Johnson, et al. Informational [Page 22] + +RFC 6656 Cisco Systems' DHCP Subnet Alloc Option July 2012 + + +12. References + +12.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", + RFC 2131, March 1997. + + [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor + Extensions", RFC 2132, March 1997. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [RFC3942] Volz, B., "Reclassifying Dynamic Host Configuration + Protocol version 4 (DHCPv4) Options", RFC 3942, + November 2004. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + +12.2. Informative References + + [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP + Messages", RFC 3118, June 2001. + + [RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP + reconfigure extension", RFC 3203, December 2001. + + [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the + Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, + November 2002. + + [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic + Host Configuration Protocol (DHCP) version 6", RFC 3633, + December 2003. + + [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing + (CIDR): The Internet Address Assignment and Aggregation + Plan", BCP 122, RFC 4632, August 2006. + + + + + + + + +Johnson, et al. Informational [Page 23] + +RFC 6656 Cisco Systems' DHCP Subnet Alloc Option July 2012 + + +Appendix A. Acknowledgments + + The authors gratefully acknowledge the contributions of Jay + Kumarasamy. + +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 + + + 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. Informational [Page 24] + |