idnits 2.17.1 draft-ietf-dhc-dhcpv6-interop-01.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 97: '...tion, the server MAY send a Reply mess...' RFC 2119 keyword, line 222: '...ires, the client MUST remove the addre...' RFC 2119 keyword, line 262: '... Servers MUST discard any rece...' RFC 2119 keyword, line 265: '... + the message MUST include a Server...' RFC 2119 keyword, line 267: '...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 (April 8, 2003) is 7682 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 351, 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: October 7, 2003 April 8, 2003 6 Results from Interoperability Tests of DHCPv6 Implementations 7 draft-ietf-dhc-dhcpv6-interop-01.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 October 7, 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. These changes will be 56 made to the DHCPv6 specification prior to its publication as an RFC. 58 The remainder of this documents lists specific issues, along with a 59 summary of any discussion of the issue that has already occurred 60 through e-mail and a proposed course of action to correct the issue. 62 Throughout this document, unless otherwise qualified, section 63 references and numbers refer to draft-ietf-dhc-dhcpv6-28. 65 1. Response of servers to Renew and Rebind messages, sections 18.2.3 and 66 18.2.4 68 Issue: Sections 18.2.3 and 18.2.4 have exactly the same sentence: 70 If the server cannot find a client entry for the IA the server 71 returns the IA containing no addresses with a Status Code 72 option set to NoBinding in the Reply message. 74 however, the semantics of "the server cannot find a client entry" 75 is slightly different between the case of Renew and the case of 76 Rebind. 78 Discussion: A Renew message is sent to a specific server, which 79 originally assigned the addresses in the IA. If the server now 80 does not have a record of the IA, it can authoritatively respond 81 with a NoBinding Status Code. 83 However, a Rebind message may be sent to more than one DHCP 84 server, and the servers that did not originally assign the 85 addresses in the IA may legitimately not have any record of the 86 IA. Therefore, in response to a Rebind message, the server should 87 only respond if it can determine that the addresses are somehow 88 invalid, and not respond if it simply has no record of the IA. 90 Resolution: Leave the sentence in section 18.2.3 unchanged. Replace 91 the sentence in section 18.2.4 with the following text: 93 If the server cannot find a client entry for the IA and the 94 server determines that the addresses in the IA are not 95 appropriate for the link to which the client's interface is 96 attached according to the server's explicit configuration 97 information, the server MAY send a Reply message to the client 98 containing the client's IA, with the lifetimes for the 99 addresses in the IA set to zero. This Reply constitutes an 100 explicit notification to the client that the addresses in the 101 IA are no longer valid. In this situation, if the server does 102 not send a Reply message it silently discards the Rebind 103 message. 105 2. Correctness of T1 and T2 parameters 107 Issue: What should a client or server do if it receives an IA_NA in a 108 message where T1 > T2 > 0? 110 Discussion: A client should ignore the IA_NA with the invalid T1 and 111 T2 values. A server should ignore the invalid T1 and T2 values 112 and process the IA_NA as though the client did not set those 113 values. 115 Resolution: Add the following paragraphs at the end of section 22.4, 116 "Identity Association for Non-temporary Addresses Option": 118 If a server receives an IA_NA with T1 greater than T2, and both 119 T1 and T2 are greater than 0, the server ignores the invalid 120 values of T1 and T2 and processes the IA_NA as though the 121 client had set T1 and T2 to 0. 123 If a client receives an IA_NA with T1 greater than T2, and both 124 T1 and T2 are greater than 0, the client discards the IA_NA 125 option and processes the remainder of the message as though the 126 server had not included the invalid IA_NA option. 128 3. Receipt of a Request message for an existing binding 130 Issue: What should a server do when it receives a Request message 131 that contains an IA for which the server already has a binding 132 associating the IA with the requesting client (this can happen if 133 the first Reply from a client is lost and the client resends the 134 Request message)? 136 Discussion: The server either updates the parameters and sends a new 137 Reply or sends a cached copy of the previous Reply. 139 Resolution: Add the following paragraph at the end of section 18.2.1: 141 If the server finds that the client has included an IA in the 142 Request message for which the server already has binding that 143 associates the IA with the client, the client has resent a 144 Request message for which it did not receive a Reply message. 145 The server either resends a previously cached Reply message or 146 sends a new Reply message. 148 4. Client response to receipt of Reply with IA containing Status Code of 149 NoAddrsAvail 151 Issue: Section 18.1.8 describes the client's behavior: 153 When the client receives a NoAddrsAvail status from the server 154 in response to a Request, the client can either try another 155 server (perhaps restarting the DHCP server discovery process) 156 or use the Information-Request to obtain configuration 157 parameters only. 159 What does the client do if it receives more than one IA, and some 160 IAs have been assigned addresses, while other IAs have been 161 returned with status NoAddrsAvail? 163 Discussion: The client should examine and process each IA 164 individually. 166 Resolution: Replace the text in question with: 168 The client examines the status code in each IA individually. 169 If the status code is NoAddrsAvail, the client has received no 170 usable addresses in the IA and may choose to try obtaining 171 addresses for the IA from another server. The client uses 172 addresses and other information from any IAs that do not 173 contain a Status Code option with the NoAddrsAvail code. If 174 the client receives no addresses in any of the IAs, it may 175 either try another server (perhaps restarting the DHCP server 176 discovery process) or use the Information-request message to 177 obtain other configuration information only. 179 5. Client processing of an IA option that does not include all addresses 180 sent by the client 182 Issue: Section 18.1.3 says: 184 The client includes an IA option with all addresses currently 185 assigned to the IA in its Renew message. 187 and Section 18.2.3 has corresponding sentence: 189 If the server finds that any of the addresses are not 190 appropriate to the link to which the client is attached, the 191 server returns the address to the client with lifetimes of 0. 193 If the server finds the addresses in the IA for the client then 194 the server sends back the IA to the client with new lifetimes and 195 T1/T2 times. The server may choose to change the list of 196 addresses and the lifetimes of addresses in IAs that are returned 197 to the client. That is,: 199 * the client sends all addresses for an IA to be renewed. 201 * (if the binding is still valid) the server returns all the 202 addresses for the IA with 0 or larger lifetimes. 204 What does the client do if an address it sent to the server is not 205 included in the IA in the Reply message from the server? 207 Discussion: The client leaves addresses in its IA, leaving the 208 lifetimes on those addresses unchanged. The client then discards 209 the addresses when their lifetimes expire. 211 Resolution: Add the following item to the bullet list in section 212 18.1.8: 214 - Leave unchanged any information about addresses the client 215 has recorded in the IA but that were not included in the IA 216 from the server 218 Add the following text to the end of the last paragraph of section 219 10: 221 Additionally, when the valid lifetime for an address in an IA 222 expires, the client MUST remove the address from the IA. 224 6. Receipt of Reply with Rapid Commit option after sending Request 226 Issue: Section 17.1.4 says: 228 If it does not receive such a Reply message and does receive a 229 valid Advertise message, the client processes the Advertise 230 message as described in section 17.1.3. 232 What should the client do if it receives a Reply message for a 233 Solicit message with a Rapid Commit option after SOL_TIMEOUT has 234 expired and the client has sent a Request message? Should the 235 client ignore or accept it? In the latter case, what happens if 236 the client has already sent a Request message (for which it will 237 receive a different Reply message)? 239 Discussion: The client can either discard the Reply message or 240 process the Reply message and discard any subsequent Reply 241 messages received in response to the Request message. 243 Resolution: Add the following text to the end of section 17.1.4: 245 If the client subsequently receives a valid Reply message that 246 includes a Rapid Commit option, it either: 248 processes the Reply message as described in section 18.1.8, 249 and discards any Reply messages received in response to the 250 Request message 252 processes any Reply messages received in response to the 253 Request message and discards the Reply message that includes 254 the Rapid Commit option 256 7. Inconsistent or incorrect text in section 15 258 Issue: Text in section 15 is inconsistent, ambiguous and incorrect. 260 Discussion: For example, in section 15.6: 262 Servers MUST discard any received Renew message that meets any 263 of the following conditions: 265 + the message MUST include a Server Identifier option 267 + the contents of the Server Identifier option MUST match the 268 server's identifier 270 + ... 272 However, there is a wording problem. The first sentence should 273 read: 275 Servers MUST discard any received Renew message that fails to 276 meet any of the following conditions: 278 Resolution: Review and reword appropriate text in section 15 for 279 consistency and correctness. 281 8. Typographic error regarding MRC in section 18.1.6 283 Issue: In the following line of Section 18.1.6: 285 MRC REL_MAX_MRC 287 should be: 289 MRC REL_MAX_RC 291 Resolution: Correct typo in section 18.1.6. 293 9. Inconsistent lifetimes for an address 295 Issue: What should a client or server do if the preferred lifetime is 296 larger than the valid lifetime for an IA address option in a reply 297 message (to request/renew, etc)? Similarly, suppose either T1 or 298 T2 is larger than the shortest preferred lifetime in the IA? 300 Discussion: A client discards any addresses for which the preferred 301 lifetime is larger than the valid lifetime. It is acceptable for 302 T1 or T2 to be larger than a preferred or valid lifetime when the 303 server does not expect to extend the lifetime of that address in 304 the future. A server ignores any invalid or inconsistent 305 lifetimes or values for T1 and T2 and processes the IA as though 306 the client had not set those invalid or inconsistent values. 308 In a related matter, the text in section 22.4 that gives 309 recommended values for T1 and T2 should be clarified to indicate 310 that T1 and T2 should be based on shortest lifetime of any address 311 that the server intends to extend in the future. 313 Resolution: Add the following paragraph before the next-to-last 314 paragraph of section 22.6 (bottom of page 65 in draft-ietf-dhc- 315 dhcpv6-28.txt): 317 A client discards any addresses for which the preferred 318 lifetime is greater than the valid lifetime. A server ignores 319 the lifetimes set by the client if the preferred lifetime is 320 greater than the valid lifetime and ignores the values for T1 321 and T2 set by the client if those values are greater than the 322 preferred lifetime. 324 Change the second sentence of the last paragraph of section 22.4 325 to: 327 Recommended values for T1 and T2 are .5 and .8 times the 328 shortest preferred lifetime of the addresses in the IA that the 329 server is willing to extend, respectively. 331 10. "Infinity" as a time value 333 Issue: Should DHCPv6 have a notion of "infinity" as lifetimes and 334 T1/T2 values? In RFC2461 [2], 0xffffffff is taken to mean 335 "infinity". If DHCPv6 intends to be consistent with that meaning, 336 there should be an explicit definition somewhere in the 337 specification. 339 Discussion: DHCPv6 should treat 0xffffffff as "infinity" in the case 340 of time values. In section 22.4, the recommendations for values 341 of T1 and T2 need to be clarified for the case when the lifetimes 342 of the addresses in an IA are 0xffffffff. 344 Resolution: Add section 5.6: 346 5.6 Representation of time values and "Infinity" as a time 347 value 349 All time values for lifetimes, T1 and T2 are unsigned 350 integers. The value 0xffffffff is taken to mean "infinity" 351 when used as a lifetime (as in RFC2461 [17]) or a value for 352 T1 or T2. 354 Add the following sentence after the sentence in the last 355 paragraph of section 22.4 that begins "Recommended values...": 357 If the "shortest" preferred lifetime is 0xffffffff 358 ("infinity"), the recommended T1 and T2 values are also 359 0xffffffff. 361 Add the following paragraph at the end of section 22.4: 363 Care should be taken in setting T1 or T2 to 0xffffffff 364 ("infinity"). A client will never attempt to extend the 365 lifetimes of any addresses in an IA with T1 set to 366 0xffffffff. A client will never attempt to use a Rebind 367 message to locate a different server to extend the lifetimes 368 of any addresses in an IA with T2 set to 0xffffffff. 370 Add the following paragraph before the next-to-last paragraph 371 of section 22.6 (bottom of page 65 in draft-ietf-dhc-dhcpv6- 372 28.txt, after the paragraph added in Section 9 of this 373 document): 375 Care should be taken in setting the valid lifetime of an 376 address to 0xffffffff ("infinity"), which amounts to a 377 permanent assignment of an address to a client. 379 11. Client behavior in response to receipt of Reply message with 380 StatusCode set to NoBinding 382 Issue: In section 18.1.8, it's not clear if the client should 383 continue to send Renew/Rebind messages as well as send a Request 384 message in response to a Reply with a Status Code set to 385 NoBinding. 387 Discussion: For each IA in the original Renew/Rebind, the client 388 should: 390 * send a Request if the StatusCode in the IA is NoBinding 392 * send a Renew/Rebind if the IA is not in the Reply 394 * accept the response if the IA is in the Reply and there is no 395 status code 397 Resolution: Change the text in the corresponding (third-to-last) 398 paragraph in section 18.1.8 to read: 400 When the client receives a Reply message in response to a Renew 401 or Rebind message, the client examines each IA independently. 402 For each IA in the original Renew or Rebind message, the 403 client: 405 + sends a Request message if the StatusCode in the IA is 406 NoBinding (and does not send any additional Renew/Rebind 407 messages) 409 + sends a Renew/Rebind if the IA is not in the Reply message 411 + otherwise accepts the information in the IA 413 12. Maximum value for Elapsed Time option 415 Issue: The value carried in the Elapsed Time option is an unsigned, 416 16 bit integer with a resolution of 1/100 of a second. The 417 maximum time that can be represented in this format is roughly 11 418 minutes. What happens if the client's elapsed time exceeds the 419 maximum value that can be represented in the Elapsed Time option? 421 Discussion: The value 0xffff should be used to represent any elapsed 422 time value greater than the maximum time that can be represented 423 in the Elapsed Time option. 425 Resolution: Add the following sentence to the end of section 22.9: 427 The elapsed time value is an unsigned, 16 bit integer. The 428 client uses the value 0xffff to represent any elapsed time 429 values greater than the largest time value that can be 430 represented in the Elapsed Time option. 432 13. Appearance of Elapsed Time option in DHCP messages 434 Issue: The table in Appendix A shows (incorrectly) that the Elapsed 435 Time option may appear in Advertise and Reply messages. 437 Discussion: A server should not include an Elapsed Time option in 438 Advertise and Reply messages. 440 Resolution: Edit the table in Appendix A. 442 14. Acknowledgments 444 Thanks to Tatuya Jinmei for identifying many of these issues and for 445 contributing to the discussion and resolution of the issues. This 446 document was reviewed and discussed by Jim Bound, Ralph Droms, Tatuya 447 Jinmei, Ted Lemon, Ole Troan, Bernie Volz and Jun Xie. 449 References 451 [1] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 452 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 453 draft-ietf-dhc-dhcpv6-28 (work in progress), November 2002. 455 [2] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for 456 IP Version 6 (IPv6)", RFC 2461, December 1998. 458 Author's Address 460 Ralph Droms 461 Cisco Systems 462 300 Apollo Drive 463 Chelmsford 01824 464 MA 466 Phone: +1 978.497.4733 467 EMail: rdroms@cisco.com 469 Full Copyright Statement 471 Copyright (C) The Internet Society (2003). All Rights Reserved. 473 This document and translations of it may be copied and furnished to 474 others, and derivative works that comment on or otherwise explain it 475 or assist in its implementation may be prepared, copied, published 476 and distributed, in whole or in part, without restriction of any 477 kind, provided that the above copyright notice and this paragraph are 478 included on all such copies and derivative works. However, this 479 document itself may not be modified in any way, such as by removing 480 the copyright notice or references to the Internet Society or other 481 Internet organizations, except as needed for the purpose of 482 developing Internet standards in which case the procedures for 483 copyrights defined in the Internet Standards process must be 484 followed, or as required to translate it into languages other than 485 English. 487 The limited permissions granted above are perpetual and will not be 488 revoked by the Internet Society or its successors or assigns. 490 This document and the information contained herein is provided on an 491 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 492 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 493 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 494 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 495 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 497 Acknowledgement 499 Funding for the RFC Editor function is currently provided by the 500 Internet Society.