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