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