idnits 2.17.1 draft-ietf-dhc-subnet-alloc-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1039. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1050. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1057. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1063. 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 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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 8, 2008) is 5770 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 8 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. Jumarasamy 4 Intended status: Informational K. Kinnear 5 Expires: January 9, 2009 M. Stapp 6 Cisco Systems, Inc. 7 July 8, 2008 9 Subnet Allocation Option 10 draft-ietf-dhc-subnet-alloc-07.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 9, 2009. 37 Abstract 39 This document defines a new DHCP option which is passed between the 40 DHCP Client and the DHCP Server to request dynamic allocation of a 41 subnet, give specifications of subnet(s) allocated, and report usage 42 statistics. This memo documents the current usage of the option in 43 agreement with [RFC3942], which declares that any pre-existing usages 44 of option numbers in the range 128 - 223 should be documented and the 45 working group will try to officially assign those numbers to those 46 options. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 3. Subnet Allocation Option format . . . . . . . . . . . . . . . 6 53 3.1. Subnet-Request Suboption format . . . . . . . . . . . . . 6 54 3.2. Subnet-Information Suboption format . . . . . . . . . . . 8 55 3.2.1. Subnet Prefix Information section format . . . . . . . 9 56 3.3. Subnet-Name Suboption format . . . . . . . . . . . . . . . 11 57 3.4. Suggested-Lease-Time Suboption format . . . . . . . . . . 11 58 4. Requesting allocation of a subnet . . . . . . . . . . . . . . 13 59 4.1. Client DHCPDISCOVER message . . . . . . . . . . . . . . . 13 60 4.2. Server DHCPOFFER message . . . . . . . . . . . . . . . . . 13 61 4.3. Client DHCPREQUEST message . . . . . . . . . . . . . . . . 14 62 4.4. Server DHCPACK message . . . . . . . . . . . . . . . . . . 14 63 5. Client renewal of subnet lease . . . . . . . . . . . . . . . . 16 64 5.1. Client RENEW DHCPREQUEST message . . . . . . . . . . . . . 16 65 5.2. Server RENEW DHCPREQUEST response . . . . . . . . . . . . 16 66 5.3. Client DHCPRELEASE message . . . . . . . . . . . . . . . . 17 67 5.4. Server DHCPFORCERENEW message . . . . . . . . . . . . . . 17 68 6. Client requesting subnet allocation information . . . . . . . 18 69 6.1. Client DHCPDISCOVER message . . . . . . . . . . . . . . . 18 70 6.2. Server DHCPOFFER response . . . . . . . . . . . . . . . . 18 71 6.3. Client additional DHCPDISCOVER messages . . . . . . . . . 18 72 6.4. Server additional DHCPOFFER messages . . . . . . . . . . . 19 73 7. DHCP Server Subnet Allocation method . . . . . . . . . . . . . 20 74 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 75 8.1. Example 1: . . . . . . . . . . . . . . . . . . . . . . . . 21 76 8.2. Example 2: . . . . . . . . . . . . . . . . . . . . . . . . 22 77 9. Differences with DHCPv6 Prefix Delegation . . . . . . . . . . 26 78 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 79 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 80 12. Intellectual Property Rights . . . . . . . . . . . . . . . . . 29 81 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 82 13.1. Normative References . . . . . . . . . . . . . . . . . . . 30 83 13.2. Informative References . . . . . . . . . . . . . . . . . . 30 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 85 Intellectual Property and Copyright Statements . . . . . . . . . . 32 87 1. Introduction 89 There is a need for a DHCP Client to be able to allocate a subnet 90 from a DHCP Server. Alternate methods of allocation, such as AAA are 91 not appropriate for various reasons and the most straight-forward way 92 to accomplish this allocation is via DHCP. A DHCP option to support 93 this may be utilized by a simple Dialin Aggregation box, or even to 94 implement a Hierarchical chain of DHCP Servers, each one in turn 95 leasing one or more subnets to the next DHCP Server down the chain. 97 This new DHCP option [RFC2132], the Subnet Allocation option is 98 specified in such a way as to use one DHCP Option number, while using 99 suboption numbers for each function. The Subnet-Request suboption 100 tells what types of subnets are needed and how many. The Subnet- 101 Information suboption gives the actual subnet number(s) and allows 102 for extra flags to convey additional information about each subnet. 103 The "Subnet-Name" suboption allows a method of passing additional 104 information about the requested subnet(s), such as department name, 105 user name, customer number, etc. The "Suggested-Lease-Time" 106 suboption provides a method for the DHCP Server to suggest a lease 107 time for addresses allocated from the offered subnet. The DHCP 108 Server has the option of not supplying all subnets requested or even 109 returning different sized subnets than were requested. Additionally, 110 usage statistics may be included in RENEW messages from the DHCP 111 Client back to the DHCP Server. 113 2. Conventions 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 This document also uses the following terms: 121 DHCP Client: DHCP Client or "Client" is an Internet host using DHCP 122 to obtain configuration parameters such as a network address. 124 DHCP Server: A DHCP Server or "Server" is an Internet host that 125 returns configuration parameters to DHCP Clients. 127 3. Subnet Allocation Option format 129 0 1 2 130 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 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Code | Len | Flags | Suboptions ... 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 Code = Subnet Allocation option code (1 octet) 220 137 Len = Length of the entire option including all sub-options and 138 excluding the "Code" and "Len" fields above (1 octet) 140 Flags = Various flags: (None currently defined) 142 One or more sub-options may be specified as described below. 144 3.1. Subnet-Request Suboption format 146 0 1 2 3 147 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | 1 | Len | Flags |i|h| Prefix | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 Len = Length of the suboption excluding the subcode and Len fields 153 (1 octet) 155 Flags = Flags field. (all unused bits MBZ) 157 'h' 159 '1' = Client will be allocating addresses from this subnet. 161 '0' = Client will be relaying DHCP requests to the Server from 162 this subnet. 164 'i' 166 '1' = Client is seeking information about previously allocated 167 subnets. 169 '0' = Client is seeking a new subnet allocation. 171 Prefix = Size of the subnet needed [RFC1878] (number of bits in 172 subnet prefix) (zero (0) means no suggested size is given) (1 173 octet) 175 The DHCP Server SHOULD NOT include the Subnet Request suboption in 176 any replies to the DHCP Client. Enough information will be present 177 in the Subnet-Information suboption, such that the Subnet Request 178 suboption is not needed in replies to the Client. 180 The DHCP Server SHOULD allocate a subnet with prefix length less than 181 or equal to the size P specified in the request. In other words, a 182 subnet containing a number of addresses at least the size requested 183 and possibly more. The DHCP Server MAY allocate a subnet with a 184 prefix size greater than that specified in the request (subnet of a 185 size smaller than requested), but this is not encouraged. 187 A size P of zero (0) MAY be specified by the DHCP Client. In this 188 case, no suggested size is given. 190 Multiple Subnet-Request suboptions in a DHCP packet indicate that 191 multiple subnets are being requested. 193 Each Subnet-Request suboption MUST result in no more than one (1) 194 Subnet-Information suboption in the DHCPOFFER message from the 195 Server, and may result in zero (0) Subnet-Information suboptions. 197 The Client MAY also include the Subnet-Information suboption in order 198 to request a particular subnet. In this case, the Client SHOULD only 199 include one (1) Subnet-Request suboption, since it would otherwise be 200 unclear which Subnet-Information suboption refered to which Subnet- 201 Request suboption. Multiple subnet requests can be made by sending 202 multiple DHCPDISCOVER packets. 204 Setting the "h" flag to "1" indicates the Client will be allocating 205 addresses from the allocated subnet(s) itself. This can be thought 206 of as a "Hierarchial DHCP" design in that control of allocation for 207 the subnet(s) will be passed to the Client. 209 Setting the "h" flag to "0" indicates the Client wants the DHCP 210 Server to retain control over allocation of addresses from the 211 subnet(s). Any address allocation requests on the subnet will be 212 relayed back to the DHCP Server. 214 Setting the "i" flag to "1" indicates the Client is NOT seeking 215 allocation of any subnets, but is simply seeking information from the 216 Server as to what subnet(s) have been allocated (or reserved) for 217 this Client. If the "i" flag is set to "1", then the "P" field 218 SHOULD be set to "0" and MUST be ignored by the Server. 220 3.2. Subnet-Information Suboption format 222 0 1 2 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | 2 | Len | Flags |c|s| SP1, SP2, ... 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 Len = Length of the sub-option excluding the Subcode and Len fields 229 (1 octet) 231 Flags = Various flags which apply to ALL Subnet Prefix Information 232 fields specified in this suboption 234 'c' = Client flag (explained below) 236 's' = Server flag (explained below) 238 SP1,SP2 = Subnet Prefix information as specified below (variable 239 sized) 241 The "Client flag" ("c") is set to "1" if this Subnet-Information 242 suboption is in response to a Client request for information from the 243 Server as to what subnet(s) have been allocated. This flag is only 244 used in response to a Subnet-Request suboption with the "i" flag set 245 and should be zero (0) otherwise. 247 The "Server flag" ("s") is set to "1" if the Server has additional 248 subnet information for the Client. 250 The Subnet-Information suboption is used by the DHCP Server in order 251 to return information as to what subnets are offered (in the case of 252 a DHCPOFFER packet) or allocated (in the case of a DHCPACK packet). 253 As is indicated above, multiple subnets may be returned in one 254 Subnet-Information suboption. 256 The Subnet-Information suboption is also used by the DHCP Client in 257 order to request allocation of specific subnets in a DHCPREQUEST 258 packet. In this case, the Address, Prefix, and Flags fields MUST NOT 259 be changed from the information which was received in the DHCPOFFER 260 packet from the server. The Client MAY, however, use multiple 261 Subnet-Information suboptions in order to request subnets which were 262 originally specified by the Server inside one Subnet-Information 263 suboption. 265 3.2.1. Subnet Prefix Information section format 267 0 1 2 3 268 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Address | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Prefix | Flags |h|d| Stat-len | Optional stats... 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 Addr = IPv4 address (4 octets) 277 Prefix = Specifying number of prefix bits in the subnet (1 octet) 279 Flags = Flags field (Undefined bits must be zero) (1 octet) 281 'd' Flag 283 '1' = Deprecate this subnet. 285 'h' Flag 287 '1' = Client will be allocating addresses from this subnet. 289 '0' = Client will be relaying DHCP requests to the Server from 290 this subnet. 292 Stat-len = Length of the optional statistics information field 294 The "d" flag may only be returned by the Server to the Client (inside 295 a DHCPACK packet, in response to a DHCP RENEW). It's presence means 296 that the Client should prepare to give up the subnet. For example, 297 if the Client is assigning addresses from this subnet to other 298 clients, it should cease doing so immediately and should not renew 299 any leases when client's ask for renewal. As soon as all addresses 300 in the subnet are unallocated, the Client should send a DHCPRELEASE 301 message to the Server, including a Subnet Prefix Information 302 suboption for the subnet in order to release the subnet. The format 303 of this message is described farther below. 305 The "h" flag tells the Client how the Server intends for the Client 306 to use the allocated subnet. It is interpreted in the same manner as 307 that in the Subnet-Request suboption. In response to a Subnet- 308 Request, the Server should normally specify the "h" flag in the same 309 mannor was it was in the Subnet-Request suboption from the Client. 310 The Server MAY, however, change the "h" flag from that specified in 311 the Subnet-Request suboption if it has been configured to override 312 the Client's request. 314 If any usage statistics information is to be included, then the 315 "Stat-len" field specifies the number of bytes of statistics 316 information which is included. See below for more information. If 317 no statistics information is included, then this byte MUST be zero. 318 The "Stat-len" field SHOULD always be zero when this suboption is 319 sent by the DHCP Server. The usage statistics information is 320 intended for use only to report usage statistics from the Client to 321 the Server. 323 3.2.1.1. Subnet Usage Statistics 325 The Subnet-Information suboption may also include usage statistics 326 information. If this information is included, then the "Stat-len" 327 (Statistics length) field MUST be set to the number of bytes of 328 statistics information which is being included. The statistics 329 information MUST be in the following form and order: 331 0 1 332 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | High water | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Currently in use | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Unusable | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 "High water" refers the to "high water mark" of allocated addresses 342 within the subnet. I.e., the largest number of addresses which were 343 ever allocated at one time from the subnet. 345 "Currently in use" refers to the number of addresses currently 346 allocated in the subnet. 348 "Unusable" refers to the number of addresses which are currently 349 unusable for any reason (such as a client returning a DHCPDECLINE, or 350 finding the address already in use). 352 Additional statistics may be added to this option in the future. If 353 so, they MUST be appended to the end of the option. All statistics 354 fields MUST remain in the same order. Use the all ones value 355 (0xFFFF) in order to skip reporting a number for a particular field. 356 Fewer fields may be included than what is specified in any current 357 RFC, but all fields which are included MUST remain in order specifed 358 here. 360 3.3. Subnet-Name Suboption format 362 0 1 363 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | 3 | Len | Name ... 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 Len = length of the sub-option excluding the Subcode and Len fields 369 (1 octet) 371 The Subnet-Name suboption may be used in order to pass a subnet name 372 to the server for use during allocation. This name may be used for 373 any purpose but is intended to tell the server something extra about 374 the needed subnet; for example, "sales department", "customer 1002", 375 "address pool FOO", or some such. The "name" should NOT be NULL 376 terminated since the "len" field already specifies the length of the 377 name. The "Name" in this suboption is simply a number of octets and 378 need not be ASCII text. 380 3.4. Suggested-Lease-Time Suboption format 382 0 1 2 3 383 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | 4 | Len (4) | t1 | t2 | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | t3 | t4 | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 Len = length of the sub-option excluding the Subcode and Len fields 391 (always 4 for this suboption) (1 octet) 393 The Suggested-Lease-Time suboption MAY be included by the Server in 394 order to suggest the lease time to be used by the Client when 395 allocating addresses from the subnet allocated. The four (4) octet 396 value of the lease time is in the same format as that of the "IP 397 Address Lease Time" option (option 51), as described in [RFC2132]. 399 If included, this suboption MUST appear only once. (Inclusion of 400 multiple such suboptions would result in ambiguity as to which 401 applied to which subnet.) If different suggested lease times are 402 needed, the Server SHOULD, instead, reply with only one offered 403 subnet and should set the "Server flag" in the Subnet-Information 404 suboption to indicate to the Client that it should send another 405 subnet request to gather the others. 407 The Client SHOULD use a lease time, when allocating addresses from 408 the subnet, which is the lesser of the remaining lease time of the 409 subnet itself and the Suggested-Lease-Time suboption. 411 4. Requesting allocation of a subnet 413 4.1. Client DHCPDISCOVER message 415 The DHCP Client creates a DHCPDISCOVER message including the Subnet 416 Allocation option, and its set of suboptions, to request allocation 417 of a subnet. The DHCP Client should include the Subnet-Request 418 suboption, specifying the prefix size of the subnet requested. The 419 "h" bit should be set to "1" if the Client intends to control 420 allocation of addresses within the subnet itself, or "0" if the 421 Server should retain control of addresses within the subnet. More 422 than one Subnet Allocation option may appear in a DHCPDISCOVER 423 message, however the client SHOULD limit the number of requests, 424 noting that the DHCP replies will need to include the Subnet- 425 Information suboption, which takes up more space than the Subnet- 426 Request suboption. 428 If more than one subnet is being requested, multiple Subnet-Request 429 suboptions MAY be included or multiple DHCPDISCOVER messages MAY be 430 sent instead. The prefix size field of each Subnet-Request suboption 431 MUST be either zero (0), or in the range of 1 to 30 inclusive. 433 The DHCP "IP address lease time" option (code 51) MAY be included in 434 the DHCPDISCOVER message to specify the lease time the Client is 435 requesting for the subnet. If not present, no suggested lease time 436 is given. 438 The DHCP "Client ID" option (code 61) MAY be included in the 439 DHCPDISCOVER message as it may be used by the Server in performing 440 the subnet allocation. 442 4.2. Server DHCPOFFER message 444 Upon receiving a DHCPDISCOVER containing the Subnet Allocation 445 option, the DHCP Server should respond with a DHCPOFFER message 446 including the Subnet-Information suboption in order to specify the 447 subnet(s) which it is willing to allocate to the Client in order to 448 fill the request(s). 450 The Server need not reserve the subnets which are being offered, but 451 SHOULD strive to not offer the same subnets to another DHCP Client 452 until a reasonable time period (implementation dependent) has passed. 453 (This is similar to normal DHCP address allocation.) 455 The Server MUST NOT include the Subnet-Request suboption in the 456 DHCPOFFER. The same information is already present in the Subnet 457 Information suboption(s) which SHOULD be included in the DHCPOFFER. 459 The Server SHOULD also include the IP address lease time option 460 (option 51) in the DHCPOFFER message. This gives the lease time for 461 all subnets given in all Subnet-Request suboptions contained in the 462 DHCPOFFER message. The Server MAY also include the Renewal and/or 463 Rebinding options in order to further control the "T1" and "T2" lease 464 timers of the client. There MUST be only one IP address lease time, 465 rebind, and/or renew option in the DHCPOFFER message. 467 The Server MAY set the "Server flag" ("s") to "1" to indicate that it 468 would like to allocate one or more additional subnet(s) to the 469 Client. This indicates that the Client should send another 470 DHCPDISCOVER message specifying a zero prefix size field, P, in order 471 to request the additional subnet allocation(s) information. This may 472 be necessary if the subnets are to be allocated with different lease 473 times, for example. 475 The "Client flag" ("c") MUST be set to zero (0) to indicate this is a 476 Server response to a client request for a new subnet allocation and 477 not a response to a request for information about already allocated 478 subnets. 480 The Server SHOULD set the DHCP yiaddr value to all zeros (0.0.0.0) 481 and the Client MUST ignore fields having to do with address 482 assignment if the packet contains a Subnet Allocation option. In 483 other words, a DHCP packet exchange can not provide subnet allocation 484 and address assignment simultaneously. 486 4.3. Client DHCPREQUEST message 488 When sending a DHCPREQUEST, the Client MUST NOT modify any fields of 489 all Subnet-Information suboptions received from the Server. However, 490 the Client MAY choose not to include some Subnet-Information 491 suboptions when issuing the DHCPREQUEST. Subnet-Request suboptions 492 MUST NOT be included in the DHCPREQUEST message, only the Subnet- 493 Information suboption(s) should be included. 495 4.4. Server DHCPACK message 497 The DHCP Server, upon receipt of the Client's DHCPREQUEST message, 498 MAY refuse allocation of any subnets (for example, if they have been 499 allocated elsewhere in the meantime), however since the Server should 500 have set aside the subnets offered for a short period of time, and 501 since the Client should have requested the subnets within a short 502 period of time after receiving the offer(s) from the server(s), this 503 last minute rejection should be rare. The DHCP Server MUST NOT 504 change the subnet address(es) or prefix size(s), however it MAY 505 remove some Subnet-Information suboptions from the list. 507 The Server SHOULD include the IP address lease time option specifying 508 the lease period for all subnet(s) in the DHCPACK. All subnets 509 allocated in one DHCP message will have the same lease time and only 510 one IP address lease time option must appear in the DHCP message. 512 If the Server has internal information which states that the Client 513 should be allocated more subnets than were requested, the Server MAY 514 set the "s" bit in the last Subnet-Information suboption to indicate 515 that the Client needs to request more subnets (as described above). 517 The allocable unit is the tuple (subnet-address, prefix-size). 518 Multiple subnets may be allocated in one DHCPACK, however since there 519 can be only one Lease-time option, each subnet allocated is assigned 520 the same lease time. Each subnet lease tuple (subnet-address, 521 prefix-size) MAY be renewed or released individually. 523 5. Client renewal of subnet lease 525 5.1. Client RENEW DHCPREQUEST message 527 The Client MUST renew all subnets allocated with a lease time in much 528 the same manner as renewing an allocated IP address. Renewal timers 529 need not be set in exactly the same manner, however. If Renewal 530 and/or Rebinding options were included in the DHCPACK of the subnet 531 allocation, then these "T1" and "T2" timers should be used just as 532 they would be in the case of address allocation timers. 534 The DHCPREQUEST message MUST include a Subnet-Information suboption 535 for which the Client is seeking renewal of the lease. This Subnet- 536 Information suboption may optionally include subnet usage statistics, 537 as described above w.r.t. the Subnet-Information suboption format. 539 The subnet IP address field (Address) and subnet prefix field 540 (Prefix) MUST agree with the values as they were originally allocated 541 to the Client by the Server. In any of the statistics fields (High, 542 Current, Ususable), a value of all ones (0xffff) SHOULD be used if 543 the Client has no information to report for a statistic. 545 5.2. Server RENEW DHCPREQUEST response 547 The Server MAY respond to a subnet RENEW with either a DHCPACK or 548 DHCPNAK response. If a DHCPNAK response is given the Client MUST 549 immediately stop using the subnet(s) specified and, if possible, 550 notify all Clients with addresses allocated from this subnet that 551 their addresses are no longer valid. The Client MAY, of course, send 552 a DHCPDISCOVER message containing the Subnet Allocation option and 553 the Subnet-Request suboption in order to acquire another subnet for 554 use. In general, the Server should ask the Client to deprecate 555 subnets by using the "d" bit of the Subnet-Information suboption in a 556 DHCPACK message (see below). 558 If a DHCPACK response is given, the "Deprecate" ("d") bit of the 559 flags field in the Subnet-Information suboption may also be set. 560 This indicates the DHCP Client should "prepare to stop using this 561 subnet". If the Client is allocating IP addresses for other clients 562 from this subnet (e.g. via DHCP), the Client SHOULD immediately stop 563 allocating such addresses. Once all allocated addresses in the 564 subnet have been released, the Client SHOULD send a DHCPRELEASE 565 message, including the Subnet-Information suboption (with optional 566 usage statistics) in order to release the subnet(s) back to the 567 Server. 569 5.3. Client DHCPRELEASE message 571 The DHCP Client should send a DHCPRELEASE message in order to release 572 allocated subnet(s) back to the Server when it is finished using 573 them. This message MUST NOT include the Subnet-Request suboption, 574 but MUST include one or more Subnet-Information suboptions, and 575 optionally including usage statistics. 577 The Client MUST release the same subnet(s) of the same prefix size 578 (Prefix), as was originally allocated. The Client MAY release a 579 subset of the subnets which were allocated originally. In other 580 words, the allocable unit is the tuple (subnet address, prefix size). 581 Multiple subnets may be allocated in one DHCPACK, however each subnet 582 MAY be released individually. 584 5.4. Server DHCPFORCERENEW message 586 The DHCP Server may issue a DHCPFORCERENEW [RFC3203] message 587 containing the Subnet Allocation option and the Subnet-Information 588 suboption. This message effectively immediately times out the 589 Client's lease(s) for the allocated subnet(s). Upon receiving this 590 message, the DHCP Client MUST issue a DHCPREQUEST message to the DHCP 591 Server in order to renew the lease on the subnet mentioned. No other 592 subnets allocated to the Client are effected. As is the case with 593 all DHCP RENEW messages, the Client may include subnet usage 594 information in the Subnet-Information suboption in order to report 595 subnet usage statistics, or set the "Stat-len" field to zero (0) if 596 no statistics are to be reported. 598 If the Server responds to this DHCPREQUEST with a DHCPNAK message, 599 then the Client MUST immediately stop using the subnet(s) and, if 600 possible, notify all Clients with addresses allocated from this/these 601 subnet(s) that their addresses are no longer valid. The Client MAY, 602 of course, send a DHCPDISCOVER message containing the Subnet 603 Allocation option and the Subnet-Request suboption in order to 604 acquire another subnet for use. 606 6. Client requesting subnet allocation information 608 The DHCP Client may request from the DHCP Server a list of what 609 subnets are currently allocated to Client. This may be used to 610 recover from a restart if the Client does not have local storage in 611 order to retain the information itself. 613 6.1. Client DHCPDISCOVER message 615 The DHCP Client DHCPDISCOVER message, in order to discover already 616 allocated subnet information, should contain a Subnet-Request 617 suboption, with the "Prefix" field set to zero (0) and with the "i" 618 flag set to "1" to indicate that the Client is seeking already 619 allocated subnet information from the Server. No Subnet-Information 620 suboptions should be included in this message. 622 This DHCPDISCOVER message MAY be unicast to a particular DHCP Server, 623 or broadcast in the normal fashion. 625 6.2. Server DHCPOFFER response 627 Any DHCP Server which has allocated subnets to the Client should 628 respond to the DHCPDISCOVER message with a DHCPOFFER message The 629 DHCPOFFER message should contain one or more Subnet-Information 630 suboption(s) telling the subnet address(es) and prefix(es) of the 631 subnet(s) allocated to the Client. 633 The Server SHOULD, internally, retain an ordered list of subnets 634 which are allocated to each Client. The subnet(s) information 635 returned in the DHCPOFFER message are the first subnet(s) from this 636 list. If the end of the list has been reached, then the "s" bit of 637 the last Subnet-Information suboption included in the message hould 638 be set to "0". If there are more subnets in the list, the "s" bit 639 should be set to "1". to indicate to the Client that more information 640 is available. If this is the initial DHCPOFFER to the client, the 641 "c" flag should be set to "1". 643 6.3. Client additional DHCPDISCOVER messages 645 The Client, upon receiving any Server DHCPOFFER messages containing 646 Subnet Information suboption information with the "c" ("Client") bit 647 set, should gather the subnet address and prefix information from the 648 message. 650 If the "s" bit is set in the last of the Subnet-Information 651 suboptions included in the message, then the client SHOULD construct 652 a new DHCPDISCOVER message containing the Subnet Allocation option 653 and the last Subnet-Information suboption from the Server's message, 654 and send this message back to the same DHCP Server originating the 655 DHCPOFFER message. The "c" and "s" bits MUST retain the same 656 settings they had from the Server's DHCPOFFER message and the subnet 657 address ("A") and prefix size ("P") fields MUST be unaltered as well. 659 If the "s" bit in all of the Subnet-Information suboptions from the 660 Server was "0", then it indicates the Server has no more information 661 about subnets allocated to the Client. 663 6.4. Server additional DHCPOFFER messages 665 The Server, upon receiving a DHCPDISCOVER message from a Client 666 containing a Subnet Information suboption with the "c" and the "s" 667 bits set, MUST use the subnet address ("A") and prefix size ("P") 668 fields in order to locate the position in the internal table of 669 allocated subnets for this Client, and then return an DHCPOFFER 670 message containing a Subnet-Information suboption giving information 671 about the next set of subnets allocated to this Client. If this 672 finishes the list in the table for this Client, then the "s" bit MUST 673 be set to "0" to indicate there is no more information. 675 7. DHCP Server Subnet Allocation method 677 The actual method of allocating subnets on the DHCP Server, as well 678 as the configuration of what networks may be subnetted and how, is 679 left up to the implementation. 681 8. Examples 683 Only the Subnet Allocation option and accompanying suboptions are 684 displayed in these examples. All other fields in the DHCP messages 685 are described in [RFC2131]. 687 8.1. Example 1: 689 DHCP Client requesting a subnet with prefix size 24 from which the 690 Client will allocate addresses to other clients. The Server responds 691 with allocation of exactly the size requested: 693 Client sends DHCPDISCOVER including the Subnet Allocation option with 694 the Subnet-Request suboption: 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | 220 | 5 | 0 | 1 | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | 2 | 0 |0|0| 24 | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 Server responds with DHCPOFFER including Subnet Allocation option 703 with a Subnet-Information suboption, offering the subnet 10.0.1.0/24. 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | 220 | 11 | 0 | 2 | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | 8 | 0 |0|0| 10 | 0 | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | 1 | 0 | 24 | |0|0| 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | 0 | 713 +-+-+-+-+-+-+-+-+ 715 Client sends DHCPREQUEST including Subnet Allocation option with 716 Subnet-Information suboption: 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | 220 | 11 | 0 | 2 | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | 8 | 0 |0|0| 10 | 0 | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | 1 | 0 | 24 | |0|0| 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | 0 | 726 +-+-+-+-+-+-+-+-+ 728 Server responds with DHCPACK including Subnet Allocation option with 729 Subnet-Information suboption: 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | 220 | 11 | 0 | 2 | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | 8 | 0 |0|0| 10 | 0 | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | 1 | 0 | 24 | |0|0| 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | 0 | 739 +-+-+-+-+-+-+-+-+ 741 Later Client sends DHCPRELEASE including Subnet Allocation option 742 with Subnet-Information suboption: 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | 220 | 11 | 0 | 2 | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | 8 | 0 |0|0| 10 | 0 | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | 1 | 0 | 24 | |0|0| 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | 0 | 752 +-+-+-+-+-+-+-+-+ 754 8.2. Example 2: 756 DHCP Client requesting two subnets, each with prefix size 24: 758 Client sends DHCPDISCOVER including the Subnet Allocation option with 759 the Subnet-Request suboption: 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | 220 | 9 | 0 | 1 | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | 2 | 0 |0|0| 24 | 1 | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | 2 | 0 |0|0| 24 | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 Server responds with DHCPOFFER including Subnet Allocation option 770 with Subnet-Information suboption: 772 DHCPOFFER includes 1 subnet of size 24 and 1 subnet of size 28. 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | 220 | 18 | 0 | 2 | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | 15 | |0|0| 10 | 0 | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | 2 | 0 | 24 | |0|0| 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | 0 | 10 | 0 | 3 | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | 0 | 28 | |0|0| 0 | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 Client sends DHCPREQUEST including Subnet Allocation option with 787 Subnet-Information suboption: 789 Client decides that the subnet of size 28 is not sufficient so 790 doesn't include it into the DHCPREQUEST message. 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | 220 | 11 | 0 | 2 | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | 8 | |0|0| 10 | 0 | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | 2 | 0 | 24 | |0|0| 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | 0 | 800 +-+-+-+-+-+-+-+-+ 802 Server responds with DHCPACK including Subnet Allocation option with 803 Subnet-Information suboption: 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | 220 | 11 | 0 | 2 | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | 8 | |0|0| 10 | 0 | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | 2 | 0 | 24 | |0|0| 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | 0 | 813 +-+-+-+-+-+-+-+-+ 815 Later Client sends DHCPREQUEST message in order to renew the lease on 816 the one subnet, including subnet usage information. It reports that 817 a maximum of 10 addresses were allocated from the subnet since the 818 last report, 7 addresses are currently allocated, and 2 addresses 819 were found to be unusable. 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | 220 | 17 | 0 | 2 | 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 | 14 | |0|0| 10 | 0 | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | 2 | 0 | 24 | |0|0| 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | 6 | 0 | 10 | 0 | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | 7 | 0 | 2 | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 Server responds with DHCPACK, however signals Client that the subnet 834 should be deprecated. 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | 220 | 11 | 0 | 2 | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | 8 | |0|0| 10 | 0 | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | 2 | 0 | 24 | |0|1| 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | 0 | 844 +-+-+-+-+-+-+-+-+ 846 Client reloads at this point and upon completion of the reload sends 847 a DHCPDISCOVER asking for information about all subnets which were 848 allocated to it. 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | 220 | 5 | 0 | 1 | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | 2 | |1|0| 0 | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 Server responds with a DHCPOFFER, giving the subnet information of 857 the one subnet which is allocated to the Client. Also the Server 858 specifies that the one allocated subnet should be immediately 859 deprecated. Note that the "s" ("Server") bit is zero (0) thus 860 indicating that there is no more information available for this 861 Client. 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | 220 | 11 | 0 | 2 | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | 8 | |1|0| 10 | 0 | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | 2 | 0 | 24 | |0|1| 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | 0 | 871 +-+-+-+-+-+-+-+-+ 873 Client responds with DHCPRELEASE message after having deprecated the 874 subnet: 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | 220 | 11 | 0 | SIS | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | 8 | |0|0| 10 | 0 | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | 2 | 0 | 24 | |0|0| 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | 0 | 884 +-+-+-+-+-+-+-+-+ 886 9. Differences with DHCPv6 Prefix Delegation 888 The following differences may be noticed between Subnet Allocation as 889 described in this document and DHCPv6 Prefix Delegation as described 890 in [RFC3633]: 892 o This option does not use anything like an "IA_PD" as is used in 893 DHCPv6. 895 o If the Server can not allocate a subnet, it remains silent, 896 instead of returning a special response saying nothing is 897 available. 899 o DHCPv6 Prefix Delegation has no mechanism for returning subnet/ 900 prefix usage statistics. 902 o DHCPv6 has no equivalent to the "subnet deprecation" flag as 903 described here. 905 o DHCPv6 Prefix Delegation makes no mention of what Client actions 906 should result from receiving a DHCPNAK during a RENEW of a 907 delegation. 909 o DHCPv6 has no equivalent of the subnet allocation "Network name" 910 suboption, which may be used by the Server for various purposes, 911 such as to specify a pool to use when allocating a subnet. 913 o DHCPv6 Prefix Delegation corresponds to "Hierarchical Subnet 914 Allocation" (setting the "h" flag in the Prefix Information 915 suboption). There is no V6 equivalent of clearing the "h" flag, 916 in which the Server retains authority over allocation of addresses 917 from the subnet. 919 o DHCPv6 Prefix Delegation has nothing to correspond to the 920 Suggested-Lease-Time suboption. 922 10. Security Considerations 924 Potential exposures to attack are discussed in section 7 of the DHCP 925 protocol specification [RFC2131]. The Subnet Allocation option can 926 be used to hoard all allocable subnets on a network. 928 Implementations should consider using the DHCP Authentication option 929 [RFC3118] in order to provide a higher level of security if it is 930 deemed necessary in their environment. Potential exposures to attack 931 are discussed in section 7 of the DHCP protocol specification in 932 [RFC2131]. 934 11. IANA Considerations 936 IANA is requested to assign DHCP option number 220 for this option, 937 in accordance with [RFC3942]. 939 No assignment of values for the suboption codes need be made at this 940 time. New values may only be defined by IETF Consensus, as described 941 in [RFC2434]. Basically, this means that they are defined by RFCs 942 approved by the IESG. 944 12. Intellectual Property Rights 946 The IETF has been notified of intellectual property rights claimed in 947 regard to some or all of the specification contained in this 948 document. For more information consult the online list of claimed 949 rights. 951 13. References 953 13.1. Normative References 955 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 956 Requirement Levels", BCP 14, RFC 2119, March 1997. 958 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 959 RFC 2131, March 1997. 961 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 962 Extensions", RFC 2132, March 1997. 964 [RFC3942] Volz, B., "Reclassifying Dynamic Host Configuration 965 Protocol version 4 (DHCPv4) Options", RFC 3942, 966 November 2004. 968 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 969 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 970 October 1998. 972 13.2. Informative References 974 [RFC1878] Pummill, T. and B. Manning, "Variable Length Subnet Table 975 For IPv4", RFC 1878, December 1995. 977 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 978 Messages", RFC 3118, June 2001. 980 [RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP 981 reconfigure extension", RFC 3203, December 2001. 983 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 984 Host Configuration Protocol (DHCP) version 6", RFC 3633, 985 December 2003. 987 Authors' Addresses 989 Richard A. Johnson 990 Cisco Systems, Inc. 991 170 W. Tasman Dr. 992 San Jose, CA 95134 993 US 995 Phone: +1 408 526 4000 996 Email: raj@cisco.com 998 Jay Kumarasamy 999 Cisco Systems, Inc. 1000 170 W. Tasman Dr. 1001 San Jose, CA 95134 1002 US 1004 Phone: +1 408 526 4000 1005 Email: jayk@cisco.com 1007 Kim Kinnear 1008 Cisco Systems, Inc. 1009 170 W. Tasman Dr. 1010 San Jose, CA 95134 1011 US 1013 Phone: +1 408 526 4000 1014 Email: kkinnear@cisco.com 1016 Mark Stapp 1017 Cisco Systems, Inc. 1018 170 W. Tasman Dr. 1019 San Jose, CA 95134 1020 US 1022 Phone: +1 408 526 4000 1023 Email: mjs@cisco.com 1025 Full Copyright Statement 1027 Copyright (C) The IETF Trust (2008). 1029 This document is subject to the rights, licenses and restrictions 1030 contained in BCP 78, and except as set forth therein, the authors 1031 retain all their rights. 1033 This document and the information contained herein are provided on an 1034 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1035 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1036 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1037 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1038 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1039 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1041 Intellectual Property 1043 The IETF takes no position regarding the validity or scope of any 1044 Intellectual Property Rights or other rights that might be claimed to 1045 pertain to the implementation or use of the technology described in 1046 this document or the extent to which any license under such rights 1047 might or might not be available; nor does it represent that it has 1048 made any independent effort to identify any such rights. Information 1049 on the procedures with respect to rights in RFC documents can be 1050 found in BCP 78 and BCP 79. 1052 Copies of IPR disclosures made to the IETF Secretariat and any 1053 assurances of licenses to be made available, or the result of an 1054 attempt made to obtain a general license or permission for the use of 1055 such proprietary rights by implementers or users of this 1056 specification can be obtained from the IETF on-line IPR repository at 1057 http://www.ietf.org/ipr. 1059 The IETF invites any interested party to bring to its attention any 1060 copyrights, patents or patent applications, or other proprietary 1061 rights that may cover technology that may be required to implement 1062 this standard. Please address the information to the IETF at 1063 ietf-ipr@ietf.org.