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