1 2 3Network Working Group R. Droms 4Internet-Draft Cisco Systems 5Expires: October 7, 2003 April 8, 2003 6 7 8 Results from Interoperability Tests of DHCPv6 Implementations 9 draft-ietf-dhc-dhcpv6-interop-01.txt 10 11Status of this Memo 12 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 15 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. 20 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 25 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 28 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 31 32 This Internet-Draft will expire on October 7, 2003. 33 34Copyright Notice 35 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 38Abstract 39 40 This document publishes issues with the DHCPv6 protocols 41 specifications, based on the results of interoperability testing 42 among several implementations. 43 44Introduction 45 46 The DHCPv6 specification [1] has been accepted as a Proposed 47 Standard, and several related specifications have been published and 48 will soon be submitted to the IESG for review. Several 49 implementations of DHCPv6 have been completed, and these 50 implementations have been tested for interoperability. 51 52 53 54 55Droms Expires October 7, 2003 [Page 1] 56 57Internet-Draft DHCPv6 Interoperability Testing April 2003 58 59 60 The purpose of this document is to provide a published record of the 61 issues discovered through interoperability testing, for review and 62 discussion by the appropriate IETF working groups. 63 64 A course of action to correct problems with the DHCPv6 specifications 65 is proposed for many of the listed issues. These changes will be 66 made to the DHCPv6 specification prior to its publication as an RFC. 67 68 The remainder of this documents lists specific issues, along with a 69 summary of any discussion of the issue that has already occurred 70 through e-mail and a proposed course of action to correct the issue. 71 72 Throughout this document, unless otherwise qualified, section 73 references and numbers refer to draft-ietf-dhc-dhcpv6-28. 74 751. Response of servers to Renew and Rebind messages, sections 18.2.3 and 76 18.2.4 77 78 Issue: Sections 18.2.3 and 18.2.4 have exactly the same sentence: 79 80 If the server cannot find a client entry for the IA the server 81 returns the IA containing no addresses with a Status Code 82 option set to NoBinding in the Reply message. 83 84 however, the semantics of "the server cannot find a client entry" 85 is slightly different between the case of Renew and the case of 86 Rebind. 87 88 Discussion: A Renew message is sent to a specific server, which 89 originally assigned the addresses in the IA. If the server now 90 does not have a record of the IA, it can authoritatively respond 91 with a NoBinding Status Code. 92 93 However, a Rebind message may be sent to more than one DHCP 94 server, and the servers that did not originally assign the 95 addresses in the IA may legitimately not have any record of the 96 IA. Therefore, in response to a Rebind message, the server should 97 only respond if it can determine that the addresses are somehow 98 invalid, and not respond if it simply has no record of the IA. 99 100 Resolution: Leave the sentence in section 18.2.3 unchanged. Replace 101 the sentence in section 18.2.4 with the following text: 102 103 If the server cannot find a client entry for the IA and the 104 server determines that the addresses in the IA are not 105 appropriate for the link to which the client's interface is 106 attached according to the server's explicit configuration 107 information, the server MAY send a Reply message to the client 108 109 110 111Droms Expires October 7, 2003 [Page 2] 112 113Internet-Draft DHCPv6 Interoperability Testing April 2003 114 115 116 containing the client's IA, with the lifetimes for the 117 addresses in the IA set to zero. This Reply constitutes an 118 explicit notification to the client that the addresses in the 119 IA are no longer valid. In this situation, if the server does 120 not send a Reply message it silently discards the Rebind 121 message. 122 123 1242. Correctness of T1 and T2 parameters 125 126 Issue: What should a client or server do if it receives an IA_NA in a 127 message where T1 > T2 > 0? 128 129 Discussion: A client should ignore the IA_NA with the invalid T1 and 130 T2 values. A server should ignore the invalid T1 and T2 values 131 and process the IA_NA as though the client did not set those 132 values. 133 134 Resolution: Add the following paragraphs at the end of section 22.4, 135 "Identity Association for Non-temporary Addresses Option": 136 137 If a server receives an IA_NA with T1 greater than T2, and both 138 T1 and T2 are greater than 0, the server ignores the invalid 139 values of T1 and T2 and processes the IA_NA as though the 140 client had set T1 and T2 to 0. 141 142 If a client receives an IA_NA with T1 greater than T2, and both 143 T1 and T2 are greater than 0, the client discards the IA_NA 144 option and processes the remainder of the message as though the 145 server had not included the invalid IA_NA option. 146 147 1483. Receipt of a Request message for an existing binding 149 150 Issue: What should a server do when it receives a Request message 151 that contains an IA for which the server already has a binding 152 associating the IA with the requesting client (this can happen if 153 the first Reply from a client is lost and the client resends the 154 Request message)? 155 156 Discussion: The server either updates the parameters and sends a new 157 Reply or sends a cached copy of the previous Reply. 158 159 Resolution: Add the following paragraph at the end of section 18.2.1: 160 161 If the server finds that the client has included an IA in the 162 Request message for which the server already has binding that 163 associates the IA with the client, the client has resent a 164 165 166 167Droms Expires October 7, 2003 [Page 3] 168 169Internet-Draft DHCPv6 Interoperability Testing April 2003 170 171 172 Request message for which it did not receive a Reply message. 173 The server either resends a previously cached Reply message or 174 sends a new Reply message. 175 176 1774. Client response to receipt of Reply with IA containing Status Code of 178 NoAddrsAvail 179 180 Issue: Section 18.1.8 describes the client's behavior: 181 182 When the client receives a NoAddrsAvail status from the server 183 in response to a Request, the client can either try another 184 server (perhaps restarting the DHCP server discovery process) 185 or use the Information-Request to obtain configuration 186 parameters only. 187 188 What does the client do if it receives more than one IA, and some 189 IAs have been assigned addresses, while other IAs have been 190 returned with status NoAddrsAvail? 191 192 Discussion: The client should examine and process each IA 193 individually. 194 195 Resolution: Replace the text in question with: 196 197 The client examines the status code in each IA individually. 198 If the status code is NoAddrsAvail, the client has received no 199 usable addresses in the IA and may choose to try obtaining 200 addresses for the IA from another server. The client uses 201 addresses and other information from any IAs that do not 202 contain a Status Code option with the NoAddrsAvail code. If 203 the client receives no addresses in any of the IAs, it may 204 either try another server (perhaps restarting the DHCP server 205 discovery process) or use the Information-request message to 206 obtain other configuration information only. 207 208 2095. Client processing of an IA option that does not include all addresses 210 sent by the client 211 212 Issue: Section 18.1.3 says: 213 214 The client includes an IA option with all addresses currently 215 assigned to the IA in its Renew message. 216 217 and Section 18.2.3 has corresponding sentence: 218 219 If the server finds that any of the addresses are not 220 221 222 223Droms Expires October 7, 2003 [Page 4] 224 225Internet-Draft DHCPv6 Interoperability Testing April 2003 226 227 228 appropriate to the link to which the client is attached, the 229 server returns the address to the client with lifetimes of 0. 230 231 If the server finds the addresses in the IA for the client then 232 the server sends back the IA to the client with new lifetimes and 233 T1/T2 times. The server may choose to change the list of 234 addresses and the lifetimes of addresses in IAs that are returned 235 to the client. That is,: 236 237 * the client sends all addresses for an IA to be renewed. 238 239 * (if the binding is still valid) the server returns all the 240 addresses for the IA with 0 or larger lifetimes. 241 242 What does the client do if an address it sent to the server is not 243 included in the IA in the Reply message from the server? 244 245 Discussion: The client leaves addresses in its IA, leaving the 246 lifetimes on those addresses unchanged. The client then discards 247 the addresses when their lifetimes expire. 248 249 Resolution: Add the following item to the bullet list in section 250 18.1.8: 251 252 - Leave unchanged any information about addresses the client 253 has recorded in the IA but that were not included in the IA 254 from the server 255 256 Add the following text to the end of the last paragraph of section 257 10: 258 259 Additionally, when the valid lifetime for an address in an IA 260 expires, the client MUST remove the address from the IA. 261 262 2636. Receipt of Reply with Rapid Commit option after sending Request 264 265 Issue: Section 17.1.4 says: 266 267 If it does not receive such a Reply message and does receive a 268 valid Advertise message, the client processes the Advertise 269 message as described in section 17.1.3. 270 271 What should the client do if it receives a Reply message for a 272 Solicit message with a Rapid Commit option after SOL_TIMEOUT has 273 expired and the client has sent a Request message? Should the 274 client ignore or accept it? In the latter case, what happens if 275 the client has already sent a Request message (for which it will 276 277 278 279Droms Expires October 7, 2003 [Page 5] 280 281Internet-Draft DHCPv6 Interoperability Testing April 2003 282 283 284 receive a different Reply message)? 285 286 Discussion: The client can either discard the Reply message or 287 process the Reply message and discard any subsequent Reply 288 messages received in response to the Request message. 289 290 Resolution: Add the following text to the end of section 17.1.4: 291 292 If the client subsequently receives a valid Reply message that 293 includes a Rapid Commit option, it either: 294 295 processes the Reply message as described in section 18.1.8, 296 and discards any Reply messages received in response to the 297 Request message 298 299 processes any Reply messages received in response to the 300 Request message and discards the Reply message that includes 301 the Rapid Commit option 302 303 3047. Inconsistent or incorrect text in section 15 305 306 Issue: Text in section 15 is inconsistent, ambiguous and incorrect. 307 308 Discussion: For example, in section 15.6: 309 310 Servers MUST discard any received Renew message that meets any 311 of the following conditions: 312 313 + the message MUST include a Server Identifier option 314 315 + the contents of the Server Identifier option MUST match the 316 server's identifier 317 318 + ... 319 320 However, there is a wording problem. The first sentence should 321 read: 322 323 Servers MUST discard any received Renew message that fails to 324 meet any of the following conditions: 325 326 Resolution: Review and reword appropriate text in section 15 for 327 consistency and correctness. 328 329 330 331 332 333 334 335Droms Expires October 7, 2003 [Page 6] 336 337Internet-Draft DHCPv6 Interoperability Testing April 2003 338 339 3408. Typographic error regarding MRC in section 18.1.6 341 342 Issue: In the following line of Section 18.1.6: 343 344 MRC REL_MAX_MRC 345 346 should be: 347 348 MRC REL_MAX_RC 349 350 Resolution: Correct typo in section 18.1.6. 351 352 3539. Inconsistent lifetimes for an address 354 355 Issue: What should a client or server do if the preferred lifetime is 356 larger than the valid lifetime for an IA address option in a reply 357 message (to request/renew, etc)? Similarly, suppose either T1 or 358 T2 is larger than the shortest preferred lifetime in the IA? 359 360 Discussion: A client discards any addresses for which the preferred 361 lifetime is larger than the valid lifetime. It is acceptable for 362 T1 or T2 to be larger than a preferred or valid lifetime when the 363 server does not expect to extend the lifetime of that address in 364 the future. A server ignores any invalid or inconsistent 365 lifetimes or values for T1 and T2 and processes the IA as though 366 the client had not set those invalid or inconsistent values. 367 368 In a related matter, the text in section 22.4 that gives 369 recommended values for T1 and T2 should be clarified to indicate 370 that T1 and T2 should be based on shortest lifetime of any address 371 that the server intends to extend in the future. 372 373 Resolution: Add the following paragraph before the next-to-last 374 paragraph of section 22.6 (bottom of page 65 in draft-ietf-dhc- 375 dhcpv6-28.txt): 376 377 A client discards any addresses for which the preferred 378 lifetime is greater than the valid lifetime. A server ignores 379 the lifetimes set by the client if the preferred lifetime is 380 greater than the valid lifetime and ignores the values for T1 381 and T2 set by the client if those values are greater than the 382 preferred lifetime. 383 384 Change the second sentence of the last paragraph of section 22.4 385 to: 386 387 Recommended values for T1 and T2 are .5 and .8 times the 388 389 390 391Droms Expires October 7, 2003 [Page 7] 392 393Internet-Draft DHCPv6 Interoperability Testing April 2003 394 395 396 shortest preferred lifetime of the addresses in the IA that the 397 server is willing to extend, respectively. 398 399 40010. "Infinity" as a time value 401 402 Issue: Should DHCPv6 have a notion of "infinity" as lifetimes and 403 T1/T2 values? In RFC2461 [2], 0xffffffff is taken to mean 404 "infinity". If DHCPv6 intends to be consistent with that meaning, 405 there should be an explicit definition somewhere in the 406 specification. 407 408 Discussion: DHCPv6 should treat 0xffffffff as "infinity" in the case 409 of time values. In section 22.4, the recommendations for values 410 of T1 and T2 need to be clarified for the case when the lifetimes 411 of the addresses in an IA are 0xffffffff. 412 413 Resolution: Add section 5.6: 414 415 5.6 Representation of time values and "Infinity" as a time 416 value 417 418 All time values for lifetimes, T1 and T2 are unsigned 419 integers. The value 0xffffffff is taken to mean "infinity" 420 when used as a lifetime (as in RFC2461 [17]) or a value for 421 T1 or T2. 422 423 Add the following sentence after the sentence in the last 424 paragraph of section 22.4 that begins "Recommended values...": 425 426 If the "shortest" preferred lifetime is 0xffffffff 427 ("infinity"), the recommended T1 and T2 values are also 428 0xffffffff. 429 430 Add the following paragraph at the end of section 22.4: 431 432 Care should be taken in setting T1 or T2 to 0xffffffff 433 ("infinity"). A client will never attempt to extend the 434 lifetimes of any addresses in an IA with T1 set to 435 0xffffffff. A client will never attempt to use a Rebind 436 message to locate a different server to extend the lifetimes 437 of any addresses in an IA with T2 set to 0xffffffff. 438 439 Add the following paragraph before the next-to-last paragraph 440 of section 22.6 (bottom of page 65 in draft-ietf-dhc-dhcpv6- 441 28.txt, after the paragraph added in Section 9 of this 442 document): 443 444 445 446 447Droms Expires October 7, 2003 [Page 8] 448 449Internet-Draft DHCPv6 Interoperability Testing April 2003 450 451 452 Care should be taken in setting the valid lifetime of an 453 address to 0xffffffff ("infinity"), which amounts to a 454 permanent assignment of an address to a client. 455 456 45711. Client behavior in response to receipt of Reply message with 458 StatusCode set to NoBinding 459 460 Issue: In section 18.1.8, it's not clear if the client should 461 continue to send Renew/Rebind messages as well as send a Request 462 message in response to a Reply with a Status Code set to 463 NoBinding. 464 465 Discussion: For each IA in the original Renew/Rebind, the client 466 should: 467 468 * send a Request if the StatusCode in the IA is NoBinding 469 470 * send a Renew/Rebind if the IA is not in the Reply 471 472 * accept the response if the IA is in the Reply and there is no 473 status code 474 475 Resolution: Change the text in the corresponding (third-to-last) 476 paragraph in section 18.1.8 to read: 477 478 When the client receives a Reply message in response to a Renew 479 or Rebind message, the client examines each IA independently. 480 For each IA in the original Renew or Rebind message, the 481 client: 482 483 + sends a Request message if the StatusCode in the IA is 484 NoBinding (and does not send any additional Renew/Rebind 485 messages) 486 487 + sends a Renew/Rebind if the IA is not in the Reply message 488 489 + otherwise accepts the information in the IA 490 491 49212. Maximum value for Elapsed Time option 493 494 Issue: The value carried in the Elapsed Time option is an unsigned, 495 16 bit integer with a resolution of 1/100 of a second. The 496 maximum time that can be represented in this format is roughly 11 497 minutes. What happens if the client's elapsed time exceeds the 498 maximum value that can be represented in the Elapsed Time option? 499 500 501 502 503Droms Expires October 7, 2003 [Page 9] 504 505Internet-Draft DHCPv6 Interoperability Testing April 2003 506 507 508 Discussion: The value 0xffff should be used to represent any elapsed 509 time value greater than the maximum time that can be represented 510 in the Elapsed Time option. 511 512 Resolution: Add the following sentence to the end of section 22.9: 513 514 The elapsed time value is an unsigned, 16 bit integer. The 515 client uses the value 0xffff to represent any elapsed time 516 values greater than the largest time value that can be 517 represented in the Elapsed Time option. 518 519 52013. Appearance of Elapsed Time option in DHCP messages 521 522 Issue: The table in Appendix A shows (incorrectly) that the Elapsed 523 Time option may appear in Advertise and Reply messages. 524 525 Discussion: A server should not include an Elapsed Time option in 526 Advertise and Reply messages. 527 528 Resolution: Edit the table in Appendix A. 529 530 53114. Acknowledgments 532 533 Thanks to Tatuya Jinmei for identifying many of these issues and for 534 contributing to the discussion and resolution of the issues. This 535 document was reviewed and discussed by Jim Bound, Ralph Droms, Tatuya 536 Jinmei, Ted Lemon, Ole Troan, Bernie Volz and Jun Xie. 537 538References 539 540 [1] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 541 Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 542 draft-ietf-dhc-dhcpv6-28 (work in progress), November 2002. 543 544 [2] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for 545 IP Version 6 (IPv6)", RFC 2461, December 1998. 546 547 548 549 550 551 552 553 554 555 556 557 558 559Droms Expires October 7, 2003 [Page 10] 560 561Internet-Draft DHCPv6 Interoperability Testing April 2003 562 563 564Author's Address 565 566 Ralph Droms 567 Cisco Systems 568 300 Apollo Drive 569 Chelmsford 01824 570 MA 571 572 Phone: +1 978.497.4733 573 EMail: rdroms@cisco.com 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615Droms Expires October 7, 2003 [Page 11] 616 617Internet-Draft DHCPv6 Interoperability Testing April 2003 618 619 620Full Copyright Statement 621 622 Copyright (C) The Internet Society (2003). All Rights Reserved. 623 624 This document and translations of it may be copied and furnished to 625 others, and derivative works that comment on or otherwise explain it 626 or assist in its implementation may be prepared, copied, published 627 and distributed, in whole or in part, without restriction of any 628 kind, provided that the above copyright notice and this paragraph are 629 included on all such copies and derivative works. However, this 630 document itself may not be modified in any way, such as by removing 631 the copyright notice or references to the Internet Society or other 632 Internet organizations, except as needed for the purpose of 633 developing Internet standards in which case the procedures for 634 copyrights defined in the Internet Standards process must be 635 followed, or as required to translate it into languages other than 636 English. 637 638 The limited permissions granted above are perpetual and will not be 639 revoked by the Internet Society or its successors or assigns. 640 641 This document and the information contained herein is provided on an 642 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 643 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 644 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 645 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 646 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 647 648Acknowledgement 649 650 Funding for the RFC Editor function is currently provided by the 651 Internet Society. 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671Droms Expires October 7, 2003 [Page 12] 672 673