idnits 2.17.1 draft-ietf-dhc-subnet-alloc-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3942]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The Server need not reserve the subnets which 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 document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 5, 2012) is 4397 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Johnson 3 Internet-Draft J. Kumarasamy 4 Intended status: Informational K. Kinnear 5 Expires: October 7, 2012 M. Stapp 6 Cisco Systems, Inc. 7 April 5, 2012 9 Description of Cisco Systems' Subnet Allocation Option for DHCPv4 10 draft-ietf-dhc-subnet-alloc-13.txt 12 Abstract 14 This memo documents a currently existing and previously privately 15 defined DHCPv4 option, documenting the operation and usage of the 16 Cisco Systems Subnet Allocation Option for DHCPv4. The option is 17 passed between the DHCPv4 Client and the DHCPv4 Server to request 18 dynamic allocation of a subnet, give specifications of subnet(s) 19 allocated, and report usage statistics. This memo documents the 20 current usage of the option in agreement with [RFC3942], which 21 declares that any pre-existing usages of option numbers in the range 22 128 - 223 should be documented and the working group will try to 23 officially assign those numbers to those options. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 7, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. Subnet Allocation Option format . . . . . . . . . . . . . . . 6 74 3.1. Subnet-Request Suboption format . . . . . . . . . . . . . 6 75 3.2. Subnet-Information Suboption format . . . . . . . . . . . 8 76 3.2.1. Subnet Prefix Information block format . . . . . . . . 9 77 3.3. Subnet-Name Suboption format . . . . . . . . . . . . . . . 11 78 3.4. Suggested-Lease-Time Suboption format . . . . . . . . . . 11 79 4. Requesting allocation of a subnet . . . . . . . . . . . . . . 13 80 4.1. Client DHCPDISCOVER message . . . . . . . . . . . . . . . 13 81 4.2. Server DHCPOFFER message . . . . . . . . . . . . . . . . . 13 82 4.3. Client DHCPREQUEST message . . . . . . . . . . . . . . . . 14 83 4.4. Server DHCPACK message . . . . . . . . . . . . . . . . . . 14 84 5. Client renewal of subnet lease . . . . . . . . . . . . . . . . 16 85 5.1. Client RENEW DHCPREQUEST message . . . . . . . . . . . . . 16 86 5.2. Server RENEW DHCPREQUEST response . . . . . . . . . . . . 16 87 5.3. Client DHCPRELEASE message . . . . . . . . . . . . . . . . 17 88 5.4. Server DHCPFORCERENEW message . . . . . . . . . . . . . . 17 89 6. Client requesting previously allocated subnet information . . 18 90 6.1. Client Initial DHCPDISCOVER Message . . . . . . . . . . . 18 91 6.2. Server Initial DHCPOFFER Response . . . . . . . . . . . . 18 92 6.3. Client Additional DHCPDISCOVER Messages . . . . . . . . . 18 93 6.4. Server Additional DHCPOFFER Responses . . . . . . . . . . 19 94 7. DHCP Server Subnet Allocation method . . . . . . . . . . . . . 20 95 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 96 8.1. Example 1: . . . . . . . . . . . . . . . . . . . . . . . . 21 97 8.2. Example 2: . . . . . . . . . . . . . . . . . . . . . . . . 22 98 9. Differences from DHCPv6 Prefix Delegation . . . . . . . . . . 26 99 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 100 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 101 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 102 12.1. Normative References . . . . . . . . . . . . . . . . . . . 29 103 12.2. Informative References . . . . . . . . . . . . . . . . . . 29 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 106 1. Introduction 108 This memo documents a DHCP option [RFC2132], the Subnet Allocation 109 option, that was developed by Cisco and allows a DHCP Client to 110 allocate a subnet given information from a DHCP Server. This 111 protocol makes use of DHCP option number 220, one of the option 112 numbers reclassified by [RFC3942]. That RFC specifies in section 4, 113 procedure 2, "Vendors that currently use one or more of the 114 reclassified options have 6 months following this RFC's publication 115 date to notify the DHC WG and IANA that they are using particular 116 options numbers and agree to document that usage in an RFC." This 117 memo serves as that documentation. The DHC WG has had no input into 118 any of the details of the protocol operation and makes no statement 119 about the correctness or any other aspect of the protocol. The WG 120 also has seen no interest in further implementation or deployment of 121 this protocol other than privately, and therefore has decided to 122 publish this document solely for informational purposes. 124 The Subnet Allocation option provides a straightforward way to 125 allocate a subnet from DHCP, useful for a simple Dialin Aggregation 126 box, or to implement a Hierarchical chain of DHCP Servers, each one 127 in turn leasing one or more subnets to the next DHCP Server down the 128 chain. This option is specified in such a way as to use one DHCP 129 Option number, while using suboption numbers for each function. 131 2. Conventions 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 This document also uses the following terms: 139 DHCP Client: DHCP Client or "Client" is an Internet host using DHCP 140 to obtain configuration parameters such as a network address. 142 DHCP Server: A DHCP Server or "Server" is an Internet host that 143 returns configuration parameters to DHCP Clients. 145 3. Subnet Allocation Option format 147 0 1 2 148 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 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 150 | Code | Len | Flags | Suboptions ... 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 153 Code = Subnet Allocation option code (1 octet): 220 154 Len = Length of the entire option including all sub-options 155 (1 octet) 156 Flags = Various flags: (None currently defined) 158 One or more sub-options may be specified as described below. 160 3.1. Subnet-Request Suboption format 162 0 1 2 3 163 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 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | 1 | Len | Flags :i:h| Prefix | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 Len = Length of the suboption (always 2 for this suboption) 169 (1 octet) 170 Flags = Flags field. (all unused bits must be zero) 172 'h' = Hierarchical flag 173 1 : Client will be allocating addresses from this subnet. 174 0 : Client will be relaying DHCP requests to the Server 175 from this subnet. 176 'i' = Information flag 177 1 : Client is seeking information about previously 178 allocated subnets. 179 0 : Client is seeking a new subnet allocation. 181 Prefix = Network prefix length requested 182 (0 means no suggested length is given) (1 octet) 184 The DHCP Server SHOULD NOT include the Subnet Request suboption in 185 any replies to the DHCP Client. Enough information will be present 186 in the Subnet-Information suboption, such that the Subnet Request 187 suboption is not needed in replies to the Client. 189 The DHCP Server SHOULD allocate a subnet with prefix length [RFC4632] 190 less than or equal to the "Prefix" field length specified in the 191 request. In other words, a subnet containing a number of addresses 192 at least the size indicated by the prefix length requested and 193 possibly more. The DHCP Server MAY allocate a subnet with a prefix 194 length greater than that specified in the request (subnet with a 195 number of addresses less than requested), but this is not encouraged. 197 A "Prefix" field size of 0 MAY be specified by the DHCP Client. In 198 this case, no suggested prefix length is given. 200 Multiple Subnet-Request suboptions in a DHCP packet indicate that 201 multiple subnets are being requested. Note that multiple occurrances 202 of this suboption MUST NOT be concatenated in the sense of [RFC3396]. 204 Each Subnet-Request suboption MUST result in no more than one Subnet- 205 Information suboption in the DHCPOFFER message from the Server, and 206 may result in no Subnet-Information suboptions. 208 The Client MAY also include the Subnet-Information suboption in order 209 to request a particular subnet. In this case, the Client SHOULD only 210 include one Subnet-Request suboption, since it would otherwise be 211 unclear which Subnet-Information suboption refered to which Subnet- 212 Request suboption. Multiple subnet requests can be made by sending 213 multiple DHCPDISCOVER packets. 215 Setting the 'h' flag to 1 indicates the Client will be allocating 216 addresses from the allocated subnet(s) itself. This can be thought 217 of as a "Hierarchial DHCP" design in that control of allocation for 218 the subnet(s) will be passed to the Client. 220 Setting the 'h' flag to 0 indicates the Client wants the DHCP Server 221 to retain control over allocation of addresses from the subnet(s). 222 Any address allocation requests on the subnet will be relayed back to 223 the DHCP Server. 225 Setting the 'i' flag to 1 indicates the Client is NOT seeking 226 allocation of any subnets, but is simply seeking information from the 227 Server as to what subnet(s) have been allocated (or reserved) for 228 this Client. If the 'i' flag is set to 1, then the "Prefix" field 229 SHOULD be set to 0 and MUST be ignored by the Server. In this case, 230 the conversation between the Client and the Server will only progress 231 to the DHCPOFFER packet from the Server, giving the information, as 232 described in section 6 below. 234 Any undefined flags (those other than 'i' and 'h', mentioned above) 235 should be ignored by the DHCP Server. 237 3.2. Subnet-Information Suboption format 239 0 1 2 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 242 | 2 | Len | Flags :c:s| SP1, SP2, ... 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 245 Len = Length of the sub-option (min. length of 8) (1 octet) 246 Flags = Various flags which apply to ALL Subnet Prefix 247 Information fields specified in this suboption. 248 Unused flags must be zero. 250 'c' : Client flag (explained below) 251 1 : This information is in response to a client request 252 (or has been echoed back by the client, when asking 253 for the next previously allocated subnet from the 254 server) 255 0 : Otherwise 256 's' : Server flag (explained below) 257 1 : Server has additional subnet information for this 258 client 259 0 : Otherwise 261 SP1, SP2, ... Subnet Prefix information blocks as specified below 262 (variable sized) 264 The "Client flag" ('c') is set to 1 if this Subnet-Information 265 suboption is in response to a Client request for information from the 266 Server as to what subnet(s) have been allocated. This flag is used 267 in response to a Subnet-Request suboption with the 'i' flag set and 268 should be 0 in other Server responses. Note, the flag is echoed back 269 from the Client to the Server when requesting the "next previously 270 allocated subnet". Another way to think of the 'c' bit would be that 271 it indicates that the subnet information contained in this suboption 272 does not represent a new allocation by the Server or a new request 273 for allocation by the Client, but instead represents previously 274 allocated subnet information. 276 The "Server flag" ('s') is set to 1 if the Server has additional 277 subnet information for the Client. 279 Any undefined flags (those other than 'c' and 's', mentioned above) 280 should be ignored by the DHCP Server. 282 The Subnet-Information suboption is used by the DHCP Server in order 283 to return information as to what subnets are offered (in the case of 284 a DHCPOFFER packet) or allocated (in the case of a DHCPACK packet). 285 As is indicated above, multiple subnets may be returned in one 286 Subnet-Information suboption. 288 The Subnet-Information suboption is also used by the DHCP Client in 289 order to request allocation of specific subnets in a DHCPREQUEST 290 packet. In this case, the "Network", "Prefix", and "Flags" fields 291 contained in the associated Subnet Prefix Information blocks MUST NOT 292 be changed from the information which was received in the DHCPOFFER 293 packet from the server. The Client MAY, however, use multiple 294 Subnet-Information suboptions in order to request subnets which were 295 originally specified by the Server inside one Subnet-Information 296 suboption. 298 3.2.1. Subnet Prefix Information block format 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Network | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Prefix | Flags |h|d| Stat-len | Optional stats... 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 Network = IPv4 network number (4 octets) 309 Prefix = Prefix length (1 octet) 310 Flags = Flags field (Undefined bits must be zero) (1 octet) 312 'd' = Deprecate flag (explained below) 313 1 : Deprecation of this subnet is requested 314 0 : No deprecation is needed 316 'h' = Hierarchical flag (explained below) 317 1 : Client will be allocating addresses from this subnet 318 0 : Client will be relaying DHCP requests to the server 319 from this subnet. 321 Stat-len = Length of the optional statistics information field 322 (zero if no statistics are included) 324 The 'd' flag may only be returned by the Server to the Client (inside 325 a DHCPACK packet, in response to a DHCP RENEW). It's presence means 326 that the Client should prepare to give up the subnet. For example, 327 if the Client is assigning addresses from this subnet to other 328 clients, it should cease doing so immediately and should not renew 329 any leases when clients ask for renewal. As soon as all addresses in 330 the subnet are unallocated, the Client should send a DHCPRELEASE 331 message to the Server, including a Subnet Prefix Information 332 suboption for the subnet in order to release the subnet. The format 333 of this message is described farther below. 335 The 'h' flag tells the Client how the Server intends for the Client 336 to use the allocated subnet. It is interpreted in the same manner as 337 that in the Subnet-Request suboption. In response to a Subnet- 338 Request, the Server should normally specify the 'h' flag in the same 339 manner as it was in the Subnet-Request suboption from the Client. 340 The Server MAY, however, change the 'h' flag from that specified in 341 the Subnet-Request suboption if it has been configured to override 342 the Client's request. 344 Any undefined flags (those other than 'd' and 'h', mentioned above) 345 should be ignored by the DHCP Server. 347 If any usage statistics information is to be included, then the 348 "Stat-len" field specifies the number of bytes of statistics 349 information which is included. See below for more information. If 350 no statistics information is included, then this byte MUST be zero. 351 The "Stat-len" field SHOULD always be zero when this suboption is 352 sent by the DHCP Server. The usage statistics information is 353 intended for use only to report usage statistics from the Client to 354 the Server. 356 3.2.1.1. Subnet Usage Statistics 358 The Subnet-Information suboption may also include usage statistics 359 information. If this information is included, then the "Stat-len" 360 (Statistics length) field MUST be set to the number of bytes of 361 statistics information which is being included. The statistics 362 information MUST be in the following form and order: 364 0 1 365 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | High water | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Currently in use | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Unusable | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 "High water" refers the to "high water mark" of allocated addresses 375 within the subnet. I.e., the largest number of addresses which were 376 ever allocated at one time from the subnet. 378 "Currently in use" refers to the number of addresses currently 379 allocated in the subnet. 381 "Unusable" refers to the number of addresses which are currently 382 unusable for any reason (such as a client returning a DHCPDECLINE, or 383 finding the address already in use). 385 Additional statistics may be added to this option in the future. If 386 so, they MUST be appended immediately after the already defined 387 statistics fields. All statistics fields MUST remain in the same 388 order. Use the all ones value (0xFFFF) in order to skip reporting a 389 number for a particular field. Fewer fields may be included than 390 what is specified above, for example the if "Stat-len" is "4", then 391 the "Unusable" field has not been included. All fields which are 392 included MUST remain in order specifed here. 394 3.3. Subnet-Name Suboption format 396 0 1 397 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 399 | 3 | Len | Name ... 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 402 Len = length of the sub-option (min. length of 1) (1 octet) 404 The Subnet-Name suboption may be used in order to pass a subnet name 405 to the server for use during allocation. This name may be used for 406 any purpose but is intended to tell the server something extra about 407 the needed subnet; for example, "sales department", "customer 1002", 408 "address pool FOO", or some such. The "name" should NOT be NULL 409 terminated since the "len" field already specifies the length of the 410 name. The "Name" in this suboption MUST be given using UTF-8 411 [RFC3629]. 413 3.4. Suggested-Lease-Time Suboption format 415 0 1 2 3 416 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 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | 4 | Len (4) | t1 | t2 | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | t3 | t4 | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 Len = length of the sub-option (always 4 for this suboption) (1 423 octet) 425 The Suggested-Lease-Time suboption MAY be included by the Server in 426 order to suggest the lease time to be used by the Client when 427 allocating addresses from the subnet allocated. The four (4) octet 428 value of the lease time is in the same format as that of the "IP 429 Address Lease Time" option (option 51), as described in [RFC2132]. 431 If included, this suboption MUST appear only once. (Inclusion of 432 multiple such suboptions would result in ambiguity as to which 433 applied to which subnet.) If different suggested lease times are 434 needed, the Server SHOULD, instead, reply with only one offered 435 subnet and should set the "Server flag" in the Subnet-Information 436 suboption to indicate to the Client that it should send another 437 subnet request to gather the others. 439 The Client SHOULD use a lease time, when allocating addresses from 440 the subnet, which is the lesser of the remaining lease time of the 441 subnet itself and the Suggested-Lease-Time suboption. 443 4. Requesting allocation of a subnet 445 4.1. Client DHCPDISCOVER message 447 The DHCP Client creates a DHCPDISCOVER message including the Subnet 448 Allocation option, and its set of suboptions, to request allocation 449 of a subnet. The DHCP Client should include the Subnet-Request 450 suboption, specifying the prefix length of the subnet requested. The 451 'h' bit should be set to 1 if the Client intends to control 452 allocation of addresses within the subnet itself, or 0 if the Server 453 should retain control of addresses within the subnet. More than one 454 Subnet Allocation option may appear in a DHCPDISCOVER message, 455 however the client SHOULD limit the number of requests, noting that 456 the DHCP replies will need to include the Subnet-Information 457 suboption, which takes up more space than the Subnet-Request 458 suboption. 460 If more than one subnet is being requested, multiple Subnet-Request 461 suboptions MAY be included or multiple DHCPDISCOVER messages MAY be 462 sent instead. The prefix length field of each Subnet-Request 463 suboption MUST be either 0, or in the range of 1 to 30 inclusive. 465 The DHCP "IP address lease time" option (code 51) MAY be included in 466 the DHCPDISCOVER message to specify the lease time the Client is 467 requesting for the subnet. If not present, no suggested lease time 468 is given. 470 The DHCP "Client ID" option (code 61) MAY be included in the 471 DHCPDISCOVER message as it may be used by the Server in performing 472 the subnet allocation. 474 4.2. Server DHCPOFFER message 476 Upon receiving a DHCPDISCOVER containing the Subnet Allocation 477 option, the DHCP Server SHOULD respond with a DHCPOFFER message 478 including the Subnet-Information suboption in order to specify the 479 subnet(s) which it is willing to allocate to the Client in order to 480 fulfill the request(s). 482 The Server need not reserve the subnets which are being offered, but 483 SHOULD not offer the same subnets to another DHCP Client until a 484 reasonable time period (implementation dependent) has passed. (This 485 is similar to normal DHCP address allocation.) 487 The Server MUST NOT include the Subnet-Request suboption in the 488 DHCPOFFER. The same information is already present in the Subnet 489 Information suboption(s) which SHOULD be included in the DHCPOFFER. 491 The Server SHOULD also include the IP address lease time option 492 (option 51) in the DHCPOFFER message. This gives the lease time for 493 all subnets given in all Subnet-Request suboptions contained in the 494 DHCPOFFER message. The Server MAY also include the Renewal and/or 495 Rebinding options in order to further control the "T1" and "T2" lease 496 timers of the client. There MUST be only one IP address lease time, 497 rebind, and/or renew option each in the DHCPOFFER message. 499 The Server MAY set the "Server flag" ('s') to 1 to indicate that it 500 would like to allocate one or more additional subnet(s) to the 501 Client. This indicates that the Client should send another 502 DHCPDISCOVER message specifying a zero prefix length field, P, in 503 order to request the additional subnet allocation(s) information. 504 This may be necessary if the subnets are to be allocated with 505 different lease times, for example. 507 The "Client flag" ('c') MUST be set to 0 to indicate this is a Server 508 response to a client request for a new subnet allocation and not a 509 response to a request for information about already allocated 510 subnets. 512 The Server SHOULD set the DHCP yiaddr value to all zeros (0.0.0.0) 513 and the Client MUST ignore fields having to do with address 514 assignment if the packet contains a Subnet Allocation option. In 515 other words, a DHCP packet exchange can not provide subnet allocation 516 and address assignment simultaneously. 518 4.3. Client DHCPREQUEST message 520 When sending a DHCPREQUEST, the Client MUST NOT modify any fields of 521 all Subnet-Information suboptions received from the Server. However, 522 the Client MAY choose not to include some Subnet-Information 523 suboptions when issuing the DHCPREQUEST. Subnet-Request suboptions 524 MUST NOT be included in the DHCPREQUEST message, only the Subnet- 525 Information suboption(s) should be included. 527 4.4. Server DHCPACK message 529 The DHCP Server, upon receipt of the Client's DHCPREQUEST message, 530 MAY refuse allocation of any subnets (for example, if they have been 531 allocated elsewhere in the meantime), however since the Server should 532 have set aside the subnets offered for a short period of time, and 533 since the Client should have requested the subnets within a short 534 period of time after receiving the offer(s) from the server(s), this 535 last minute rejection should be rare. The DHCP Server MUST NOT 536 change the network number(s) or prefix length(s), however it MAY 537 remove some Subnet-Information suboptions from the list. 539 The Server SHOULD include the IP address lease time option specifying 540 the lease period for all subnet(s) in the DHCPACK. All subnets 541 allocated in one DHCP message will have the same lease time and only 542 one IP address lease time option must appear in the DHCP message. 544 If the Server has internal information which states that the Client 545 should be allocated more subnets than were requested, the Server MAY 546 set the 's' bit in the last Subnet-Information suboption to indicate 547 that the Client needs to request more subnets (as described above). 549 The allocable unit is the tuple (network number, prefix length). 550 Multiple subnets may be allocated in one DHCPACK, however since there 551 can be only one Lease-time option, each subnet allocated is assigned 552 the same lease time. Each subnet lease tuple (network number, prefix 553 length) MAY be renewed or released individually. 555 5. Client renewal of subnet lease 557 5.1. Client RENEW DHCPREQUEST message 559 The Client MUST renew all subnets allocated with a lease time in much 560 the same manner as renewing an allocated IP address. Renewal timers 561 need not be set in exactly the same manner, however. If Renewal 562 and/or Rebinding options were included in the DHCPACK of the subnet 563 allocation, then these "T1" and "T2" timers should be used just as 564 they would be in the case of address allocation timers. 566 The DHCPREQUEST message MUST include a Subnet-Information suboption 567 for which the Client is seeking renewal of the lease. This Subnet- 568 Information suboption may optionally include subnet usage statistics, 569 as described above in the Subnet-Information suboption format section 570 (3.2). 572 The subnet network number field ("Network") and subnet prefix length 573 field ("Prefix") MUST agree with the values as they were originally 574 allocated to the Client by the Server. In any of the statistics 575 fields (High, Current, Unusable), a value of all ones (0xffff) SHOULD 576 be used if the Client has no information to report for a statistic. 578 5.2. Server RENEW DHCPREQUEST response 580 The Server MAY respond to a subnet RENEW with either a DHCPACK or 581 DHCPNAK response. If a DHCPNAK response is given the Client MUST 582 immediately stop using the subnet(s) specified and, if possible, 583 notify all Clients with addresses allocated from this subnet that 584 their addresses are no longer valid. The Client MAY, of course, send 585 a DHCPDISCOVER message containing the Subnet Allocation option and 586 the Subnet-Request suboption in order to acquire another subnet for 587 use. In general, the Server should ask the Client to deprecate 588 subnets by using the 'd' bit of the Subnet-Information suboption in a 589 DHCPACK message (see below). 591 If a DHCPACK response is given, the "Deprecate" ('d') bit of the 592 flags field in the Subnet-Information suboption may also be set. 593 This indicates the DHCP Client should "prepare to stop using this 594 subnet". If the Client is allocating IP addresses for other clients 595 from this subnet (e.g. via DHCP), the Client SHOULD immediately stop 596 allocating such addresses. Once all allocated addresses in the 597 subnet have been released, the Client SHOULD send a DHCPRELEASE 598 message, including the Subnet-Information suboption (with optional 599 usage statistics) in order to release the subnet(s) back to the 600 Server. 602 5.3. Client DHCPRELEASE message 604 The DHCP Client SHOULD send a DHCPRELEASE message in order to release 605 allocated subnet(s) back to the Server when it is finished using 606 them. This message MUST NOT include the Subnet-Request suboption, 607 but MUST include one or more Subnet-Information suboptions, and 608 optionally including usage statistics. 610 The Client MUST release the same subnet(s) of the same prefix length 611 ("Prefix"), as was originally allocated. The Client MAY release a 612 subset of the subnets which were allocated originally. In other 613 words, the allocable unit is the tuple (network number, prefix 614 length). Multiple subnets may be allocated in one DHCPACK, however 615 each subnet MAY be released individually. 617 5.4. Server DHCPFORCERENEW message 619 The DHCP Server MAY issue a DHCPFORCERENEW [RFC3203] message 620 containing the Subnet Allocation option and the Subnet-Information 621 suboption. Upon receiving this message, the DHCP Client MUST issue a 622 DHCPREQUEST message to the DHCP Server in order to renew the lease on 623 the subnet mentioned. No other subnets allocated to the Client are 624 effected. As is the case with all DHCP RENEW messages, the Client 625 may include subnet usage information in the Subnet-Information 626 suboption in order to report subnet usage statistics, or set the 627 "Stat-len" field to 0 if no statistics are to be reported. 629 If the Server responds to this DHCPREQUEST with a DHCPNAK message, 630 then the Client MUST immediately stop using the subnet(s) and, if 631 possible, notify all Clients with addresses allocated from this/these 632 subnet(s) that their addresses are no longer valid. The Client MAY, 633 of course, send a DHCPDISCOVER message containing the Subnet 634 Allocation option and the Subnet-Request suboption in order to 635 acquire another subnet for use. 637 6. Client requesting previously allocated subnet information 639 A DHCP Client MAY request from the DHCP Server a list of what subnets 640 are currently allocated to the Client. This may be used to recover 641 from a restart if the Client does not have local storage in order to 642 retain the information itself. (For example of this, see the section 643 8.2 below.) 645 6.1. Client Initial DHCPDISCOVER Message 647 The DHCP Client DHCPDISCOVER message, when used to discover already 648 allocated subnet information, SHOULD contain a Subnet-Request 649 suboption with the "Prefix" field set to 0 and with the 'i' flag set 650 to 1 to indicate that the Client is seeking already allocated subnet 651 information from the Server. No Subnet-Information suboptions should 652 be included in this message. Note, no Subnet-Information suboption 653 is included in this message, since the client would not know of any 654 subnet to request at this point. 656 This DHCPDISCOVER message MAY be unicast to a particular DHCP Server, 657 or broadcast in the normal fashion. 659 6.2. Server Initial DHCPOFFER Response 661 Any DHCP Server which has allocated subnets to the Client SHOULD 662 respond to the DHCPDISCOVER message with a DHCPOFFER message. The 663 DHCPOFFER message should contain one or more Subnet-Information 664 suboption(s) telling the prefix of the subnet(s) allocated to the 665 Client. 667 The Server SHOULD, internally, retain an ordered list of subnets 668 which are allocated to each Client. In response to an initial 669 DHCPDISCOVER message requesting allocated subnet information (i.e., 670 one with the 'i' flag set to 1, but not carrying a Subnet-Information 671 suboption), the server returns in the DHCPOFFER message the subnet(s) 672 information for the first subnet(s) from this list. If the end of 673 the list has been reached, then the 's' bit of the last Subnet- 674 Information suboption included in the message MUST be set to 0. If 675 there are more subnets in the list, the 's' bit MUST be set to 1 to 676 indicate to the Client that more information is available. Since 677 this information is in response to a client request for previously 678 allocated subnet information, the 'c' bit MUST be set to 1. 680 6.3. Client Additional DHCPDISCOVER Messages 682 The Client, upon receiving any Server DHCPOFFER messages containing 683 Subnet Information suboption information with the 'c' ("Client") bit 684 set, SHOULD gather the network number ("Network") and prefix length 685 ("Prefix") information from the message. 687 If the 's' bit is set in the last of the Subnet-Information 688 suboptions included in the message, then the client SHOULD construct 689 a new DHCPDISCOVER message containing the Subnet Allocation option 690 and the last Subnet-Information suboption from the Server's message. 691 This message SHOULD then be sent back to the same DHCP Server 692 originating the DHCPOFFER message. The 'c' and 's' bits MUST retain 693 the same settings they had from the Server's DHCPOFFER message and 694 the network number ("Network") and prefix length ("Prefix") fields 695 MUST be unaltered as well. 697 If the 's' bit in all of the Subnet-Information suboptions from the 698 Server was 0, then it indicates the Server has no more information 699 about subnets allocated to the Client. 701 6.4. Server Additional DHCPOFFER Responses 703 The Server, upon receiving from a Client an additional DHCPDISCOVER 704 message for allocated subnet information retrieval, with the 'i' flag 705 set to 1 and containing one or more Subnet Information suboptions 706 with the 'c' and the 's' bits set, MUST use the network number 707 ("Network") and prefix length ("Prefix") fields contained in the last 708 such Subnet Information suboption in order to locate the position in 709 the internal table of allocated subnets for this Client, and then 710 return an DHCPOFFER message containing a Subnet-Information suboption 711 giving information about the next set of subnets allocated to this 712 Client. If this finishes the list in the table for this Client, then 713 the 's' bit MUST be set to 0 to indicate there is no more 714 information. Any Subnet Information suboptions encountered without 715 both the 'c' and 's' bits set should be ignored by the Server. 717 7. DHCP Server Subnet Allocation method 719 The actual method of allocating subnets on the DHCP Server, as well 720 as the configuration of what networks may be subnetted and how, is 721 left up to the implementation. 723 8. Examples 725 Only the Subnet Allocation option and accompanying suboptions are 726 displayed in these examples. All other fields in the DHCP messages 727 are described in [RFC2131]. 729 8.1. Example 1: 731 A DHCP Client requesting a subnet with prefix length 24 from which 732 the Client will allocate addresses to other clients. The Server 733 responds with an allocation of exactly the size requested: 735 The Client sends a DHCPDISCOVER message including a Subnet Allocation 736 option with the Subnet-Request suboption: 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | 220 | 5 | 0 | 1 | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | 2 | 0 |0|0| 24 | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 The Server responds with a DHCPOFFER message including a Subnet 745 Allocation option with a Subnet-Information suboption, offering the 746 subnet 10.0.1.0/24. 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | 220 | 11 | 0 | 2 | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | 8 | 0 |0|0| 10 | 0 | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | 1 | 0 | 24 | |0|0| 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | 0 | 756 +-+-+-+-+-+-+-+-+ 758 The Client sends a DHCPREQUEST including a Subnet Allocation option 759 with a Subnet-Information suboption: 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | 220 | 11 | 0 | 2 | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | 8 | 0 |0|0| 10 | 0 | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | 1 | 0 | 24 | |0|0| 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | 0 | 769 +-+-+-+-+-+-+-+-+ 770 The Server responds with a DHCPACK message including a Subnet 771 Allocation option with a Subnet-Information suboption: 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | 220 | 11 | 0 | 2 | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | 8 | 0 |0|0| 10 | 0 | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | 1 | 0 | 24 | |0|0| 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | 0 | 781 +-+-+-+-+-+-+-+-+ 783 Later the Client sends a DHCPRELEASE message including a Subnet 784 Allocation option with a Subnet-Information suboption: 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | 220 | 11 | 0 | 2 | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | 8 | 0 |0|0| 10 | 0 | 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | 1 | 0 | 24 | |0|0| 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | 0 | 794 +-+-+-+-+-+-+-+-+ 796 8.2. Example 2: 798 A DHCP Client requesting two subnets, each with prefix length 24: 800 The Client sends a DHCPDISCOVER message including a Subnet Allocation 801 option with a Subnet-Request suboption: 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | 220 | 9 | 0 | 1 | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | 2 | 0 |0|0| 24 | 1 | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | 2 | 0 |0|0| 24 | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 The Server responds with a DHCPOFFER message including a Subnet 812 Allocation option with a Subnet-Information suboption: 814 The DHCPOFFER specifies 1 subnet of size 24 and 1 subnet of size 28. 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | 220 | 18 | 0 | 2 | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | 15 | |0|0| 10 | 0 | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | 2 | 0 | 24 | |0|0| 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | 0 | 10 | 0 | 3 | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | 0 | 28 | |0|0| 0 | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 The Client sends a DHCPREQUEST message including a Subnet Allocation 829 option with a Subnet-Information suboption: 831 The Client decides that the subnet of size 28 is not sufficient so it 832 doesn't include that subnet into the DHCPREQUEST message. 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | 220 | 11 | 0 | 2 | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | 8 | |0|0| 10 | 0 | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | 2 | 0 | 24 | |0|0| 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | 0 | 842 +-+-+-+-+-+-+-+-+ 844 The Server responds with a DHCPACK message including a Subnet 845 Allocation option with a Subnet-Information suboption: 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | 220 | 11 | 0 | 2 | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | 8 | |0|0| 10 | 0 | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | 2 | 0 | 24 | |0|0| 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | 0 | 855 +-+-+-+-+-+-+-+-+ 857 Later the Client sends a DHCPREQUEST message in order to renew the 858 lease on the one subnet and includes subnet usage information. It 859 reports that a maximum of 10 addresses were allocated from the subnet 860 since the last report, 7 addresses are currently allocated, and 2 861 addresses were found to be unusable. 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | 220 | 17 | 0 | 2 | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | 14 | |0|0| 10 | 0 | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | 2 | 0 | 24 | |0|0| 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | 6 | 0 | 10 | 0 | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | 7 | 0 | 2 | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 The Server responds with a DHCPACK message, however it signals to the 876 Client that the subnet should be deprecated. 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | 220 | 11 | 0 | 2 | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | 8 | |0|0| 10 | 0 | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | 2 | 0 | 24 | |0|1| 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | 0 | 886 +-+-+-+-+-+-+-+-+ 888 The Client reloads at this point and upon completion of the reload 889 sends a DHCPDISCOVER asking for information about all subnets which 890 were allocated to it. 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | 220 | 5 | 0 | 1 | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | 2 | |1|0| 0 | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 The Server responds with a DHCPOFFER, giving the subnet information 899 of the one subnet which is allocated to the Client. Also the Server 900 specifies that the one allocated subnet should be immediately 901 deprecated. Note that the 's' ("Server") bit is 0 thus indicating 902 that there is no more information available for this Client. 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | 220 | 11 | 0 | 2 | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | 8 | |1|0| 10 | 0 | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | 2 | 0 | 24 | |0|1| 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | 0 | 912 +-+-+-+-+-+-+-+-+ 914 The Client responds with a DHCPRELEASE message after having 915 deprecated the subnet: 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | 220 | 11 | 0 | SIS | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | 8 | |0|0| 10 | 0 | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | 2 | 0 | 24 | |0|0| 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | 0 | 925 +-+-+-+-+-+-+-+-+ 927 9. Differences from DHCPv6 Prefix Delegation 929 The following differences may be noticed between Subnet Allocation as 930 described in this document and DHCPv6 Prefix Delegation as described 931 in [RFC3633]: 933 o This option does not use anything like an "IA_PD" as is used in 934 DHCPv6. 936 o If the Server can not allocate a subnet, it remains silent, 937 instead of returning a special response saying nothing is 938 available. 940 o DHCPv6 Prefix Delegation has no mechanism for returning subnet/ 941 prefix usage statistics. 943 o DHCPv6 has no equivalent to the "subnet deprecation" flag as 944 described here. 946 o DHCPv6 Prefix Delegation makes no mention of what Client actions 947 should result from receiving a DHCPNAK during a RENEW of a 948 delegation. 950 o DHCPv6 has no equivalent of the subnet allocation "Network name" 951 suboption, which may be used by the Server for various purposes, 952 such as to specify a pool to use when allocating a subnet. 954 o DHCPv6 Prefix Delegation corresponds to "Hierarchical Subnet 955 Allocation" (setting the 'h' flag in the Prefix Information 956 suboption). There is no V6 equivalent of clearing the 'h' flag, 957 in which the Server retains authority over allocation of addresses 958 from the subnet. 960 o DHCPv6 Prefix Delegation has nothing to correspond to the 961 Suggested-Lease-Time suboption. 963 10. Security Considerations 965 Potential exposures to attack are discussed in section 7 of the DHCP 966 protocol specification [RFC2131]. The Subnet Allocation option can 967 be used to hoard all allocable subnets on a network. 969 Implementations should consider using the DHCP Authentication option 970 [RFC3118] in order to provide a higher level of security if it is 971 deemed necessary in their environment. Potential exposures to attack 972 are discussed in section 7 of the DHCP protocol specification in 973 [RFC2131]. 975 11. IANA Considerations 977 IANA is requested to assign DHCP option number 220 for this option, 978 in accordance with [RFC3942]. 980 No assignment of values for the suboption codes need be made at this 981 time. New values may only be defined by IETF Consensus, as described 982 in [RFC5226]. Basically, this means that they are defined by RFCs 983 approved by the IESG. 985 12. References 987 12.1. Normative References 989 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 990 Requirement Levels", BCP 14, RFC 2119, March 1997. 992 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 993 RFC 2131, March 1997. 995 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 996 Extensions", RFC 2132, March 1997. 998 [RFC3942] Volz, B., "Reclassifying Dynamic Host Configuration 999 Protocol version 4 (DHCPv4) Options", RFC 3942, 1000 November 2004. 1002 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1003 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1004 May 2008. 1006 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1007 10646", STD 63, RFC 3629, November 2003. 1009 12.2. Informative References 1011 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 1012 Messages", RFC 3118, June 2001. 1014 [RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP 1015 reconfigure extension", RFC 3203, December 2001. 1017 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 1018 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 1019 November 2002. 1021 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1022 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1023 December 2003. 1025 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 1026 (CIDR): The Internet Address Assignment and Aggregation 1027 Plan", BCP 122, RFC 4632, August 2006. 1029 Authors' Addresses 1031 Richard A. Johnson 1032 Cisco Systems, Inc. 1033 170 W. Tasman Dr. 1034 San Jose, CA 95134 1035 US 1037 Phone: +1 408 526 4000 1038 Email: raj@cisco.com 1040 Jay Kumarasamy 1041 Cisco Systems, Inc. 1042 170 W. Tasman Dr. 1043 San Jose, CA 95134 1044 US 1046 Phone: +1 408 526 4000 1047 Email: jayk@cisco.com 1049 Kim Kinnear 1050 Cisco Systems, Inc. 1051 170 W. Tasman Dr. 1052 San Jose, CA 95134 1053 US 1055 Phone: +1 408 526 4000 1056 Email: kkinnear@cisco.com 1058 Mark Stapp 1059 Cisco Systems, Inc. 1060 170 W. Tasman Dr. 1061 San Jose, CA 95134 1062 US 1064 Phone: +1 408 526 4000 1065 Email: mjs@cisco.com