Subject: Re: [dhcwg] unresolved comments in dhcpv6-25

From: Ralph Droms <[email-masked]>
Date: Wed, 05 Jun 2002 00:02:18 -0400

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ralph Droms <[email-masked]>
Date: Wed, 05 Jun 2002 00:34:52 -0400

Responses to your other comments:

   15. What if a client receives a reconfigure message but none of the
       configuration information was provided by the server (that sends
       the reconfigure)?  What if only a part of the configuration
       information was provided by the server?  Section 19.3.1 is not
       clear (enough) about the cases.

Are you asking what the client should do if the server's Reply message
doesn't include all the configuration information specified by the
client in the Request or Information-request message?

   16. (Relevant to the comment 12 above) Section 19.3.1 says

	the client
	ignores any additional Reconfigure messages (regardless
	of the transaction ID in the Reconfigure message) until
	the exchange is complete.  Subsequent Reconfigure messages
	(again independent of the transaction ID) cause the client
	to initiate a new exchange.

   But, according to Section 19.1.1, the transaction ID should always be
   0.  So I don't get the rationale about the wording here.  Does this
   simply mean the client should always ignore the transaction-ID?  If
   so, it seems to me more natural to say so explicitly.

You are correct; wording fixed.

   17. Section 21.5.2 says

      A DHCP message MUST NOT contain more than one Authentication option
      when using the delayed authentication protocol.

   Then, what if a received message contains more than one Authentication
   option?  Ignore the entire message, ignore the authentication options
   (but a particular one), or others?

Added text to section "Message Validation":

   Any DHCP message that includes more than one authentication option
   MUST be discarded.

   (an editorial comment) we need some additional white space in this
   paragraph:

      ...
      in the DHCP message to facilitate processing of the authentication
      information.The format of the Authentication...

   after "information".

Fixed (deleted sentence specifying placement of authentication
option).

   18. Section 21.5.3 says

      receiver computes the MAC as described in [9].  The entire DHCP
      message (except the MAC field of the authentication option itself),
      is used as input to the HMAC-MDS computation function.

   This is not very clear to me.  Does this mean we should regard the MAC
   field as an all-0 field when computation?

Text about MAC field in MAC computation has been clarified.

   19. We need a closing parenthesis in the first sentence of Section
       21.5.5.4:

      If the server has selected a key for the client in a previous message
      exchange (see section 21.5.6.1, the client MUST use the same key
      to generate the authentication information.

   The appropriate point should be after "21.5.6.1".

Fixed.

   20. Section 22.5 says

      An identity association for temporary addresses option MUST NOT
      appear in a Renew or Rebind message.

   What should the receiving node do if this condition is broken?

IA_TA now allowed in Renew or Rebind; DHCP allows lifetimes of
temporary addresses to be extended.

   21. Section 22.14 specifies to use a UTF-8 encoded text string, but it
       seems to me too much.  I think a simple ascii text is enough.
       (However, this may be based on a consensus of a former discussion,
       and if so, I don't oppose to the result.)

The DHC WG as settled on UTF-8 for text strings like this...

   22. Section 22.17 says

      A DHCP message MUST NOT contain more than one Vendor Class option.

   What should the receiving node do if this condition is broken?

   23. Section 22.18 says

      A DHCP message MUST NOT contain
      more than one Vendor-specific Information option with the same
      Enterprise Number.

   What should the receiving node do if this condition is broken?

(See below)

   24. Section 22.19 says

      This option MUST NOT
      appear in any message except a Relay-Forward or Relay-Reply message.

   What should the receiving node do if this condition is broken?  (This
   question should be extended in a general form; "what should the
   receiving node do if an option is included in a message in which the
   option MUST NOT be appeared?")

In general, the decision about how to proceed with messages that don't
adhere to the rules about option inclusion - for example, if the
message includes more than one Vendor-specific Information option with
the same Enterprise number - is a policy decision for the DHCP
server.

---

From: "Raymond Jayaraj" <[email-masked]>
Date: Wed, 5 Jun 2002 15:03:02 +0800

Hi guys,

>             configuration information for a client is indexed by

Sorry to barge in like this; but we're also hot on the heels of
implementing (and verifying) DHC6, and would like to confirm if:

By the change in the definition as above, a node can use stateless
(RA) address(es) yet maintain (RENEW/REBIND applies) stateful,
address-unrelated, context/configuration (e.g. roaming, security,
qos, billing, mobility etc.) information with the network via DHC6?

We've been trying to figure out other ways to accomplish this, but
always end up with sub-optimal methods.

It would be neat if DHC6 can be extended to this end; then there
won't be need to define additional edge access / "network session"
protocols - just more DHC6 options (IMHO).

Raymond Jayaraj
Institute For Communications Research
Agency For Science, Technology & Research
Singapore.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 10 Jun 2002 14:47:56 +0900

>>>>> On Wed, 05 Jun 2002 00:34:52 -0400, 
>>>>> Ralph Droms <[email-masked]> said:

> client in the Request or Information-request message?

Sorry, perhaps I was just confused when writing the question.  Please
forget it.  BTW, the first sentence of 19.3.1 seems to have a typo:

   Upon receipt of a valid Reconfigure message, the client initiates a
   transaction with the server by sending a Reply or Information-request
   message.

Shouldn't the "Reply" be "Renew"?  (this may have been fixed in the
local copy of the latest revision).

> the same Enterprise number - is a policy decision for the DHCP

Okay, if this is noted in the draft explicitly, I'm fine with it.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 10 Jun 2002 14:26:30 +0900

Hello, thanks for the response,

>>>>> On Wed, 05 Jun 2002 00:02:18 -0400, 

> described in this response.

I cannot get www.dhcp.org/draft-26.txt, but I'm basically fine with

> servers." to each of the DISCUSSION paragraphs explaining the use of

Perhaps the added sentence is okay, but it still seems to talk about
benefits of using unicast, not about when the server should or can use
unicast.

> had incorrect configuration information about two interfaces being on

Sorry, I don't understand the response.  Section 17.2.2 talks about
server's behavior, and I don't get why the restriction on the server
side can solve the client's issue.

					JINMEI, Tatuya

---

From: Ralph Droms <[email-masked]>
Date: Mon, 10 Jun 2002 06:13:51 -0400 (EDT)

I apologize for the typo - the draft is available at
www.dhcp.org/dhcpv6-26.txt

- Ralph

---

From: SHIRASAKI Yasuhiro <[email-masked]>
Date: Mon, 10 Jun 2002 19:31:29 +0900 (JST)

> the responses.  A few points to clarify:

It might be:

http://www.dhcp.org/dhcpv6-26.txt

--
SHIRASAKI Yasuhiro @ NTT Communications

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 11 Jun 2002 14:30:20 +0900

> described in this response.

I've checked the latest snapshot.  The followings are supplement
comments based on the latest one.

> option in the Option Request option), containing the desired option

I'm not sure if the current text (which is same as previous ones) can
read like this.  I can live with the current wording, but would be
happier if the text says this point more clearly.

(snip)

> only if the client included IA options in the Solicit message.

Is this really true?  The latest one just says

   If the server will not assign any addresses to any 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
   code NoAddrsAvail, a status message for the user, a Server Identifier
   option with the server's DUID and a Client Identifier option with the
   client's DUID.

I can't read this to mean that AddrUnavail is limited to the case
where IAs are in Solicit.

BTW: there seems to be some confusion about status code names.  The
latest snap uses "NoAddrsAvail", not "AddrUnavail".  The latter one is
actually used nowhere except in Section 24.4 (a summary list of status
codes).  If AddrUnavail was deprecated, it should be removed from the
list IMO.

The same comment applies to ConfNoMatch.

> The phrase "invalid addresses" has been clarified.

Hmm, the current text says:

   The server ignores addresses not
   assigned to the IA, and it may make a notification if it finds such
   an address.

But my main point is not addressed; what if the source address of the
release message is contained in an IA of the message (where the source
address was assigned to the IA)?  Again, please note 18.1.6 has a
corresponding restriction:

   The client MUST NOT use any of the addresses it is releasing as
   the source address in the Release message or in any subsequently
   transmitted message.

					JINMEI, Tatuya