idnits 2.17.1 draft-ietf-dhc-subnet-alloc-12.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). -- 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 (June 2, 2011) is 4705 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 (~~), 3 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: December 4, 2011 M. Stapp 6 Cisco Systems, Inc. 7 June 2, 2011 9 Subnet Allocation Option 10 draft-ietf-dhc-subnet-alloc-12.txt 12 Abstract 14 This document defines a new DHCP option which is passed between the 15 DHCP Client and the DHCP Server to request dynamic allocation of a 16 subnet, give specifications of subnet(s) allocated, and report usage 17 statistics. This memo documents the current usage of the option in 18 agreement with [RFC3942], which declares that any pre-existing usages 19 of option numbers in the range 128 - 223 should be documented and the 20 working group will try to officially assign those numbers to those 21 options. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 4, 2011. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Subnet Allocation Option format . . . . . . . . . . . . . . . 6 72 3.1. Subnet-Request Suboption format . . . . . . . . . . . . . 6 73 3.2. Subnet-Information Suboption format . . . . . . . . . . . 8 74 3.2.1. Subnet Prefix Information block format . . . . . . . . 9 75 3.3. Subnet-Name Suboption format . . . . . . . . . . . . . . . 11 76 3.4. Suggested-Lease-Time Suboption format . . . . . . . . . . 11 77 4. Requesting allocation of a subnet . . . . . . . . . . . . . . 13 78 4.1. Client DHCPDISCOVER message . . . . . . . . . . . . . . . 13 79 4.2. Server DHCPOFFER message . . . . . . . . . . . . . . . . . 13 80 4.3. Client DHCPREQUEST message . . . . . . . . . . . . . . . . 14 81 4.4. Server DHCPACK message . . . . . . . . . . . . . . . . . . 14 82 5. Client renewal of subnet lease . . . . . . . . . . . . . . . . 16 83 5.1. Client RENEW DHCPREQUEST message . . . . . . . . . . . . . 16 84 5.2. Server RENEW DHCPREQUEST response . . . . . . . . . . . . 16 85 5.3. Client DHCPRELEASE message . . . . . . . . . . . . . . . . 17 86 5.4. Server DHCPFORCERENEW message . . . . . . . . . . . . . . 17 87 6. Client requesting previously allocated subnet information . . 18 88 6.1. Client Initial DHCPDISCOVER Message . . . . . . . . . . . 18 89 6.2. Server Initial DHCPOFFER Response . . . . . . . . . . . . 18 90 6.3. Client Additional DHCPDISCOVER Messages . . . . . . . . . 18 91 6.4. Server Additional DHCPOFFER Responses . . . . . . . . . . 19 92 7. DHCP Server Subnet Allocation method . . . . . . . . . . . . . 20 93 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 94 8.1. Example 1: . . . . . . . . . . . . . . . . . . . . . . . . 21 95 8.2. Example 2: . . . . . . . . . . . . . . . . . . . . . . . . 22 96 9. Differences from DHCPv6 Prefix Delegation . . . . . . . . . . 26 97 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 98 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 99 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 100 12.1. Normative References . . . . . . . . . . . . . . . . . . . 29 101 12.2. Informative References . . . . . . . . . . . . . . . . . . 29 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 104 1. Introduction 106 There is a need for a DHCP Client to be able to allocate a subnet 107 from a DHCP Server. Alternate methods of allocation, such as AAA are 108 not appropriate for various reasons and the most straight-forward way 109 to accomplish this allocation is via DHCP. A DHCP option to support 110 this may be utilized by a simple Dialin Aggregation box, or even to 111 implement a Hierarchical chain of DHCP Servers, each one in turn 112 leasing one or more subnets to the next DHCP Server down the chain. 114 This new DHCP option [RFC2132], the Subnet Allocation option is 115 specified in such a way as to use one DHCP Option number, while using 116 suboption numbers for each function. The Subnet-Request suboption 117 tells what types of subnets are needed and how many. The Subnet- 118 Information suboption gives the actual subnet number(s) and allows 119 for extra flags to convey additional information about each subnet. 120 The "Subnet-Name" suboption allows a method of passing additional 121 information about the requested subnet(s), such as department name, 122 user name, customer number, etc. The "Suggested-Lease-Time" 123 suboption provides a method for the DHCP Server to suggest a lease 124 time for addresses allocated from the offered subnet. The DHCP 125 Server has the option of not supplying all subnets requested or even 126 returning different sized subnets than were requested. Additionally, 127 usage statistics may be included in RENEW messages from the DHCP 128 Client back to the DHCP Server. 130 At the time when RFC 3942 came out, Cisco Systems had already 131 deployed products which made use of option number 220. In RFC 3942, 132 section 4, procedure 2, it is clearly stated, "Vendors that currently 133 use one or more of the reclassified options have 6 months following 134 this RFC's publication date to notify the DHC WG and IANA that they 135 are using particular options numbers and agree to document that usage 136 in an RFC." This procedure was immediately followed. It further 137 states, "Vendors have 18 months from this RFC's publication date to 138 start the documentation process by submitting an Internet-Draft." 139 This procedure was also followed. For the purposes of clarity, it 140 was thought important for the submitted draft to go through Working 141 Group review. This process took quite a long time, with the document 142 moving to "Last Call" multiple times. Since Cisco Systems already 143 had deployed products, and thus wanted to avoid anything except for 144 minor changes to the existing option definition, it was deemed best 145 for the document to be Informational instead of Standard Track. This 146 decision was made in cooperation with the Working Group and Work 147 Group Chair at the time. 149 2. Conventions 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC2119]. 155 This document also uses the following terms: 157 DHCP Client: DHCP Client or "Client" is an Internet host using DHCP 158 to obtain configuration parameters such as a network address. 160 DHCP Server: A DHCP Server or "Server" is an Internet host that 161 returns configuration parameters to DHCP Clients. 163 3. Subnet Allocation Option format 165 0 1 2 166 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 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 168 | Code | Len | Flags | Suboptions ... 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 171 Code = Subnet Allocation option code (1 octet): 220 172 Len = Length of the entire option including all sub-options 173 (1 octet) 174 Flags = Various flags: (None currently defined) 176 One or more sub-options may be specified as described below. 178 3.1. Subnet-Request Suboption format 180 0 1 2 3 181 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 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | 1 | Len | Flags :i:h| Prefix | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 Len = Length of the suboption (always 2 for this suboption) 187 (1 octet) 188 Flags = Flags field. (all unused bits must be zero) 190 'h' = Hierarchical flag 191 1 : Client will be allocating addresses from this subnet. 192 0 : Client will be relaying DHCP requests to the Server 193 from this subnet. 194 'i' = Information flag 195 1 : Client is seeking information about previously 196 allocated subnets. 197 0 : Client is seeking a new subnet allocation. 199 Prefix = Network prefix length requested 200 (0 means no suggested length is given) (1 octet) 202 The DHCP Server SHOULD NOT include the Subnet Request suboption in 203 any replies to the DHCP Client. Enough information will be present 204 in the Subnet-Information suboption, such that the Subnet Request 205 suboption is not needed in replies to the Client. 207 The DHCP Server SHOULD allocate a subnet with prefix length [RFC4632] 208 less than or equal to the "Prefix" field length specified in the 209 request. In other words, a subnet containing a number of addresses 210 at least the size indicated by the prefix length requested and 211 possibly more. The DHCP Server MAY allocate a subnet with a prefix 212 length greater than that specified in the request (subnet with a 213 number of addresses less than requested), but this is not encouraged. 215 A "Prefix" field size of 0 MAY be specified by the DHCP Client. In 216 this case, no suggested prefix length is given. 218 Multiple Subnet-Request suboptions in a DHCP packet indicate that 219 multiple subnets are being requested. Note that multiple occurrances 220 of this suboption MUST NOT be concatenated in the sense of [RFC3396]. 222 Each Subnet-Request suboption MUST result in no more than one Subnet- 223 Information suboption in the DHCPOFFER message from the Server, and 224 may result in no Subnet-Information suboptions. 226 The Client MAY also include the Subnet-Information suboption in order 227 to request a particular subnet. In this case, the Client SHOULD only 228 include one Subnet-Request suboption, since it would otherwise be 229 unclear which Subnet-Information suboption refered to which Subnet- 230 Request suboption. Multiple subnet requests can be made by sending 231 multiple DHCPDISCOVER packets. 233 Setting the 'h' flag to 1 indicates the Client will be allocating 234 addresses from the allocated subnet(s) itself. This can be thought 235 of as a "Hierarchial DHCP" design in that control of allocation for 236 the subnet(s) will be passed to the Client. 238 Setting the 'h' flag to 0 indicates the Client wants the DHCP Server 239 to retain control over allocation of addresses from the subnet(s). 240 Any address allocation requests on the subnet will be relayed back to 241 the DHCP Server. 243 Setting the 'i' flag to 1 indicates the Client is NOT seeking 244 allocation of any subnets, but is simply seeking information from the 245 Server as to what subnet(s) have been allocated (or reserved) for 246 this Client. If the 'i' flag is set to 1, then the "Prefix" field 247 SHOULD be set to 0 and MUST be ignored by the Server. In this case, 248 the conversation between the Client and the Server will only progress 249 to the DHCPOFFER packet from the Server, giving the information, as 250 described in section 6 below. 252 3.2. Subnet-Information Suboption format 254 0 1 2 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 257 | 2 | Len | Flags :c:s| SP1, SP2, ... 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 260 Len = Length of the sub-option (min. length of 8) (1 octet) 261 Flags = Various flags which apply to ALL Subnet Prefix 262 Information fields specified in this suboption. 263 Unused flags must be zero. 265 'c' : Client flag (explained below) 266 1 : This information is in response to a client request 267 (or has been echoed back by the client, when asking 268 for the next previously allocated subnet from the 269 server) 270 0 : Otherwise 271 's' : Server flag (explained below) 272 1 : Server has additional subnet information for this 273 client 274 0 : Otherwise 276 SP1, SP2, ... Subnet Prefix information blocks as specified below 277 (variable sized) 279 The "Client flag" ('c') is set to 1 if this Subnet-Information 280 suboption is in response to a Client request for information from the 281 Server as to what subnet(s) have been allocated. This flag is used 282 in response to a Subnet-Request suboption with the 'i' flag set and 283 should be 0 in other Server responses. Note, the flag is echoed back 284 from the Client to the Server when requesting the "next previously 285 allocated subnet". Another way to think of the 'c' bit would be that 286 it indicates that the subnet information contained in this suboption 287 does not represent a new allocation by the Server or a new request 288 for allocation by the Client, but instead represents previously 289 allocated subnet information. 291 The "Server flag" ('s') is set to 1 if the Server has additional 292 subnet information for the Client. 294 The Subnet-Information suboption is used by the DHCP Server in order 295 to return information as to what subnets are offered (in the case of 296 a DHCPOFFER packet) or allocated (in the case of a DHCPACK packet). 297 As is indicated above, multiple subnets may be returned in one 298 Subnet-Information suboption. 300 The Subnet-Information suboption is also used by the DHCP Client in 301 order to request allocation of specific subnets in a DHCPREQUEST 302 packet. In this case, the "Network", "Prefix", and "Flags" fields 303 contained in the associated Subnet Prefix Information blocks MUST NOT 304 be changed from the information which was received in the DHCPOFFER 305 packet from the server. The Client MAY, however, use multiple 306 Subnet-Information suboptions in order to request subnets which were 307 originally specified by the Server inside one Subnet-Information 308 suboption. 310 3.2.1. Subnet Prefix Information block format 312 0 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Network | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Prefix | Flags |h|d| Stat-len | Optional stats... 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 Addr = IPv4 network number (4 octets) 321 Prefix = Prefix length (1 octet) 322 Flags = Flags field (Undefined bits must be zero) (1 octet) 324 'd' = Deprecate flag (explained below) 325 1 : Deprecation of this subnet is requested 326 0 : No deprecation is needed 328 'h' = Hierarchical flag (explained below) 329 1 : Client will be allocating addresses from this subnet 330 0 : Client will be relaying DHCP requests to the server 331 from this subnet. 333 Stat-len = Length of the optional statistics information field 334 (zero if no statistics are included) 336 The 'd' flag may only be returned by the Server to the Client (inside 337 a DHCPACK packet, in response to a DHCP RENEW). It's presence means 338 that the Client should prepare to give up the subnet. For example, 339 if the Client is assigning addresses from this subnet to other 340 clients, it should cease doing so immediately and should not renew 341 any leases when clients ask for renewal. As soon as all addresses in 342 the subnet are unallocated, the Client should send a DHCPRELEASE 343 message to the Server, including a Subnet Prefix Information 344 suboption for the subnet in order to release the subnet. The format 345 of this message is described farther below. 347 The 'h' flag tells the Client how the Server intends for the Client 348 to use the allocated subnet. It is interpreted in the same manner as 349 that in the Subnet-Request suboption. In response to a Subnet- 350 Request, the Server should normally specify the 'h' flag in the same 351 manner as it was in the Subnet-Request suboption from the Client. 352 The Server MAY, however, change the 'h' flag from that specified in 353 the Subnet-Request suboption if it has been configured to override 354 the Client's request. 356 If any usage statistics information is to be included, then the 357 "Stat-len" field specifies the number of bytes of statistics 358 information which is included. See below for more information. If 359 no statistics information is included, then this byte MUST be zero. 360 The "Stat-len" field SHOULD always be zero when this suboption is 361 sent by the DHCP Server. The usage statistics information is 362 intended for use only to report usage statistics from the Client to 363 the Server. 365 3.2.1.1. Subnet Usage Statistics 367 The Subnet-Information suboption may also include usage statistics 368 information. If this information is included, then the "Stat-len" 369 (Statistics length) field MUST be set to the number of bytes of 370 statistics information which is being included. The statistics 371 information MUST be in the following form and order: 373 0 1 374 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | High water | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Currently in use | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Unusable | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 "High water" refers the to "high water mark" of allocated addresses 384 within the subnet. I.e., the largest number of addresses which were 385 ever allocated at one time from the subnet. 387 "Currently in use" refers to the number of addresses currently 388 allocated in the subnet. 390 "Unusable" refers to the number of addresses which are currently 391 unusable for any reason (such as a client returning a DHCPDECLINE, or 392 finding the address already in use). 394 Additional statistics may be added to this option in the future. If 395 so, they MUST be appended to the end of the option. All statistics 396 fields MUST remain in the same order. Use the all ones value 397 (0xFFFF) in order to skip reporting a number for a particular field. 398 Fewer fields may be included than what is specified in any current 399 RFC, but all fields which are included MUST remain in order specifed 400 here. 402 3.3. Subnet-Name Suboption format 404 0 1 405 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 407 | 3 | Len | Name ... 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 410 Len = length of the sub-option (min. length of 1) (1 octet) 412 The Subnet-Name suboption may be used in order to pass a subnet name 413 to the server for use during allocation. This name may be used for 414 any purpose but is intended to tell the server something extra about 415 the needed subnet; for example, "sales department", "customer 1002", 416 "address pool FOO", or some such. The "name" should NOT be NULL 417 terminated since the "len" field already specifies the length of the 418 name. The "Name" in this suboption is simply a number of octets and 419 need not be ASCII text. 421 3.4. Suggested-Lease-Time Suboption format 423 0 1 2 3 424 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 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | 4 | Len (4) | t1 | t2 | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | t3 | t4 | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 Len = length of the sub-option (always 4 for this suboption) (1 432 octet) 434 The Suggested-Lease-Time suboption MAY be included by the Server in 435 order to suggest the lease time to be used by the Client when 436 allocating addresses from the subnet allocated. The four (4) octet 437 value of the lease time is in the same format as that of the "IP 438 Address Lease Time" option (option 51), as described in [RFC2132]. 440 If included, this suboption MUST appear only once. (Inclusion of 441 multiple such suboptions would result in ambiguity as to which 442 applied to which subnet.) If different suggested lease times are 443 needed, the Server SHOULD, instead, reply with only one offered 444 subnet and should set the "Server flag" in the Subnet-Information 445 suboption to indicate to the Client that it should send another 446 subnet request to gather the others. 448 The Client SHOULD use a lease time, when allocating addresses from 449 the subnet, which is the lesser of the remaining lease time of the 450 subnet itself and the Suggested-Lease-Time suboption. 452 4. Requesting allocation of a subnet 454 4.1. Client DHCPDISCOVER message 456 The DHCP Client creates a DHCPDISCOVER message including the Subnet 457 Allocation option, and its set of suboptions, to request allocation 458 of a subnet. The DHCP Client should include the Subnet-Request 459 suboption, specifying the prefix length of the subnet requested. The 460 'h' bit should be set to 1 if the Client intends to control 461 allocation of addresses within the subnet itself, or 0 if the Server 462 should retain control of addresses within the subnet. More than one 463 Subnet Allocation option may appear in a DHCPDISCOVER message, 464 however the client SHOULD limit the number of requests, noting that 465 the DHCP replies will need to include the Subnet-Information 466 suboption, which takes up more space than the Subnet-Request 467 suboption. 469 If more than one subnet is being requested, multiple Subnet-Request 470 suboptions MAY be included or multiple DHCPDISCOVER messages MAY be 471 sent instead. The prefix length field of each Subnet-Request 472 suboption MUST be either 0, or in the range of 1 to 30 inclusive. 474 The DHCP "IP address lease time" option (code 51) MAY be included in 475 the DHCPDISCOVER message to specify the lease time the Client is 476 requesting for the subnet. If not present, no suggested lease time 477 is given. 479 The DHCP "Client ID" option (code 61) MAY be included in the 480 DHCPDISCOVER message as it may be used by the Server in performing 481 the subnet allocation. 483 4.2. Server DHCPOFFER message 485 Upon receiving a DHCPDISCOVER containing the Subnet Allocation 486 option, the DHCP Server should respond with a DHCPOFFER message 487 including the Subnet-Information suboption in order to specify the 488 subnet(s) which it is willing to allocate to the Client in order to 489 fulfill the request(s). 491 The Server need not reserve the subnets which are being offered, but 492 SHOULD strive to not offer the same subnets to another DHCP Client 493 until a reasonable time period (implementation dependent) has passed. 494 (This is similar to normal DHCP address allocation.) 496 The Server MUST NOT include the Subnet-Request suboption in the 497 DHCPOFFER. The same information is already present in the Subnet 498 Information suboption(s) which SHOULD be included in the DHCPOFFER. 500 The Server SHOULD also include the IP address lease time option 501 (option 51) in the DHCPOFFER message. This gives the lease time for 502 all subnets given in all Subnet-Request suboptions contained in the 503 DHCPOFFER message. The Server MAY also include the Renewal and/or 504 Rebinding options in order to further control the "T1" and "T2" lease 505 timers of the client. There MUST be only one IP address lease time, 506 rebind, and/or renew option each in the DHCPOFFER message. 508 The Server MAY set the "Server flag" ('s') to 1 to indicate that it 509 would like to allocate one or more additional subnet(s) to the 510 Client. This indicates that the Client should send another 511 DHCPDISCOVER message specifying a zero prefix length field, P, in 512 order to request the additional subnet allocation(s) information. 513 This may be necessary if the subnets are to be allocated with 514 different lease times, for example. 516 The "Client flag" ('c') MUST be set to 0 to indicate this is a Server 517 response to a client request for a new subnet allocation and not a 518 response to a request for information about already allocated 519 subnets. 521 The Server SHOULD set the DHCP yiaddr value to all zeros (0.0.0.0) 522 and the Client MUST ignore fields having to do with address 523 assignment if the packet contains a Subnet Allocation option. In 524 other words, a DHCP packet exchange can not provide subnet allocation 525 and address assignment simultaneously. 527 4.3. Client DHCPREQUEST message 529 When sending a DHCPREQUEST, the Client MUST NOT modify any fields of 530 all Subnet-Information suboptions received from the Server. However, 531 the Client MAY choose not to include some Subnet-Information 532 suboptions when issuing the DHCPREQUEST. Subnet-Request suboptions 533 MUST NOT be included in the DHCPREQUEST message, only the Subnet- 534 Information suboption(s) should be included. 536 4.4. Server DHCPACK message 538 The DHCP Server, upon receipt of the Client's DHCPREQUEST message, 539 MAY refuse allocation of any subnets (for example, if they have been 540 allocated elsewhere in the meantime), however since the Server should 541 have set aside the subnets offered for a short period of time, and 542 since the Client should have requested the subnets within a short 543 period of time after receiving the offer(s) from the server(s), this 544 last minute rejection should be rare. The DHCP Server MUST NOT 545 change the network number(s) or prefix length(s), however it MAY 546 remove some Subnet-Information suboptions from the list. 548 The Server SHOULD include the IP address lease time option specifying 549 the lease period for all subnet(s) in the DHCPACK. All subnets 550 allocated in one DHCP message will have the same lease time and only 551 one IP address lease time option must appear in the DHCP message. 553 If the Server has internal information which states that the Client 554 should be allocated more subnets than were requested, the Server MAY 555 set the 's' bit in the last Subnet-Information suboption to indicate 556 that the Client needs to request more subnets (as described above). 558 The allocable unit is the tuple (network number, prefix length). 559 Multiple subnets may be allocated in one DHCPACK, however since there 560 can be only one Lease-time option, each subnet allocated is assigned 561 the same lease time. Each subnet lease tuple (network number, prefix 562 length) MAY be renewed or released individually. 564 5. Client renewal of subnet lease 566 5.1. Client RENEW DHCPREQUEST message 568 The Client MUST renew all subnets allocated with a lease time in much 569 the same manner as renewing an allocated IP address. Renewal timers 570 need not be set in exactly the same manner, however. If Renewal 571 and/or Rebinding options were included in the DHCPACK of the subnet 572 allocation, then these "T1" and "T2" timers should be used just as 573 they would be in the case of address allocation timers. 575 The DHCPREQUEST message MUST include a Subnet-Information suboption 576 for which the Client is seeking renewal of the lease. This Subnet- 577 Information suboption may optionally include subnet usage statistics, 578 as described above in the Subnet-Information suboption format section 579 (3.2). 581 The subnet network number field ("Network") and subnet prefix length 582 field ("Prefix") MUST agree with the values as they were originally 583 allocated to the Client by the Server. In any of the statistics 584 fields (High, Current, Unusable), a value of all ones (0xffff) SHOULD 585 be used if the Client has no information to report for a statistic. 587 5.2. Server RENEW DHCPREQUEST response 589 The Server MAY respond to a subnet RENEW with either a DHCPACK or 590 DHCPNAK response. If a DHCPNAK response is given the Client MUST 591 immediately stop using the subnet(s) specified and, if possible, 592 notify all Clients with addresses allocated from this subnet that 593 their addresses are no longer valid. The Client MAY, of course, send 594 a DHCPDISCOVER message containing the Subnet Allocation option and 595 the Subnet-Request suboption in order to acquire another subnet for 596 use. In general, the Server should ask the Client to deprecate 597 subnets by using the 'd' bit of the Subnet-Information suboption in a 598 DHCPACK message (see below). 600 If a DHCPACK response is given, the "Deprecate" ('d') bit of the 601 flags field in the Subnet-Information suboption may also be set. 602 This indicates the DHCP Client should "prepare to stop using this 603 subnet". If the Client is allocating IP addresses for other clients 604 from this subnet (e.g. via DHCP), the Client SHOULD immediately stop 605 allocating such addresses. Once all allocated addresses in the 606 subnet have been released, the Client SHOULD send a DHCPRELEASE 607 message, including the Subnet-Information suboption (with optional 608 usage statistics) in order to release the subnet(s) back to the 609 Server. 611 5.3. Client DHCPRELEASE message 613 The DHCP Client should send a DHCPRELEASE message in order to release 614 allocated subnet(s) back to the Server when it is finished using 615 them. This message MUST NOT include the Subnet-Request suboption, 616 but MUST include one or more Subnet-Information suboptions, and 617 optionally including usage statistics. 619 The Client MUST release the same subnet(s) of the same prefix length 620 ("Prefix"), as was originally allocated. The Client MAY release a 621 subset of the subnets which were allocated originally. In other 622 words, the allocable unit is the tuple (network number, prefix 623 length). Multiple subnets may be allocated in one DHCPACK, however 624 each subnet MAY be released individually. 626 5.4. Server DHCPFORCERENEW message 628 The DHCP Server may issue a DHCPFORCERENEW [RFC3203] message 629 containing the Subnet Allocation option and the Subnet-Information 630 suboption. Upon receiving this message, the DHCP Client MUST issue a 631 DHCPREQUEST message to the DHCP Server in order to renew the lease on 632 the subnet mentioned. No other subnets allocated to the Client are 633 effected. As is the case with all DHCP RENEW messages, the Client 634 may include subnet usage information in the Subnet-Information 635 suboption in order to report subnet usage statistics, or set the 636 "Stat-len" field to 0 if no statistics are to be reported. 638 If the Server responds to this DHCPREQUEST with a DHCPNAK message, 639 then the Client MUST immediately stop using the subnet(s) and, if 640 possible, notify all Clients with addresses allocated from this/these 641 subnet(s) that their addresses are no longer valid. The Client MAY, 642 of course, send a DHCPDISCOVER message containing the Subnet 643 Allocation option and the Subnet-Request suboption in order to 644 acquire another subnet for use. 646 6. Client requesting previously allocated subnet information 648 A DHCP Client may request from the DHCP Server a list of what subnets 649 are currently allocated to the Client. This may be used to recover 650 from a restart if the Client does not have local storage in order to 651 retain the information itself. (For example of this, see the section 652 8.2 below.) 654 6.1. Client Initial DHCPDISCOVER Message 656 The DHCP Client DHCPDISCOVER message, when used to discover already 657 allocated subnet information, should contain a Subnet-Request 658 suboption with the "Prefix" field set to 0 and with the 'i' flag set 659 to 1 to indicate that the Client is seeking already allocated subnet 660 information from the Server. No Subnet-Information suboptions should 661 be included in this message. Note, no Subnet-Information suboption 662 is included in this message, since the client would not know of any 663 subnet to request at this point. 665 This DHCPDISCOVER message MAY be unicast to a particular DHCP Server, 666 or broadcast in the normal fashion. 668 6.2. Server Initial DHCPOFFER Response 670 Any DHCP Server which has allocated subnets to the Client should 671 respond to the DHCPDISCOVER message with a DHCPOFFER message. The 672 DHCPOFFER message should contain one or more Subnet-Information 673 suboption(s) telling the prefix of the subnet(s) allocated to the 674 Client. 676 The Server SHOULD, internally, retain an ordered list of subnets 677 which are allocated to each Client. In response to an initial 678 DHCPDISCOVER message requesting allocated subnet information (i.e., 679 one with the 'i' flag set to 1, but not carrying a Subnet-Information 680 suboption), the server returns in the DHCPOFFER message the subnet(s) 681 information for the first subnet(s) from this list. If the end of 682 the list has been reached, then the 's' bit of the last Subnet- 683 Information suboption included in the message MUST be set to 0. If 684 there are more subnets in the list, the 's' bit MUST be set to 1 to 685 indicate to the Client that more information is available. Since 686 this information is in response to a client request for previously 687 allocated subnet information, the 'c' bit MUST be set to 1. 689 6.3. Client Additional DHCPDISCOVER Messages 691 The Client, upon receiving any Server DHCPOFFER messages containing 692 Subnet Information suboption information with the 'c' ("Client") bit 693 set, should gather the network number ("Network") and prefix length 694 ("Prefix") information from the message. 696 If the 's' bit is set in the last of the Subnet-Information 697 suboptions included in the message, then the client SHOULD construct 698 a new DHCPDISCOVER message containing the Subnet Allocation option 699 and the last Subnet-Information suboption from the Server's message. 700 This message SHOULD then be sent back to the same DHCP Server 701 originating the DHCPOFFER message. The 'c' and 's' bits MUST retain 702 the same settings they had from the Server's DHCPOFFER message and 703 the network number ("Network") and prefix length ("Prefix") fields 704 MUST be unaltered as well. 706 If the 's' bit in all of the Subnet-Information suboptions from the 707 Server was 0, then it indicates the Server has no more information 708 about subnets allocated to the Client. 710 6.4. Server Additional DHCPOFFER Responses 712 The Server, upon receiving from a Client an additional DHCPDISCOVER 713 message for allocated subnet information retrieval, with the 'i' flag 714 set to 1 and containing one or more Subnet Information suboptions 715 with the 'c' and the 's' bits set, MUST use the network number 716 ("Network") and prefix length ("Prefix") fields contained in the last 717 such Subnet Information suboption in order to locate the position in 718 the internal table of allocated subnets for this Client, and then 719 return an DHCPOFFER message containing a Subnet-Information suboption 720 giving information about the next set of subnets allocated to this 721 Client. If this finishes the list in the table for this Client, then 722 the 's' bit MUST be set to 0 to indicate there is no more 723 information. Any Subnet Information suboptions encountered without 724 both the 'c' and 's' bits set should be ignored by the Server. 726 7. DHCP Server Subnet Allocation method 728 The actual method of allocating subnets on the DHCP Server, as well 729 as the configuration of what networks may be subnetted and how, is 730 left up to the implementation. 732 8. Examples 734 Only the Subnet Allocation option and accompanying suboptions are 735 displayed in these examples. All other fields in the DHCP messages 736 are described in [RFC2131]. 738 8.1. Example 1: 740 A DHCP Client requesting a subnet with prefix length 24 from which 741 the Client will allocate addresses to other clients. The Server 742 responds with an allocation of exactly the size requested: 744 The Client sends a DHCPDISCOVER message including a Subnet Allocation 745 option with the Subnet-Request suboption: 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | 220 | 5 | 0 | 1 | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | 2 | 0 |0|0| 24 | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 The Server responds with a DHCPOFFER message including a Subnet 754 Allocation option with a Subnet-Information suboption, offering the 755 subnet 10.0.1.0/24. 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | 220 | 11 | 0 | 2 | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | 8 | 0 |0|0| 10 | 0 | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | 1 | 0 | 24 | |0|0| 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | 0 | 765 +-+-+-+-+-+-+-+-+ 767 The Client sends a DHCPREQUEST including a Subnet Allocation option 768 with a Subnet-Information suboption: 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | 220 | 11 | 0 | 2 | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | 8 | 0 |0|0| 10 | 0 | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | 1 | 0 | 24 | |0|0| 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | 0 | 778 +-+-+-+-+-+-+-+-+ 779 The Server responds with a DHCPACK message including a Subnet 780 Allocation option with a Subnet-Information suboption: 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | 220 | 11 | 0 | 2 | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | 8 | 0 |0|0| 10 | 0 | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | 1 | 0 | 24 | |0|0| 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | 0 | 790 +-+-+-+-+-+-+-+-+ 792 Later the Client sends a DHCPRELEASE message including a Subnet 793 Allocation option with a Subnet-Information suboption: 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | 220 | 11 | 0 | 2 | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | 8 | 0 |0|0| 10 | 0 | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | 1 | 0 | 24 | |0|0| 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | 0 | 803 +-+-+-+-+-+-+-+-+ 805 8.2. Example 2: 807 A DHCP Client requesting two subnets, each with prefix length 24: 809 The Client sends a DHCPDISCOVER message including a Subnet Allocation 810 option with a Subnet-Request suboption: 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | 220 | 9 | 0 | 1 | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | 2 | 0 |0|0| 24 | 1 | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | 2 | 0 |0|0| 24 | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 The Server responds with a DHCPOFFER message including a Subnet 821 Allocation option with a Subnet-Information suboption: 823 The DHCPOFFER specifies 1 subnet of size 24 and 1 subnet of size 28. 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | 220 | 18 | 0 | 2 | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | 15 | |0|0| 10 | 0 | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | 2 | 0 | 24 | |0|0| 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | 0 | 10 | 0 | 3 | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | 0 | 28 | |0|0| 0 | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 The Client sends a DHCPREQUEST message including a Subnet Allocation 838 option with a Subnet-Information suboption: 840 The Client decides that the subnet of size 28 is not sufficient so it 841 doesn't include that subnet into the DHCPREQUEST message. 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | 220 | 11 | 0 | 2 | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | 8 | |0|0| 10 | 0 | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | 2 | 0 | 24 | |0|0| 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | 0 | 851 +-+-+-+-+-+-+-+-+ 853 The Server responds with a DHCPACK message including a Subnet 854 Allocation option with a Subnet-Information suboption: 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | 220 | 11 | 0 | 2 | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | 8 | |0|0| 10 | 0 | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | 2 | 0 | 24 | |0|0| 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | 0 | 864 +-+-+-+-+-+-+-+-+ 866 Later the Client sends a DHCPREQUEST message in order to renew the 867 lease on the one subnet and includes subnet usage information. It 868 reports that a maximum of 10 addresses were allocated from the subnet 869 since the last report, 7 addresses are currently allocated, and 2 870 addresses were found to be unusable. 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | 220 | 17 | 0 | 2 | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | 14 | |0|0| 10 | 0 | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | 2 | 0 | 24 | |0|0| 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | 6 | 0 | 10 | 0 | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | 7 | 0 | 2 | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 The Server responds with a DHCPACK message, however it signals to the 885 Client that the subnet should be deprecated. 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | 220 | 11 | 0 | 2 | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | 8 | |0|0| 10 | 0 | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | 2 | 0 | 24 | |0|1| 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | 0 | 895 +-+-+-+-+-+-+-+-+ 897 The Client reloads at this point and upon completion of the reload 898 sends a DHCPDISCOVER asking for information about all subnets which 899 were allocated to it. 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | 220 | 5 | 0 | 1 | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | 2 | |1|0| 0 | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 The Server responds with a DHCPOFFER, giving the subnet information 908 of the one subnet which is allocated to the Client. Also the Server 909 specifies that the one allocated subnet should be immediately 910 deprecated. Note that the 's' ("Server") bit is 0 thus indicating 911 that there is no more information available for this Client. 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | 220 | 11 | 0 | 2 | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | 8 | |1|0| 10 | 0 | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | 2 | 0 | 24 | |0|1| 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | 0 | 921 +-+-+-+-+-+-+-+-+ 923 The Client responds with a DHCPRELEASE message after having 924 deprecated the subnet: 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | 220 | 11 | 0 | SIS | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | 8 | |0|0| 10 | 0 | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 | 2 | 0 | 24 | |0|0| 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 | 0 | 934 +-+-+-+-+-+-+-+-+ 936 9. Differences from DHCPv6 Prefix Delegation 938 The following differences may be noticed between Subnet Allocation as 939 described in this document and DHCPv6 Prefix Delegation as described 940 in [RFC3633]: 942 o This option does not use anything like an "IA_PD" as is used in 943 DHCPv6. 945 o If the Server can not allocate a subnet, it remains silent, 946 instead of returning a special response saying nothing is 947 available. 949 o DHCPv6 Prefix Delegation has no mechanism for returning subnet/ 950 prefix usage statistics. 952 o DHCPv6 has no equivalent to the "subnet deprecation" flag as 953 described here. 955 o DHCPv6 Prefix Delegation makes no mention of what Client actions 956 should result from receiving a DHCPNAK during a RENEW of a 957 delegation. 959 o DHCPv6 has no equivalent of the subnet allocation "Network name" 960 suboption, which may be used by the Server for various purposes, 961 such as to specify a pool to use when allocating a subnet. 963 o DHCPv6 Prefix Delegation corresponds to "Hierarchical Subnet 964 Allocation" (setting the 'h' flag in the Prefix Information 965 suboption). There is no V6 equivalent of clearing the 'h' flag, 966 in which the Server retains authority over allocation of addresses 967 from the subnet. 969 o DHCPv6 Prefix Delegation has nothing to correspond to the 970 Suggested-Lease-Time suboption. 972 10. Security Considerations 974 Potential exposures to attack are discussed in section 7 of the DHCP 975 protocol specification [RFC2131]. The Subnet Allocation option can 976 be used to hoard all allocable subnets on a network. 978 Implementations should consider using the DHCP Authentication option 979 [RFC3118] in order to provide a higher level of security if it is 980 deemed necessary in their environment. Potential exposures to attack 981 are discussed in section 7 of the DHCP protocol specification in 982 [RFC2131]. 984 11. IANA Considerations 986 IANA is requested to assign DHCP option number 220 for this option, 987 in accordance with [RFC3942]. 989 No assignment of values for the suboption codes need be made at this 990 time. New values may only be defined by IETF Consensus, as described 991 in [RFC5226]. Basically, this means that they are defined by RFCs 992 approved by the IESG. 994 12. References 996 12.1. Normative References 998 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 999 Requirement Levels", BCP 14, RFC 2119, March 1997. 1001 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1002 RFC 2131, March 1997. 1004 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1005 Extensions", RFC 2132, March 1997. 1007 [RFC3942] Volz, B., "Reclassifying Dynamic Host Configuration 1008 Protocol version 4 (DHCPv4) Options", RFC 3942, 1009 November 2004. 1011 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1012 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1013 May 2008. 1015 12.2. Informative References 1017 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 1018 Messages", RFC 3118, June 2001. 1020 [RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP 1021 reconfigure extension", RFC 3203, December 2001. 1023 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 1024 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 1025 November 2002. 1027 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1028 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1029 December 2003. 1031 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 1032 (CIDR): The Internet Address Assignment and Aggregation 1033 Plan", BCP 122, RFC 4632, August 2006. 1035 Authors' Addresses 1037 Richard A. Johnson 1038 Cisco Systems, Inc. 1039 170 W. Tasman Dr. 1040 San Jose, CA 95134 1041 US 1043 Phone: +1 408 526 4000 1044 Email: raj@cisco.com 1046 Jay Kumarasamy 1047 Cisco Systems, Inc. 1048 170 W. Tasman Dr. 1049 San Jose, CA 95134 1050 US 1052 Phone: +1 408 526 4000 1053 Email: jayk@cisco.com 1055 Kim Kinnear 1056 Cisco Systems, Inc. 1057 170 W. Tasman Dr. 1058 San Jose, CA 95134 1059 US 1061 Phone: +1 408 526 4000 1062 Email: kkinnear@cisco.com 1064 Mark Stapp 1065 Cisco Systems, Inc. 1066 170 W. Tasman Dr. 1067 San Jose, CA 95134 1068 US 1070 Phone: +1 408 526 4000 1071 Email: mjs@cisco.com