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

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

Network Working Group                                           R. Droms
Internet-Draft                                             Cisco Systems
Expires: October 7, 2003                                   April 8, 2003


     Results from Interoperability Tests of DHCPv6 Implementations
                  draft-ietf-dhc-dhcpv6-interop-01.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on October 7, 2003.

Copyright Notice

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

Abstract

   This document publishes issues with the DHCPv6 protocols
   specifications, based on the results of interoperability testing
   among several implementations.

Introduction

   The DHCPv6 specification [1] has been accepted as a Proposed
   Standard, and several related specifications have been published and
   will soon be submitted to the IESG for review.  Several
   implementations of DHCPv6 have been completed, and these
   implementations have been tested for interoperability.




Droms                    Expires October 7, 2003                [Page 1]

Internet-Draft       DHCPv6 Interoperability Testing          April 2003


   The purpose of this document is to provide a published record of the
   issues discovered through interoperability testing, for review and
   discussion by the appropriate IETF working groups.

   A course of action to correct problems with the DHCPv6 specifications
   is proposed for many of the listed issues.  These changes will be
   made to the DHCPv6 specification prior to its publication as an RFC.

   The remainder of this documents lists specific issues, along with a
   summary of any discussion of the issue that has already occurred
   through e-mail and a proposed course of action to correct the issue.

   Throughout this document, unless otherwise qualified, section
   references and numbers refer to draft-ietf-dhc-dhcpv6-28.

1. Response of servers to Renew and Rebind messages, sections 18.2.3 and
   18.2.4

   Issue: Sections 18.2.3 and 18.2.4 have exactly the same sentence:

         If the server cannot find a client entry for the IA the server
         returns the IA containing no addresses with a Status Code
         option set to NoBinding in the Reply message.

      however, the semantics of "the server cannot find a client entry"
      is slightly different between the case of Renew and the case of
      Rebind.

   Discussion: A Renew message is sent to a specific server, which
      originally assigned the addresses in the IA.  If the server now
      does not have a record of the IA, it can authoritatively respond
      with a NoBinding Status Code.

      However, a Rebind message may be sent to more than one DHCP
      server, and the servers that did not originally assign the
      addresses in the IA may legitimately not have any record of the
      IA.  Therefore, in response to a Rebind message, the server should
      only respond if it can determine that the addresses are somehow
      invalid, and not respond if it simply has no record of the IA.

   Resolution: Leave the sentence in section 18.2.3 unchanged.  Replace
      the sentence in section 18.2.4 with the following text:

         If the server cannot find a client entry for the IA and the
         server determines that the addresses in the IA are not
         appropriate for the link to which the client's interface is
         attached according to the server's explicit configuration
         information, the server MAY send a Reply message to the client



Droms                    Expires October 7, 2003                [Page 2]

Internet-Draft       DHCPv6 Interoperability Testing          April 2003


         containing the client's IA, with the lifetimes for the
         addresses in the IA set to zero.  This Reply constitutes an
         explicit notification to the client that the addresses in the
         IA are no longer valid.  In this situation, if the server does
         not send a Reply message it silently discards the Rebind
         message.


2. Correctness of T1 and T2 parameters

   Issue: What should a client or server do if it receives an IA_NA in a
      message where T1 > T2 > 0?

   Discussion: A client should ignore the IA_NA with the invalid T1 and
      T2 values.  A server should ignore the invalid T1 and T2 values
      and process the IA_NA as though the client did not set those
      values.

   Resolution: Add the following paragraphs at the end of section 22.4,
      "Identity Association for Non-temporary Addresses Option":

         If a server receives an IA_NA with T1 greater than T2, and both
         T1 and T2 are greater than 0, the server ignores the invalid
         values of T1 and T2 and processes the IA_NA as though the
         client had set T1 and T2 to 0.

         If a client receives an IA_NA with T1 greater than T2, and both
         T1 and T2 are greater than 0, the client discards the IA_NA
         option and processes the remainder of the message as though the
         server had not included the invalid IA_NA option.


3. Receipt of a Request message for an existing binding

   Issue: What should a server do when it receives a Request message
      that contains an IA for which the server already has a binding
      associating the IA with the requesting client (this can happen if
      the first Reply from a client is lost and the client resends the
      Request message)?

   Discussion: The server either updates the parameters and sends a new
      Reply or sends a cached copy of the previous Reply.

   Resolution: Add the following paragraph at the end of section 18.2.1:

       If the server finds that the client has included an IA in the
         Request message for which the server already has binding that
         associates the IA with the client, the client has resent a



Droms                    Expires October 7, 2003                [Page 3]

Internet-Draft       DHCPv6 Interoperability Testing          April 2003


         Request message for which it did not receive a Reply message.
         The server either resends a previously cached Reply message or
         sends a new Reply message.


4. Client response to receipt of Reply with IA containing Status Code of
   NoAddrsAvail

   Issue: Section 18.1.8 describes the client's behavior:

         When the client receives a NoAddrsAvail status from the server
         in response to a Request, the client can either try another
         server (perhaps restarting the DHCP server discovery process)
         or use the Information-Request to obtain configuration
         parameters only.

      What does the client do if it receives more than one IA, and some
      IAs have been assigned addresses, while other IAs have been
      returned with status NoAddrsAvail?

   Discussion: The client should examine and process each IA
      individually.

   Resolution: Replace the text in question with:

         The client examines the status code in each IA individually.
         If the status code is NoAddrsAvail, the client has received no
         usable addresses in the IA and may choose to try obtaining
         addresses for the IA from another server.  The client uses
         addresses and other information from any IAs that do not
         contain a Status Code option with the NoAddrsAvail code.  If
         the client receives no addresses in any of the IAs, it may
         either try another server (perhaps restarting the DHCP server
         discovery process) or use the Information-request message to
         obtain other configuration information only.


5. Client processing of an IA option that does not include all addresses
   sent by the client

   Issue: Section 18.1.3 says:

         The client includes an IA option with all addresses currently
         assigned to the IA in its Renew message.

      and Section 18.2.3 has corresponding sentence:

         If the server finds that any of the addresses are not



Droms                    Expires October 7, 2003                [Page 4]

Internet-Draft       DHCPv6 Interoperability Testing          April 2003


         appropriate to the link to which the client is attached, the
         server returns the address to the client with lifetimes of 0.

      If the server finds the addresses in the IA for the client then
      the server sends back the IA to the client with new lifetimes and
      T1/T2 times.  The server may choose to change the list of
      addresses and the lifetimes of addresses in IAs that are returned
      to the client.  That is,:

      *  the client sends all addresses for an IA to be renewed.

      *  (if the binding is still valid) the server returns all the
         addresses for the IA with 0 or larger lifetimes.

      What does the client do if an address it sent to the server is not
      included in the IA in the Reply message from the server?

   Discussion: The client leaves addresses in its IA, leaving the
      lifetimes on those addresses unchanged.  The client then discards
      the addresses when their lifetimes expire.

   Resolution: Add the following item to the bullet list in section
      18.1.8:

         - Leave unchanged any information about addresses the client
         has recorded in the IA but that were not included in the IA
         from the server

      Add the following text to the end of the last paragraph of section
      10:

         Additionally, when the valid lifetime for an address in an IA
         expires, the client MUST remove the address from the IA.


6. Receipt of Reply with Rapid Commit option after sending Request

   Issue: Section 17.1.4 says:

         If it does not receive such a Reply message and does receive a
         valid Advertise message, the client processes the Advertise
         message as described in section 17.1.3.

      What should the client do if it receives a Reply message for a
      Solicit message with a Rapid Commit option after SOL_TIMEOUT has
      expired and the client has sent a Request message?  Should the
      client ignore or accept it?  In the latter case, what happens if
      the client has already sent a Request message (for which it will



Droms                    Expires October 7, 2003                [Page 5]

Internet-Draft       DHCPv6 Interoperability Testing          April 2003


      receive a different Reply message)?

   Discussion: The client can either discard the Reply message or
      process the Reply message and discard any subsequent Reply
      messages received in response to the Request message.

   Resolution: Add the following text to the end of section 17.1.4:

         If the client subsequently receives a valid Reply message that
         includes a Rapid Commit option, it either:

            processes the Reply message as described in section 18.1.8,
            and discards any Reply messages received in response to the
            Request message

            processes any Reply messages received in response to the
            Request message and discards the Reply message that includes
            the Rapid Commit option


7. Inconsistent or incorrect text in section 15

   Issue: Text in section 15 is inconsistent, ambiguous and incorrect.

   Discussion: For example, in section 15.6:

         Servers MUST discard any received Renew message that meets any
         of the following conditions:

         +  the message MUST include a Server Identifier option

         +  the contents of the Server Identifier option MUST match the
            server's identifier

         +  ...

      However, there is a wording problem.  The first sentence should
      read:

         Servers MUST discard any received Renew message that fails to
         meet any of the following conditions:

   Resolution: Review and reword appropriate text in section 15 for
      consistency and correctness.







Droms                    Expires October 7, 2003                [Page 6]

Internet-Draft       DHCPv6 Interoperability Testing          April 2003