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

["Bernie Volz (volz)" <[e-mail]>]

Hi Jinmei:

http://gyazo.com/40653139343151e40e25cc0937c192f1 didn't work for me.

Regarding IA_TA, yes I generally agree with you that these are probably mostly independent transactions. It may start out that the first Solicit/Request cycle includes the IA_TA, but probably these lifetimes and client usage of them, would mean that future IA_TA Requests would likely be separate. Also, I think the model for IA_TA is that a client might get them only when it needs them (i.e., some application starts that wants a privacy address). Renewals would only be needed for these if the application wanted to (hopefully) continue  using the temporary address when the lifetime is near expiration - hence it is a separate set of transactions.

I think I said so in an earlier email, but might be an interesting question as to whether to DEPRECATE IA_TAs. Their value is limited in a DHCPv6 environment. That is probably a good issue to add to the Toronto discussion.

We probably need to add words that explain assumption? Again we don't want to preclude them being included (i.e. in initial exchange), but IA_TA will likely require a client to have separate transactions with the server - but again, this depends on the client's model and services. There isn't anything that would prohibit a client to send a Renew when the IA_TA needs to be renewed / refreshed that includes the IA_NA and IA_PD and having them all renewed.)

A few more comments inline below (BV>).

- Bernie

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of ????
Sent: Tuesday, July 08, 2014 2:09 PM
To: Bernie Volz (volz)
Cc: [e-mail]
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt

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.


BV> That is what the Stateful Draft says to do. The server SHOULD send one set of values (same in each IA_NA/IA_PD). But as servers might not yet be updated, the client should use the 'shortest' set of T1/T2 values across the IA_NA/IA_PDs.

- 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).

BV> Yes, I believe that has 'always' been the assumption. There isn't an issue if a client wanted to maintain separate sets of transactions, but in general we don't feel clients need (or want) that complexity.

- 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.
BV> There is always the Reconfigure from the server that could be used by the server.
BV> There could be other actions by/on the client that could trigger an earlier exchange, but yes in general that would be the case.

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.

BV> Yeah, but I would hope we are moving forward (much better than current state of 3315/3633) which people seem to have worked around fairly well.

--
JINMEI, Tatuya