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

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

On Mon, Jun 30, 2014 at 9:55 AM, Bernie Volz (volz) <[e-mail]> wrote:

> Anyway, give the current draft a read and if there are concerns or questions (or you have a view on the issue), please send mail to the list ASAP.

Now, I'm going to make my complete review comments on the draft.  I'll
begin with a set of overall comments at a higher level.  I'll send
specific comments on the draft text separately.

With the understanding that this draft intends to specify the general
case of using multiple types of IAs including yet-to-define future
ones, I think it will need to discuss many more points.  For example:

- (forgetting IA_TA for now) it seems to assume all IAs have the
  concept of "T1" and "T2", and it always (or at least generally)
  makes sense to use the same T1/T2 values for all IAs for a specific
  DHCPv6 session.  Can we safely assume that?  May or may not be so,
  but even if so, I think such an assumption is explicitly noted.
- likewise, it seems to assume all IAs have the concept of
  "lifetimes".  Same discussion as the first bullet applies here.
- there seems to be some implicit assumption on the normal case
  operation, e.g.: in normal cases, a set of IAs that can be bound
  by servers is the same for all available servers; otherwise, the
  following case will cause a suboptimal situation for the client:
  + the client would like bindings for IA1 and IA2
  + server A can provide a binding for IA1 but not for IA2
  + server B can provide a binding for IA2 but not for IA1
  According to the approach described in the draft, the client should
  have a single DHCPv6 session for both IAs and choose either server A
  or B.  In either case the client can only get a binding for one of
  the two IAs; if the client can have separate DHCPv6 sessions for
  these IAs, it can get bindings for both IAs.  I'm not necessarily
  saying we shouldn't impose this assumption.  In fact, such an
  assumption would probably be reasonable in many cases in practice
  (would be certainly so for the mix of IA_NA and IA_PD).  But the
  assumption isn't obvious, so IMO we should explicitly clarify that
  (and, ideally, how we should consider when the assumption isn't met;
  whether we should declare it as out of scope, whether we should
  explicitly prohibit it using an RFC2119 keyword, etc).
- Similarly, it seems to be assumed that when a server could provide
  bindings for IA1 and IA2:
  + the server can provide bindings for both IA1 and IA2, or,
  + it can provide a binding for neither IA1 nor IA2.
  Otherwise, the following case will become suboptimal for the client:
  + the client would like bindings for IA1 and IA2
  + the server provides binding for IA1.  a binding for IA2 is
    temporarily unavailable.
  + the client will need to wait until T1 expires to get a binding
    for IA2, even if the binding is actually available immediately
    after the Request-Reply exchange.

And then there's the point of how to handle IA_TA.  In addition to the
mere fact that it doesn't have T1 and T2 (see above about the
assumptions), I suspect its nature of non-renewability makes the
situation complicated in more fundamental way.  Suppose a client wants
to get IA_TA and IA_NA (or any other IA_xx than IA_TA).  According to
the draft the client will have a single DHCPv6 session for both IAs
and (hopefully) get bindings for them.  Then, at time T1 (of IA_NA),
specifically what should the client do?  Just excluding IA_TA in the
renew message?  Maybe this is okay, but then what should it do when
the binding for IA_TA (is about to) expires?  In practice the client
should need another temporary address before the expiration, but
should the client now request another IA_TA binding in the existing
DHCPv6 session?  If so, how?  If not, should it start a separate
DHCPv6 session for the new IA_TA?  But in that case it breaks the
proposed model where the client should have a single session for all
IAs.  As long as we include IA_TA in the discussion, I don't think we
can leave these questions open.

One option would be to completely exclude IA_TA from the discussion
and declare that we only consider IAs that have the concept of T1 and
T2.  That will make the discussion a lot easier and simpler, and would
make sense especially if we even consider deprecate the concept of
IA_TA (as briefly mentioned, IIRC, in the discussion on the previous
version of the draft).

Finally, and also somehow related to the points discussed above, I
think this document will have to clarify the relationship between
a DHCPv6 session and state of IAs in more detail.  A simple diagram of
state transition of IA based on RFC3315 would look like this:
http://gyazo.com/40653139343151e40e25cc0937c192f1 (a png image)
The stateful-issues draft would introduce another state named
something like "unbound" since a DHCPv6 session can conceptually
include an IA that is not yet assigned by the server.  Also, the
stateful-issues draft specifically discusses the case with multiple
IAs for a single DHCPv6 session, so conceptually we need to think
about multiple these diagrams and how they affect the DHCPv6 session.
Right now, it only shows how a client (and server) should do focusing
on DHCPv6 message handling (just following RFC3315), but the concept
is now more complicated and it seems to me that we need some more
architectural description...I know this comment may sound vague.  I'm
not sure specifically how I'd suggest addressing it at the moment, but
at least I'd feel there are too many open points in the current shape
draft if I were to try to implement it and would need something more
specific.

--
JINMEI, Tatuya