[dhcwg] comments and qeustions on dhcpv6-24

[JINMEI Tatuya / 神明達哉 <[e-mail]>]

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
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[e-mail]

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


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