Re: [dhcwg] unresolved comments in dhcpv6-25

Thanks for your careful review and helpful comments.  We've
reviewed your comments and included our responses in line
below.  www.dhcp.org/draft-26.txt reflects the changes
described in this response.

- Ralph

=====
   Message 1:
   ----------
   Other questions to this section:
     - what should the receiving server do if the Information-request
       contains a client Identifier option?  I think the server MUST
       copy the option to the reply, but the draft does not mention this
       case.
     - what should the receiving server do if the Information-request
       contains an IA option?  Section 18.1.5 says that:
         The client MUST NOT include any IA options.
       But none of this section and Section 15.12 mention this case.

We've fixed these specific problems.

   BTW: there seem to me several cases for this type of incompleteness.
   For example, Section 22.6 says "The IA Address option must be
   encapsulated in the Options field of an Identity Association option."
   But I'm not sure what a node should do when it receives an IA address
   option not encapsulated in an IA option.  I've not gone through the
   entire draft, so I may miss something, and if so, I'd apologize in
   advance.  If my guess is correct, however, then I'd suggest to check
   the consistency of the requirements over the entire draft.

The "UnSpecFail" status code is available to indicate a problem with
the DHCP option where the action for that problem is not specifically
described in the doc.

   Message 2:
   ----------
   1. Section 4.1. defines

         binding                   A binding (or, client binding) is a
                                   group of server data records containing
                                   the information the server has about
                                   the addresses in an IA and any other
                                   configuration information assigned to
                                   the client.  A binding is indexed by
                                   the tuple <DUID, IA-type, IAID> (where
                                   IA-type is the type of address in the
                                   IA; for example, temporary)

   Is it always appropriate to contain "IA-TYPE" and "IAID" in the index
   of a binding?  What if a configuration information (that needs a
   binding) is not associated with an IA?  An IPv6 prefix delegated by
   DHCPv6 can be an example of such binding.

Changed definition of binding to:

  binding   A binding (or, client binding) is a group of server data
            records containing the information the server has about
            the addresses in an IA or configuration information
            assigned to the client.  A binding containing
            information about an IA is indexed by the tuple <DUID,
            IA-type, IAID> (where IA-type is the type of address in
            the IA; for example, temporary).  A binding containing
            configuration information for a client is indexed by
            <DUID>.

   2. Section 15.13. says

      Clients MUST discard any received Relay-forward messages.

   What if a relay agent receives a relay-forward message?

We have added new text that addresses "chaining" of relay agents; that
is, the ability of one relay agent to send a relay-forward message to
another relay agent.

   4. Section 17.1. says

      A client uses the Solicit message to discover DHCP servers configured
      to serve addresses on the link to which the client is attached.

   The wording is too specific.  Since the client may just need other
   information than addresses, the text should be like "DHCP servers
   configured to server addresses or other configuration
   parameters...".

Right; fixed...

   5. Section 17.1.1. says

      The client MAY include
      options with data values as hints to the server about parameter
      values the client would like to have returned.

   I'm not sure how the data values are specified.  An option request
   option can only specify required option "types"...

   The same comments applies to Sections 18.1.1 and 18.1.5.

The client includes the requested option (rather than indicating the
option in the Option Request option), containing the desired option
value.

   6. Section 17.1.3 says

      The client MUST ignore any Advertise message that includes a Status
      Code option containing the value AddrUnavail, with the exception that
      the client MAY display the associated status message to the user.

   and Section 17.2.2 has a corresponding text:

      If the server will not assign any addresses to IAs in a subsequent
      Request from the client, the server MUST send an Advertise message to
      the client that includes only a status code option with the status
      code set to AddrUnavail and a status message for the user.

   With the specification, it seems to me that a client cannot configure
   itself without getting addresses (except via information-request and
   reply exchanges).  For example, suppose that a client wants to be
   delegated an IPv6 prefix from a provider, and sends a solicit without
   any IA option.  The server is configured to delegate prefixes only
   (i.e. not addresses), so it sends an Advertise message with an
   AddrUnavail code.  Since the client MUST ignore the advertise message,
   it cannot proceed any more.

   So, the specification should be clearer on the procedure when a client
   does not need addresses.

Text in 17.2.2 clarified to specify that server returns AddrUnavail
only if the client included IA options in the Solicit message.

   7. What if a reply message for a solicit with a rapid commit option
      does *not* contain a rapid commit option?  Section 17.2.3 says that
      the server includes a Rapid Commit option in the Reply message, but
      Section 17.1.4 says nothing about the case if the rapid commit
      option is not included.

Added a sentence requiring a client to discard any Reply messages that
do not include a Rapid Commit option.

   8. It is not very clear when a server includes a Server Unicast
      option.  Section 18.1.1 (and some succeeding sections) says

         Use of multicast or anycast on a link and relay agents
         enables the inclusion of relay agent options in all messages
         sent by the client.  The server should enable the use of
         unicast only when relay agent options will not be used.

     But, this only talks about some restrictions of including the
     option.  Even with the text of section 22.13, I'm still not sure
     when a server should or can send a Server Unicast option.  It
     would be better to describe the allowed (or necessary) cases
     explicitly.

Added the sentence: "Use of unicast may avoid delays due to forwarding
of messages by relay agents as well as avoid overhead and duplicate
responses by servers due to delivery of client messages to multiple
servers." to each of the DISCUSSION paragraphs explaining the use of
the Unicast option.

   9. (I've once pointed it out, but I'll do it again) Section 17.2.2
      says

      If the Solicit message was received directly by the
      server,...The Advertise message MUST be unicast through the
      interface on which the Solicit message was received.

     Technically, the requirement is too strong, since links are larger
     than interfaces according to the IPv6 scoped address architecture.
     So, more accurately, it should say "The Advertise message MUST be
     unicast through the link on which the Solicit message was received."
     (Also see the last paragraph of Section 16.)

We used the more specific requirement to avoid the problem of a client
sending a DHCP message on an incorrect interface because the client
had incorrect configuration information about two interfaces being on
the same link.

   10. Section 18.2.1 says

      When the server receives a Request message via unicast from a
      client to which the server has not sent a unicast option, the server
      discards the Request message and responds with a Reply message
      containing a status code option with value UseMulticast and no other
      options.

   I'm not sure how the client should act when it receives the reply
   message.  Should it resend the request to multicast?  Should it
   restart the entire procedure from the solicit?  At least Section
   18.1.6 should mention this case.

   The same comment applies to Sections 18.2.3, 18.2.6, and 18.2.7.

Fixed with the following text:

    When the client receives a Reply message with a Status Code
    UseMulticast option, the client records the receipt of the
    message and sends subsequent messages through that interface using
    multicast. The client resends the original message using multicast.

   11. Section 18.2.6 says "The server ignores invalid addresses."  What
       does "invalid" exactly mean?  In particular, I'm not sure if the
       source address of the receipt message is "invalid" or not (note
       that section 18.1.7 prohibits the client to use addresses being
       released as the source address).  The text should clearly define
       the term "invalid".

   The same comment applies to Section 18.2.7.

The phrase "invalid addresses" has been clarified.

   12. Section 19.1.1 says "The server sets the transaction-id field to
       0".  But I could not found description about the case where the
       client receives a reconfigure message with a non-0 transaction-id.
       Should it discard the message, or should it ignore the non-0
       value, or others?

Added sentence specifying that the client ignores the transaction-id
field in received Reconfigure messages.

   13. Why doesn't the timeout and retransmission rule in Section 19.1.2
       follow the general rules described in Section 14?  Is there
       something special for reconfigure messages?

The randomization is not required as Reconfigure messages won't be
synchronized by some external event.

   Message 3:
   ----------
   (1) If the client sent a solicit message with a rapid commit option
       but the server responds to the solicitation with an advertise
       message, what should the client do?  Should it ignore the
       advertise, should it accept the advertise and send a request, or
       others?  Section 17.1.4 says

        ...If the client does not
        receive a Reply message, the client restarts the server solicitation
        process by sending a Solicit message that does not include a Rapid
        Commit option.

      So, the client should probably ignore the advertise (and keep
      waiting for a reply.)  But I'm not 100% sure about this.

Section 17.1.4 is clarified to allow a client to use an Advertise
message in this case if it receives no Reply with a Rapid Commit
option.

   (2) Section 17.1.2 says:

      If the client is waiting for an Advertise message, the mechanism in
      section 14 is modified as follows for use in the transmission of
      Solicit messages.  The message exchange is not terminated by the
      receipt of an Advertise before IRT has elapsed.  Rather, the client
      collects Advertise messages until IRT has elapsed.

   Should this rule apply if the client is retransmitting solicit
   messages?  For example, suppose that there is no advertise in response
   to the first solicit, and so the client retransmit the solicit.  If
   the client then receives a first advertise, should it still wait until
   IRT elapses?

A couple of paragraphs farther down in 17.1.2 is this text:

    If the client does not receive any Advertise messages before
    the first RT has elapsed, it begins the retransmission mechanism
    described in section 14.  The client terminates the retransmission
    process as soon as it receives any Advertise message, and the client
    acts on the received Advertise message without waiting for any
    additional Advertise messages.

This text is intended to address the question you raise.

   (3) The paragraph above then says:
      Also, the first
      RT MUST be selected to be strictly greater than IRT by choosing RAND
      to be strictly greater than 0.

   However, according to Section 13, the first RT should be

         RT = 2*IRT + RAND*IRT

   where RAND is a random number chosen with a uniform distribution
   between -0.1 and +0.1.  Thus,

         RT >= 2*IRT - 0.1*IRT = 1.9 * IRT >= IRT
         (the rightmost '=' is satisfied only when IRT is 0)

   So the RT should always be greater than IRT regardless of the value of
   RAND, and "by choosing RAND to be strictly greater than 0" seems to be
   redundant.  Is my understanding correct?

The initial choice of RT included a typo; it should (and now does)
read:

    RT = IRT + RAND*IRT

   Message 4:
   ----------
   Section 18.2.1 of dhcpv6-24 says:

       When the server receives a Request message via unicast from a
       client to which the server has not sent a unicast option, the server
       discards the Request message and responds with a Reply message
       containing a status code option with value UseMulticast and no other
       options.

    On the other hand, section 15.10 says

        -  the message does not include a Server Identifier option
    (snip)
        -  the message does not include a Client Identifier option and the
           original message from the client contained a Client Identifier
           option

    Those two requirements seem to be inconsistent, or at least be
    confusing.  Should the reply message contain the Server Identifier
    option (and the Client Identifier option if the original message
    contained it) in the Reply even if the server is responding with a
    status code option with UseMulticast?  Or should the client loosen the
    validation in 15.10 if the reply contains a status code option?  Or
    others?

Clarified to allow additional options; paragraph now reads:

    When the server receives a Request message via unicast from a
    client to which the server has not sent a unicast option, the server
    discards the Request message and responds with a Reply message
    containing a Status Code option with value UseMulticast, a Server
    Identifier option containing the server's DUID, the Client Identifier
    option from the client message and no other options. 

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg