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

From: 神明達哉 <[email-masked]>
Date: Thu, 3 Jul 2014 09:27:47 -0700

At Mon, 30 Jun 2014 16:55:59 +0000,
"Bernie Volz (volz)" <[email-masked]> wrote:

> There is one outstanding issue that we'd like to get feedback on from folks (as well as of course the other changes made). We can discuss on the mailing list but will also discuss at the Toronto IETF DHC WG Session.
>
> This is the issue of which status codes Renew and Rebind should use when a server is unable to provide "leases" for a binding. Presently the text says to use NoBinding and part of that reason was that this is consistent with what is currently written in RFC 3315. But it may be better to use NoAddrsAvail/NoPrefixAvail instead of NoBinding. Marcin and I debated this some and here is some data regarding this issue:

Many points are discussed after these paragraphs, and I cannot easily
say which is the best with confidence.  But I figure out that it's at
least incompatible with existing client implementations if the server
returns something other than NoBinding.  According to RFC 3315, the
client will subsequently send a Request for the IA to (re-)establish
the binding.  If the server doesn't return NoBinding, and if the
client doesn't regard it as the need for some recovery action (sending
Request or Solicit), then the binding for the IA will eventually
expire (from a quick look at the code, this seems to be what would
happen with the WIDE DHCPv6 client implementation:
http://sourceforge.net/projects/wide-dhcpv6/).  It doesn't seem to be
a good idea to break backward compatibility this way unless there's a
strong reason for that.

BTW, as I read the entire draft it occurred to me that this draft
should probably describe what a client should do upon receiving a
Reply (in response to various types of messages) more specifically,
and with specific proposed text to revise Section 18.1.8 of RFC 3315.
Discussions on the client behavior on receiving a Reply will also be
related to the question on NoBinding vs others.

--
JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 3 Jul 2014 18:26:10 +0000

Hi Jinmei:

Yes, that is the one issue with changing the status codes - it breaks backwards compatibility. However, we already have changes that technically break this (such as the Advertise status codes). The risk for these changes should be fairly small as (1) clients are hopefully robust enough that they will handle unknown/unexpected status codes and either 'ignore' the binding (since it contains no addresses/prefixes) or restart at Solicit and (2) these are edge cases that may not have been well tested in all cases and are likely to occur rarely (i.e., mostly impact Rebinds when 'new' bindings appear which are probably not that common).

These are clearly concerns we have and it would be great to hear from client implementers to understand whether there are any potential nasty impacts. It may also be an interesting area to perform some tests on a 'updated' server to see how a sampling of client implementations handle these situations.

Regarding revising Section 18.1.8 and providing the text in the draft, if I recall that was plan and part of the reason to hold off on making this change - there wasn't sufficient time to do this 'properly' before the deadline.

Thanks for your review and comments!!!

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
Sent: Thursday, July 03, 2014 12:28 PM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt

> This is the issue of which status codes Renew and Rebind should use when a server is unable to provide "leases" for a binding. Presently the text says to use NoBinding and part of that reason was t…

Many points are discussed after these paragraphs, and I cannot easily say which is the best with confidence.  But I figure out that it's at least incompatible with existing client implementations if the server returns something other than NoBinding.  According to RFC 3315, the client will subsequently send a Request for the IA to (re-)establish the binding.  If the server doesn't return NoBinding, and if the client doesn't regard it as the need for some recovery action (sending Request or Solicit), then the binding for the IA will eventually expire (from a quick look at the code, this seems to be what would happen with the WIDE DHCPv6 client implementation:
http://sourceforge.net/projects/wide-dhcpv6/).  It doesn't seem to be a good idea to break backward compatibility this way unless there's a strong reason for that.

BTW, as I read the entire draft it occurred to me that this draft should probably describe what a client should do upon receiving a Reply (in response to various types of messages) more specifically, and with specific proposed text to revise Section 18.1.8 of RFC 3315.
Discussions on the client behavior on receiving a Reply will also be related to the question on NoBinding vs others.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Mon, 7 Jul 2014 11:31:02 -0700

At Thu, 3 Jul 2014 18:26:10 +0000,

> Yes, that is the one issue with changing the status codes - it breaks backwards compatibility. However, we already have changes that technically break this (such as the Advertise status codes). The…

I've thought this original behavior of RFC3315 intended recovery from
a server crash.  If a server crashes due to unexpected power cycle, a
serious implementation bug, etc, and forgets all bindings it assigned
before the crash, then the server will eventually receive a Renew (or
Rebind) from clients that it previously served but "the server cannot
find a client entry" (quoting 18.2.3 of RFC3315).  With the original
behavior, the server returns NoBindng, and the client will react to it
by sending a Request.  The server would probably be able to create the
same binding(s) for the Request as it previously did, in which case
the server crash is almost an opaque event for the client('s user).

If the server returns NoAddrsAvail, and the client behaves similar to
WIDE DHCPv6, however, the client will just ignore the Renew (and
subsequently Rebind), and end up with using the "dangling" binding for
much longer, increasing the risk of letting that binding be assigned
to some other client.

A server crash would be a rare event, but shouldn't be that rare that
we cannot ignore IMO.  So I'd be more careful if we change how to
handle such cases.

--
JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 7 Jul 2014 19:18:31 +0000

This is indeed an interesting case to consider.

First, my own feeling is that at least for a Renew, if the server has no record of the client at all [on that particular link], I think it should definitely return NoBinding. The intent with the being able to add a 'new' binding to an existing set in the Renew was not to allow a client to essentially 'start at Renew'. I didn't check the latest Stateful Issues text but if we don't have that there, we do need to clean this up to add it. This would I think solve this issue for Renew. Note also that for any addresses/prefixes that the client claims it is using (i.e., by providing them in the Renew) but the server does not have, the server must either (1) assign the address/prefix if there is no conflict or (2) return 0 lifetimes if there is a conflict.

Rebind in this particular case is more difficult, since the server doesn't know whether the bindings are 'existing' or 'additional' (except perhaps whether any addresses/prefixes are present in the Rebind). But in this case we're not really in trouble at all since the server SHOULD be assigning the client any existing addresses or prefixes in the Rebind request - unless it is unable to do so because it has conflicting information. The NoAddrAvail/NoPrefixAvail is only in the case where the binding has no leases and the server is unable to allocate ones.

The important point here is that Rebind is always assumed to assign the addresses/prefixes the client claims it is currently using (of course if the server has conflicting information, it can return the addresses/prefixes with 0 lifetimes).

The points that are important here:
- For a Solicit and Request, the server assumes that the client is NOT presently using any of the addresses/prefixes specified. Therefore, it is much freer to ignore these (i.e., treat them as very "mild" hints).
- For a Renew and Rebind, the server MUST assume that the client is presently using any of the addresses/prefixes specified (excepting a hint with 0::0). The server MUST either allocate the address/prefix (if not already existing) or must return 0 lifetimes to indicate to the client to stop using the addresses/prefixes.

Note also that it is important for a client to send its current addresses/prefixes when sending a Renew/Rebind.

So, I don't think there are any issue with this case if on theRenew/Rebind the server sends the NoAddrsAvail/NoPrefixAvail for a 'new' binding that has no 'in-use' address/prefix present by the client.

Note: This situation is a bit tricky anyway since there is no way for the server to know what addresses/prefixes are in use. And the server may well assign a client that sends a Solicit (/Request) an address or prefix that is already in use by another client, before that other client sends a Renew/Rebind. (This is one of the reasons that Failover has worked out well in DHCPv4 - since it provides another place for the data to be stored to avoid loss of state). I guess one "solution" might be to not allow new addresses/prefixes to be assigned for whatever lifetime would assure at lease a Renew (i.e., >50% of the lease time). But that is not nice to new clients either :).

- Bernie

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

> Yes, that is the one issue with changing the status codes - it breaks backwards compatibility. However, we already have changes that technically break this (such as the Advertise status codes). The…

I've thought this original behavior of RFC3315 intended recovery from a server crash.  If a server crashes due to unexpected power cycle, a serious implementation bug, etc, and forgets all bindings it assigned before the crash, then the server will eventually receive a Renew (or
Rebind) from clients that it previously served but "the server cannot find a client entry" (quoting 18.2.3 of RFC3315).  With the original behavior, the server returns NoBindng, and the client will react to it by sending a Request.  The server would probably be able to create the same binding(s) for the Request as it previously did, in which case the server crash is almost an opaque event for the client('s user).

If the server returns NoAddrsAvail, and the client behaves similar to WIDE DHCPv6, however, the client will just ignore the Renew (and subsequently Rebind), and end up with using the "dangling" binding for much longer, increasing the risk of letting that binding be assigned to some other client.

A server crash would be a rare event, but shouldn't be that rare that we cannot ignore IMO.  So I'd be more careful if we change how to handle such cases.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Tue, 8 Jul 2014 11:09:19 -0700

On Mon, Jun 30, 2014 at 9:55 AM, Bernie Volz (volz) <[email-masked]> 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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 8 Jul 2014 18:44:19 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of ????
Sent: Tuesday, July 08, 2014 2:09 PM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt

> 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:

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.

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.

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 8 Jul 2014 18:44:51 +0000

Oh ... the link finally did work -- just took a while (it completed while I was writing the email below).

- Bernie

-----Original Message-----
From: Bernie Volz (volz) 
Sent: Tuesday, July 08, 2014 2:44 PM
To: '神明達哉'
Cc: [email-masked]
Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt

Hi Jinmei:

- Bernie

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

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Wed, 9 Jul 2014 09:38:52 -0700

At Mon, 30 Jun 2014 18:19:37 +0000,
"Bernie Volz (volz)" <[email-masked]> wrote:

> But because we're making changes to the specifications (i.e., revised sections of 3315, 3633, and even in some cases providing text for possible use in the 3315bis work), we are indeed trying to cover all IA_* options (while we hope it includes future possible IA_* options, that is more difficult to achieve as we don't know what those might be).
>
> >Can I assume that this draft tries to provide a generalized specification for all current and possible IA_xx
[...]
> Bottom line is that yes we are trying to accommodate all (existing) IA_* types. And, in general we've assumed that 3315 has handled IA_NA/IA_TA co-existence sufficiently, so the revised text focuses on included IA_PD handling.

The nuance is subtle here, so please let me be sure: which one is
(more) correct?
1. this draft excludes the applicability to future possible IA_XXs
   (i.e., it only covers IA_NA, IA_TA, and IA_PD, and the main
   motivation is the concurrent use of IA_NA and IA_PD).
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.

My initial interpretation was #2.  Am I correct?

--
JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 9 Jul 2014 17:07:40 +0000

Hi Jinmei:

Yes, #2 is our hope.

--

It occurs to me that if this as this is the intent, we might want to discuss whether to add a new "OPTION_T1T2" (or some other name). Reasons would be:
1. It would be a good way for servers to know if the client has been uplifted as including this option code in the ORO would tell the server that.
2. Servers would return the T1/T2 for all (renewable) bindings in this option (as well as setting these values in the existing IA_NA/IA_PD options - servers COULD set these fields to 0 in the IA_NA/IA_PD option if returning the option as requested by the client).
3. Clients would know if the server was uplifted (if it returned this option).
4. It would remove the need for these fields in any future IA_* type options.

I think this idea was raised by someone else (Marcin?) at one time (though that may not have been on the list).

- Bernie

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

[...]

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Wed, 9 Jul 2014 12:01:51 -0700

At Wed, 9 Jul 2014 17:07:40 +0000,

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

---

From: Marcin Siodelski <[email-masked]>
Date: Thu, 10 Jul 2014 19:48:36 +0200

Jinmei,

Thanks for the thorough and careful review. I can answer some of the
points you raised (see below). Some of them Bernie or Ole may want to
address, so I left them not answered.

Marcin

>   out some of such cases below, but they are not comprehensive.

The "stateful-issues" draft is meant to update the RFC3315 and RFC3633
respectively. That's why it refers to the term "address" where it
updates RFC3315 and "prefix" where it updates RFC3633.

The RFC3315bis work is conducted in parallel to this work and one of the
goals is to merge the RFC3633 and RFC3315 and provide the unified text
for different IA types.

Since, the "stateful-issues" draft addresses various aspects of
coexistence of different IA types we thought it may be useful to also
include the unified text that can be directly (or easily) ported to the
RFC3315bis document. That's why there are separate sections including a
unified text for RFC3315bis and in those sections the items carried in
the IA options are called "resources".

For example: sections 4.1 and 4.2 provide the updates to RFC3315 and
RFC3633 respectively and use the term "address"/"prefix". Sections 4.3
and 4.4. present the unified text to be included in the RFC3315bis
document and use the term "resources".

>   specific cases where I felt the confusion below.

The "stateful option" is a DHCP option (such as IA_NA or IA_PD) which is
carrying a resource (e.g. address or prefix). Resource is content
carried in the stateful option.

I'll go over the document and try to unify it according to the meaning
meant.

>                                    resources are: IPv6 address or an

Ok, thanks.

>                                    for temporary addresses").

This is the reference to the section 22.5. of RFC3315. And it was
copy-pasted from the terminology in RFC3315 which includes exactly the
same reference. But, I think it can be improved. For example, the
following statement in terminology:

" In addition to the terminology defined in [RFC3315], [RFC3633], and
   [RFC7227], the following terminology is used in this document:"

doesn't seem to be true because IA defined here is not "additional" but
rather replaces the definition in RFC3315.

>   option (types)" in this context (see above).

Probably "resources" would be better.

>    IA_PD was in the Solicit):

The reason why it explicitly speaks about "addresses" is that for the
Advertise the NoAddrsAvail is included in the global scope when the
server doesn't allocate at least one address (see RFC3315). For IA_PD
(and hopefully for future IA types) the status code is always in the
IA_PD option. So, it is very specific to addresses and shouldn't be
generalized.
>       information requested by the client.

Yes, if the server doesn't create a binding (e.g. it is not configured
to create bindings when processing Renew/Rebind) it should send NoBinding.

We were also considering the possibility for the server to return other
status codes in certain cases (NoAddrsAvail/NoPrefixAvail etc.) and it
seems that it has been briefly discussed between you and Bernie.
However, this is currently not included in the draft.

In the current version of the draft, it is NoBinding that can be
returned if the bindings are not created.

>    to extend the lifetimes on client's bindings through the T1 and T2

I don't disagree. I will come up with some proper split of this
paragraph between server/client specific sections.

>    T2 value to each binding assigned to the client.  In this case the

The RFC3315 introduces no requirement for the T1/T2 times to be
synchronized between the IAs for the same client. We wanted to give a
strong recommendation for the server to send the same T1/T2 timers
across all IAs. However, there will be cases when the server doesn't do
that because it is not yet updated to the current specification. We want
the clients to deal with that and that's why we add paragraphs what the
client should do if it gets different T1/T2 times, which only really
makes sense if it is not the absolute requirement (MUST).

I may not have enough knowledge where the MUST vs SHOULD apply but in my
opinion "SHOULD" well conveys the message that there may be cases in
which server will respond with different T1/T2 timers and the client has
to be prepared for this.

>    may send Renew or Rebind message, respectively, at the client's

This is the exact paragraph from the original document. See 18.1.3.
Creation and Transmission of Renew Messages in RFC3315.

>    in IA options that the client does not have.

The intent here is that the client should not stick addresses or
prefixes into the IA options that the client didn't obtain from the DHCP
server.

In order words, if the client has an address and sends Renew/Rebind it
should only stick this address to the IA_NA option it is sending to the
server. It should not put any address into the IA_NA that it never
obtained from the DHCP server.

Or, if the client has the address and not a prefix and the client wants
the prefix be allocated (with the Renew/Rebind) it should put an empty
IA_PD option, and not put any prefixes into it (e.g. as hints to the
server).

>    lifetimes set to 0 MUST NOT use the corresponding resource.

While I concur that it would be better to avoid "valid" and "preferred"
because it may not apply to resources defined in the future, the single
lifetime is a special case of multiple lifetimes and changing it to "a
lifetime" would suggest that resources come with only one lifetime
value. Also, we already have multiple lifetimes for existing resources.

>   (BTW: "addresses" should probably be generalized)

This is similar to the issue that is already in the RFC3315 when the
client sends the Solicit with Rapid Commit option. I'd assume that the
server implementation would provide a configuration knob to
enable/disable this behavior. If you don't want to deal with this issue,
don't enable it (just like for Rapid Commit). If you do enable, you may
need to adjust the lifetimes for assigned leases so as you don't end up
with unused leases dangling for a long time.

>   client end up having multiple DHCPv6 sessions (which this draft

Did you really mean 4.5.2 from the datatracker:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-stateful-issues/
?

The 4.5.2 doesn't seem to be relevant here.

>    information to be returned to the client as described in section

It could.

>    a Decline message for the conflicting address(es).

I'd let Bernie or Ole explain but I'd be opposed to putting any specific
server implementations here.

Marcin

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 10 Jul 2014 18:44:01 +0000

Haven't yet processed this thread completely ... but will respond to one issue:

>I'd let Bernie or Ole explain but I'd be opposed to putting any specific server implementations here.

Yes, it does describe existing implementations. This is an issue that Tim Winters raised. I don't believe I have details on which specific CLIENT implementations might be doing this. But in any case, I don't think it is appropriate to specify which implementations in a document such as this.

Are you suggesting we remove the first paragraph and just simple leave the second? But I do think it adds value to explain that this might be 'in the field' behavior. Is there better wording you want used (other than naming 'some implementations'). Would "Some client implementations are [have been] known to ..." be better wording?

- Bernie

-----Original Message-----
From: Marcin Siodelski [mailto:[email-masked]] 
Sent: Thursday, July 10, 2014 1:49 PM
To: 神明達哉; Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt

Jinmei,

Thanks for the thorough and careful review. I can answer some of the points you raised (see below). Some of them Bernie or Ole may want to address, so I left them not answered.

Marcin

>   out some of such cases below, but they are not comprehensive.

The "stateful-issues" draft is meant to update the RFC3315 and RFC3633 respectively. That's why it refers to the term "address" where it updates RFC3315 and "prefix" where it updates RFC3633.

The RFC3315bis work is conducted in parallel to this work and one of the goals is to merge the RFC3633 and RFC3315 and provide the unified text for different IA types.

Since, the "stateful-issues" draft addresses various aspects of coexistence of different IA types we thought it may be useful to also include the unified text that can be directly (or easily) ported to the RFC3315bis document. That's why there are separate sections including a unified text for RFC3315bis and in those sections the items carried in the IA options are called "resources".

For example: sections 4.1 and 4.2 provide the updates to RFC3315 and
RFC3633 respectively and use the term "address"/"prefix". Sections 4.3 and 4.4. present the unified text to be included in the RFC3315bis document and use the term "resources".

>   specific cases where I felt the confusion below.

The "stateful option" is a DHCP option (such as IA_NA or IA_PD) which is carrying a resource (e.g. address or prefix). Resource is content carried in the stateful option.

I'll go over the document and try to unify it according to the meaning meant.

Ok, thanks.

>                                    for temporary addresses").

This is the reference to the section 22.5. of RFC3315. And it was copy-pasted from the terminology in RFC3315 which includes exactly the same reference. But, I think it can be improved. For example, the following statement in terminology:

doesn't seem to be true because IA defined here is not "additional" but rather replaces the definition in RFC3315.

>    IA_PD was in the Solicit):

The reason why it explicitly speaks about "addresses" is that for the Advertise the NoAddrsAvail is included in the global scope when the server doesn't allocate at least one address (see RFC3315). For IA_PD (and hopefully for future IA types) the status code is always in the IA_PD option. So, it is very specific to addresses and shouldn't be generalized.
>       information requested by the client.

Yes, if the server doesn't create a binding (e.g. it is not configured to create bindings when processing Renew/Rebind) it should send NoBinding.

We were also considering the possibility for the server to return other status codes in certain cases (NoAddrsAvail/NoPrefixAvail etc.) and it seems that it has been briefly discussed between you and Bernie.
However, this is currently not included in the draft.

In the current version of the draft, it is NoBinding that can be returned if the bindings are not created.

>    to extend the lifetimes on client's bindings through the T1 and T2

I don't disagree. I will come up with some proper split of this paragraph between server/client specific sections.

>    T2 value to each binding assigned to the client.  In this case the

The RFC3315 introduces no requirement for the T1/T2 times to be synchronized between the IAs for the same client. We wanted to give a strong recommendation for the server to send the same T1/T2 timers across all IAs. However, there will be cases when the server doesn't do that because it is not yet updated to the current specification. We want the clients to deal with that and that's why we add paragraphs what the client should do if it gets different T1/T2 times, which only really makes sense if it is not the absolute requirement (MUST).

I may not have enough knowledge where the MUST vs SHOULD apply but in my opinion "SHOULD" well conveys the message that there may be cases in which server will respond with different T1/T2 timers and the client has to be prepared for this.

>    in IA options that the client does not have.

The intent here is that the client should not stick addresses or prefixes into the IA options that the client didn't obtain from the DHCP server.

In order words, if the client has an address and sends Renew/Rebind it should only stick this address to the IA_NA option it is sending to the server. It should not put any address into the IA_NA that it never obtained from the DHCP server.

Or, if the client has the address and not a prefix and the client wants the prefix be allocated (with the Renew/Rebind) it should put an empty IA_PD option, and not put any prefixes into it (e.g. as hints to the server).

While I concur that it would be better to avoid "valid" and "preferred"
because it may not apply to resources defined in the future, the single lifetime is a special case of multiple lifetimes and changing it to "a lifetime" would suggest that resources come with only one lifetime value. Also, we already have multiple lifetimes for existing resources.

>   (BTW: "addresses" should probably be generalized)

This is similar to the issue that is already in the RFC3315 when the client sends the Solicit with Rapid Commit option. I'd assume that the server implementation would provide a configuration knob to enable/disable this behavior. If you don't want to deal with this issue, don't enable it (just like for Rapid Commit). If you do enable, you may need to adjust the lifetimes for assigned leases so as you don't end up with unused leases dangling for a long time.

It could.

>    a Decline message for the conflicting address(es).

I'd let Bernie or Ole explain but I'd be opposed to putting any specific server implementations here.

Marcin

---

From: 神明達哉 <[email-masked]>
Date: Thu, 10 Jul 2014 12:58:11 -0700

At Thu, 10 Jul 2014 18:44:01 +0000,

> Are you suggesting we remove the first paragraph and just simple leave the second? But I do think it adds value to explain that this might be 'in the field' behavior. Is there better wording you wa…

I didn't intend to suggest anything (that's why I said "just
wondering").  It was just not very clear to me whether this is about
some actual implementation or it states something general.  Now that I
understand it's the former, "Some client implementations are [have
been] known to ..." sounds clearer to me, but that's not a strong
opinion.

--
JINMEI, Tatuya

---

From: Cong Liu <[email-masked]>
Date: Mon, 14 Jul 2014 17:13:33 +0800

Hi,

I have a question on section 4:
   "Proposed solution: the client should keep *a single session* with the
   server and include the missing options on subsequent messages
   (Request, Renew, and Rebind) to the server.

My understanding is that it implicitly objects to "create separate DHCP
sessions for each IA option type" in the previous paragraph.

If there are two servers: server_A only replies IA_NA and server_P only
replies IA_PD. The client sends Solicit message requesting both IA_NA and
IA_PD, and receives Advertise messages from both servers. Will the client
only keep a single session with just one of the servers, or two sessions
with both servers? For the former case, the client will unlikely get both
IA_NA and IA_PD although it continue requesting both IA_NA and IA_PD
in subsequent
messages.

If it is the latter case, what would be in the client's IA_NA in subsequent
Request, Renew, and Rebind messages to the server_P? Does the IA_NA to
server_P contains the IA_NA address from server_A's Advertise (that's what
the client gets), or no address (that's what server_P has replied) ?

Best Regards,
Cong

2014-07-01 0:55 GMT+08:00 Bernie Volz (volz) <[email-masked]>:

> Hi:
>
> A new version of this document has been posted. Sorry for the long delay
> but there were some significant changes to make and thanks to Marcin for
> joining the authors to make some of those changes.
>
> The major differences are:
> 1. Sections 4.1 and 4.2 (Advertise Message and Placement of Status Code)
> were swapped. The reason for this is because we decided to use the Reply
> formatting for the status codes in Advertise too. It turns out that there
> are server implementations that did already use this formatting and there
> have been no reported issues. So, client implementations must be handling
> this acceptable. This is a better long term solution since it doesn't
> special case the IA_NA/IA_TA handling in Advertise.
> 2. The 4.4 Renew and 4.5 Rebind sections have had major changes and rework
> (that to Marcin).
> 3. The 4.6 Confirm section was changed to remove use of Confirm for IA_PD
> (Rebind is mandated). For IA_NA and/or IA_TA only, Confirm can be used. If
> IA_PD exists, Rebind should be used (not Confirm).
> 4. Replaced 4.7.  Release Message with a 4.7  Decline Should Not
> Necessarily Trigger a Release (an issue reported by Tim Winters).
> 5. There are other minor edits (such as referencing RFC 7084 instead of
> RFC 6204).
>
> There is one outstanding issue that we'd like to get feedback on from
> folks (as well as of course the other changes made). We can discuss on the
> mailing list but will also discuss at the Toronto IETF DHC WG Session.
>
> This is the issue of which status codes Renew and Rebind should use when a
> server is unable to provide "leases" for a binding. Presently the text says
> to use NoBinding and part of that reason was that this is consistent with
> what is currently written in RFC 3315. But it may be better to use
> NoAddrsAvail/NoPrefixAvail instead of NoBinding. Marcin and I debated this
> some and here is some data regarding this issue:
>
> 1. A Request never returns NoBinding. It uses NoAddrsAvail/NoPrefixAvail.
> So, if we wanted to make Renew (and Rebind) more closely aligned ...
> 2. Existing servers (that follow 3315) will return NoBinding. Thus,
> returning this would provide a client no information as to whether the
> server was new or not - and whether to initiate a Solicit/... cycle. On the
> flip side, existing clients handle NoBinding so that could avoid issues
> with unexpected status results?
> 3. We have 4 possible responses for an IA for a Renew/Rebind when no
> 'resources'  are assigned:
> 3.a. Return NoBinding.
> 3.b. Return NoAddrsAvail/NoPrefixAvail.
> 3.c. Return an 'empty' IA (no IAADDR or IAPREFIX options).
> 3.d. Don't return the IA. (I'm not a fan of this one as it might imply to
> the client that the server doesn't know that IA.) 4. Is there any value in
> returning additional information to a client for a Rebind? For a Rebind,
> there are two possibilities as to why the server didn't assign
> addresses/prefixes:
> 4.a. The server has no resources available at the present time.
> 4.b. The server is not able to assign resources because it is not
> configured to support "rapid commit".
> So, should we consider whether these should be handled differently? For
> 4.a., if the client retries (i.e., Renew, Solicit) it may get a resource
> but may not - depends on why it isn't available and whether something has
> happened to make a resource available. For 4.b, if the client retries
> (i.e., Renew, Solicit) it would likely get the resource.
> 5. There is one other condition to consider - my original assumption for
> Renew was that the server could 'refuse' to service the client if the
> server had no record of the client (i.e., no bindings). In this case,
> returning NoBinding for all of the IA_* would be appropriate - to force the
> client to Solicit/...
>
> (If we do 'drop' NoBinding from Renew/Rebind, then this status code would
> only be used for Release/Decline Replies.)
>
> My feeling is that for Renew/Rebind:
> - We should return NoAddrsAvail/NoPrefixAvail when the server cannot
> provide the requested resources but would if it 'could'.
> - We should reserve NoBinding to trigger the client to go back to
> Solicit/... or Request. Therefore, this should only be used in conditions
> where the server wants (needs) the client to do that.
>
> If would be nice if the status codes (or empty or missing IA) had
> consistent meanings for 'all' messages and thus triggered consistent client
> actions.
>
> Putting NoAddrsAvail into the IA carried in the Reply to Renew/Rebind
> shouldn't cause problems in the clients that really follow the current
> RFC3315 as in the section 18.1.8 it clearly specifies what to do with IAs
> that contain NoAddrsAvail in the Reply message  and it doesn't
> differentiate between the types of messages in response to which the Reply
> has been received. The following paragraph:
>
> "When the client receives a Reply message in response to a Renew or
>    Rebind message, the client examines each IA independently.  For each
>    IA in the original Renew or Rebind message, the client:
>
>    -  sends a Request message if the IA contained a Status Code option
>       with the NoBinding status (and does not send any additional
>       Renew/Rebind messages)
>
>    -  sends a Renew/Rebind if the IA is not in the Reply message
>
>    -  otherwise accepts the information in the IA "
> may be a source of trouble for clients which implementers ignored the
> preceding paragraph and simply made an assumption that NoAddrsAvail is not
> returned for Renew/Rebind. On the other hand the client shouldn't fall over
> just because it gets the unexpected status code.
>
> So in principle it seems to be fine to use NoAddrsAvail/NoPrefixAvail in
> the Reply messages sent as a response to Renew/Rebind.
>
>
> 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.
>
> - Bernie
>
> From: dhcwg [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Monday, June 30, 2014 12:34 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  This draft is a work item of the Dynamic Host Configuration Working Group
> of the IETF.
>
>         Title           : Issues with multiple stateful DHCPv6 options
>         Authors         : Ole Troan
>                           Bernie Volz
>                           Marcin Siodelski
>         Filename        : draft-ietf-dhc-dhcpv6-stateful-issues-06.txt
>         Pages           : 20
>         Date            : 2014-06-30
>
> Abstract:
>    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 shoe-horned the new options 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.
>
>
> The IETF datatracker status page for this draft is:
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issues-06
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-stateful-issues-06
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 14 Jul 2014 13:02:54 +0000

Hi:

This is “should”. That allows for cases where a client may want to use multiple sessions to different servers. This might well be the case if multiple provisioning domains were in play – see section 4.8. But this is an  area of potential future work …

If a client decides to start multiple sessions, why would it then combine the two separate sessions? I think it should keep the transactions completely separate (even when reaching the Rebind ‘state’). If it doesn’t keep things separate, it could very well end up with conflicting answers – it all depends on what each server knows about what the other has and how it responds (respond with “NoBinding”, respond with 0 lifetimes, respond with “NotOnLink”, …).

We do NOT cover this since we do NOT expect clients will generally want to do this. But there is nothing that prohibits this based on RFC 3315 and this draft.

I don’t know if you are suggesting any changes to the text, if so, please provide those suggestions.

-          Bernie

From: Cong Liu [mailto:[email-masked]]
Sent: Monday, July 14, 2014 5:14 AM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt

Hi,

I have a question on section 4:
   "Proposed solution: the client should keep a single session with the
   server and include the missing options on subsequent messages
   (Request, Renew, and Rebind) to the server.

My understanding is that it implicitly objects to "create separate DHCP sessions for each IA option type" in the previous paragraph.

If there are two servers: server_A only replies IA_NA and server_P only replies IA_PD. The client sends Solicit message requesting both IA_NA and IA_PD, and receives Advertise messages from both servers. Will the client only keep a single session with just one of the servers, or two sessions with both servers? For the former case, the client will unlikely get both IA_NA and IA_PD although it continue requesting both IA_NA and IA_PD in subsequent messages.

If it is the latter case, what would be in the client's IA_NA in subsequent Request, Renew, and Rebind messages to the server_P? Does the IA_NA to server_P contains the IA_NA address from server_A's Advertise (that's what the client gets), or no address (that's what server_P has replied) ?

Best Regards,
Cong

2014-07-01 0:55 GMT+08:00 Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>:
Hi:

A new version of this document has been posted. Sorry for the long delay but there were some significant changes to make and thanks to Marcin for joining the authors to make some of those changes.

The major differences are:
1. Sections 4.1 and 4.2 (Advertise Message and Placement of Status Code) were swapped. The reason for this is because we decided to use the Reply formatting for the status codes in Advertise too. It turns out that there are server implementations that did already use this formatting and there have been no reported issues. So, client implementations must be handling this acceptable. This is a better long term solution since it doesn't special case the IA_NA/IA_TA handling in Advertise.
2. The 4.4 Renew and 4.5 Rebind sections have had major changes and rework (that to Marcin).
3. The 4.6 Confirm section was changed to remove use of Confirm for IA_PD (Rebind is mandated). For IA_NA and/or IA_TA only, Confirm can be used. If IA_PD exists, Rebind should be used (not Confirm).
4. Replaced 4.7.  Release Message with a 4.7  Decline Should Not Necessarily Trigger a Release (an issue reported by Tim Winters).
5. There are other minor edits (such as referencing RFC 7084 instead of RFC 6204).

1. A Request never returns NoBinding. It uses NoAddrsAvail/NoPrefixAvail. So, if we wanted to make Renew (and Rebind) more closely aligned ...
2. Existing servers (that follow 3315) will return NoBinding. Thus, returning this would provide a client no information as to whether the server was new or not - and whether to initiate a Solicit/... cycle. On the flip side, existing clients handle NoBinding so that could avoid issues with unexpected status results?
3. We have 4 possible responses for an IA for a Renew/Rebind when no 'resources'  are assigned:
3.a. Return NoBinding.
3.b. Return NoAddrsAvail/NoPrefixAvail.
3.c. Return an 'empty' IA (no IAADDR or IAPREFIX options).
3.d. Don't return the IA. (I'm not a fan of this one as it might imply to the client that the server doesn't know that IA.) 4. Is there any value in returning additional information to a client for a Rebind? For a Rebind, there are two possibilities as to why the server didn't assign addresses/prefixes:
4.a. The server has no resources available at the present time.
4.b. The server is not able to assign resources because it is not configured to support "rapid commit".
So, should we consider whether these should be handled differently? For 4.a., if the client retries (i.e., Renew, Solicit) it may get a resource but may not - depends on why it isn't available and whether something has happened to make a resource available. For 4.b, if the client retries (i.e., Renew, Solicit) it would likely get the resource.
5. There is one other condition to consider - my original assumption for Renew was that the server could 'refuse' to service the client if the server had no record of the client (i.e., no bindings). In this case, returning NoBinding for all of the IA_* would be appropriate - to force the client to Solicit/...

(If we do 'drop' NoBinding from Renew/Rebind, then this status code would only be used for Release/Decline Replies.)

My feeling is that for Renew/Rebind:
- We should return NoAddrsAvail/NoPrefixAvail when the server cannot provide the requested resources but would if it 'could'.
- We should reserve NoBinding to trigger the client to go back to Solicit/... or Request. Therefore, this should only be used in conditions where the server wants (needs) the client to do that.

If would be nice if the status codes (or empty or missing IA) had consistent meanings for 'all' messages and thus triggered consistent client actions.

Putting NoAddrsAvail into the IA carried in the Reply to Renew/Rebind shouldn't cause problems in the clients that really follow the current RFC3315 as in the section 18.1.8 it clearly specifies what to do with IAs that contain NoAddrsAvail in the Reply message  and it doesn't differentiate between the types of messages in response to which the Reply has been received. The following paragraph:

   -  otherwise accepts the information in the IA "
may be a source of trouble for clients which implementers ignored the preceding paragraph and simply made an assumption that NoAddrsAvail is not returned for Renew/Rebind. On the other hand the client shouldn't fall over just because it gets the unexpected status code.

So in principle it seems to be fine to use NoAddrsAvail/NoPrefixAvail in the Reply messages sent as a response to Renew/Rebind.

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, June 30, 2014 12:34 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

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

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

---

From: 神明達哉 <[email-masked]>
Date: Mon, 14 Jul 2014 11:06:03 -0700

At Mon, 14 Jul 2014 13:02:54 +0000,

> This is “should”. That allows for cases where a client may want to use multiple sessions to different servers. This might well be the case if multiple provisioning domains were in play – see sectio…

My understanding of the question is that it's more related to the
undocumented operational assumption I raised in a prior comment:
http://www.ietf.org/mail-archive/web/dhcwg/current/msg15657.html

>>  + it can provide a binding for neither IA1 nor IA2.

If my understanding is correct, what I think should be done for this
document is:

- get a consensus on the validity of this assumption.  (Personally, I
  think it's reasonable for the case of IA_NA + IA_PD; I'm not so sure
  about the general IA1 and IA2)
- assuming we have the consensus, explicitly clarify the operational
  assumption on which this document is based, and also clarify what's
  excluded from the scope of considerations.  Perhaps the assumption
  was so obvious to the authors, but the fact we have this discussion
  now would suggest that it's not that trivial to others and worth
  documenting explicitly.

--
JINMEI, Tatuya

---

From: Cong Liu <[email-masked]>
Date: Wed, 16 Jul 2014 02:51:41 +0800

Hi Bernie,

2014-07-14 21:02 GMT+08:00 Bernie Volz (volz) <[email-masked]>:

>  Hi:
>
>
>
> This is “should”. That allows for cases where a client may want to use
> multiple sessions to different servers. This might well be the case if
> multiple provisioning domains were in play – see section 4.8. But this is
> an  area of potential future work …
>

>
> If a client decides to start multiple sessions, why would it then combine
> the two separate sessions? I think it should keep the transactions
> completely separate (even when reaching the Rebind ‘state’).
>
Agree.

> If it doesn’t keep things separate, it could very well end up with
> conflicting answers – it all depends on what each server knows about what
> the other has and how it responds (respond with “NoBinding”, respond with 0
> lifetimes, respond with “NotOnLink”, …).
>
>
>
> We do NOT cover this since we do NOT expect clients will generally want to
> do this. But there is nothing that prohibits this based on RFC 3315 and
> this draft.
>
>
>
I didn't pay much attention to section 4.8 and it solves my question. I
think it would be better to move section 4.8 before the IA-related
discussions in section 4, to clarify the scope and assumptions clearer as
Jinmei suggested.

Best Regards,
Cong