1 2 3Network Working Group R. Droms 4Internet-Draft Cisco Systems 5Expires: August 23, 2003 February 22, 2003 6 7 8 Results from Interoperability Tests of DHCPv6 Implementations 9 draft-ietf-dhc-dhcpv6-interop-00.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 August 23, 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 August 23, 2003 [Page 1] 56 57Internet-Draft DHCPv6 Interoperability Testing February 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. Any changes to the 66 specifications will be published to the appropriate working group 67 mailing lists. 68 69 The remainder of this documents lists specific issues, along with a 70 summary of any discussion of the issue that has already occurred 71 through e-mail and a proposed course of action to correct the issue. 72 73 Throughout this document, unless otherwise qualified, section 74 references and numbers refer to draft-ietf-dhc-dhcpv6-28. 75 761. Response of servers to Renew and Rebind messages, sections 18.2.3 and 77 18.2.4 78 79 Issue: Sections 18.2.3 and 18.2.4 have exactly the same sentence: 80 81 If the server cannot find a client entry for the IA the server 82 returns the IA containing no addresses with a Status Code 83 option set to NoBinding in the Reply message. 84 85 however, the semantics of "the server cannot find a client entry" 86 is slightly different between the case of Renew and the case of 87 Rebind. 88 89 Discussion: A Renew message is sent to a specific server, which 90 originally assigned the addresses in the IA. If the server now 91 does not have a record of the IA, it can authoritatively respond 92 with a NoBinding Status Code. 93 94 However, a Rebind message may be sent to more than one DHCP 95 server, and the servers that did not originally assign the 96 addresses in the IA may legitimately not have any record of the 97 IA. Therefore, in response to a Rebind message, the server should 98 only respond if it can determine that the addresses are somehow 99 invalid, and not respond if it simply has no record of the IA. 100 101 Resolution: Leave the sentence in section 18.2.3 unchanged. Replace 102 the sentence in section 18.2.4 with the following text: 103 104 If the server cannot find a client entry for the IA and the 105 server determines that the addresses in the IA are not 106 appropriate for the link to which the client's interface is 107 attached according to the server's explicit configuration 108 109 110 111Droms Expires August 23, 2003 [Page 2] 112 113Internet-Draft DHCPv6 Interoperability Testing February 2003 114 115 116 information, the server MAY send a Reply message to the client 117 containing the client's IA, with the lifetimes for the 118 addresses in the IA set to zero. This Reply constitutes an 119 explicit notification to the client that the addresses in the 120 IA are no longer valid. In this situation, if the server does 121 not send a Reply message it silently discards the Rebind 122 message. 123 124 1252. Correctness of T1 and T2 parameters 126 127 Issue: What should a client or server do if it receives an IA_NA in a 128 message where T1 > T2 > 0? 129 130 Discussion: A client should ignore the IA_NA with the invalid T1 and 131 T2 values. A server should ignore the invalid T1 and T2 values 132 and process the IA_NA as though the client did not set those 133 values. 134 135 Resolution: Add the following paragraphs at the end of section 22.4, 136 "Identity Association for Non-temporary Addresses Option": 137 138 If a server receives an IA_NA with T1 greater than T2, and both 139 T1 and T2 are greater than 0, the server ignores the invalid 140 values of T1 and T2 and processes the IA_NA as though the 141 client had set T1 and T2 to 0. 142 143 If a client receives an IA_NA with T1 greater than T2, and both 144 T1 and T2 are greater than 0, the client discards the IA_NA 145 option and processes the remainder of the message as though the 146 server had not included the invalid IA_NA option. 147 148 1493. Receipt of a Request message for an existing binding 150 151 Issue: What should a server do when it receives a Request message 152 that contains an IA for which the server already has a binding 153 associating the IA with the requesting client (this can happen if 154 the first Reply from a client is lost and the client resends the 155 Request message)? 156 157 Discussion: The server either updates the parameters and sends a new 158 Reply or sends a cached copy of the previous Reply. 159 160 Resolution: Add the following paragraph at the end of section 18.2.1: 161 162 If the server finds that the client has included an IA in the 163 Request message for which the server already has binding that 164 165 166 167Droms Expires August 23, 2003 [Page 3] 168 169Internet-Draft DHCPv6 Interoperability Testing February 2003 170 171 172 associates the IA with the client, the client has resent a 173 Request message for which it did not receive a Reply message. 174 The server either resends a previously cached Reply message or 175 sends a new Reply message. 176 177 1784. Client response to receipt of Reply with IA containing Status Code of 179 NoAddrsAvail 180 181 Issue: Section 18.1.8 describes the client's behavior: 182 183 When the client receives a NoAddrsAvail status from the server 184 in response to a Request, the client can either try another 185 server (perhaps restarting the DHCP server discovery process) 186 or use the Information-Request to obtain configuration 187 parameters only. 188 189 What does the client do if it receives more than one IA, and some 190 IAs have been assigned addresses, while other IAs have been 191 returned with status NoAddrsAvail? 192 193 Discussion: The client should examine and process each IA 194 individually. 195 196 Resolution: Replace the text in question with: 197 198 The client examines the status code in each IA individually. 199 If the status code is NoAddrsAvail, the client has received no 200 usable addresses in the IA and may choose to try obtaining 201 addresses for the IA from another server. The client uses 202 addresses and other information from any IAs that do not 203 contain a Status Code option with the NoAddrsAvail code. If 204 the client receives no addresses in any of the IAs, it may 205 either try another server (perhaps restarting the DHCP server 206 discovery process) or use the Information-request message to 207 obtain other configuration information only. 208 209 2105. Client processing of an IA option that does not include all addresses 211 sent by the client 212 213 Issue: Section 18.1.3 says: 214 215 The client includes an IA option with all addresses currently 216 assigned to the IA in its Renew message. 217 218 and Section 18.2.3 has corresponding sentence: 219 220 221 222 223Droms Expires August 23, 2003 [Page 4] 224 225Internet-Draft DHCPv6 Interoperability Testing February 2003 226 227 228 If the server finds that any of the addresses are not 229 appropriate to the link to which the client is attached, the 230 server returns the address to the client with lifetimes of 0. 231 232 If the server finds the addresses in the IA for the client then 233 the server sends back the IA to the client with new lifetimes and 234 T1/T2 times. The server may choose to change the list of 235 addresses and the lifetimes of addresses in IAs that are returned 236 to the client. That is,: 237 238 * the client sends all addresses for an IA to be renewed. 239 240 * (if the binding is still valid) the server returns all the 241 addresses for the IA with 0 or larger lifetimes. 242 243 What does the client do if an address it sent to the server is not 244 included in the IA in the Reply message from the server? 245 246 Discussion: The client leaves addresses in its IA, leaving the 247 lifetimes on those addresses unchanged. The client then discards 248 the addresses when their lifetimes expire. 249 250 Resolution: Add the following item to the bullet list in section 251 18.1.8: 252 253 - Leave unchanged any information about addresses the client 254 has recorded in the IA but that were not included in the IA 255 from the server 256 257 Add the following text to the end of the last paragraph of section 258 10: 259 260 Additionally, when the valid lifetime for an address in an IA 261 expires, the client MUST remove the address from the IA. 262 263 2646. Receipt of Reply with Rapid Commit option after sending Request 265 266 Issue: Section 17.1.4 says: 267 268 If it does not receive such a Reply message and does receive a 269 valid Advertise message, the client processes the Advertise 270 message as described in section 17.1.3. 271 272 What should the client do if it receives a Reply message for a 273 Solicit message with a Rapid Commit option after SOL_TIMEOUT has 274 expired and the client has sent a Request message? Should the 275 client ignore or accept it? In the latter case, what happens if 276 277 278 279Droms Expires August 23, 2003 [Page 5] 280 281Internet-Draft DHCPv6 Interoperability Testing February 2003 282 283 284 the client has already sent a Request message (for which it will 285 receive a different Reply message)? 286 287 Discussion: The client can either discard the Reply message or 288 process the Reply message and discard any subsequent Reply 289 messages received in response to the Request message. 290 291 Resolution: Add the following text to the end of section 17.1.4: 292 293 If the client subsequently receives a valid Reply message that 294 includes a Rapid Commit option, it either: 295 296 processes the Reply message as described in section 18.1.8, 297 and discards any Reply messages received in response to the 298 Request message 299 300 processes any Reply messages received in response to the 301 Request message and discards the Reply message that includes 302 the Rapid Commit option 303 304 3057. Inconsistent or incorrect text in section 15 306 307 Issue: Text in section 15 is inconsistent, ambiguous and incorrect. 308 309 Discussion: For example, in section 15.6: 310 311 Servers MUST discard any received Renew message that meets any 312 of the following conditions: 313 314 + the message MUST include a Server Identifier option 315 316 + the contents of the Server Identifier option MUST match the 317 server's identifier 318 319 + ... 320 321 However, there should be a wording problem. The first sentence 322 should read: 323 324 Servers MUST discard any received Renew message that fails to 325 meet any of the following conditions: 326 327 Resolution: Review and reword appropriate text in section 15 for 328 consistency and correctness. 329 330 331 332 333 334 335Droms Expires August 23, 2003 [Page 6] 336 337Internet-Draft DHCPv6 Interoperability Testing February 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 August 23, 2003 [Page 7] 392 393Internet-Draft DHCPv6 Interoperability Testing February 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 August 23, 2003 [Page 8] 448 449Internet-Draft DHCPv6 Interoperability Testing February 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 August 23, 2003 [Page 9] 504 505Internet-Draft DHCPv6 Interoperability Testing February 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 August 23, 2003 [Page 10] 560 561Internet-Draft DHCPv6 Interoperability Testing February 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 August 23, 2003 [Page 11] 616 617Internet-Draft DHCPv6 Interoperability Testing February 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 August 23, 2003 [Page 12] 672 673