Subject: Re: [dhcwg] some comments and questions on dhcpv6-24

From: Ralph Droms <[email-masked]>
Date: Mon, 13 May 2002 10:37:09 -0400

Thanks for your review - I apologize for the delay in replying, and we'll 
take your comments into account when we edit the next rev of the draft.

- Ralph

At 05:24 PM 4/26/2002 +0900, JINMEI Tatuya / 
=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
>I have some comments and questions on the latest I-D of DHCPv6,
>draft-ietf-dhc-dhcpv6-24.txt.
>
>15.10. Reply message
>
>    Clients MUST discard any received Reply messages that meet any of the
>    following conditions:
>
>     -  the message does not include a Server Identifier option
>
>     -  the "transaction-ID" field in the message does not match the
>        value used in the original message
>
>     -  the message does not include a Client Identifier option and the
>        original message from the client contained a Client Identifier
>        option
>
>     -  the message includes a Client Identifier option and the contents
>        of the Client Identifier option does not match the DUID of the
>        client
>
>What if the message includes a Client Identifier option but the client
>did not send the option in the corresponding request?

The message should be rejected if it includes a Client Identifier option
and the client did not include the option in its original message.

>17.2.2. Creation and transmission of Advertise messages
>
>    ... The Advertise message MUST
>    be unicast through the interface on which the Solicit message was
>    received.
>
>It seems to me the requirement is too strong.  Is this really
>necessary?

It's necessary if the server received the Solicit directly from the client; 
i.e., if the server and the client are on the same link and the server is 
sending the Advertise to the client's link-local address.

>18.2.5. Receipt of Information-request messages
>
>    The server contructs a Reply message by setting the "msg-type" field
>               ^^^^^^^^^this should be "constructs".  There are many
>other "contructs" in the draft.

This problem was fixed between preliminary publication of the -24
rev and the final version published at the IETF.

>    to REPLY, copying the transaction ID from the Rebind message into the
>                                                  ^^^^^^
>    transaction-ID field.
>
>Should the "Rebind" message be "Information-request"?  This sentence
>seems to be just copied from the previous section...

This problem was fixed between preliminary publication of the -24
rev and the final version published at the IETF.

>    The server MUST include a Server Identifier option containing the
>    server's DUID and the Client Identifier option from the Rebind
>                                                            ^^^^^^
>    message in the Reply message.
>
>Again, should the "Rebind" be "Information-request"?

This problem was fixed between preliminary publication of the -24
rev and the final version published at the IETF.

>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.

Yes, we should make that clarification.

>   - 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 will add text clarifying that an Information-request containing IA options
is discarded.

>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.

OK, we'll make that consistency check.

>                                         JINMEI, Tatuya
>                                         Communication Platform Lab.
>                                         Corporate R&D Center, Toshiba Corp.
>                                         [email-masked]
>
>
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 13 May 2002 16:57:43 +0900

>>>>> On Mon, 13 May 2002 16:02:06 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> I've just gone thorough dhcpv6-24, and have some comments and
> questions on it.

I forgot to add one last (editorial) comment:

Section 25.6 contains unnecessary slash characters:

   UseMulticast    7 Sent by a server to a client to force the
                     client to send messages to the server
                     using the All\_DHCP\_Relay\_Agents\_and\_Servers
                     address

This should be just "All_DHCP_Relay_Agents_and_Servers".

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 13 May 2002 16:02:06 +0900

I've just gone thorough dhcpv6-24, and have some comments and
questions on it.  Since most of them are just for clarification or
editorial comments, I've put all of them into this message.  If we
need to discuss some of them separately, please make another thread for
the particular items.

I've also checked recent discussions on the list based on comments
from Thomas and tried to avoid duplicated comments (actually I have
one.)  I'd apologize in advance, if there is still any duplication.

					JINMEI, Tatuya

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.

2. Section 15.13. says

   Clients MUST discard any received Relay-forward messages.

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

3. Section 16. repeatedly says like

   When a client sends a DHCP message to the DHCP_Anycast address, it
   MUST use an address assigned to the interface for which the client
   is interested in obtaining configuration,...

I think requiring the client to use an address on the particular
"interface" is too strong (though it should be the typical case).  The
source address MUST be on the "link" to which the interface being
configured belongs, since the server may use the information to detect
the client's link, but does not necessarily have to be on the exact
interface.  Using the term "link" instead of "interface" is also
consistent with the last paragraph of this section.

Also, I don't get why the "default address selection" draft is
cited here.  If this is just because the draft describes the generic
mechanism to select source addresses, I don't think we need to cite it
explicitly here.

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...".

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.

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.

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.

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.

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.)

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.

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.

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?

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?

14. In the first sentence of Section 19.3

   A client MUST accept Reconfigure messages sent to UDP port 546on...

we need a white space after "546".

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.

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.

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?

(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".

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?

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".

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?

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.)

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?

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?")

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 14 May 2002 10:18:45 +0900

>>>>> On Mon, 13 May 2002 10:37:09 -0400, 
>>>>> Ralph Droms <[email-masked]> said:

> sending the Advertise to the client's link-local address.

I understand that, but as I said in the succeeding message, I think
the "link" (not "interface") is more accurate.  Requiring to send a
particular "interface" is overspecification from a strict
scope-architecture point of view.  Also, using the word "link" is
consistent with the wording in Section 16.

> rev and the final version published at the IETF.

Okay, but where can I get the "final version"?  The -24 draft at
ftp://ftp.ietf.org/internet-drafts has the same problems.

					JINMEI, Tatuya

---

From: Ralph Droms <[email-masked]>
Date: Tue, 14 May 2002 05:46:46 -0400

At 10:18 AM 5/14/2002 +0900, JINMEI Tatuya / 
>consistent with the wording in Section 16.

You're correct - we can reuse the wording of section 16 here.

>ftp://ftp.ietf.org/internet-drafts has the same problems.

Sorry - the version at ftp.ietf.org is the "final version".  I missed that 
the "Rebind"->"Information-request" goof was not fixed...

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 16 May 2002 03:16:39 +0900

I have some additional comments (and questions) on dhcpv6-24,
particularly about server solicitation.

(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.

(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?

(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?

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 16 May 2002 14:41:01 +0900

Section 18.2.1 of dhcpv6-24 says:

On the other hand, section 15.10 says

(snip)

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?

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 31 May 2002 01:14:30 +0900

(Sorry for the long attachments)

I've checked the draft dhcpv6-25 and found that most of my comments to
the 24 draft was not addressed in the latest draft.  Namely:

- the "other questions" part of the first message
- all comments except 3 and 14 in the second message
- the comments 1 and 2 in the third message
- the comment in the fourth message

Some of the unresolved comments have been responded in this list, but
it seems to me that the responses have not been reflected in the
latest draft.  Most of them are even not responded at all.

Perhaps the reason is just because the comments and questions are so
trivial and neglected.  But, even so, I'd like to hear a short
response like "they are trivial and does not have to be considered in
the draft".

Thanks,

					JINMEI, Tatuya

Subject: [dhcwg] some comments and questions on dhcpv6-24
From: JINMEI Tatuya / 神明達哉 <[email-masked]>
To: [email-masked]
Date: Fri, 26 Apr 2002 17:24:23 +0900
List-Id: <dhcwg.ietf.org>

15.10. Reply message

					JINMEI, Tatuya

Subject: [dhcwg] comments and qeustions on dhcpv6-24
From: JINMEI Tatuya / 神明達哉 <[email-masked]>
To: [email-masked]
Date: Mon, 13 May 2002 16:02:06 +0900
List-Id: <dhcwg.ietf.org>

					JINMEI, Tatuya

1. Section 4.1. defines

2. Section 15.13. says

4. Section 17.1. says

5. Section 17.1.1. says

   The client MAY include

6. Section 17.1.3 says

10. Section 18.2.1 says

      the client

17. Section 21.5.2 says

   ...

after "information".

18. Section 21.5.3 says

20. Section 22.5 says

22. Section 22.17 says

23. Section 22.18 says

24. Section 22.19 says

   This option MUST NOT

Subject: [dhcwg] additional comments on dhcpv6-24
From: JINMEI Tatuya / 神明達哉 <[email-masked]>
To: [email-masked]
Date: Thu, 16 May 2002 03:16:39 +0900
List-Id: <dhcwg.ietf.org>

(2) Section 17.1.2 says:

      RT = 2*IRT + RAND*IRT

					JINMEI, Tatuya

Subject: [dhcwg] [dhcpv6] UseMulticast
From: JINMEI Tatuya / 神明達哉 <[email-masked]>
To: [email-masked]
Date: Thu, 16 May 2002 14:41:01 +0900
List-Id: <dhcwg.ietf.org>

					JINMEI, Tatuya