Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt

[神明達哉 <[e-mail]>]

At Wed, 9 Jul 2014 17:07:40 +0000,
"Bernie Volz (volz)" <[e-mail]> wrote:

> Yes, #2 is our hope.

>> The nuance is subtle here, so please let me be sure: which one is
>> (more) correct?
>> 2. this draft intends to be applicable to future possible IA_XXs,
>>    even if this is currently just a hope (since we don't know the
>>    future possibilities right now) and may turn out to be infeasible.

Okay, on top of that, this is my comments on the draft body (finally):

- Title: maybe we should change it from "issues", since it's not an
  issue statement (anymore) but actually proposes specific protocols.

- General: as briefly discussed separately, I think this document
  should also describe how the client should handle a Reply to various
  types of messages based on the revised behavior, with specific
  revised text against Section 18.1.8 of RFC 3315.  I now understand
  it's included in the plan but is not simply realized in this
  version, but I'm explicitly mentioning it here so it won't be
  forgotten.  (it would be a good idea to have an "open issues"
  appendix section for such stuff)

- General: as we discussed separately, some of the updates proposed in
  the draft break backward compatibility.  It may or may not be
  justified (I myself am not really sure about it; I'll need to think
  about it more), but at least I think the draft should summarize
  incompatible changes with discussion of how it's justified.

- General: the generalization attempt doesn't seem to be complete; in
  some cases the proposed revised text still only talks about
  addresses or prefixes, rather than general "resources".  I'll point
  out some of such cases below, but they are not comprehensive.

- Introduction: I'd suggest clarifying the intended coverage (the '#2'
  above) in the introduction section.

- Introduction (or in some new section): as discussed separately, this
  draft imposes some assumption on the definition and usage of
  (especially future) IAs:
  + they should have T1/T2 values (with the only exception of IA_TA)
  + all IAs should share the same set of T1/T2.  This also means that
    it's less likely that we can define a (future) IA that expects
    extremely shorter/longer T1/T2 (e.g. years or microseconds) in
    usual operations than other IAs
  + resources managed in an IA should have some kind of "lifetime".
  I'd suggest clarifying these assumptions more explicitly somewhere
  in the document.

- Section 1: as long as we choose to include IA_TA in the
  consideration, this sentence looks awkward to me:

   IA_TA also has limited value when DHCPv6 is used for address
   assignment, as the privacy issues identified for IPv6 stateless
   address assignment ([RFC4941]) do not apply to DHCPv6 assignments.

  What is stated may (or may not) be true itself, but seems to be an
  orthogonal topic (it would be very relevant, on the other hand, if
  we are excluding IA_TA and try to justify it).

- Section 3: as I read the draft I felt a bit confused about the
  difference between "resource" and "stateful options".  In some cases
  I saw the former (latter) is used where the latter (former) may be a
  better choice.  Maybe we can unify these?  I'll point out some
  specific cases where I felt the confusion below.

- Section 3: s/An example/Examples/ or s/are/is/
                                   stateful options.  An example of the
                                   resources are: IPv6 address or an

- Section 3: I don't understand what this refers to:
                                   (see "identity association
                                   for temporary addresses").

- Section 4.1: this is not necessarily accurate, since NoBinding is
  used for all current IAs (and could also be used for future ones as
  its concept is quite generic):

   While a Status Code option is implicitly bound to a specific type of
   IA,

- Section 4.1: s/addresses/some stateful option types/ so the
  description is generic?

   With the introduction of multiple IA option
   types, there might be a case where a server is not willing to offer
   addresses, but might be willing to offer other stateful option types.

  BTW, I wonder whether "resources" may be better than "stateful
  option (types)" in this context (see above).

- Section 4.1: this sentence should probably be generalized:

   Clients MUST be prepared to handle each of the following Advertise
   messages formats when there are no addresses available (even when no
   IA_PD was in the Solicit):

  e.g. by avoiding to use "addresses" or "IA_PD".

- Section 4.2: this text should probably be generalized (not
  hardcoding "address" etc)

   With (this includes the changes made by [RFC7083]):

     The client MUST ignore any Advertise message that contains no
     addresses (IAADDR options encapsulated in IA_NA or IA_TA options)
     [...]

- Section 4.2: maybe this should be generalized:

   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.

- Section 4.3: regarding this behavior:

   Proposed solution: [...]  To deal
   with the case where servers have not yet been updated to do that,
   clients MUST use the shortest (explicit or implicit) T1/T2 timer
   (larger than 0) in any IA options in the Reply.  Longer T1/T2 timers
   are ignored.

  what should happen if we have two sets of T1/T2?
  - T1a = 10, T2a = 20
  - T1b = 0, T2b = 5
  If we pick up the shortests (> 0), T1 would be 10 and T2 would be
  5, which is an invalid combination.

- Section 4.4.1: this change seems to be too substantial.  I'm not
  necessarily opposed to it, but I cannot be immediately sure if this
  doesn't have any unexpected bad effect.  Besides, what if the server
  finds it can't create any such binding?  Should it return  NoBinding
  just like the old RFC 3315?

   Replace Section 18.2.3 of RFC 3315:
   [...]
   With:

      If the server cannot find a client entry for the IA the server
      creates the bindings for that client according to the server's
      policy and configuration information and returns the IAs and other
      information requested by the client.

- Section 4.4.3: this paragraph is awkward in this context as it
  describes the server behavior in the context of describing the
  client behavior (Creation and Transmission of Renew):

   The server controls the time at which the client contacts the server
   to extend the lifetimes on client's bindings through the T1 and T2
   [...]

- Section 4.4.3: why SHOULD?  can't (shouldn't) this be a MUST?

   The server SHOULD assign the same T1 and
   T2 value to each binding assigned to the client.  In this case the

- Section 4.4.3: this paragraph seems to say that a client may send
  a Renew/Rebind for IA_TA.  Is that intent?  If so, is it a good
  idea?

   If T1 or T2 is set to 0 by the server for all IA_NA and IA_PD
   options, or there are no T1 or T2 times (for an IA_TA), the client
   may send Renew or Rebind message, respectively, at the client's
   discretion.

- Section 4.4.3: I don't understand why (and actually I'm not really
  sure what this sentence really tries to say):
   The client constructing a Renew message SHOULD NOT include resources
   in IA options that the client does not have.

- Section 4.4.3: this paragraph assumes resource for any (future) IAs
  has *multiple* lifetimes.  While it would probably be reasonable to
  assume resource for an IA generally has "a" lifetime, I'm not so
  sure if it always have multiple lifetimes (for IA_NA, they are valid
  and preferred lifetimes.  They are very specific to the nature of
  IPv6 addresses).  The same comment applies to some other parts of
  the draft, but basically I won't repeat it.

   If the server finds that any resource sent by the client is not
   appropriate, according to the server's configuration information, the
   server sends back the IA with the corresponding IA Address (for
   inappropriate address), IA Prefix option (for inappropriate prefix)
   or other option appropriate for the type of the resource, with
   lifetimes set to 0.  The client which receives the option with
   lifetimes set to 0 MUST NOT use the corresponding resource.

- Section 4.5.1: is it okay for the Rebind case?  Rebind can be
  handled multiple servers, so multiple servers could end up with
  creating bindings.

     If the server cannot find a client entry for the IA and the IA is
     empty (i.e. contains no addresses), the server MAY assign the
     addresses to this IA and send a Reply message to the client with
     this IA containing allocated addresses with lifetimes and T1/T2
     times.
  (BTW: "addresses" should probably be generalized)

- Section 4.5.2: this should probably be generalized (and we might
  revisit the term "*valid* lifetimes", see the next bullet).  Also,
  what if there are multiple IAs?  Should this continue until all
  resource lifetimes of all IAs expire?  Or should it stop when all
  resource lifetimes of some of the IAs expire (maybe the first time
  it happens)?

      MRD     Remaining time until valid lifetimes of all addresses or
              prefixes in the IA have expired

- Section 4.5.2: this even assumes resource for any (future) IA has a
  "valid" lifetime.  Isn't it too specific for a generic specification?

   The message exchange is terminated when the valid lifetimes of all
   the resources assigned to the IA expire, at which time the client has
   several alternative actions to choose from; for example:

- Section 4.5.2: related to the comment about the MRD above, what if the
  client has multiple IAs?
   -  The client may choose to use a Solicit message to locate a new
      DHCP server and send a Request for the expired IA to the new
      server.
  If the client does this for one IA while (resources of)  other IAs
  still not expired and keeps sending Rebinding for them, doesn't the
  client end up having multiple DHCPv6 sessions (which this draft
  tries to avoid)?

- Section 4.5.4: maybe "of RFC 3315" should be appended, to be
  consistent with other part of the text:

   The server includes other options containing configuration
   information to be returned to the client as described in section
   18.2.

- Section 4.7: just wondering: does this describe some specific
  existing client implementation?

   Some clients will send a Release message for other bindings they may
   have received after they determine a conflict and have correctly sent
   a Decline message for the conflicting address(es).

--
JINMEI, Tatuya