draft-ietf-dhc-dhcpv6-interop-00.txt

DHCPv6协议在Linux操作系统下的一个客户端实现。

8. Typographic error regarding MRC in section 18.1.6

   Issue: In the following line of Section 18.1.6:

         MRC   REL_MAX_MRC

      should be:

         MRC   REL_MAX_RC

   Resolution: Correct typo in section 18.1.6.


9. Inconsistent lifetimes for an address

   Issue: What should a client or server do if the preferred lifetime is
      larger than the valid lifetime for an IA address option in a reply
      message (to request/renew, etc)?  Similarly, suppose either T1 or
      T2 is larger than the shortest preferred lifetime in the IA?

   Discussion: A client discards any addresses for which the preferred
      lifetime is larger than the valid lifetime.  It is acceptable for
      T1 or T2 to be larger than a preferred or valid lifetime when the
      server does not expect to extend the lifetime of that address in
      the future.  A server ignores any invalid or inconsistent
      lifetimes or values for T1 and T2 and processes the IA as though
      the client had not set those invalid or inconsistent values.

      In a related matter, the text in section 22.4 that gives
      recommended values for T1 and T2 should be clarified to indicate
      that T1 and T2 should be based on shortest lifetime of any address
      that the server intends to extend in the future.

   Resolution: Add the following paragraph before the next-to-last
      paragraph of section 22.6 (bottom of page 65 in draft-ietf-dhc-
      dhcpv6-28.txt):

         A client discards any addresses for which the preferred
         lifetime is greater than the valid lifetime.  A server ignores
         the lifetimes set by the client if the preferred lifetime is
         greater than the valid lifetime and ignores the values for T1
         and T2 set by the client if those values are greater than the
         preferred lifetime.

      Change the second sentence of the last paragraph of section 22.4
      to:

         Recommended values for T1 and T2 are .5 and .8 times the



Droms                    Expires August 23, 2003                [Page 7]

Internet-Draft       DHCPv6 Interoperability Testing       February 2003


         shortest preferred lifetime of the addresses in the IA that the
         server is willing to extend, respectively.


10. "Infinity" as a time value

   Issue: Should DHCPv6 have a notion of "infinity" as lifetimes and
      T1/T2 values?  In RFC2461 [2], 0xffffffff is taken to mean
      "infinity".  If DHCPv6 intends to be consistent with that meaning,
      there should be an explicit definition somewhere in the
      specification.

   Discussion: DHCPv6 should treat 0xffffffff as "infinity" in the case
      of time values.  In section 22.4, the recommendations for values
      of T1 and T2 need to be clarified for the case when the lifetimes
      of the addresses in an IA are 0xffffffff.

   Resolution: Add section 5.6:

         5.6 Representation of time values and "Infinity" as a time
         value

            All time values for lifetimes, T1 and T2 are unsigned
            integers.  The value 0xffffffff is taken to mean "infinity"
            when used as a lifetime (as in RFC2461 [17]) or a value for
            T1 or T2.

         Add the following sentence after the sentence in the last
         paragraph of section 22.4 that begins "Recommended values...":

            If the "shortest" preferred lifetime is 0xffffffff
            ("infinity"), the recommended T1 and T2 values are also
            0xffffffff.

         Add the following paragraph at the end of section 22.4:

            Care should be taken in setting T1 or T2 to 0xffffffff
            ("infinity").  A client will never attempt to extend the
            lifetimes of any addresses in an IA with T1 set to
            0xffffffff.  A client will never attempt to use a Rebind
            message to locate a different server to extend the lifetimes
            of any addresses in an IA with T2 set to 0xffffffff.

         Add the following paragraph before the next-to-last paragraph
         of section 22.6 (bottom of page 65 in draft-ietf-dhc-dhcpv6-
         28.txt, after the paragraph added in Section 9 of this
         document):




Droms                    Expires August 23, 2003                [Page 8]

Internet-Draft       DHCPv6 Interoperability Testing       February 2003


            Care should be taken in setting the valid lifetime of an
            address to 0xffffffff ("infinity"), which amounts to a
            permanent assignment of an address to a client.


11. Client behavior in response to receipt of Reply message with
    StatusCode set to NoBinding

   Issue: In section 18.1.8, it's not clear if the client should
      continue to send Renew/Rebind messages as well as send a Request
      message in response to a Reply with a Status Code set to
      NoBinding.

   Discussion: For each IA in the original Renew/Rebind, the client
      should:

      *  send a Request if the StatusCode in the IA is NoBinding

      *  send a Renew/Rebind if the IA is not in the Reply

      *  accept the response if the IA is in the Reply and there is no
         status code

   Resolution: Change the text in the corresponding (third-to-last)
      paragraph in section 18.1.8 to read:

         When the client receives a Reply message in response to a Renew
         or Rebind message, the client examines each IA independently.
         For each IA in the original Renew or Rebind message, the
         client:

         +  sends a Request message if the StatusCode in the IA is
            NoBinding (and does not send any additional Renew/Rebind
            messages)

         +  sends a Renew/Rebind if the IA is not in the Reply message

         +  otherwise accepts the information in the IA


12. Maximum value for Elapsed Time option

   Issue: The value carried in the Elapsed Time option is an unsigned,
      16 bit integer with a resolution of 1/100 of a second.  The
      maximum time that can be represented in this format is roughly 11
      minutes.  What happens if the client's elapsed time exceeds the
      maximum value that can be represented in the Elapsed Time option?




Droms                    Expires August 23, 2003                [Page 9]

Internet-Draft       DHCPv6 Interoperability Testing       February 2003


   Discussion: The value 0xffff should be used to represent any elapsed
      time value greater than the maximum time that can be represented
      in the Elapsed Time option.

   Resolution: Add the following sentence to the end of section 22.9:

         The elapsed time value is an unsigned, 16 bit integer.  The
         client uses the value 0xffff to represent any elapsed time
         values greater than the largest time value that can be
         represented in the Elapsed Time option.


13. Appearance of Elapsed Time option in DHCP messages

   Issue: The table in Appendix A shows (incorrectly) that the Elapsed
      Time option may appear in Advertise and Reply messages.

   Discussion: A server should not include an Elapsed Time option in
      Advertise and Reply messages.

   Resolution: Edit the table in Appendix A.


14. Acknowledgments

   Thanks to Tatuya Jinmei for identifying many of these issues and for
   contributing to the discussion and resolution of the issues.  This
   document was reviewed and discussed by Jim Bound, Ralph Droms, Tatuya
   Jinmei, Ted Lemon, Ole Troan, Bernie Volz and Jun Xie.

References

   [1]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
        Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
        draft-ietf-dhc-dhcpv6-28 (work in progress), November 2002.

   [2]  Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
        IP Version 6 (IPv6)", RFC 2461, December 1998.













Droms                    Expires August 23, 2003               [Page 10]

Internet-Draft       DHCPv6 Interoperability Testing       February 2003


Author's Address

   Ralph Droms
   Cisco Systems
   300 Apollo Drive
   Chelmsford  01824
   MA

   Phone: [phone]
   EMail: [e-mail]









































Droms                    Expires August 23, 2003               [Page 11]

Internet-Draft       DHCPv6 Interoperability Testing       February 2003


Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Droms                    Expires August 23, 2003               [Page 12]