idnits 2.17.1 draft-ietf-dhc-rapid-commit-opt-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** There are 32 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 (28 November 2003) is 7453 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 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 352, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DHC Working Group S. Daniel Park 2 Internet-Draft Pyungsoo Kim 3 Expires : 27 May 2004 SAMSUNG Electronics 4 Bernie Volz 5 (unaffiliated) 6 28 November 2003 8 Rapid Commit Option for DHCPv4 9 draft-ietf-dhc-rapid-commit-opt-00.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................................................3 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. Author' Addresses............................................9 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 A client that supports the Rapid Commit option SHOULD include it in 91 DHCPDISCOVER messages that it sends. The client MUST NOT include 92 it in any other messages. 94 A client that sent a DHCPDISCOVER with Rapid Commit option processes 95 responses as described in [RFC 2131]. However, if the client 96 receives a DHCPACK message with a Rapid Commit option, it SHOULD 97 process the DHCPACK immediately (without waiting for additional 98 DHCPOFFER or DHCPACK messages) and use the address and 99 configuration information contained therein. 101 A server that supports the Rapid Commit option MAY respond to a 102 DHCPDISCOVER message that included the Rapid Commit option with a 103 DHCPACK that includes the Rapid Commit option and fully committed 104 address and configuration information. A server MUST NOT include 105 the Rapid Commit option in any other messages. 107 The Rapid Commit option MUST NOT appear in a Parameter Request 108 List option [RFC 2132]. 110 All other DHCP operations are as documented in [RFC 2131]. 112 3.1 Detailed Flow 114 The following is a revised Section 3.1 of [RFC 2131] that includes 115 handling of the Rapid Commit option. 117 1. The client broadcasts a DHCPDISCOVER message on its local 118 physical subnet and SHOULD include the Rapid Commit option if 119 it supports this option. The DHCPDISCOVER message MAY include 120 options that suggest values for the network address and lease 121 duration. BOOTP relay agents may pass the message on to DHCP 122 servers not on the same physical subnet. 124 2. Each server may respond with either a DHCPOFFER message or a 125 DHCPACK message with Rapid Commit option (the latter only if 126 the DHCPDISCOVER contained a Rapid Commit option and the 127 server's configuration policies allow use of Rapid Commit) 128 that includes an available network address in the 'yiaddr' 129 field (and other configuration parameters in DHCP options). 130 Servers sending a DHCPOFFER need not reserve the offered 131 network address, although the protocol will work more 132 efficiently if the server avoids allocating the offered 133 network address to another client. Servers sending the 134 DHCPACK message commit the binding for the client to 135 persistent storage before sending the DHCPACK. The 136 combination of 'client identifier' or 'chaddr' and assigned 137 network address constitute a unique identifier for the 138 client's lease and are used by both the client and server 139 to identify a lease referred to in any DHCP messages. The 140 server transmits the DHCPOFFER or DHCPACK message to the 141 client, using the BOOTP relay agent if necessary. 143 When allocating a new address, servers SHOULD check that the 144 offered network address is not already in use; e.g., the 145 server may probe the offered address with an ICMP Echo Request. 146 Servers SHOULD be implemented so that network administrators 147 MAY choose to disable probes of newly allocated addresses. 149 Figure 3 in [RFC 2131] shows the flow for the normal 4-message 150 exchange. Figure 1 below shows the 2-message exchange. 152 Server Client Server 153 (not selected) (selected) 155 v v v 156 | | | 157 | Begins initialization | 158 | | | 159 | _____________/|\____________ | 160 |/DHCPDISCOVER | DHCPDISCOVER \| 161 | w/Rapid Commit| w/Rapid Commit| 162 | | | 164 Determines | Determines 165 configuration | configuration 166 | | Commits configuration 167 | Collects replies | 168 |\ | ____________/| 169 | \________ | / DHCPACK | 170 | DHCPOFFER\ |/w/Rapid Commit| 171 | (discarded) | | 172 | Initialization complete | 173 | | | 174 . . . 175 . . . 176 | | | 177 | Graceful shutdown | 178 | | | 179 | |\ ____________ | 180 | | DHCPRELEASE \| 181 | | | 182 | | Discards lease 183 | | | 184 v v v 186 Figure 1: Timeline diagram when Rapid Commit used 188 3. The client receives one or more DHCPOFFER or DHCPACK (if Rapid 189 Commit option sent in DHCPDISCOVER) messages from one or more 190 servers. If a DHCPACK (with Rapid Commit option) is received, 191 the client may immediately advance to step 5 below if the 192 offered configuration parameters are acceptable. The client may 193 choose to wait for multiple responses. The client chooses one 194 server from which to request or accept configuration parameters, 195 based on the configuration parameters offered in the DHCPOFFER 196 and DHCPACK messages. If the client chooses a DHCPACK, it 197 advances to step 5. Otherwise, the client broadcasts a 198 DHCPREQUEST message that MUST include the 'server identifier' 199 option to indicate which server it has selected, and that MAY 200 include other options specifying desired configuration values. 201 The 'requested IP address' option MUST be set to the value of 202 'yiaddr' in the DHCPOFFER message from the server. This 203 DHCPREQUEST message is broadcast and relayed through DHCP/BOOTP 204 relay agents. To help ensure that any BOOTP relay agents 205 forward the DHCPREQUEST message to the same set of DHCP servers 206 that received the original DHCPDISCOVER message, the 207 DHCPREQUEST message MUST use the same value in the DHCP message 208 header's 'secs' field and be sent to the same IP broadcast 209 address as the original DHCPDISCOVER message. The client times 210 out and retransmits the DHCPDISCOVER message if the client 211 receives no DHCPOFFER messages. 213 4. The servers receive the DHCPREQUEST broadcast from the client. 214 Those servers not selected by the DHCPREQUEST message use the 215 message as notification that the client has declined that 216 server's offer. The server selected in the DHCPREQUEST message 217 commits the binding for the client to persistent storage and 218 responds with a DHCPACK message containing the configuration 219 parameters for the requesting client. The combination of 220 'client identifier' or 'chaddr' and assigned network address 221 constitute a unique identifier for the client's lease and are 222 used by both the client and server to identify a lease referred 223 to in any DHCP messages. Any configuration parameters in the 224 DHCPACK message SHOULD NOT conflict with those in the earlier 225 DHCPOFFER message to which the client is responding. The 226 server SHOULD NOT check the offered network address at this 227 point. The 'yiaddr' field in the DHCPACK messages is filled in 228 with the selected network address. 230 If the selected server is unable to satisfy the DHCPREQUEST 231 message (e.g., the requested network address has been 232 allocated), the server SHOULD respond with a DHCPNAK message. 234 A server MAY choose to mark addresses offered to clients in 235 DHCPOFFER messages as unavailable. The server SHOULD mark an 236 address offered to a client in a DHCPOFFER message as available 237 if the server receives no DHCPREQUEST message from that client. 239 5. The client receives the DHCPACK message with configuration 240 parameters. The client SHOULD perform a final check on the 241 parameters (e.g., ARP for allocated network address), and notes 242 the duration of the lease specified in the DHCPACK message. At 243 this point, the client is configured. If the client detects 244 that the address is already in use (e.g., through the use of 245 ARP), the client MUST send a DHCPDECLINE message to the server 246 and restarts the configuration process. The client SHOULD wait 247 a minimum of ten seconds before restarting the configuration 248 process to avoid excessive network traffic in case of looping. 250 If the client receives a DHCPNAK message, the client restarts 251 the configuration process. 253 The client times out and retransmits the DHCPREQUEST message if 254 the client receives neither a DHCPACK or a DHCPNAK message. 255 The client retransmits the DHCPREQUEST according to the 256 retransmission algorithm in section 4.1 of [RFC 2131]. The 257 client should choose to retransmit the DHCPREQUEST enough times 258 to give adequate probability of contacting the server without 259 causing the client (and the user of that client) to wait overly 260 long before giving up; e.g., a client retransmitting as 261 described in section 4.1 of [RFC 2131] might retransmit the 262 DHCPREQUEST message four times, for a total delay of 60 seconds, 263 before restarting the initialization procedure. If the client 264 receives neither a DHCPACK or a DHCPNAK message after employing 265 the retransmission algorithm, the client reverts to INIT 266 state and restarts the initialization process. The client 267 SHOULD notify the user that the initialization process has 268 failed and is restarting. 270 6. The client may choose to relinquish its lease on a network 271 address by sending a DHCPRELEASE message to the server. The 272 client identifies the lease to be released with its 'client 273 identifier', or 'chaddr' and network address in the DHCPRELEASE 274 message. If the client used a 'client identifier' when it 275 obtained the lease, it MUST use the same 'client identifier' in 276 the DHCPRELEASE message. 278 3.2 Administrative Considerations 280 Network administrators MUST only enable the use of Rapid Commit on a 281 DHCP server if one of the following conditions is met: 283 1. The server is the only server for the subnet. 285 2. Addresses are plentiful for the client population. When 286 multiple servers are present, they may each commit a binding 287 for all clients and therefore each server must have sufficient 288 addresses available. 290 A server MAY allow configuration for a different (likely 291 shorter) initial lease time for addresses assigned when Rapid 292 Commit is used to expedite reclaiming addresses not used by 293 clients. 295 4. Rapid Commit Option Format 297 The Rapid Commit option is used to signal the use of the two message 298 exchange for address assignment. The code for the Rapid Commit 299 Option has to be defined (TBD). The format of the option is: 301 Code Len 302 +-----+-----+ 303 | TBD | 0 | 304 +-----+-----+ 306 A client SHOULD include this option in a DHCPDISCOVER message 307 if the client is prepared to perform the DHCPDISCOVER-DHCPACK 308 message exchange described earlier. 310 A server MUST include this option in a DHCPACK message sent in 311 a response to a DHCPDISCOVER message when completing the 312 DHCPDISCOVER-DHCPACK message exchange. 314 5. IANA Considerations 316 IANA is requested to assign a value for the Rapid Commit option code 317 in accordance with [RFC 2939]. 319 6. Security Considerations 321 The concepts in this document do not significantly alter the 322 security considerations for DHCP (see [RFC 2131] and [RFC 3118]). 323 However, use of this option could expedite denial of service attacks 324 by allowing a mischievous client to more rapidly consume all 325 available addresses or to do so without requiring two-way 326 communication (as injecting DHCPDISCOVER messages with the Rapid 327 Commit option is sufficient to cause a server to allocate an 328 address). 330 7. References 332 7.1 Normative References 334 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 335 Requirement Levels", BCP 14, RFC 2119, March 1997. 337 [RFC 2131] R. Droms, Dynamic Host Configuration Protocol, RFC 2131, 338 March 1997. 340 7.2 Informative References 342 [RFC 2132] Alexander, S. and Droms, R., "DHCP Options and BOOTP 343 Vendor Extensions," RFC 2132, March 1997. 345 [RFC 2939] R. Droms, Procedures and IANA Guidelines for Definition 346 of New DHCP Options and Message Types, RFC 2939, 347 September 2000. 349 [RFC 3118] R. Droms and W. Arbaugh, Authentication for DHCP 350 Messages, RFC 3118, June 2001. 352 [RFC 3315] R. Droms, et. al., Dynamic Host Configuration Protocol 353 for IPv6, RFC 3315, July 2003. 355 8. Author' Addresses 357 Soohong Daniel Park 358 Mobile Platform Laboratory, SAMSUNG Electronics 359 416, Maetan-3Dong, Paldal-Gu, Suwon 360 Gyeonggi-Do, Korea 362 Phone: +82-31-200-4508 363 EMail: soohong.park@samsung.com 365 Pyungsoo Kim 366 Mobile Platform Laboratory, SAMSUNG Electronics 367 416, Maetan-3Dong, Paldal-Gu, Suwon 368 Gyeonggi-Do, Korea 370 Phone: +82-31-200-4635 371 Email: kimps@samsung.com 373 Bernie Volz 374 116 Hawkins Pond Road 375 Center Harbor, NH 03226-3103 376 USA 378 Phone: +1-603-968-3062 379 EMail: volz@metrocast.net 381 9. Acknowledgements 383 Special thanks to Ted Lemon and Andre Kostur for their many 384 valuable comments. 386 Notice Regarding Intellectual Property Rights 388 See http://www.ietf.org/ietf/IPR/samsung-general-patent04102003.txt 390 Full Copyright Statement 392 Copyright (C) The Internet Society (2003). All Rights Reserved. 394 This document and translations of it may be copied and furnished to 395 others, and derivative works that comment on or otherwise explain it 396 or assist in its implementation may be prepared, copied, published 397 and distributed, in whole or in part, without restriction of any 398 kind, provided that the above copyright notice and this paragraph 399 are included on all such copies and derivative works. However, this 400 document itself may not be modified in any way, such as by removing 401 the copyright notice or references to the Internet Society or other 402 Internet organizations, except as needed for the purpose of 403 developing Internet standards in which case the procedures for 404 copyrights defined in the Internet Standards process must be 405 followed, or as required to translate it into languages other than 406 English. 408 The limited permissions granted above are perpetual and will not be 409 revoked by the Internet Society or its successors or assignees. 411 This document and the information contained herein is provided on an 412 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 413 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 414 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 415 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 416 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 418 Funding for the RFC editor function is currently provided by the 419 internet Society.