idnits 2.17.1 draft-ietf-dhc-subnet-alloc-06.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 1040. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1051. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1058. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1064. 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 ([4]), 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 (November 15, 2007) is 6008 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2434 (ref. '5') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3633 (ref. '9') (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: May 18, 2008 M. Stapp 6 Cisco Systems, Inc. 7 November 15, 2007 9 Subnet Allocation Option 10 draft-ietf-dhc-subnet-alloc-06.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 May 18, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document defines a new DHCP option which is passed between the 44 DHCP Client and the DHCP Server to request dynamic allocation of a 45 subnet, give specifications of subnet(s) allocated, and report usage 46 statistics. This memo documents the current usage of the option in 47 agreement with RFC-3942[4], which declares that any pre-existing 48 usages of option numbers in the range 128 - 223 should be documented 49 and the working group will try to officially assign those numbers to 50 those options. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3. Subnet Allocation Option format . . . . . . . . . . . . . . . 6 57 3.1. Subnet-Request Suboption format . . . . . . . . . . . . . 6 58 3.2. Subnet-Information Suboption format . . . . . . . . . . . 8 59 3.2.1. Subnet Prefix Information section format . . . . . . . 9 60 3.3. Subnet-Name Suboption format . . . . . . . . . . . . . . . 11 61 3.4. Suggested-Lease-Time Suboption format . . . . . . . . . . 11 62 4. Requesting allocation of a subnet . . . . . . . . . . . . . . 13 63 4.1. Client DHCPDISCOVER message . . . . . . . . . . . . . . . 13 64 4.2. Server DHCPOFFER message . . . . . . . . . . . . . . . . . 13 65 4.3. Client DHCPREQUEST message . . . . . . . . . . . . . . . . 14 66 4.4. Server DHCPACK message . . . . . . . . . . . . . . . . . . 14 67 5. Client renewal of subnet lease . . . . . . . . . . . . . . . . 16 68 5.1. Client RENEW DHCPREQUEST message . . . . . . . . . . . . . 16 69 5.2. Server RENEW DHCPREQUEST response . . . . . . . . . . . . 16 70 5.3. Client DHCPRELEASE message . . . . . . . . . . . . . . . . 17 71 5.4. Server DHCPFORCERENEW message . . . . . . . . . . . . . . 17 72 6. Client requesting subnet allocation information . . . . . . . 18 73 6.1. Client DHCPDISCOVER message . . . . . . . . . . . . . . . 18 74 6.2. Server DHCPOFFER response . . . . . . . . . . . . . . . . 18 75 6.3. Client additional DHCPDISCOVER messages . . . . . . . . . 18 76 6.4. Server additional DHCPOFFER messages . . . . . . . . . . . 19 77 7. DHCP Server Subnet Allocation method . . . . . . . . . . . . . 20 78 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 79 8.1. Example 1: . . . . . . . . . . . . . . . . . . . . . . . . 21 80 8.2. Example 2: . . . . . . . . . . . . . . . . . . . . . . . . 22 81 9. Differences with DHCPv6 Prefix Delegation . . . . . . . . . . 26 82 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 83 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 84 12. Intellectual Property Rights . . . . . . . . . . . . . . . . . 29 85 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 86 13.1. Normative References . . . . . . . . . . . . . . . . . . . 30 87 13.2. Informative References . . . . . . . . . . . . . . . . . . 30 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 89 Intellectual Property and Copyright Statements . . . . . . . . . . 32 91 1. Introduction 93 There is a need for a DHCP Client to be able to allocate a subnet 94 from a DHCP Server. Alternate methods of allocation, such as AAA are 95 not appropriate for various reasons and the most straight-forward way 96 to accomplish this allocation is via DHCP. A DHCP option to support 97 this may be utilized by a simple Dialin Aggregation box, or even to 98 implement a Hierarchical chain of DHCP Servers, each one in turn 99 leasing one or more subnets to the next DHCP Server down the chain. 101 This new DHCP option [3], the Subnet Allocation option is specified 102 in such a way as to use one DHCP Option number, while using suboption 103 numbers for each function. The Subnet-Request suboption tells what 104 types of subnets are needed and how many. The Subnet-Information 105 suboption gives the actual subnet number(s) and allows for extra 106 flags to convey additional information about each subnet. The 107 "Subnet-Name" suboption allows a method of passing additional 108 information about the requested subnet(s), such as department name, 109 user name, customer number, etc. The "Suggested-Lease-Time" 110 suboption provides a method for the DHCP Server to suggest a lease 111 time for addresses allocated from the offered subnet. The DHCP 112 Server has the option of not supplying all subnets requested or even 113 returning different sized subnets than were requested. Additionally, 114 usage statistics may be included in RENEW messages from the DHCP 115 Client back to the DHCP Server. 117 2. Conventions 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [1]. 123 This document also uses the following terms: 125 DHCP Client: DHCP Client or "Client" is an Internet host using DHCP 126 to obtain configuration parameters such as a network address. 128 DHCP Server: A DHCP Server or "Server" is an Internet host that 129 returns configuration parameters to DHCP Clients. 131 3. Subnet Allocation Option format 133 0 1 2 134 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 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Code | Len | Flags | Suboptions ... 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 Code = Subnet Allocation option code (1 octet) 220 141 Len = Length of the entire option including all sub-options and 142 excluding the "Code" and "Len" fields above (1 octet) 144 Flags = Various flags: (None currently defined) 146 One or more sub-options may be specified as described below. 148 3.1. Subnet-Request Suboption format 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | 1 | Len | Flags |i|h| Prefix | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 Len = Length of the suboption excluding the subcode and Len fields 157 (1 octet) 159 Flags = Flags field. (all unused bits MBZ) 161 'h' 163 '1' = Client will be allocating addresses from this subnet. 165 '0' = Client will be relaying DHCP requests to the Server from 166 this subnet. 168 'i' 170 '1' = Client is seeking information about previously allocated 171 subnets. 173 '0' = Client is seeking a new subnet allocation. 175 Prefix = Size of the subnet needed [6] (number of bits in subnet 176 prefix) (zero (0) means no suggested size is given) (1 octet) 178 The DHCP Server SHOULD NOT include the Subnet Request suboption in 179 any replies to the DHCP Client. Enough information will be present 180 in the Subnet-Information suboption, such that the Subnet Request 181 suboption is not needed in replies to the Client. 183 The DHCP Server SHOULD allocate a subnet with prefix size less than 184 or equal to the size P specified in the request. In other words, a 185 subnet at least the size requested and possibly bigger. The DHCP 186 Server MAY allocate a subnet with a prefix size greater than that 187 specified in the request (subnet of a size smaller than requested), 188 but this is not encouraged. 190 A size P of zero (0) MAY be specified by the DHCP Client. In this 191 case, no suggested size is given. 193 Multiple Subnet-Request suboptions in a DHCP packet indicate that 194 multiple subnets are being requested. 196 Each Subnet-Request suboption MUST result in no more than one (1) 197 Subnet-Information suboption in the DHCPOFFER message from the 198 Server, and may result in zero (0) Subnet-Information suboptions. 200 The Client MAY also include the Subnet-Information suboption in order 201 to request a particular subnet. In this case, the Client SHOULD only 202 include one (1) Subnet-Request suboption, since it would otherwise be 203 unclear which Subnet-Information suboption refered to which Subnet- 204 Request suboption. Multiple subnet requests can be made by sending 205 multiple DHCPDISCOVER packets. 207 Setting the "h" flag to "1" indicates the Client will be allocating 208 addresses from the allocated subnet(s) itself. This can be thought 209 of as a "Hierarchial DHCP" design in that control of allocation for 210 the subnet(s) will be passed to the Client. 212 Setting the "h" flag to "0" indicates the Client wants the DHCP 213 Server to retain control over allocation of addresses from the 214 subnet(s). Any address allocation requests on the subnet will be 215 relayed back to the DHCP Server. 217 Setting the "i" flag to "1" indicates the Client is NOT seeking 218 allocation of any subnets, but is simply seeking information from the 219 Server as to what subnet(s) have been allocated (or reserved) for 220 this Client. If the "i" flag is set to "1", then the "P" field 221 SHOULD be set to "0" and MUST be ignored by the Server. 223 3.2. Subnet-Information Suboption format 225 0 1 2 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | 2 | Len | Flags |c|s| SP1, SP2, ... 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Len = Length of the sub-option excluding the Subcode and Len fields 232 (1 octet) 234 Flags = Various flags which apply to ALL Subnet Prefix Information 235 fields specified in this suboption 237 'c' = Client flag (explained below) 239 's' = Server flag (explained below) 241 SP1,SP2 = Subnet Prefix information as specified below (variable 242 sized) 244 The "Client flag" ("c") is set to "1" if this Subnet-Information 245 suboption is in response to a Client request for information from the 246 Server as to what subnet(s) have been allocated. This flag is only 247 used in response to a Subnet-Request suboption with the "i" flag set 248 and should be zero (0) otherwise. 250 The "Server flag" ("s") is set to "1" if the Server has additional 251 subnet information for the Client. 253 The Subnet-Information suboption is used by the DHCP Server in order 254 to return information as to what subnets are offered (in the case of 255 a DHCPOFFER packet) or allocated (in the case of a DHCPACK packet). 256 As is indicated above, multiple subnets may be returned in one 257 Subnet-Information suboption. 259 The Subnet-Information suboption is also used by the DHCP Client in 260 order to request allocation of specific subnets in a DHCPREQUEST 261 packet. In this case, the Address, Prefix, and Flags fields MUST NOT 262 be changed from the information which was received in the DHCPOFFER 263 packet from the server. The Client MAY, however, use multiple 264 Subnet-Information suboptions in order to request subnets which were 265 originally specified by the Server inside one Subnet-Information 266 suboption. 268 3.2.1. Subnet Prefix Information section format 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Address | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Prefix | Flags |h|d| Stat-len | Optional stats... 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 Addr = IPv4 address (4 octets) 280 Prefix = Specifying number of prefix bits in the subnet (1 octet) 282 Flags = Flags field (Undefined bits must be zero) (1 octet) 284 'd' Flag 286 '1' = Deprecate this subnet. 288 'h' Flag 290 '1' = Client will be allocating addresses from this subnet. 292 '0' = Client will be relaying DHCP requests to the Server from 293 this subnet. 295 Stat-len = Length of the optional statistics information field 297 The "d" flag may only be returned by the Server to the Client (inside 298 a DHCPACK packet, in response to a DHCP RENEW). It's presence means 299 that the Client should prepare to give up the subnet. For example, 300 if the Client is assigning addresses from this subnet to other 301 clients, it should cease doing so immediately and should not renew 302 any leases when client's ask for renewal. As soon as all addresses 303 in the subnet are unallocated, the Client should send a DHCPRELEASE 304 message to the Server, including a Subnet Prefix Information 305 suboption for the subnet in order to release the subnet. The format 306 of this message is described farther below. 308 The "h" flag tells the Client how the Server intends for the Client 309 to use the allocated subnet. It is interpreted in the same manner as 310 that in the Subnet-Request suboption. In response to a Subnet- 311 Request, the Server should normally specify the "h" flag in the same 312 mannor was it was in the Subnet-Request suboption from the Client. 313 The Server MAY, however, change the "h" flag from that specified in 314 the Subnet-Request suboption if it has been configured to override 315 the Client's request. 317 If any usage statistics information is to be included, then the 318 "Stat-len" field specifies the number of bytes of statistics 319 information which is included. See below for more information. If 320 no statistics information is included, then this byte MUST be zero. 321 The "Stat-len" field SHOULD always be zero when this suboption is 322 sent by the DHCP Server. The usage statistics information is 323 intended for use only to report usage statistics from the Client to 324 the Server. 326 3.2.1.1. Subnet Usage Statistics 328 The Subnet-Information suboption may also include usage statistics 329 information. If this information is included, then the "Stat-len" 330 (Statistics length) field MUST be set to the number of bytes of 331 statistics information which is being included. The statistics 332 information MUST be in the following form and order: 334 0 1 335 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | High water | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Currently in use | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Unusable | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 "High water" refers the to "high water mark" of allocated addresses 345 within the subnet. I.e., the largest number of addresses which were 346 ever allocated at one time from the subnet. 348 "Currently in use" refers to the number of addresses currently 349 allocated in the subnet. 351 "Unusable" refers to the number of addresses which are currently 352 unusable for any reason (such as a client returning a DHCPDECLINE, or 353 finding the address already in use). 355 Additional statistics may be added to this option in the future. If 356 so, they MUST be appended to the end of the option. All statistics 357 fields MUST remain in the same order. Use the all ones value 358 (0xFFFF) in order to skip reporting a number for a particular field. 359 Fewer fields may be included than what is specified in any current 360 RFC, but all fields which are included MUST remain in order specifed 361 here. 363 3.3. Subnet-Name Suboption format 365 0 1 366 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | 3 | Len | Name ... 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Len = length of the sub-option excluding the Subcode and Len fields 372 (1 octet) 374 The Subnet-Name suboption may be used in order to pass a subnet name 375 to the server for use during allocation. This name may be used for 376 any purpose but is intended to tell the server something extra about 377 the needed subnet; for example, "sales department", "customer 1002", 378 "address pool FOO", or some such. The "name" should NOT be NULL 379 terminated since the "len" field already specifies the length of the 380 name. The "Name" in this suboption is simply a number of octets and 381 need not be ASCII text. 383 3.4. Suggested-Lease-Time Suboption format 385 0 1 2 3 386 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 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | 4 | Len (4) | t1 | t2 | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | t3 | t4 | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 Len = length of the sub-option excluding the Subcode and Len fields 394 (always 4 for this suboption) (1 octet) 396 The Suggested-Lease-Time suboption MAY be included by the Server in 397 order to suggest the lease time to be used by the Client when 398 allocating addresses from the subnet allocated. The four (4) octet 399 value of the lease time is in the same format as that of the "IP 400 Address Lease Time" option (option 51), as described in [3]. 402 If included, this suboption MUST appear only once. (Inclusion of 403 multiple such suboptions would result in ambiguity as to which 404 applied to which subnet.) If different suggested lease times are 405 needed, the Server SHOULD, instead, reply with only one offered 406 subnet and should set the "Server flag" in the Subnet-Information 407 suboption to indicate to the Client that it should send another 408 subnet request to gather the others. 410 The Client SHOULD use a lease time, when allocating addresses from 411 the subnet, which is the lesser of the remaining lease time of the 412 subnet itself and the Suggested-Lease-Time suboption. 414 4. Requesting allocation of a subnet 416 4.1. Client DHCPDISCOVER message 418 The DHCP Client creates a DHCPDISCOVER message including the Subnet 419 Allocation option, and its set of suboptions, to request allocation 420 of a subnet. The DHCP Client should include the Subnet-Request 421 suboption, specifying the prefix size of the subnet requested. The 422 "h" bit should be set to "1" if the Client intends to control 423 allocation of addresses within the subnet itself, or "0" if the 424 Server should retain control of addresses within the subnet. More 425 than one Subnet Allocation option may appear in a DHCPDISCOVER 426 message, however the client SHOULD limit the number of requests, 427 noting that the DHCP replies will need to include the Subnet- 428 Information suboption, which takes up more space than the Subnet- 429 Request suboption. 431 If more than one subnet is being requested, multiple Subnet-Request 432 suboptions MAY be included or multiple DHCPDISCOVER messages MAY be 433 sent instead. The prefix size field of each Subnet-Request suboption 434 MUST be either zero (0), or in the range of 1 to 30 inclusive. 436 The DHCP "IP address lease time" option (code 51) MAY be included in 437 the DHCPDISCOVER message to specify the lease time the Client is 438 requesting for the subnet. If not present, no suggested lease time 439 is given. 441 The DHCP "Client ID" option (code 61) MAY be included in the 442 DHCPDISCOVER message as it may be used by the Server in performing 443 the subnet allocation. 445 4.2. Server DHCPOFFER message 447 Upon receiving a DHCPDISCOVER containing the Subnet Allocation 448 option, the DHCP Server should respond with a DHCPOFFER message 449 including the Subnet-Information suboption in order to specify the 450 subnet(s) which it is willing to allocate to the Client in order to 451 fill the request(s). 453 The Server need not reserve the subnets which are being offered, but 454 SHOULD strive to not offer the same subnets to another DHCP Client 455 until a reasonable time period (implementation dependent) has passed. 456 (This is similar to normal DHCP address allocation.) 458 The Server MUST NOT include the Subnet-Request suboption in the 459 DHCPOFFER. The same information is already present in the Subnet 460 Information suboption(s) which SHOULD be included in the DHCPOFFER. 462 The Server SHOULD also include the IP address lease time option 463 (option 51) in the DHCPOFFER message. This gives the lease time for 464 all subnets given in all Subnet-Request suboptions contained in the 465 DHCPOFFER message. The Server MAY also include the Renewal and/or 466 Rebinding options in order to further control the "T1" and "T2" lease 467 timers of the client. There MUST be only one IP address lease time, 468 rebind, and/or renew option in the DHCPOFFER message. 470 The Server MAY set the "Server flag" ("s") to "1" to indicate that it 471 would like to allocate one or more additional subnet(s) to the 472 Client. This indicates that the Client should send another 473 DHCPDISCOVER message specifying a zero prefix size field, P, in order 474 to request the additional subnet allocation(s) information. This may 475 be necessary if the subnets are to be allocated with different lease 476 times, for example. 478 The "Client flag" ("c") MUST be set to zero (0) to indicate this is a 479 Server response to a client request for a new subnet allocation and 480 not a response to a request for information about already allocated 481 subnets. 483 The Server SHOULD set the DHCP yiaddr value to all zeros (0.0.0.0) 484 and the Client MUST ignore fields having to do with address 485 assignment if the packet contains a Subnet Allocation option. In 486 other words, a DHCP packet exchange can not provide subnet allocation 487 and address assignment simultaneously. 489 4.3. Client DHCPREQUEST message 491 When sending a DHCPREQUEST, the Client MUST NOT modify any fields of 492 all Subnet-Information suboptions received from the Server. However, 493 the Client MAY choose not to include some Subnet-Information 494 suboptions when issuing the DHCPREQUEST. Subnet-Request suboptions 495 MUST NOT be included in the DHCPREQUEST message, only the Subnet- 496 Information suboption(s) should be included. 498 4.4. Server DHCPACK message 500 The DHCP Server, upon receipt of the Client's DHCPREQUEST message, 501 MAY refuse allocation of any subnets (for example, if they have been 502 allocated elsewhere in the meantime), however since the Server should 503 have set aside the subnets offered for a short period of time, and 504 since the Client should have requested the subnets within a short 505 period of time after receiving the offer(s) from the server(s), this 506 last minute rejection should be rare. The DHCP Server MUST NOT 507 change the subnet address(es) or prefix size(s), however it MAY 508 remove some Subnet-Information suboptions from the list. 510 The Server SHOULD include the IP address lease time option specifying 511 the lease period for all subnet(s) in the DHCPACK. All subnets 512 allocated in one DHCP message will have the same lease time and only 513 one IP address lease time option must appear in the DHCP message. 515 If the Server has internal information which states that the Client 516 should be allocated more subnets than were requested, the Server MAY 517 set the "s" bit in the last Subnet-Information suboption to indicate 518 that the Client needs to request more subnets (as described above). 520 The allocable unit is the tuple (subnet-address, prefix-size). 521 Multiple subnets may be allocated in one DHCPACK, however since there 522 can be only one Lease-time option, each subnet allocated is assigned 523 the same lease time. Each subnet lease tuple (subnet-address, 524 prefix-size) MAY be renewed or released individually. 526 5. Client renewal of subnet lease 528 5.1. Client RENEW DHCPREQUEST message 530 The Client MUST renew all subnets allocated with a lease time in much 531 the same manner as renewing an allocated IP address. Renewal timers 532 need not be set in exactly the same manner, however. If Renewal 533 and/or Rebinding options were included in the DHCPACK of the subnet 534 allocation, then these "T1" and "T2" timers should be used just as 535 they would be in the case of address allocation timers. 537 The DHCPREQUEST message MUST include a Subnet-Information suboption 538 for which the Client is seeking renewal of the lease. This Subnet- 539 Information suboption may optionally include subnet usage statistics, 540 as described above w.r.t. the Subnet-Information suboption format. 542 The subnet IP address field (Address) and subnet prefix field 543 (Prefix) MUST agree with the values as they were originally allocated 544 to the Client by the Server. In any of the statistics fields (High, 545 Current, Ususable), a value of all ones (0xffff) SHOULD be used if 546 the Client has no information to report for a statistic. 548 5.2. Server RENEW DHCPREQUEST response 550 The Server MAY respond to a subnet RENEW with either a DHCPACK or 551 DHCPNAK response. If a DHCPNAK response is given the Client MUST 552 immediately stop using the subnet(s) specified and, if possible, 553 notify all Clients with addresses allocated from this subnet that 554 their addresses are no longer valid. The Client MAY, of course, send 555 a DHCPDISCOVER message containing the Subnet Allocation option and 556 the Subnet-Request suboption in order to acquire another subnet for 557 use. In general, the Server should ask the Client to deprecate 558 subnets by using the "d" bit of the Subnet-Information suboption in a 559 DHCPACK message (see below). 561 If a DHCPACK response is given, the "Deprecate" ("d") bit of the 562 flags field in the Subnet-Information suboption may also be set. 563 This indicates the DHCP Client should "prepare to stop using this 564 subnet". If the Client is allocating IP addresses for other clients 565 from this subnet (e.g. via DHCP), the Client SHOULD immediately stop 566 allocating such addresses. Once all allocated addresses in the 567 subnet have been released, the Client SHOULD send a DHCPRELEASE 568 message, including the Subnet-Information suboption (with optional 569 usage statistics) in order to release the subnet(s) back to the 570 Server. 572 5.3. Client DHCPRELEASE message 574 The DHCP Client should send a DHCPRELEASE message in order to release 575 allocated subnet(s) back to the Server when it is finished using 576 them. This message MUST NOT include the Subnet-Request suboption, 577 but MUST include one or more Subnet-Information suboptions, and 578 optionally including usage statistics. 580 The Client MUST release the same subnet(s) of the same prefix size 581 (Prefix), as was originally allocated. The Client MAY release a 582 subset of the subnets which were allocated originally. In other 583 words, the allocable unit is the tuple (subnet address, prefix size). 584 Multiple subnets may be allocated in one DHCPACK, however each subnet 585 MAY be released individually. 587 5.4. Server DHCPFORCERENEW message 589 The DHCP Server may issue a DHCPFORCERENEW [8] message containing the 590 Subnet Allocation option and the Subnet-Information suboption. This 591 message effectively immediately times out the Client's lease(s) for 592 the allocated subnet(s). Upon receiving this message, the DHCP 593 Client MUST issue a DHCPREQUEST message to the DHCP Server in order 594 to renew the lease on the subnet mentioned. No other subnets 595 allocated to the Client are effected. As is the case with all DHCP 596 RENEW messages, the Client may include subnet usage information in 597 the Subnet-Information suboption in order to report subnet usage 598 statistics, or set the "Stat-len" field to zero (0) if no statistics 599 are to be reported. 601 If the Server responds to this DHCPREQUEST with a DHCPNAK message, 602 then the Client MUST immediately stop using the subnet(s) and, if 603 possible, notify all Clients with addresses allocated from this/these 604 subnet(s) that their addresses are no longer valid. The Client MAY, 605 of course, send a DHCPDISCOVER message containing the Subnet 606 Allocation option and the Subnet-Request suboption in order to 607 acquire another subnet for use. 609 6. Client requesting subnet allocation information 611 The DHCP Client may request from the DHCP Server a list of what 612 subnets are currently allocated to Client. This may be used to 613 recover from a restart if the Client does not have local storage in 614 order to retain the information itself. 616 6.1. Client DHCPDISCOVER message 618 The DHCP Client DHCPDISCOVER message, in order to discover already 619 allocated subnet information, should contain a Subnet-Request 620 suboption, with the "Prefix" field set to zero (0) and with the "i" 621 flag set to "1" to indicate that the Client is seeking already 622 allocated subnet information from the Server. No Subnet-Information 623 suboptions should be included in this message. 625 This DHCPDISCOVER message MAY be unicast to a particular DHCP Server, 626 or broadcast in the normal fashion. 628 6.2. Server DHCPOFFER response 630 Any DHCP Server which has allocated subnets to the Client should 631 respond to the DHCPDISCOVER message with a DHCPOFFER message The 632 DHCPOFFER message should contain one or more Subnet-Information 633 suboption(s) telling the subnet address(es) and prefix(es) of the 634 subnet(s) allocated to the Client. 636 The Server SHOULD, internally, retain an ordered list of subnets 637 which are allocated to each Client. The subnet(s) information 638 returned in the DHCPOFFER message are the first subnet(s) from this 639 list. If the end of the list has been reached, then the "s" bit of 640 the last Subnet-Information suboption included in the message hould 641 be set to "0". If there are more subnets in the list, the "s" bit 642 should be set to "1". to indicate to the Client that more information 643 is available. If this is the initial DHCPOFFER to the client, the 644 "c" flag should be set to "1". 646 6.3. Client additional DHCPDISCOVER messages 648 The Client, upon receiving any Server DHCPOFFER messages containing 649 Subnet Information suboption information with the "c" ("Client") bit 650 set, should gather the subnet address and prefix information from the 651 message. 653 If the "s" bit is set in the last of the Subnet-Information 654 suboptions included in the message, then the client SHOULD construct 655 a new DHCPDISCOVER message containing the Subnet Allocation option 656 and the last Subnet-Information suboption from the Server's message, 657 and send this message back to the same DHCP Server originating the 658 DHCPOFFER message. The "c" and "s" bits MUST retain the same 659 settings they had from the Server's DHCPOFFER message and the subnet 660 address ("A") and prefix size ("P") fields MUST be unaltered as well. 662 If the "s" bit in all of the Subnet-Information suboptions from the 663 Server was "0", then it indicates the Server has no more information 664 about subnets allocated to the Client. 666 6.4. Server additional DHCPOFFER messages 668 The Server, upon receiving a DHCPDISCOVER message from a Client 669 containing a Subnet Information suboption with the "c" and the "s" 670 bits set, MUST use the subnet address ("A") and prefix size ("P") 671 fields in order to locate the position in the internal table of 672 allocated subnets for this Client, and then return an DHCPOFFER 673 message containing a Subnet-Information suboption giving information 674 about the next set of subnets allocated to this Client. If this 675 finishes the list in the table for this Client, then the "s" bit MUST 676 be set to "0" to indicate there is no more information. 678 7. DHCP Server Subnet Allocation method 680 The actual method of allocating subnets on the DHCP Server, as well 681 as the configuration of what networks may be subnetted and how, is 682 left up to the implementation. 684 8. Examples 686 Only the Subnet Allocation option and accompanying suboptions are 687 displayed in these examples. All other fields in the DHCP messages 688 are described in [2]. 690 8.1. Example 1: 692 DHCP Client requesting a subnet with prefix size 24 from which the 693 Client will allocate addresses to other clients. The Server responds 694 with allocation of exactly the size requested: 696 Client sends DHCPDISCOVER including the Subnet Allocation option with 697 the Subnet-Request suboption: 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | 220 | 5 | 0 | 1 | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | 2 | 0 |0|0| 24 | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 Server responds with DHCPOFFER including Subnet Allocation option 706 with a Subnet-Information suboption, offering the subnet 10.0.1.0/24. 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | 220 | 11 | 0 | 2 | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | 8 | 0 |0|0| 10 | 0 | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | 1 | 0 | 24 | |0|0| 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | 0 | 716 +-+-+-+-+-+-+-+-+ 718 Client sends DHCPREQUEST including Subnet Allocation option with 719 Subnet-Information suboption: 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | 220 | 11 | 0 | 2 | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | 8 | 0 |0|0| 10 | 0 | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | 1 | 0 | 24 | |0|0| 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | 0 | 729 +-+-+-+-+-+-+-+-+ 731 Server responds with DHCPACK including Subnet Allocation option with 732 Subnet-Information suboption: 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | 220 | 11 | 0 | 2 | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | 8 | 0 |0|0| 10 | 0 | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | 1 | 0 | 24 | |0|0| 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | 0 | 742 +-+-+-+-+-+-+-+-+ 744 Later Client sends DHCPRELEASE including Subnet Allocation option 745 with Subnet-Information suboption: 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | 220 | 11 | 0 | 2 | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | 8 | 0 |0|0| 10 | 0 | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | 1 | 0 | 24 | |0|0| 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | 0 | 755 +-+-+-+-+-+-+-+-+ 757 8.2. Example 2: 759 DHCP Client requesting two subnets, each with prefix size 24: 761 Client sends DHCPDISCOVER including the Subnet Allocation option with 762 the Subnet-Request suboption: 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | 220 | 9 | 0 | 1 | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | 2 | 0 |0|0| 24 | 1 | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | 2 | 0 |0|0| 24 | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 Server responds with DHCPOFFER including Subnet Allocation option 773 with Subnet-Information suboption: 775 DHCPOFFER includes 1 subnet of size 24 and 1 subnet of size 28. 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | 220 | 18 | 0 | 2 | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | 15 | |0|0| 10 | 0 | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | 2 | 0 | 24 | |0|0| 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | 0 | 10 | 0 | 3 | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | 0 | 28 | |0|0| 0 | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 Client sends DHCPREQUEST including Subnet Allocation option with 790 Subnet-Information suboption: 792 Client decides that the subnet of size 28 is not sufficient so 793 doesn't include it into the DHCPREQUEST message. 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | 220 | 11 | 0 | 2 | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | 8 | |0|0| 10 | 0 | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | 2 | 0 | 24 | |0|0| 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | 0 | 803 +-+-+-+-+-+-+-+-+ 805 Server responds with DHCPACK including Subnet Allocation option with 806 Subnet-Information suboption: 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | 220 | 11 | 0 | 2 | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | 8 | |0|0| 10 | 0 | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | 2 | 0 | 24 | |0|0| 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | 0 | 816 +-+-+-+-+-+-+-+-+ 818 Later Client sends DHCPREQUEST message in order to renew the lease on 819 the one subnet, including subnet usage information. It reports that 820 a maximum of 10 addresses were allocated from the subnet since the 821 last report, 7 addresses are currently allocated, and 2 addresses 822 were found to be unusable. 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | 220 | 17 | 0 | 2 | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | 14 | |0|0| 10 | 0 | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | 2 | 0 | 24 | |0|0| 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | 6 | 0 | 10 | 0 | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | 7 | 0 | 2 | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 Server responds with DHCPACK, however signals Client that the subnet 837 should be deprecated. 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | 220 | 11 | 0 | 2 | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | 8 | |0|0| 10 | 0 | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | 2 | 0 | 24 | |0|1| 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | 0 | 847 +-+-+-+-+-+-+-+-+ 849 Client reloads at this point and upon completion of the reload sends 850 a DHCPDISCOVER asking for information about all subnets which were 851 allocated to it. 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | 220 | 5 | 0 | 1 | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | 2 | |1|0| 0 | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 Server responds with a DHCPOFFER, giving the subnet information of 860 the one subnet which is allocated to the Client. Also the Server 861 specifies that the one allocated subnet should be immediately 862 deprecated. Note that the "s" ("Server") bit is zero (0) thus 863 indicating that there is no more information available for this 864 Client. 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | 220 | 11 | 0 | 2 | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | 8 | |1|0| 10 | 0 | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | 2 | 0 | 24 | |0|1| 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | 0 | 874 +-+-+-+-+-+-+-+-+ 876 Client responds with DHCPRELEASE message after having deprecated the 877 subnet: 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | 220 | 11 | 0 | SIS | 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | 8 | |0|0| 10 | 0 | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | 2 | 0 | 24 | |0|0| 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | 0 | 887 +-+-+-+-+-+-+-+-+ 889 9. Differences with DHCPv6 Prefix Delegation 891 The following differences may be noticed between Subnet Allocation as 892 described in this document and DHCPv6 Prefix Delegation as described 893 in [9]: 895 o This option does not use anything like an "IA_PD" as is used in 896 DHCPv6. 898 o If the Server can not allocate a subnet, it remains silent, 899 instead of returning a special response saying nothing is 900 available. 902 o DHCPv6 Prefix Delegation has no mechanism for returning subnet/ 903 prefix usage statistics. 905 o DHCPv6 has no equivalent to the "subnet deprecation" flag as 906 described here. 908 o DHCPv6 Prefix Delegation makes no mention of what Client actions 909 should result from receiving a DHCPNAK during a RENEW of a 910 delegation. 912 o DHCPv6 has no equivalent of the subnet allocation "Network name" 913 suboption, which may be used by the Server for various purposes, 914 such as to specify a pool to use when allocating a subnet. 916 o DHCPv6 Prefix Delegation corresponds to "Hierarchical Subnet 917 Allocation" (setting the "h" flag in the Prefix Information 918 suboption). There is no V6 equivalent of clearing the "h" flag, 919 in which the Server retains authority over allocation of addresses 920 from the subnet. 922 o DHCPv6 Prefix Delegation has nothing to correspond to the 923 Suggested-Lease-Time suboption. 925 10. Security Considerations 927 Potential exposures to attack are discussed in section 7 of the DHCP 928 protocol specification [2]. The Subnet Allocation option can be used 929 to hoard all allocable subnets on a network. 931 Implementations should consider using the DHCP Authentication option 932 [7] in order to provide a higher level of security if it is deemed 933 necessary in their environment. Potential exposures to attack are 934 discussed in section 7 of the DHCP protocol specification in RFC 2131 935 [2]. 937 11. IANA Considerations 939 IANA is requested to assign DHCP option number 220 for this option, 940 in accordance with [4]. 942 No assignment of values for the suboption codes need be made at this 943 time. New values may only be defined by IETF Consensus, as described 944 in [5]. Basically, this means that they are defined by RFCs approved 945 by the IESG. 947 12. Intellectual Property Rights 949 The IETF has been notified of intellectual property rights claimed in 950 regard to some or all of the specification contained in this 951 document. For more information consult the online list of claimed 952 rights. 954 13. References 956 13.1. Normative References 958 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 959 Levels", BCP 14, RFC 2119, March 1997. 961 [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 962 March 1997. 964 [3] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 965 Extensions", RFC 2132, March 1997. 967 [4] Volz, B., "Reclassifying Dynamic Host Configuration Protocol 968 version 4 (DHCPv4) Options", RFC 3942, November 2004. 970 [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 971 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 973 13.2. Informative References 975 [6] Pummill, T. and B. Manning, "Variable Length Subnet Table For 976 IPv4", RFC 1878, December 1995. 978 [7] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 979 RFC 3118, June 2001. 981 [8] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP reconfigure 982 extension", RFC 3203, December 2001. 984 [9] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 985 Configuration Protocol (DHCP) version 6", RFC 3633, 986 December 2003. 988 Authors' Addresses 990 Richard A. Johnson 991 Cisco Systems, Inc. 992 170 W. Tasman Dr. 993 San Jose, CA 95134 994 US 996 Phone: +1 408 526 4000 997 Email: raj@cisco.com 999 Jay Kumarasamy 1000 Cisco Systems, Inc. 1001 170 W. Tasman Dr. 1002 San Jose, CA 95134 1003 US 1005 Phone: +1 408 526 4000 1006 Email: jayk@cisco.com 1008 Kim Kinnear 1009 Cisco Systems, Inc. 1010 170 W. Tasman Dr. 1011 San Jose, CA 95134 1012 US 1014 Phone: +1 408 526 4000 1015 Email: kkinnear@cisco.com 1017 Mark Stapp 1018 Cisco Systems, Inc. 1019 170 W. Tasman Dr. 1020 San Jose, CA 95134 1021 US 1023 Phone: +1 408 526 4000 1024 Email: mjs@cisco.com 1026 Full Copyright Statement 1028 Copyright (C) The IETF Trust (2007). 1030 This document is subject to the rights, licenses and restrictions 1031 contained in BCP 78, and except as set forth therein, the authors 1032 retain all their rights. 1034 This document and the information contained herein are provided on an 1035 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1036 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1037 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1038 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1039 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1040 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1042 Intellectual Property 1044 The IETF takes no position regarding the validity or scope of any 1045 Intellectual Property Rights or other rights that might be claimed to 1046 pertain to the implementation or use of the technology described in 1047 this document or the extent to which any license under such rights 1048 might or might not be available; nor does it represent that it has 1049 made any independent effort to identify any such rights. Information 1050 on the procedures with respect to rights in RFC documents can be 1051 found in BCP 78 and BCP 79. 1053 Copies of IPR disclosures made to the IETF Secretariat and any 1054 assurances of licenses to be made available, or the result of an 1055 attempt made to obtain a general license or permission for the use of 1056 such proprietary rights by implementers or users of this 1057 specification can be obtained from the IETF on-line IPR repository at 1058 http://www.ietf.org/ipr. 1060 The IETF invites any interested party to bring to its attention any 1061 copyrights, patents or patent applications, or other proprietary 1062 rights that may cover technology that may be required to implement 1063 this standard. Please address the information to the IETF at 1064 ietf-ipr@ietf.org. 1066 Acknowledgment 1068 Funding for the RFC Editor function is provided by the IETF 1069 Administrative Support Activity (IASA).