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