idnits 2.17.1 draft-ietf-dhc-dhcpv6-interop-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 a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 98: '...tion, the server MAY send a Reply mess...' RFC 2119 keyword, line 223: '...ires, the client MUST remove the addre...' RFC 2119 keyword, line 263: '... Servers MUST discard any rece...' RFC 2119 keyword, line 266: '... + the message MUST include a Server...' RFC 2119 keyword, line 268: '...erver Identifier option MUST match the...' (1 more instance...) 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 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 (February 22, 2003) is 7734 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: '17' is mentioned on line 352, but not defined ** Obsolete normative reference: RFC 2461 (ref. '2') (Obsoleted by RFC 4861) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Droms 3 Internet-Draft Cisco Systems 4 Expires: August 23, 2003 February 22, 2003 6 Results from Interoperability Tests of DHCPv6 Implementations 7 draft-ietf-dhc-dhcpv6-interop-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on August 23, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This document publishes issues with the DHCPv6 protocols 39 specifications, based on the results of interoperability testing 40 among several implementations. 42 Introduction 44 The DHCPv6 specification [1] has been accepted as a Proposed 45 Standard, and several related specifications have been published and 46 will soon be submitted to the IESG for review. Several 47 implementations of DHCPv6 have been completed, and these 48 implementations have been tested for interoperability. 50 The purpose of this document is to provide a published record of the 51 issues discovered through interoperability testing, for review and 52 discussion by the appropriate IETF working groups. 54 A course of action to correct problems with the DHCPv6 specifications 55 is proposed for many of the listed issues. Any changes to the 56 specifications will be published to the appropriate working group 57 mailing lists. 59 The remainder of this documents lists specific issues, along with a 60 summary of any discussion of the issue that has already occurred 61 through e-mail and a proposed course of action to correct the issue. 63 Throughout this document, unless otherwise qualified, section 64 references and numbers refer to draft-ietf-dhc-dhcpv6-28. 66 1. Response of servers to Renew and Rebind messages, sections 18.2.3 and 67 18.2.4 69 Issue: Sections 18.2.3 and 18.2.4 have exactly the same sentence: 71 If the server cannot find a client entry for the IA the server 72 returns the IA containing no addresses with a Status Code 73 option set to NoBinding in the Reply message. 75 however, the semantics of "the server cannot find a client entry" 76 is slightly different between the case of Renew and the case of 77 Rebind. 79 Discussion: A Renew message is sent to a specific server, which 80 originally assigned the addresses in the IA. If the server now 81 does not have a record of the IA, it can authoritatively respond 82 with a NoBinding Status Code. 84 However, a Rebind message may be sent to more than one DHCP 85 server, and the servers that did not originally assign the 86 addresses in the IA may legitimately not have any record of the 87 IA. Therefore, in response to a Rebind message, the server should 88 only respond if it can determine that the addresses are somehow 89 invalid, and not respond if it simply has no record of the IA. 91 Resolution: Leave the sentence in section 18.2.3 unchanged. Replace 92 the sentence in section 18.2.4 with the following text: 94 If the server cannot find a client entry for the IA and the 95 server determines that the addresses in the IA are not 96 appropriate for the link to which the client's interface is 97 attached according to the server's explicit configuration 98 information, the server MAY send a Reply message to the client 99 containing the client's IA, with the lifetimes for the 100 addresses in the IA set to zero. This Reply constitutes an 101 explicit notification to the client that the addresses in the 102 IA are no longer valid. In this situation, if the server does 103 not send a Reply message it silently discards the Rebind 104 message. 106 2. Correctness of T1 and T2 parameters 108 Issue: What should a client or server do if it receives an IA_NA in a 109 message where T1 > T2 > 0? 111 Discussion: A client should ignore the IA_NA with the invalid T1 and 112 T2 values. A server should ignore the invalid T1 and T2 values 113 and process the IA_NA as though the client did not set those 114 values. 116 Resolution: Add the following paragraphs at the end of section 22.4, 117 "Identity Association for Non-temporary Addresses Option": 119 If a server receives an IA_NA with T1 greater than T2, and both 120 T1 and T2 are greater than 0, the server ignores the invalid 121 values of T1 and T2 and processes the IA_NA as though the 122 client had set T1 and T2 to 0. 124 If a client receives an IA_NA with T1 greater than T2, and both 125 T1 and T2 are greater than 0, the client discards the IA_NA 126 option and processes the remainder of the message as though the 127 server had not included the invalid IA_NA option. 129 3. Receipt of a Request message for an existing binding 131 Issue: What should a server do when it receives a Request message 132 that contains an IA for which the server already has a binding 133 associating the IA with the requesting client (this can happen if 134 the first Reply from a client is lost and the client resends the 135 Request message)? 137 Discussion: The server either updates the parameters and sends a new 138 Reply or sends a cached copy of the previous Reply. 140 Resolution: Add the following paragraph at the end of section 18.2.1: 142 If the server finds that the client has included an IA in the 143 Request message for which the server already has binding that 144 associates the IA with the client, the client has resent a 145 Request message for which it did not receive a Reply message. 146 The server either resends a previously cached Reply message or 147 sends a new Reply message. 149 4. Client response to receipt of Reply with IA containing Status Code of 150 NoAddrsAvail 152 Issue: Section 18.1.8 describes the client's behavior: 154 When the client receives a NoAddrsAvail status from the server 155 in response to a Request, the client can either try another 156 server (perhaps restarting the DHCP server discovery process) 157 or use the Information-Request to obtain configuration 158 parameters only. 160 What does the client do if it receives more than one IA, and some 161 IAs have been assigned addresses, while other IAs have been 162 returned with status NoAddrsAvail? 164 Discussion: The client should examine and process each IA 165 individually. 167 Resolution: Replace the text in question with: 169 The client examines the status code in each IA individually. 170 If the status code is NoAddrsAvail, the client has received no 171 usable addresses in the IA and may choose to try obtaining 172 addresses for the IA from another server. The client uses 173 addresses and other information from any IAs that do not 174 contain a Status Code option with the NoAddrsAvail code. If 175 the client receives no addresses in any of the IAs, it may 176 either try another server (perhaps restarting the DHCP server 177 discovery process) or use the Information-request message to 178 obtain other configuration information only. 180 5. Client processing of an IA option that does not include all addresses 181 sent by the client 183 Issue: Section 18.1.3 says: 185 The client includes an IA option with all addresses currently 186 assigned to the IA in its Renew message. 188 and Section 18.2.3 has corresponding sentence: 190 If the server finds that any of the addresses are not 191 appropriate to the link to which the client is attached, the 192 server returns the address to the client with lifetimes of 0. 194 If the server finds the addresses in the IA for the client then 195 the server sends back the IA to the client with new lifetimes and 196 T1/T2 times. The server may choose to change the list of 197 addresses and the lifetimes of addresses in IAs that are returned 198 to the client. That is,: 200 * the client sends all addresses for an IA to be renewed. 202 * (if the binding is still valid) the server returns all the 203 addresses for the IA with 0 or larger lifetimes. 205 What does the client do if an address it sent to the server is not 206 included in the IA in the Reply message from the server? 208 Discussion: The client leaves addresses in its IA, leaving the 209 lifetimes on those addresses unchanged. The client then discards 210 the addresses when their lifetimes expire. 212 Resolution: Add the following item to the bullet list in section 213 18.1.8: 215 - Leave unchanged any information about addresses the client 216 has recorded in the IA but that were not included in the IA 217 from the server 219 Add the following text to the end of the last paragraph of section 220 10: 222 Additionally, when the valid lifetime for an address in an IA 223 expires, the client MUST remove the address from the IA. 225 6. Receipt of Reply with Rapid Commit option after sending Request 227 Issue: Section 17.1.4 says: 229 If it does not receive such a Reply message and does receive a 230 valid Advertise message, the client processes the Advertise 231 message as described in section 17.1.3. 233 What should the client do if it receives a Reply message for a 234 Solicit message with a Rapid Commit option after SOL_TIMEOUT has 235 expired and the client has sent a Request message? Should the 236 client ignore or accept it? In the latter case, what happens if 237 the client has already sent a Request message (for which it will 238 receive a different Reply message)? 240 Discussion: The client can either discard the Reply message or 241 process the Reply message and discard any subsequent Reply 242 messages received in response to the Request message. 244 Resolution: Add the following text to the end of section 17.1.4: 246 If the client subsequently receives a valid Reply message that 247 includes a Rapid Commit option, it either: 249 processes the Reply message as described in section 18.1.8, 250 and discards any Reply messages received in response to the 251 Request message 253 processes any Reply messages received in response to the 254 Request message and discards the Reply message that includes 255 the Rapid Commit option 257 7. Inconsistent or incorrect text in section 15 259 Issue: Text in section 15 is inconsistent, ambiguous and incorrect. 261 Discussion: For example, in section 15.6: 263 Servers MUST discard any received Renew message that meets any 264 of the following conditions: 266 + the message MUST include a Server Identifier option 268 + the contents of the Server Identifier option MUST match the 269 server's identifier 271 + ... 273 However, there should be a wording problem. The first sentence 274 should read: 276 Servers MUST discard any received Renew message that fails to 277 meet any of the following conditions: 279 Resolution: Review and reword appropriate text in section 15 for 280 consistency and correctness. 282 8. Typographic error regarding MRC in section 18.1.6 284 Issue: In the following line of Section 18.1.6: 286 MRC REL_MAX_MRC 288 should be: 290 MRC REL_MAX_RC 292 Resolution: Correct typo in section 18.1.6. 294 9. Inconsistent lifetimes for an address 296 Issue: What should a client or server do if the preferred lifetime is 297 larger than the valid lifetime for an IA address option in a reply 298 message (to request/renew, etc)? Similarly, suppose either T1 or 299 T2 is larger than the shortest preferred lifetime in the IA? 301 Discussion: A client discards any addresses for which the preferred 302 lifetime is larger than the valid lifetime. It is acceptable for 303 T1 or T2 to be larger than a preferred or valid lifetime when the 304 server does not expect to extend the lifetime of that address in 305 the future. A server ignores any invalid or inconsistent 306 lifetimes or values for T1 and T2 and processes the IA as though 307 the client had not set those invalid or inconsistent values. 309 In a related matter, the text in section 22.4 that gives 310 recommended values for T1 and T2 should be clarified to indicate 311 that T1 and T2 should be based on shortest lifetime of any address 312 that the server intends to extend in the future. 314 Resolution: Add the following paragraph before the next-to-last 315 paragraph of section 22.6 (bottom of page 65 in draft-ietf-dhc- 316 dhcpv6-28.txt): 318 A client discards any addresses for which the preferred 319 lifetime is greater than the valid lifetime. A server ignores 320 the lifetimes set by the client if the preferred lifetime is 321 greater than the valid lifetime and ignores the values for T1 322 and T2 set by the client if those values are greater than the 323 preferred lifetime. 325 Change the second sentence of the last paragraph of section 22.4 326 to: 328 Recommended values for T1 and T2 are .5 and .8 times the 329 shortest preferred lifetime of the addresses in the IA that the 330 server is willing to extend, respectively. 332 10. "Infinity" as a time value 334 Issue: Should DHCPv6 have a notion of "infinity" as lifetimes and 335 T1/T2 values? In RFC2461 [2], 0xffffffff is taken to mean 336 "infinity". If DHCPv6 intends to be consistent with that meaning, 337 there should be an explicit definition somewhere in the 338 specification. 340 Discussion: DHCPv6 should treat 0xffffffff as "infinity" in the case 341 of time values. In section 22.4, the recommendations for values 342 of T1 and T2 need to be clarified for the case when the lifetimes 343 of the addresses in an IA are 0xffffffff. 345 Resolution: Add section 5.6: 347 5.6 Representation of time values and "Infinity" as a time 348 value 350 All time values for lifetimes, T1 and T2 are unsigned 351 integers. The value 0xffffffff is taken to mean "infinity" 352 when used as a lifetime (as in RFC2461 [17]) or a value for 353 T1 or T2. 355 Add the following sentence after the sentence in the last 356 paragraph of section 22.4 that begins "Recommended values...": 358 If the "shortest" preferred lifetime is 0xffffffff 359 ("infinity"), the recommended T1 and T2 values are also 360 0xffffffff. 362 Add the following paragraph at the end of section 22.4: 364 Care should be taken in setting T1 or T2 to 0xffffffff 365 ("infinity"). A client will never attempt to extend the 366 lifetimes of any addresses in an IA with T1 set to 367 0xffffffff. A client will never attempt to use a Rebind 368 message to locate a different server to extend the lifetimes 369 of any addresses in an IA with T2 set to 0xffffffff. 371 Add the following paragraph before the next-to-last paragraph 372 of section 22.6 (bottom of page 65 in draft-ietf-dhc-dhcpv6- 373 28.txt, after the paragraph added in Section 9 of this 374 document): 376 Care should be taken in setting the valid lifetime of an 377 address to 0xffffffff ("infinity"), which amounts to a 378 permanent assignment of an address to a client. 380 11. Client behavior in response to receipt of Reply message with 381 StatusCode set to NoBinding 383 Issue: In section 18.1.8, it's not clear if the client should 384 continue to send Renew/Rebind messages as well as send a Request 385 message in response to a Reply with a Status Code set to 386 NoBinding. 388 Discussion: For each IA in the original Renew/Rebind, the client 389 should: 391 * send a Request if the StatusCode in the IA is NoBinding 393 * send a Renew/Rebind if the IA is not in the Reply 395 * accept the response if the IA is in the Reply and there is no 396 status code 398 Resolution: Change the text in the corresponding (third-to-last) 399 paragraph in section 18.1.8 to read: 401 When the client receives a Reply message in response to a Renew 402 or Rebind message, the client examines each IA independently. 403 For each IA in the original Renew or Rebind message, the 404 client: 406 + sends a Request message if the StatusCode in the IA is 407 NoBinding (and does not send any additional Renew/Rebind 408 messages) 410 + sends a Renew/Rebind if the IA is not in the Reply message 412 + otherwise accepts the information in the IA 414 12. Maximum value for Elapsed Time option 416 Issue: The value carried in the Elapsed Time option is an unsigned, 417 16 bit integer with a resolution of 1/100 of a second. The 418 maximum time that can be represented in this format is roughly 11 419 minutes. What happens if the client's elapsed time exceeds the 420 maximum value that can be represented in the Elapsed Time option? 422 Discussion: The value 0xffff should be used to represent any elapsed 423 time value greater than the maximum time that can be represented 424 in the Elapsed Time option. 426 Resolution: Add the following sentence to the end of section 22.9: 428 The elapsed time value is an unsigned, 16 bit integer. The 429 client uses the value 0xffff to represent any elapsed time 430 values greater than the largest time value that can be 431 represented in the Elapsed Time option. 433 13. Appearance of Elapsed Time option in DHCP messages 435 Issue: The table in Appendix A shows (incorrectly) that the Elapsed 436 Time option may appear in Advertise and Reply messages. 438 Discussion: A server should not include an Elapsed Time option in 439 Advertise and Reply messages. 441 Resolution: Edit the table in Appendix A. 443 14. Acknowledgments 445 Thanks to Tatuya Jinmei for identifying many of these issues and for 446 contributing to the discussion and resolution of the issues. This 447 document was reviewed and discussed by Jim Bound, Ralph Droms, Tatuya 448 Jinmei, Ted Lemon, Ole Troan, Bernie Volz and Jun Xie. 450 References 452 [1] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 453 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 454 draft-ietf-dhc-dhcpv6-28 (work in progress), November 2002. 456 [2] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for 457 IP Version 6 (IPv6)", RFC 2461, December 1998. 459 Author's Address 461 Ralph Droms 462 Cisco Systems 463 300 Apollo Drive 464 Chelmsford 01824 465 MA 467 Phone: +1 978.497.4733 468 EMail: rdroms@cisco.com 470 Full Copyright Statement 472 Copyright (C) The Internet Society (2003). All Rights Reserved. 474 This document and translations of it may be copied and furnished to 475 others, and derivative works that comment on or otherwise explain it 476 or assist in its implementation may be prepared, copied, published 477 and distributed, in whole or in part, without restriction of any 478 kind, provided that the above copyright notice and this paragraph are 479 included on all such copies and derivative works. However, this 480 document itself may not be modified in any way, such as by removing 481 the copyright notice or references to the Internet Society or other 482 Internet organizations, except as needed for the purpose of 483 developing Internet standards in which case the procedures for 484 copyrights defined in the Internet Standards process must be 485 followed, or as required to translate it into languages other than 486 English. 488 The limited permissions granted above are perpetual and will not be 489 revoked by the Internet Society or its successors or assigns. 491 This document and the information contained herein is provided on an 492 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 493 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 494 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 495 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 496 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 498 Acknowledgement 500 Funding for the RFC Editor function is currently provided by the 501 Internet Society.