Subject: [dhcwg] comments on draft-ietf-dhc-dhcpv6-27.txt

From: Richard Hussong <[email-masked]>
Date: Tue, 29 Oct 2002 16:42:44 -0500

To: Ralph Droms <[email-masked]>

I have some comments on the new DHCPv6 draft.  I think the changes have
improved its clarity quite a bit, but I still see a few problems.
Actually, some of these were in the previous draft; I'm sorry I didn't find
them there and bring them to your attention, but I haven't been on this
stuff for long.

First, a general comment:  since IPv6 has stateless address
auto-configuration, and small routers are becoming increasingly common,
even in homes, isn't it possible, even likely, that the main use of DHCPv6
will be for prefix delegation rather than address assignment?  If this is
the case, it seems unfortunate that prefix delegation is not in this
document, since that fact makes it appear that it is of lower status or
importance than the address assignment that is in the document.  I am sure
there are sound historical reasons for putting prefix delegation in a
separate document (including the controversy over whether prefix delegation
should be handled by DHCPv6 at all), but there are so many parallels
between address assignment and prefix delegation that it seems a shame not
to treat them in a parallel fashion.

The rest of the comments are on particular sections of the draft.

=============

Section 1.3, "Client-server Exchanges Involving Four Messages"

Typo in Paragraph 2: "the client sends a Renew messages ..."; "messages"
should be "message".

=============

Section 16. Client Source Address and Interface Selection

Typo in Paragraph 1: "... is certain the two interface are ...";
"interface" should be "interfaces".

=============

Section 17.1.1. Creation of Solicit Messages

In Paragraph 4:

  The client MUST include an Option Request option (see section 22.7)
  to indicate the options the client is interested in receiving.

This states that the Option Request option is required in a Solicit
message.  However, Section 22.7 says:

  A client MAY include an Option Request option in a Solicit, Request,
  Renew, Rebind, Confirm or Information-request message to inform
  the server about options the client wants the server to send to
  the client.

This implies that the Option Request option is not required in a Solicit
message.

Should the server treat a Solicit message without an Option Request option
as invalid?  If the client includes instances of particular options without
listing their codes in the Option Request option, should those options be
ignored?

=============

Section 17.1.1. Creation of Solicit Messages

In Paragraph 5:

  The client MUST include a Reconfigure Accept option (see
  section 22.20) indicating whether or not the client is willing to
  accept Reconfigure messages from the server.

This states that the Reconfigure Accept option is required in a Solicit
message.  However, Section 22.20 says:

  The default behavior, in the absence of this
  option, means unwillingness to accept Reconfigure messages, or
  instruction not to accept Reconfigure messages, for the client and
  server messages, respectively.

This implies that the Reconfigure Accept option is not required in a
Solicit message.

Should the server treat a Solicit message without a Reconfigure Accept
option as invalid?

=============

Section 18.1.5. Creation and Transmission of Information Request Messages

In Paragraph 5:

  The first Information-request message from the client on the interface
  MUST be delayed by a random amount of time between 0 and INF_MAX_DELAY.

It is not specified what event defines the start of the delay period.  I
imagine the intent is that the delay starts from the "interface up" event.
Is that true, and would there be any value in making it explicit?

=============

Section 18.1.8. Receipt of Reply Messages

Paragraph 3, bullet 4:

    -  Discard any addresses from the IA as recorded by the client that
       have a lifetime of 0 in the IA Address option

Just for clarity, perhaps "lifetime" should be "valid lifetime"?

=============

Section 18.2.8. Transmission of Reply Messages

Typo in Paragraph 2: "see Section!22.10" should be "see Section 22.10".

=============

Section 22.4. Identity Association for Non-temporary Addresses Option

In the next-to-last paragraph,

  In a message sent by a server to a client, the client MUST use the
  values in the T1 and T2 fields for the T1 and T2 parameters.

However, in the last paragraph,

   If the time at which the addresses in an IA_NA are to be renewed is
   to be left to the discretion of the client, the server sets T1 and T2
   to 0.

I suspect the intent of the extract from the next-to-last paragraph is
something like "In a message sent by a server to a client, the client MUST
use the values in the T1 and T2 fields for the T1 and T2 parameters, unless
they are 0", right?

=============

Section 22.6. IA Address Option

In Paragraph 3:

  In a message sent by a server to a client, the client MUST use
  the values in the preferred and valid lifetime fields for the
  preferred and valid lifetimes.

Just for clarity, it might be useful to note here than a valid lifetime
field value of 0 has the special meaning of "stop using this address", even
though that is the natural consequence of a valid lifetime of 0.  It would
be even handier if a cross-reference were included to Section 18.1.8, which
discusses the Reply message that might actually use such 0 lifetime values.

=============

Section 22.6. IA Address Option

Typo in Paragraph 3: "More than one IA Address Options can appear";
"Options" should be "Option".

=============

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

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Tue, 29 Oct 2002 16:19:43 -0600

Richard:

Thanks for the corrections ...

The prefix delegation came after much of the core work on the DHCPv6 protocol was far
along. And, as it is still debated as to how best to accomplish this, we felt it best
to keep it out of the base specification.

Regarding 18.1.5, see 17.1.2 as this explains the delay start. Perhaps we should add
a reference to 17.1.2 here or cut and paste the text. If a -28 is done (or during the
RFC editing process assuming the IESG accepts this draft), we will look to clarify
this (and the other corrections).

Regarding 17.1.1 and 22.7 (ORO option), I think we can change it to a SHOULD for the
Solicit message. I don't see that this is a MUST. (Section 15.2 does not indicate that
no ORO means drop the message.)

Regarding 17.1.1 and Reconfigure Accept option, this is an error and should be modified
to read that the option is included only if the client desires to have the server make
use of Reconfigure. At one time this option contained a flag byte which indicated whether
Reconfigure was or was not supported and this was not properly updated then the option
was changed.

Regarding the issue with Section 22.4, a T1/T2 of 0 means don't renew. It is client
implementation specific as to how it deals with this (whether it uses 0 to mean don't
renew and don't start a timer) or does something else (such as using very large values).

- Bernie

-----Original Message-----
From: Richard Hussong [mailto:[email-masked]]
Sent: Tuesday, October 29, 2002 4:43 PM
To: [email-masked]
Subject: [dhcwg] comments on draft-ietf-dhc-dhcpv6-27.txt

=============

=============

=============

In Paragraph 4:

=============

In Paragraph 5:

=============

In Paragraph 5:

=============

Paragraph 3, bullet 4:

=============

=============

=============

In Paragraph 3:

=============

=============

- Richard Hussong