idnits 2.17.1 draft-ietf-dhc-rapid-commit-opt-04.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 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 434. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 418. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 424. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 440), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 33 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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. (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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3315' is mentioned on line 79, but not defined ** Obsolete undefined reference: RFC 3315 (Obsoleted by RFC 8415) == Missing Reference: 'RFC2131' is mentioned on line 85, but not defined == Unused Reference: 'RFC 3315' is defined on line 361, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Park 3 Internet-Draft P. Kim 4 June 21, 2004 Samsung Electronics 5 B. Volz 6 Cisco Systems 8 Rapid Commit Option for DHCPv4 9 draft-ietf-dhc-rapid-commit-opt-04.txt 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance 16 with RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at http:// 29 www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 20, 2004. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 This document defines a new DHCPv4 option, modeled on the DHCPv6 43 Rapid Commit option, for obtaining IP address and configuration 44 information using a 2-message exchange rather than the usual 4- 45 message exchange, expediting client configuration. 47 Table of Contents 49 1. Introduction..................................................2 50 2. Requirements..................................................3 51 3. Client/Server Operations......................................3 52 3.1 Detailed Flow................................................4 53 3.2 Administrative Considerations................................7 54 4. Rapid Commit Option Format....................................8 55 5. IANA Considerations...........................................8 56 6. Security Considerations.......................................8 57 7. References....................................................9 58 7.1 Normative References.........................................9 59 7.2 Informative References.......................................9 60 8. Authors' Addresses...........................................10 61 9. Acknowledgements.............................................10 63 1. Introduction 65 In some environments, such as those in which high mobility occurs 66 and the network attachment point changes frequently, it is benefical 67 to rapidly configure clients. And, in these environments it is 68 possible to more quickly configure clients because the protections 69 offered by the normal (and longer) 4-message exchange may not be 70 needed. The 4-message exchange allows for redundancy (multiple DHCP 71 servers) without wasting addresses, as addresses are only 72 provisionally assigned to a client until the client chooses and 73 requests one of the provisionally assigned addresses. The 2-message 74 exchange may therefore be used when only one server is present or 75 when addresses are plentiful and having multiple servers commit 76 addresses for a client is not a problem. 78 This document defines a new Rapid Commit option for DHCPv4, modeled 79 on the DHCPv6 Rapid Commit option [RFC3315], which can be used to 80 initiate a 2-message exchange to expedite client configuration in 81 some environments. A client advertises its support of this option 82 by sending it in DHCPDISCOVER messages. A server then determines 83 whether to allow the 2-message exchange based on its configuration 84 information and can either handle the DHCPDISCOVER as defined in 85 [RFC2131] or commit the client's configuration information and 86 advance to sending a DHCPACK message with the Rapid Commit option 87 as defined herein. 89 2. Requirements 91 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 92 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 93 document, are to be interpreted as described in [RFC 2119] 95 3. Client/Server Operations 97 If a client that supports the Rapid Commit option intends to use 98 the rapid commit capability, it includes a Rapid Commit option in 99 DHCPDISCOVER messages that it sends. The client MUST NOT include 100 it in any other messages. A client and server only use this option 101 when configured to do so. 103 A client that sent a DHCPDISCOVER with Rapid Commit option processes 104 responses as described in [RFC 2131]. However, if the client 105 receives a DHCPACK message with a Rapid Commit option, it SHOULD 106 process the DHCPACK immediately (without waiting for additional 107 DHCPOFFER or DHCPACK messages) and use the address and 108 configuration information contained therein. 110 A server that supports the Rapid Commit option MAY respond to a 111 DHCPDISCOVER message that included the Rapid Commit option with a 112 DHCPACK that includes the Rapid Commit option and fully committed 113 address and configuration information. A server MUST NOT include 114 the Rapid Commit option in any other messages. 116 The Rapid Commit option MUST NOT appear in a Parameter Request 117 List option [RFC 2132]. 119 All other DHCP operations are as documented in [RFC 2131]. 121 3.1 Detailed Flow 123 The following is a revised Section 3.1 of [RFC 2131] that includes 124 handling of the Rapid Commit option. 126 1. The client broadcasts a DHCPDISCOVER message on its local 127 physical subnet. If the client supports the Rapid Commit 128 option and intends to use the rapid commit capability, it 129 includes a Rapid Commit option in the DHCPDISCOVER message. 130 The DHCPDISCOVER message MAY include options that suggest 131 values for the network address and lease duration. BOOTP 132 relay agents may pass the message on to DHCP servers not on 133 the same physical subnet. 135 2. Each server may respond with either a DHCPOFFER message or a 136 DHCPACK message with Rapid Commit option (the latter only if 137 the DHCPDISCOVER contained a Rapid Commit option and the 138 server's configuration policies allow use of Rapid Commit) 139 that includes an available network address in the 'yiaddr' 140 field (and other configuration parameters in DHCP options). 141 Servers sending a DHCPOFFER need not reserve the offered 142 network address, although the protocol will work more 143 efficiently if the server avoids allocating the offered 144 network address to another client. Servers sending the 145 DHCPACK message commit the binding for the client to 146 persistent storage before sending the DHCPACK. The 147 combination of 'client identifier' or 'chaddr' and assigned 148 network address constitute a unique identifier for the 149 client's lease and are used by both the client and server 150 to identify a lease referred to in any DHCP messages. The 151 server transmits the DHCPOFFER or DHCPACK message to the 152 client, using the BOOTP relay agent if necessary. 154 When allocating a new address, servers SHOULD check that the 155 offered network address is not already in use; e.g., the 156 server may probe the offered address with an ICMP Echo Request. 157 Servers SHOULD be implemented so that network administrators 158 MAY choose to disable probes of newly allocated addresses. 160 Figure 3 in [RFC 2131] shows the flow for the normal 4-message 161 exchange. Figure 1 below shows the 2-message exchange. 163 Server Client Server 164 (not selected) (selected) 166 v v v 167 | | | 168 | Begins initialization | 169 | | | 170 | _____________/|\____________ | 171 |/DHCPDISCOVER | DHCPDISCOVER \| 172 | w/Rapid Commit| w/Rapid Commit| 173 | | | 174 Determines | Determines 175 configuration | configuration 176 | | Commits configuration 177 | Collects replies | 178 |\ | ____________/| 179 | \________ | / DHCPACK | 180 | DHCPOFFER\ |/w/Rapid Commit| 181 | (discarded) | | 182 | Initialization complete | 183 | | | 184 . . . 185 . . . 186 | | | 187 | Graceful shutdown | 188 | | | 189 | |\ ____________ | 190 | | DHCPRELEASE \| 191 | | | 192 | | Discards lease 193 | | | 194 v v v 196 Figure 1: Timeline diagram when Rapid Commit used 198 3. The client receives one or more DHCPOFFER or DHCPACK (if Rapid 199 Commit option sent in DHCPDISCOVER) messages from one or more 200 servers. If a DHCPACK (with Rapid Commit option) is received, 201 the client may immediately advance to step 5 below if the 202 offered configuration parameters are acceptable. The client may 203 choose to wait for multiple responses. The client chooses one 204 server from which to request or accept configuration parameters, 205 based on the configuration parameters offered in the DHCPOFFER 206 and DHCPACK messages. If the client chooses a DHCPACK, it 207 advances to step 5. Otherwise, the client broadcasts a 208 DHCPREQUEST message that MUST include the 'server identifier' 209 option to indicate which server it has selected, and that MAY 210 include other options specifying desired configuration values. 211 The 'requested IP address' option MUST be set to the value of 212 'yiaddr' in the DHCPOFFER message from the server. This 213 DHCPREQUEST message is broadcast and relayed through DHCP/BOOTP 214 relay agents. To help ensure that any BOOTP relay agents 215 forward the DHCPREQUEST message to the same set of DHCP servers 216 that received the original DHCPDISCOVER message, the 217 DHCPREQUEST message MUST use the same value in the DHCP message 218 header's 'secs' field and be sent to the same IP broadcast 219 address as the original DHCPDISCOVER message. The client times 220 out and retransmits the DHCPDISCOVER message if the client 221 receives no DHCPOFFER messages. 223 4. The servers receive the DHCPREQUEST broadcast from the client. 224 Those servers not selected by the DHCPREQUEST message use the 225 message as notification that the client has declined that 226 server's offer. The server selected in the DHCPREQUEST message 227 commits the binding for the client to persistent storage and 228 responds with a DHCPACK message containing the configuration 229 parameters for the requesting client. The combination of 230 'client identifier' or 'chaddr' and assigned network address 231 constitute a unique identifier for the client's lease and are 232 used by both the client and server to identify a lease referred 233 to in any DHCP messages. Any configuration parameters in the 234 DHCPACK message SHOULD NOT conflict with those in the earlier 235 DHCPOFFER message to which the client is responding. The 236 server SHOULD NOT check the offered network address at this 237 point. The 'yiaddr' field in the DHCPACK messages is filled in 238 with the selected network address. 240 If the selected server is unable to satisfy the DHCPREQUEST 241 message (e.g., the requested network address has been 242 allocated), the server SHOULD respond with a DHCPNAK message. 244 A server MAY choose to mark addresses offered to clients in 245 DHCPOFFER messages as unavailable. The server SHOULD mark an 246 address offered to a client in a DHCPOFFER message as available 247 if the server receives no DHCPREQUEST message from that client. 249 5. The client receives the DHCPACK message with configuration 250 parameters. The client SHOULD perform a final check on the 251 parameters (e.g., ARP for allocated network address), and notes 252 the duration of the lease specified in the DHCPACK message. At 253 this point, the client is configured. If the client detects 254 that the address is already in use (e.g., through the use of 255 ARP), the client MUST send a DHCPDECLINE message to the server 256 and restarts the configuration process. The client SHOULD wait 257 a minimum of ten seconds before restarting the configuration 258 process to avoid excessive network traffic in case of looping. 260 If the client receives a DHCPNAK message, the client restarts 261 the configuration process. 263 The client times out and retransmits the DHCPREQUEST message if 264 the client receives neither a DHCPACK nor a DHCPNAK message. 265 The client retransmits the DHCPREQUEST according to the 266 retransmission algorithm in section 4.1 of [RFC 2131]. The 267 client should choose to retransmit the DHCPREQUEST enough times 268 to give adequate probability of contacting the server without 269 causing the client (and the user of that client) to wait overly 270 long before giving up; e.g., a client retransmitting as 271 described in section 4.1 of [RFC 2131] might retransmit the 272 DHCPREQUEST message four times, for a total delay of 60 seconds, 273 before restarting the initialization procedure. If the client 274 receives neither a DHCPACK nor a DHCPNAK message after 275 employing the retransmission algorithm, the client reverts to 276 INIT state and restarts the initialization process. The client 277 SHOULD notify the user that the initialization process has 278 failed and is restarting. 280 6. The client may choose to relinquish its lease on a network 281 address by sending a DHCPRELEASE message to the server. The 282 client identifies the lease to be released with its 'client 283 identifier', or 'chaddr' and network address in the DHCPRELEASE 284 message. If the client used a 'client identifier' when it 285 obtained the lease, it MUST use the same 'client identifier' in 286 the DHCPRELEASE message. 288 3.2 Administrative Considerations 290 Network administrators MUST only enable the use of Rapid Commit on a 291 DHCP server if one of the following conditions is met: 293 1. The server is the only server for the subnet. 295 2. When multiple servers are present, they may each commit a 296 binding for all clients and therefore each server must have 297 sufficient addresses available. 299 A server MAY allow configuration for a different (likely 300 shorter) initial lease time for addresses assigned when Rapid 301 Commit is used to expedite reclaiming addresses not used by 302 clients. 304 4. Rapid Commit Option Format 306 The Rapid Commit option is used to signal the use of the two message 307 exchange for address assignment. The code for the Rapid Commit 308 Option has to be defined (TBD). The format of the option is: 310 Code Len 311 +-----+-----+ 312 | TBD | 0 | 313 +-----+-----+ 315 A client MUST include this option in a DHCPDISCOVER message if 316 the client is prepared to perform the DHCPDISCOVER-DHCPACK 317 message exchange described earlier. 319 A server MUST include this option in a DHCPACK message sent in 320 a response to a DHCPDISCOVER message when completing the 321 DHCPDISCOVER-DHCPACK message exchange. 323 5. IANA Considerations 325 IANA is requested to assign a value for the Rapid Commit option code 326 in accordance with [RFC 2939]. 328 6. Security Considerations 330 The concepts in this document do not significantly alter the 331 security considerations for DHCP (see [RFC 2131] and [RFC 3118]). 332 However, use of this option could expedite denial of service attacks 333 by allowing a mischievous client to more rapidly consume all 334 available addresses or to do so without requiring two-way 335 communication (as injecting DHCPDISCOVER messages with the Rapid 336 Commit option is sufficient to cause a server to allocate an 337 address). 339 7. References 341 7.1 Normative References 343 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 344 Requirement Levels", BCP 14, RFC 2119, March 1997. 346 [RFC 2131] R. Droms, Dynamic Host Configuration Protocol, RFC 2131, 347 March 1997. 349 7.2 Informative References 351 [RFC 2132] Alexander, S. and Droms, R., "DHCP Options and BOOTP 352 Vendor Extensions," RFC 2132, March 1997. 354 [RFC 2939] R. Droms, Procedures and IANA Guidelines for Definition 355 of New DHCP Options and Message Types, RFC 2939, 356 September 2000. 358 [RFC 3118] R. Droms and W. Arbaugh, Authentication for DHCP 359 Messages, RFC 3118, June 2001. 361 [RFC 3315] R. Droms, et. al., Dynamic Host Configuration Protocol 362 for IPv6, RFC 3315, July 2003. 364 8. Authors' Addresses 366 Soohong Daniel Park 367 Mobile Platform Laboratory 368 Samsung Electronics 369 416, Maetan-3dong, Yeongtong-Gu 370 Suwon, Korea 372 Phone: +82-31-200-4508 373 EMail: soohong.park@samsung.com 375 Pyungsoo Kim 376 Mobile Platform Laboratory 377 Samsung Electronics 378 416, Maetan-3dong, Yeongtong-Gu 379 Suwon, Korea 381 Phone: +82-31-200-4635 382 Email: kimps@samsung.com 384 Bernie Volz 385 Cisco Systems, Inc. 386 1414 Massachusette Ave. 387 Boxborough, MA 01719 388 USA 390 Phone: +1-978-936-0382 391 EMail: volz@cisco.com 393 9. Acknowledgements 395 Special thanks to Ted Lemon and Andre Kostur for their many 396 valuable comments. Thanks to Ralph Droms for his review comments 397 during WGLC. Thanks to Youngkeun Kim for his support on this work. 399 Particularly, authors would like to acknowledge the implementation 400 contributions by Minho Lee of Samsung Electronics. 402 Intellectual Property Statement 404 The IETF takes no position regarding the validity or scope of any 405 Intellectual Property Rights or other rights that might be claimed 406 to pertain to the implementation or use of the technology described 407 in this document or the extent to which any license under such 408 rights might or might not be available; nor does it represent that 409 it has made any independent effort to identify any such rights. 410 Information on the IETF's procedures with respect to rights in IETF 411 Documents can be found in BCP 78 and BCP 79. 413 Copies of IPR disclosures made to the IETF Secretariat and any 414 assurances of licenses to be made available, or the result of an 415 attempt made to obtain a general license or permission for the use 416 of such proprietary rights by implementers or users of this 417 specification can be obtained from the IETF on-line IPR repository 418 at http://www.ietf.org/ipr. 420 The IETF invites any interested party to bring to its attention any 421 copyrights, patents or patent applications, or other proprietary 422 rights that may cover technology that may be required to implement 423 this standard. Please address the information to the IETF at 424 ietf-ipr@ietf.org. 426 Disclaimer of Validity 428 This document and the information contained herein are provided on 429 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 430 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 431 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 432 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 433 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 434 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 436 Copyright Statement 438 Copyright (C) The Internet Society (2004). This document is subject 439 to the rights, licenses and restrictions contained in BCP 78, and 440 except as set forth therein, the authors retain all their rights. 442 Acknowledgment 444 Funding for the RFC Editor function is currently provided by the 445 Internet Society.