Subject: [dhcwg] WGLC review of draft-ietf-dhc-dhcpv6-stateful-issues

From: Ted Lemon <[email-masked]>
Date: Mon, 15 Dec 2014 14:35:40 -0500

Aside from this rather voluminous set of nits and comments, the document looks good and I support advancing it.   Thanks for the hard work on this.   I will become less and less available between now and 1/5, so please don't delay updating the document while waiting for a response from me.   I will review whatever comments follow when I get back as part of what I assume will be a request for publication.

My comments/nits:

The abstract is a bit colloquial and contains references to other documents that I don't think are necessary to understand what this document does, and actually prevent people who don't already know what the document does from quickly figuring it out.   I'm a bit on the warpath about long abstracts: they should really be the elevator pitch for your document.   Suggestion:

OLD:
   Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written
   with the expectation that additional stateful DHCPv6 options would be
   developed.  IPv6 Prefix Options for Dynamic Host Configuration
   Protocol (DHCP) version 6 has since shoe-horned a new option for
   Prefix Delegation into DHCPv6.  Implementation experience of the CPE
   model described in RFC 7084 has shown multiple issues with the DHCPv6
   protocol in supporting multiple stateful options.  This document
   updates RFC 3315 and RFC 3633 to address the identified issues.

NEW:
   The DHCPv6 specification defines two stateful options, IA_NA
   and IA_TA, but does not anticipate the development of additional
   stateful options.  DHCPv6 Prefix Delegation adds the IA_PD option,
   which is stateful.  Applications that use IA_NA and IA_PD
   together have revealed issues that need to be addressed.  This
   document updates RFC 3315 and RFC 3633 to address these issues.

In the introduction, don't use "shoe-horned."   Just say "added."   The RFC editor would probably ding you on this, but I'm saying it now in hopes that more people will read this review than would read the interaction with the RFC editor.   Colloquialisms make documents harder to read for anyone who is not familiar with the colloquialism, which is at present the majority of readers of RFCs.

OLD:
   This document describes a number of problems encountered with
   coexistence of the IA_NA and IA_PD option types and changes to the
   DHCPv6 protocol specifications to address these problems.
NEW:
   This document describes a number of problems encountered with
   coexistence of the IA_NA and IA_PD option types and specifies 
   changes to the DHCPv6 protocol to address these problems.

(making it a compound sentence instead of a sentence with a compound phrase makes it less ambiguous and hence easier to understand.)

This doesn't make sense:
   DHCPv6 assigned temporary addresses also
   have limited value when DHCPv6 is used for non-temporary address
   assignment, as the privacy issues identified for IPv6 stateless
   address assignment ([RFC4941]) do not apply to DHCPv6 assignments.

The expected use of IA_TA is that you would acquire temporary addresses and a non-temporary address; the temporary addresses are used for outgoing connections; the non-temporary address is used for incoming connections and is optionally entered in the DNS.   As long as the host enforces the separate uses of temporary and non-temporary addresses, it all works: an off-network listener will not know that the IA_TA and IA_NA addresses belong to the same host.   That's a big if, but that's not our problem.

I think the gist of this paragraph is correct, but the sentence above is incorrect and should just be deleted.  I also think IA_TA is completely out of scope for this document, not just mostly out of scope, for the reason stated in the first sentence in the paragraph.   I notice that IA_TA is referenced throughout the document as equivalent to IA_NA; if indeed the assertion here is correct, then it shouldn't be mentioned again in the document.   I think that would make the document a bit clearer.

Maybe make the second sentence a bulleted list:

   If a client requests multiple IA option types, but the server is
   configured to only offer a subset of them, the client could react in
   several ways.  Reset the state machine and continue to send Solicit
   messages, create separate DHCP sessions for each IA option type and
   continue to Solicit for the unfulfilled IA options, or it could
   continue with the single session, and include the unfulfilled IA
   options in subsequent messages to the server.

The case mentioned in the second sentence would happen whenever such a broken client is on a network with no DHCP server.   Does it really need to be mentioned here?

   Reseting the state machine and continuing to send Solicit messages
   may result in the client never completing DHCP and is generally not
   considered a good solution.  It can also result in a request storm if
   the client does not appropriately rate limit its sending of Solicit
   messages.

OLD:
   This leaves a single DHCP session and state machine which is the
   proposed solution.  Here, the client can use what it is able to
   obtain and can continue to request what it was previously unable to
   obtain while maintaining a single session and state machine.

   Proposed solution: the client should keep a single session with the
   server and include the missing options in subsequent messages
   (Request, Renew, and Rebind) to the server.
NEW:
   We have chosen the remaining option: a single DHCP session and state
   machine.  The client maintains a single session and state machine.
   It uses the best configuration it is able to obtain during any
   configuration exchange.   But it continues, in each subsequent
   configuration exchange, to request all the configuration information
   it is programmed to try to obtain, including any stateful configuration
   options for which no results were returned in previous exchanges.

In 4.1 paragraph 1 you use the terms "encapsulation" and "top level".   These should be defined in the glossary, ideally by referring to their definitions either in RFC3315, if possible, or in RFC 7227, which has a really good discussion in section 9 on the topic of encapsulation, although it doesn't explicitly hit on the topic of "top level" options.   Actually, the term top level is used but not defined in 7227, and vaguely referenced, but never named nor discussed explicitly that I can see in 3315, so this should just be explained in the glossary.  I would say something like this:

   Top Level options
      Top level options are DHCPv6 options that are not encapsulated
      within other options, excluding the Relay-Message option.   Options
      encapsulated by Relay-message options, but not by any other option,
      are still top-level options, whether they appear in a relay agent
      message or a server message.

If this is an update to a standard, then we have chosen a solution--we aren't just proposing one.  The phrasing you are using here would be appropriate in an experimental doc, but (ironically) is not appropriate in a proposed standard:

OLD:
   Therefore, the proposed solution is:
NEW:
   We have chosen the following solution:

However, this seems like it's part of the update.   Is there a place in RFC 3315 where this could be said to be added?   This is clearly normative text.

I don't think this is quite right:

     -  The client MAY choose a less-preferred server if that server
        has a better set of advertised parameters, such as the
        available options advertised in IAs.

I suggest:

     -  The client MAY choose a less-preferred server if that server
        has a better set of advertised parameters, such as the
        available set of IAs, as well as the set of non-IA options
        advertised.

You could leave out the final dependent clause if you like, but I think the way I've restated it is closer to combining what was previously intended with what you need to change.

Shouldn't the following text be normative?

   It is important to note that the receipt of an Advertise message
   without any addresses and delegated prefixes does not imply that the
   client should restart the Solicit retransmissions timers.  Doing so
   would lead to a Solicit/Advertise storm.

There's quite a bit of text in subsequent sections that looks something like this:

   Proposed solution: The server MUST set the T1/T2 times in all IA

The same comment I made earlier applies here.   You should just substitude "Solution: " in place of "Proposed Solution" in each of these instances.

This is really confusing, so I suggest changing it:
OLD:
     To extend the valid and preferred lifetimes for the addresses
     associated with an IA, the client sends a Renew message to the
     server from which the client obtained the addresses in the IA
     containing an IA option for the IA.  The client includes IA Address
     options in the IA option for the addresses associated with the IA.
     The server determines new lifetimes for the addresses in the IA
     according to the administrative configuration of the server.  The
     server may also add new addresses to the IA.  The server may remove
     addresses from the IA by setting the preferred and valid lifetimes
     of those addresses to zero.
NEW:
     To extend the valid and preferred lifetimes for the addresses
     assigned to an IA, the client sends a Renew message to the
     server from which the addresses were obtained,
     which includes an IA option for the IA whose whose address
     lifetimes are to be extended.  The client includes IA Address
     options within the IA option for the addresses assigned to the IA.
     The server determines new lifetimes for these addresses
     according to the administrative configuration of the server.  The
     server may also add new addresses to the IA.  The server can remove
     addresses from the IA by returning IA Address options for such
     addresses with preferred and valid lifetimes set to zero.

I think this is bad advice:

     If T1 or T2 had been set to 0 by the server (for an IA_NA) or there
     are no T1 or T2 times (for an IA_TA) in a previous Reply, the
     client may send a Renew or Rebind message, respectively, at the
     client's discretion.

Can the client send a Renew or Rebind after zero seconds?   That would be at its discretion, but obviously bad.   I think the right advice is to say that the client should choose a renew and rebind interval that is consistent with the valid and preferred times of all the addresses and prefixes received: if there are addresses and/or prefixes with preferred times, then the renewal and rebind times should result in those addresses and/or prefixes being renewed well before the preferred lifetime expires; if there are addresses with preferred lifetimes of zero, but residual valid lifetimes, these should not be renewed.   That might be too complicated for this document, though--if you prefer, you could just say "at the client's discretion, but no sooner than X," but then we'd have to argue about what X should be.

I think the following is unclear.   I've proposed a clearer version that I think says what was intended, but it was unclear, so I don't know if I correctly understood what was intended.   Also, I think this applies to Renew and Rebind messages, according to the preceding text, so the specific mention of Reply messages seems wrong, and I left it out of my proposed text:

OLD:
     The client includes an IA option with all addresses currently
     assigned to the IA in its Renew message.  The client also includes
     IA options for all other bindings for which the client desires to
     extend the lifetimes of addresses.  The client MUST only include
     addresses in the IA that the client obtained from the server and
     are still valid (have non-zero lifetime).
NEW:
     For IAs to which addresses have been assigned, the client includes
     a corresponding IA option containing an IA Address option for each
     address assigned to the IA.   For IAs to which prefixes have been
     assigned, the client includes a corresponding IA option containing
     an IA Prefix option for each prefix assigned to the IA.   The client
     MUST NOT include addresses or prefixes in any IA option that the
     client did not obtain from the server or that are no longer valid
     (that have have a zero valid lifetime).

You'll probably get a DISCUSS on this:

     If the client receives a Reply message with a Status Code
     containing UnspecFail, the server is indicating that it was unable
     to process the message due to an unspecified failure condition.  If
     the client retransmits the original message to the same server to
     retry the desired operation, the client MUST limit the rate at
     which it retransmits the message and limit the duration of the time
     during which it retransmits the message.

You really need to say something about how this rate limiting is done, or else it's too vague to really be meaningful.   For example, the client could send no more frequently than every thirty seconds, and on a small network this would be no problem, but it would be absolutely nuts on a really big network.

In the following text, I am left wondering on what basis the client should choose between the two alternatives:

     The client uses addresses and other information from any IAs that
     do not contain a Status Code option with the NoAddrsAvail code.
     For each IA for which the client receives NoAddrsAvail status code
     the client has the following choices:

     -  The client includes the IA with no addresses in subsequent Renew
        and Rebind messages sent to the server, to request creation of
        the binding for the IA.

     -  Tries another server (by restarting the DHCP server discovery
        process).

I think it's that if the client can't continue to operate without the resource it's trying to renew, it will choose to restart the process; if it can, it doesn't restart the process.   Also, does this text apply just to addresses, or also to prefixes?

What if the server has no record that it sent a unicast option, but is configured to support unicast?

     When the server receives a Renew message via unicast from a client
     to which the server has not sent a unicast option, the server
     discards the Renew message and responds with a Reply message

In 4.6, it might be worth adding that the client should treat the failure to acquire an address as a result of a DaD conflict to be equivalent to not having received that address, insofar as it determined how it behaves when renewing/rebinding/confirming.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 18 Dec 2014 03:48:20 +0000

Ted:

Thanks for your careful review (and to the others that provided comments, we are being to work through these).

I do have some comments  (I have not yet had an opportunity to review the issues with Marcin):

For 4.4.3, your comment:

Applies to text which we did not change and was copied directly from RFC 3315. While I think the original assumption agrees with your thoughts, it clearly isn't written that way. But we are trying to minimize the fixes to 3315 here to those related to the issue. So, this one is better handled (if not already) in the RFC 3315bis work.

The same issue exists for the text in section 4.4.6 on which you commented - What if the server has no record that it sent a unicast option, but is configured to support unicast? We again can raise this as a ticket for RFC 3315bis.

And, in another comment regarding text in 4.4.3, you  suggested revised text for RFC 3315. But that text specifically includes PD related text which RFC 3315 does not have. So, adding that text would be rather strange? Your proposed text would be more appropriate for RFC 3315 bis work. Your text was, and the 2nd sentence is the issue related to PD.

NEW: For IAs to which addresses have been assigned, the client includes a corresponding IA option containing an IA Address option for each address assigned to the IA.   For IAs to which prefixes have been assigned, the client includes a corresponding IA option containing an IA Prefix option for each prefix assigned to the IA.   The client MUST NOT include addresses or prefixes in any IA option that the client did not obtain from the server or that are no longer valid (that have have a zero valid lifetime).

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Monday, December 15, 2014 2:36 PM
To: dhcwg
Subject: [dhcwg] WGLC review of draft-ietf-dhc-dhcpv6-stateful-issues

My comments/nits:

OLD:

NEW:

OLD:

This doesn't make sense:

OLD:

   Top Level options

OLD:

I suggest:

OLD:

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Dec 2014 07:25:46 -0500

On Dec 17, 2014, at 10:48 PM, Bernie Volz (volz) <[email-masked]> wrote:

Thanks for adding the 3315bis tickets.   I figured that was the right way to address the problem, but knew that if I didn't mention it during the review, I would forget.

> And, in another comment regarding text in 4.4.3, you  suggested revised text for RFC 3315. But that text specifically includes PD related text which RFC 3315 does not have. So, adding that text wou…

I see your point, but the problem is that _this_ document is trying to fix the problem that occurs when you have IA_NAs and IA_PDs in the same message.   So if you never mention IA_PDs, it seems to me that you haven't really fixed it, because your new text doesn't apply to IA_PDs.   Is your intention that the update for IA_NAs be sufficient, and that no changes are required for IA_PD?   I didn't look closely at 3633, so I would have missed that.