Subject: [dhcwg] Please review version -07 of draft-ietf-dhc-dhcpv6-stateful-issues

From: Marcin Siodelski <[email-masked]>
Date: Thu, 02 Oct 2014 11:10:48 +0200

Hi All,

The version -07 of the draft-ietf-dhc-dhcpv6-stateful-issues is now
available at:

http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-stateful-issues/

This version introduces numerous changes to the draft to address "New
issues" presented on IETF in Toronto:
http://www.ietf.org/proceedings/90/slides/slides-90-dhc-2.pdf. It also
addresses some issues raised on the mailing list. Thanks to Jinmei, Cong
and others for their interest and reviews.

In the new version we try to clarify the scope of this work - the
"Introduction" has been extended to state that the goal of this work is
to address the issues related to coexistence of IA_NA and IA_PD and we
get away from attempts to provide a generalized text for all existing IA
types (including IA_TA) and future IAs, as it is impossible to know how
they will look like.

The previous version of the draft provided a "unified" text (for
Renew/Rebind processing) which was intended to be used for the
RFC3315bis work. The new version removes the "unified" text to avoid
confusion that the draft is intended to provide generalized approach for
all IA types. Instead, the new text provides respective updates to
RFC3315 and RFC3633 for IA_NA and IA_PD processing in a single DHCP session.

The more detailed list of changes between version -06 and -07 is given
below.

1. The draft title has been changed from "Issues with multiple stateful
DHCPv6 options" to "Issues and Recommendations with Multiple DHCPv6
Stateful Options", as in fact the draft not only identifies the issues
but also proposes specific solutions.

2. The Introduction has been extended to clarify the scope of the draft
as mentioned above.

3. Use "stateful options" and "resources" where appropriate.

4. Provided the updates to relevant sections of RFC3315 to mandate that
the server MUST set the T1/T2 times to the same values across all IA
options sent to a client.

5. Removed the "unified" text (intended for RFC3315bis) from the
Renew/Rebind sections. The current text only provides respective updates
for RFC3315 and RFC3633.

6. With updated Renew/Rebind processing the server returns NoAddrsAvail
status code for the IA, when the server is configured to create new
bindings for the renewing clients but the binding cannot be created
(e.g. address pool exhausted or other reasons). If the server is not
configured (or updated) to create new bindings in the Renew/Rebind time,
the NoBinding is returned which falls back to the original behavior.

7. Reworked section 18.1.8. Receipt of Reply Message in RFC3315, mainly
to account for the NoAddrsAvail/NoPrefixAvail being returned by the
server in response to Renew/Rebind.

8. Updated 18.1.8 with a note that the client must use the shortest
T1/T2 time from the same IA across all IA options to facilitate the
renewal of all bindings at the same time.

9. Updated 18.1.8. with a note that client should follow the
retransmission procedure if it finds that the IA is not in the Reply
message from the server sent in response to Renew/Rebind. The original
text stated that the client should send Renew/Rebind if the IA is not
present in the server's response. This resulted in the Renew/Rebind storm.

9. Client SHOULD (relaxed from a MUST) initiate Confirm when it may have
moved to a new link as the client may have determined whether it moved
or not by other means. A reference to RFC6059 has been added.

Please provide your comments. Note that this work builds the ground for
the RFC3315bis, so your interest is important.

Marcin

---

From: 神明達哉 <[email-masked]>
Date: Wed, 8 Oct 2014 11:22:55 -0700

At Thu, 02 Oct 2014 11:10:48 +0200,

> http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-stateful-issues/
[...]
> the RFC3315bis, so your interest is important.

Here's my review.  I almost forgot the full context of the discussion
regarding my previous review comments, so I might simply repeat some
points I made before.  Hopefully they are still valid.

First, I have a couple of higher level points to discuss:

- What's the final goal of this document?  Is it supposed to be
  published as a separate RFC, or is it just a placeholder for
  discussion for 3315bis and is supposed to be dropped once the result
  is incorporated to 3315bis?  I'm asking this because in its current
  form this document relies on the fact that readers are pretty
  familiar with the discussion context and won't be friendly for
  future readers if published as a separate document.  But if the goal
  is the latter of the above two, it's probably okay and it would be
  more constructive to just discuss purely technical matters rather
  than try to make it (more) readable for first-time readers.

- I'm not necessarily opposed to it, but why this?

> Renew/Rebind sections. The current text only provides respective updates

  If the eventual goal is to unify 3315 and 3633 in 3315bis (I
  personally didn't think it a very good idea, but I wouldn't argue on
  that point in this context), such unification will be eventually
  inevitable.  So shouldn't it rather better to discuss it sooner
  (i.e., in this draft) than later?

Specific comments to the draft text follow:

- Title: now that our main focus is the mixed use of IA_NA and IA_PD
  rather than generalizing the concept of stateful resources, I think
  it makes more sense to reflect it in the title, for example,
  "Issues and Recommendations with Multiple DHCPv6 IA Options".
  See also my comments on Section 3 (terminology) below.

- Abstract: this is more about readability (see above), but I'm afraid
  the current abstract text wouldn't be really helpful for first-time
  readers (on the other hand, it's not a problem for "me", because I
  already know what it is).  At the very least I'd briefly summarize
  the actual proposals here.  On the other hand, I don't see the
  sentence that refers to RFC 7084 in this context (it's useful in
  Introduction, but not for abstract).

- Section 1: this is not a complete sentence:

   [...] And, to provide a framework to support
   new IA option types, assuming they are similar enough.

  probably it's just expected to be a continuation of the preceding
  sentence? "requested as per [RFC7084], and to provide...".

- Section 1, regarding the same text and this one:

   [...]  Future
   documents that define new IA option types will need to specify
   whether they fit into this framework or define the DHCP operation for
   the new and existing IA option types, as appropriate.

  IMO, this document should talk a bit more about the "framework".
  I'd suggest explaining these, for example: this framework is based
  on some assumptions, including:
  - An IA option has the concept of T1/T2 values for renew and rebind,
    and the semantics is same for all these IA options types
  - The information (or a set of it) assigned in IA is associated with
    a lifetime.
  - These multiple IA options are expected to be assigned as a set,
    and it's generally considered an operator's error if a DHCPv6
    server can only provide a subset of it, even if it's not rejected
    by the protocol. (without this assumption, we could have an
    awkward situation, e.g., where a client request both IA_NA and
    IA_PD and the server only replies with IA_NA, and the client can't
    get IA_PD at least until the first renew or unless reconfigure is
    made possible)

- Section 1, on the paragraph talking about IA_TA:

   Note that while IA_TA (temporary addresses) options may be included
   with other IA option type requests, [...]

  I have a feeling that this paragraph is incomplete.  That is, I'd
  say "so what?" on reading this paragraph.  My suggestion is to
  clearly declare that the mixture of IA_TA and other types of IAs is
  out of scope of this document.  In fact, IA_TA doesn't fit in the
  framework shown in the previous bullet (as it doesn't have T1/T2),
  and we won't be able to well-define it.  And we can probably justify
  the decision based on the observation that it "has limited value".
  This paragraph would make sense if it's provided with such a
  decision.

- Section 3: now that we've limited the scope of this document
  mainly focusing on the specific case of IA_NA and IA_PD, I
  suggest simplifying the terminology.  It would be more
  reader-friendly if the reader doesn't have to understand fewer
  concepts as a prerequisite.  Specifically:
  - remove "resource".  I don't see the need for this generalized
    concept anymore.  In fact, other than in this particular section,
    this term is used only once (Section 4.1)
  - replace "stateful options" with "IA options" (and to this end we
    might not bother to list in the terminology section explicitly)

- Section 4: I suggest adding the rationale of the proposal.  In its
  current form the proposal seems to be suddenly given without
  explaining why.  Even if some hints are (seemingly) scattered in
  other sections of the document, I believe this should be the primary
  place to give it.

- Section 4.1, regarding the replacement for RFC 3315 17.2.2:

      If the server will not assign any addresses to an IA in a
      subsequent Request from the client, the server MUST include
      the IA in the Advertise message with no addresses in the IA
      and a Status Code option encapsulated in the IA containing
      status code NoAddrsAvail.

  Maybe we should also say "the server MUST NOT place a Status Code
  option for an IA at the top level".

- Section 4.2: replacement for RFC 3315 17.1.3:

     The client MUST ignore any Advertise message that contains no
     addresses (IAADDR options encapsulated in IA_NA or IA_TA options)
     and no delegated prefixes (IAPREFIX options encapsulated in IA_PD
     options, see RFC 3633) with the exception that the client
     MUST process an included SOL_MAX_RT option (RFC 7083), MUST
     process an included INF_MAX_RT option (RFC 7083), and MAY
     display any associated status message(s) to the user.

  It's awkward to see it mention prefixes while this version
  intentionally cancels the idea of "unified" text for renew/rebind.
  It's not clear to me why Section 17.1.3 (regarding advertise) still
  needs to provide "unified" text.

- Section 4.3: I don't understand the following text:

   [...] 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 times
   (larger than 0), from the same IA option, in the Reply.  T1/T2 times
   from other IAs are ignored.

  I guess it tries to address the corner case I pointed out for the
  previous version of the draft:
  http://www.ietf.org/mail-archive/web/dhcwg/current/msg15663.html
  but I don't even understand what the client would do in this case
  based on the new text.  To recap, what should happen if the client
  sees the following two sets of T1/T2 according to the above text?
  - T1a = 10, T2a = 20
  - T1b = 0, T2b = 5

- Section 4.4.5: does this mean, if the client has bindings of
  multiple IAs, it should (effectively) abandon all of the bindings
  and establish new bindings for all of the IAs starting from Solicit?
  If so, it makes sense to me, but it's not really clear from the
  text, and I suggest clarifying that point.

     When the client receives a NotOnLink status from the server in
     response to a Confirm message, the client performs DHCP server
     solicitation, as described in section 17, and client-initiated
     configuration as described in section 18.

- Section 4.4.5: I'm not sure if I understand this:

     -  Tries to obtain the IA from another server (by restarting the
        DHCP discovery process) if the client attempted to obtain a new
        binding in the Renew or Rebind message by sending an IA without
        any addresses and the server responded with NoBinding status
        code.

  What if the client has a binding for another IA (and it's
  successfully renewed in this response)?  If the above means the
  client starts a new DHCPv6 session for the IA that doesn't have a
  binding separately from the other IA with a binding, it seems to
  break the main idea of this draft: maintaining a single DHCPv6
  session for all IAs.  So does this mean the client terminates the
  existing DHCPv6 session and tries to establish all bindings for all
  IAs from Solicit?

--
JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 15 Oct 2014 16:16:36 +0000

Jinmei:

Thanks much for your thorough review!

Some comments below (inline, starting with **).

We are hopeful to receive further review comments so don't plan to publish an 08 revision until just before the IETF-91 draft deadline (Oct 27).

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of ????
Sent: Wednesday, October 08, 2014 2:23 PM
To: Marcin Siodelski
Cc: [email-masked]
Subject: Re: [dhcwg] Please review version -07 of draft-ietf-dhc-dhcpv6-stateful-issues

[...]
> Please provide your comments. Note that this work builds the ground 
> for the RFC3315bis, so your interest is important.

Here's my review.  I almost forgot the full context of the discussion regarding my previous review comments, so I might simply repeat some points I made before.  Hopefully they are still valid.

** The goal here is for this work to be an RFC. The 3315bis work is separate; obviously the 3315bis will want to incorporate the stateful issues changes. But we believe leaving the merged text to 3315bis is best. 3315bis may have other changes that impact the text in different ways.

> Renew/Rebind sections. The current text only provides respective 
> updates for RFC3315 and RFC3633.

** See above. And, yes the goal of 3315bis is to produce one document that unifies 3315 and 3633.

** We will leave the title as it is.

** We will leave the abstract pretty much as is. We change last sentence to mention that the (RFC) changes are to address the identified issues.

** See below.

   [...]  Future

** We will rework the Introduction to remove the 'framework' concept and just focus on the IA_NA/IA_PD issues. When and if there are future IA's, those documents can indicate whether they integrate into this work (i.e., add IA_foo to IA_NA, IA_PD in the stateful issues document) or if they are separate and independent.

** We plan on making this change.

** We plan on making some of these changes (stateful options will stay).

** We plan on moving this rationale into section 4 (remove from section 1).

** No change planned; we feel that the text is sufficiently clear on this when compared with the original RFC 3315 text.

** While we could drop "and no delegated prefixes (...)", does that really help significantly especially since RFC 7083 material is being pulled in already? Also, in this case if we leave it out, people may be confused about what happens if there are no addresses but prefixes. (For most of the other changes later, RFC 3633 already covers these changes as it generally implies to replace "addresses" with "delegated prefixes" in much of the Reply processing. And, we've provided the revised text where needed for 3633.) Also, RFC 3633 already points to 17.1.3 of 3315 and this avoids having to specify replacement text for 3633.

   [...] To deal

** We will include this example and explain it. Note that T1b  = 0 means that the client must calculate the T1 time (50% of lifetime) and that it obviously needs to be less than T2b. So, in this case the T1b =0, T2b = 5 would be used but the T1b time is the 'implicit' time (we can't give the value since the lifetimes are not specified).

** There are perhaps other cases, for example T1a = 10, T2a = 20, T1b = 5, T2b = 25 that are a bit more interesting since picking (b) means T1=5/T2=25 which means T2 is longer than T2a.

** Perhaps we need to review whether the shortest 'effective' T1 and independently shortest 'effective' T2 are a better choice (obviously the client would have to adjust T1 if this means T1>T2, but I'm not sure that could even happen since for any individual IA, T1 must be less than or equal to T2). Note that by 'effective' here I mean either the server supplied value or, if 0, the client determined value based on the lifetimes within that IA.  If we used that algorithm, for your case the answer would not change; for my example T1 would be and T2 would be 20 which are probably better values for this case.

** Comments about this issue (and perhaps additional case analysis if appropriate) would be useful.

** We will create a 3315bis ticket since this is pre-existing text used "as is" from 3315. And, this is not an issue that is particular to this draft. Note that Confirm is IA_NA (IA_TA) specific as IA_PD requires a Rebind; so this is an open issue in the original 3315 and should be added by the bis document. It also is more of a clarification, rather than a "change". The bis document can clarify that when a client sends a Solicit, it MUST not be using any of the addresses or delegated prefixes for the bindings included in the Solicit.

** Note also that it appears the original 3315 text missed specifying the actions for NotOnLink for Renew and Rebind.

** We've opened a new DHCPv6bis ticket for this - http://trac.tools.ietf.org/group/dhcpv6bis/ticket/123.

** Yes, this seems to have been done in error. We will revise. Restarting DHCP discovery process should only be done if there are no addresses/prefixes at all.

--
JINMEI, Tatuya

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

---

From: 神明達哉 <[email-masked]>
Date: Thu, 16 Oct 2014 10:33:59 -0700

At Wed, 15 Oct 2014 16:16:36 +0000,
"Bernie Volz (volz)" <[email-masked]> wrote:

> - What's the final goal of this document?
>
> ** The goal here is for this work to be an RFC.

Okay, in that case I'll also check overall readability as a separate
document for future versions.

> ** We will leave the title as it is.

Hmm, if we are going to even more focus on the specific case of the
mix of IA_NA and IA_PD as you'll mention below, and also if it's
supposed to be published as a single document, I'd avoid making the
tile too generic.  So, I'd even make it more specific such as

    Issues and Recommendations with Mixed Use of DHCPv6 Address
    Assignment and Prefix Delegation

But it's ultimately up to the authors.  If the authors still thinks
the current title is the best, I won't insist further.

>   already know what it is). [...]
>

Ditto.  But I'll see how the abstract of the next version will look
like.

[...]
[...]
> ** We will rework the Introduction to remove the 'framework' concept and just focus on the IA_NA/IA_PD issues. When and if there are future IA's, those documents can indicate whether they integrate…

Okay.

> ** While we could drop "and no delegated prefixes (...)", does that really help significantly especially since RFC 7083 material is being pulled in already? Also, in this case if we leave it out, p…

I wouldn't necessarily insist on it, it just looks awkward to me but
otherwise is not really a problem.  Maybe it helps if you note that
you're providing unified text with the reason of why (e.g., because
RFC 3633 doesn't describe its own version of this behavior but just
refers to RFC 3315.)

> ** We will include this example and explain it. Note that T1b  = 0 means that the client must calculate the T1 time (50% of lifetime) and that it obviously needs to be less than T2b. So, in this ca…

Hmm, then the phrase "(larger than 0)" can be misleading.

> ** There are perhaps other cases, for example T1a = 10, T2a = 20, T1b = 5, T2b = 25 that are a bit more interesting since picking (b) means T1=5/T2=25 which means T2 is longer than T2a.

Personally, I'm okay with just dismissing such a case as a server
misconfiguration (as we basically require the server use the same
T1/T2 values for all IAs).  I'd be fine unless a compliant client
behavior leads to a clearly broken result, such as T1 > T2.

> ** Perhaps we need to review whether the shortest 'effective' T1 and independently shortest 'effective' T2 are a better choice (obviously the client would have to adjust T1 if this means T1>T2, but…

See above.  IMO it doesn't have to be too complicated and we can
basically leave it to the diligence of the server
implementation/operation.  All I want to see is a clear and
well-defined client behavior.

> ** We will create a 3315bis ticket since this is pre-existing text used "as is" from 3315. And, this is not an issue that is particular to this draft. Note that Confirm is IA_NA (IA_TA) specific as…

I'm not sure if I understand this as a response to my comment...to
clarify my point, what I wanted to raise is what should happen if:

- A client with bindings for both an IA_NA and an IA_PD detects it may
  have moved to a different link, so sends a Confirm for the IA_NA.
- The client receives a NotOnLink status in response to it.

Should the client (effectively) discards the binding for IA_PD (and
for IA_NA) and try to establish new bindings for both?  Or should it
keep the binding for IA_PD (but it would break the proposed model of
this draft)?  I thought the intent is the former, and I thought it's
not clear enough and suggested to clarify it in the text.

--
JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 16 Oct 2014 18:13:30 +0000

Hi:

>Hmm, then the phrase "(larger than 0)" can be misleading.

Well, what this was there for was to indicate that if there were no IAADDR/IAPREFIX options or the lifetimes were all 0, the "effective" T1 (and T2) for this IA_NA or IA_PD would be 0 and we would NOT want to use that. If the "effective" T1 is 0, we want the client to skip that set of T1/T2 values.

In this case, the server would have had to send 0 not because it didn't calculate the T1/T2 values, but because that is what the values are. But the client is told that if these values are 0, it needs to calculate them (from the lifetimes in that IA). Thus the resulting ("effective") values are 0 too. And we don't want the client to Renew/Rebind immediately?

Regarding your issue with Section 4.4.5, if a client has both an IA_NA and IA_PD, it uses the Rebind message - not Confirm (see 4.5).

So:

>I'm not sure if I understand this as a response to my comment...to clarify my
>point, what I wanted to raise is what should happen if:
>
>Should the client (effectively) discards the binding for IA_PD (and for IA_NA)
>and try to establish new bindings for both?  Or should it keep the binding for
>IA_PD (but it would break the proposed model of this draft)?  I thought the
>intent is the former, and I thought it's not clear enough and suggested to
>clarify it in the text.

And for Rebind processing (RFC 3315, but also applies to 3633):

   If the server finds that any of the addresses are no longer
   appropriate for the link to which the client is attached, the server
   returns the address to the client with lifetimes of 0.

The question then is what happens if the client ends up with only non-zero lifetimes for IAADDR or IAPREFIX options, but not the other (or more simply some IA option ends up with no addresses/prefixes, but another binding might have them).

This might be something to review in terms of RFC 3315 as I don't think it addresses this question.

The replacement text here (4.4.5, replacement text for Section 18.1.8 of RFC 3315):

     If the client finds no usable addresses in any IA, the client MAY
     use the Information-request message to obtain other configuration
     information only.

The 3315 text is:

   If the client receives no addresses in
   any of the IAs, it may either try another server (perhaps restarting
   the DHCP server discovery process) or use the Information-request
   message to obtain other configuration information only.

So, we can revisit how best to address this but some of this are flaws that are in the base 3315 document.

This is also more significant now that allocating new addresses or delegating new prefixes is problematic for a Rebind (see 4.4.7.  Updates to Section 18.2.4 of RFC 3315) because of multiple servers processing the Rebind.

Marcin and I will discuss to see what we might do about this issue.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
Sent: Thursday, October 16, 2014 1:34 PM
To: Bernie Volz (volz)
Cc: Marcin Siodelski; [email-masked]
Subject: Re: [dhcwg] Please review version -07 of draft-ietf-dhc-dhcpv6-stateful-issues

> ** The goal here is for this work to be an RFC.

Okay, in that case I'll also check overall readability as a separate document for future versions.

> ** We will leave the title as it is.

Hmm, if we are going to even more focus on the specific case of the mix of IA_NA and IA_PD as you'll mention below, and also if it's supposed to be published as a single document, I'd avoid making the tile too generic.  So, I'd even make it more specific such as

But it's ultimately up to the authors.  If the authors still thinks the current title is the best, I won't insist further.

> ** We will leave the abstract pretty much as is. We change last sentence to mention that the (RFC) changes are to address the identified issues.

Ditto.  But I'll see how the abstract of the next version will look like.

[...]
[...]

Okay.

> ** While we could drop "and no delegated prefixes (...)", does that really help significantly especially since RFC 7083 material is being pulled in already? Also, in this case if we leave it out, p…

I wouldn't necessarily insist on it, it just looks awkward to me but otherwise is not really a problem.  Maybe it helps if you note that you're providing unified text with the reason of why (e.g., because RFC 3633 doesn't describe its own version of this behavior but just refers to RFC 3315.)

> ** There are perhaps other cases, for example T1a = 10, T2a = 20, T1b = 5, T2b = 25 that are a bit more interesting since picking (b) means T1=5/T2=25 which means T2 is longer than T2a.

Personally, I'm okay with just dismissing such a case as a server misconfiguration (as we basically require the server use the same
T1/T2 values for all IAs).  I'd be fine unless a compliant client behavior leads to a clearly broken result, such as T1 > T2.

> ** Perhaps we need to review whether the shortest 'effective' T1 and independently shortest 'effective' T2 are a better choice (obviously the client would have to adjust T1 if this means T1>T2, but…

See above.  IMO it doesn't have to be too complicated and we can basically leave it to the diligence of the server implementation/operation.  All I want to see is a clear and well-defined client behavior.

> ** We will create a 3315bis ticket since this is pre-existing text used "as is" from 3315. And, this is not an issue that is particular to this draft. Note that Confirm is IA_NA (IA_TA) specific as…

I'm not sure if I understand this as a response to my comment...to clarify my point, what I wanted to raise is what should happen if:

Should the client (effectively) discards the binding for IA_PD (and for IA_NA) and try to establish new bindings for both?  Or should it keep the binding for IA_PD (but it would break the proposed model of this draft)?  I thought the intent is the former, and I thought it's not clear enough and suggested to clarify it in the text.

--
JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 16 Oct 2014 19:08:07 +0000

I forgot to mention that both of these issues are related - since the issue you raised for 4.4.5 can result in the 0 lifetimes (hence 0 T1/T2).

And, perhaps a result of whatever we work out is that whatever T1/T2 times are determined may not be used in this case - if the client, for example, is supposed to take some other action (return to Renew or perhaps restart the configuration process).

Part of the problem with this stateful issues work is that it has exposed a lot of issues that have existed in RFC 3315. And, it seems that the choices at this time are:
1. Ignore some of those issues for now and address in 3315bis (limit scope of stateful issues draft),
2. Drop the stateful issues and work only on 3315 bis to fix (hopefully) all of these issues.

The original plan was for the stateful issues draft to provide interim changes and guidance mostly for the CPE issues, not to correct all of the 3315. This would also be good input to the 3315bis work and we would have agreed upon solutions (and not be debating these during the bis work - of course, the stateful issues turned out to be much more complex and not as quick as we had hoped).

My own feeling is that:
- If a server receives a Solicit or Request, it SHOULD assume that the client is NOT using the addresses or prefixes therein.
- If a server receives a Renew or Rebind, it MUST assume that the client is presently using the addresses or prefixes therein.
- Confirm is close to Renew/Rebind.

So let's take the case where a client has an IA_NA with one or more addresses and a IA_PD with one or more prefixes.

If the client sent a Renew and the Reply has 0 lifetimes for EITHER (but not both) the IA_NA or IA_PD. What should the client do?
- If it sends another Renew, that probably won't get it anywhere since what would have changed?
- If it sends a Request, that probably won't get it anywhere either? (And this might mean it has to 'drop' what it can still use as we generally want to the client to "request" everything at once - not just a single IA option as that leads to the split state machine.)
- So, that leaves the client with two choices:
1) Use what it has and at T1, send a Renew with both IA_NA and IA_PD again (one will be 'empty').
2) Return to Solicit (and since we want the client to have one state machine), that means it MUST stop using anything left from either IA and Solicit for both (in this case, it could provide its "old" addresses/prefixes as hints).

If the client sent a Rebind (either because it has reached T2 or this is a "confirm") and the Reply has 0 lifetimes for EITHER (but not both) the IA_NA or IA_PD:
- In this case, sending a Renew [to the server that replied] might help since perhaps the server may not have been able to assign new addresses/prefixes. This is also the reason we wanted this case to be communicated to the client by sending it NoAddrsAvail/NoPrefixAvail. Though looking back at that changed text, it only covers the case when the server didn't find the binding - not when it had the binding but might have had new addresses (prefixes) to assign so we may want to clarify that. In this case, the IA in the Reply would include both IAADDR/IAPREFIX options and a Status Code of NoAddrsAvail/NoPrefixAvail. But perhaps we don't need a change to the text and can just have the client determine that the IA ended up empty and to try the Renew.
- Otherwise, I think that leaves the client the same choices as with Renew (1 & 2).

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Thursday, October 16, 2014 2:14 PM
To: 神明達哉
Cc: [email-masked]
Subject: Re: [dhcwg] Please review version -07 of draft-ietf-dhc-dhcpv6-stateful-issues

Hi:

So:

>Should the client (effectively) discards the binding for IA_PD (and for 
>IA_NA) and try to establish new bindings for both?  Or should it keep 
>the binding for IA_PD (but it would break the proposed model of this 
>draft)?  I thought the intent is the former, and I thought it's not 
>clear enough and suggested to clarify it in the text.

The 3315 text is:

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
Sent: Thursday, October 16, 2014 1:34 PM
To: Bernie Volz (volz)
Cc: Marcin Siodelski; [email-masked]
Subject: Re: [dhcwg] Please review version -07 of draft-ietf-dhc-dhcpv6-stateful-issues

[...]
[...]

Okay.

---

From: 神明達哉 <[email-masked]>
Date: Fri, 17 Oct 2014 10:27:25 -0700

At Thu, 16 Oct 2014 18:13:30 +0000,

> In this case, the server would have had to send 0 not because it didn't calculate the T1/T2 values, but because that is what the values are. But the client is told that if these values are 0, it ne…

To be accurate: "if these values are 0", the client can send next
renew at any timing (slightly different from "the client is told to
calculate it") per Section 18.1.3 of RFC 3315:

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

And, since it's up to the client how to calculate the value, the
"effective" value is not necessarily 0.

Obviously, we wouldn't want immediate (and repeated) renew/rebind if
the calculated value is somehow 0.  RFC 3315 is just silent about
these corner cases, and in my understanding it's left to implementor's
choice.  In a DHCPv6 client I'm relatively familiar with, it sets T2 to
30 (sec) and T1 to 18:

        /*
         * Be proactive for too-small timeout values.  Note that
         * the adjusted values may make some information expire
         * without renewal.
         */
        if (ia->t2 < DHCP6_DURATION_MIN) { /* DHCP6_DURATION_MIN=30*/
            ia->t2 = DHCP6_DURATION_MIN;
            ia->t1 = ia->t2 * 5 / 8;
        }

Anyway, these are minor technicality in this context.  As I said
in my previous message, I'm okay with any sensible and clearly-written
behavior since the basic assumption is T1/T2 and lifetimes should be
same for all IAs and other cases are exceptions.  I just tried to say
that the current text of the draft is not clear enough.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Fri, 17 Oct 2014 10:32:47 -0700

At Thu, 16 Oct 2014 19:08:07 +0000,

> If the client sent a Renew and the Reply has 0 lifetimes for EITHER (but not both) the IA_NA or IA_PD. What should the client do?

I've not considered all of the ramifications (and, frankly, I've not
read all of this response closely), this breaks basic operational
assumption (i.e., all lifetimes and T1/T2 should be same for all IAs),
right?  If so, we might rather not try to be perfect but just make
sure that client ends up with a valid state (like having T2 < T1) and
leave other details open.

--
JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 17 Oct 2014 19:01:30 +0000

Jinmei:

We have to handle EXISTING servers which I believe base the T1/T2 times on each IA separately - though that is just my assumption -- I haven't analyzed all of the servers. Obviously this also depends on the lifetimes configured (i.e., if they are all the same and the server assigns the addresses/PDs are the same time, the lifetimes should generally all be identical and hence so should the T1/T2 times).

This is the point about the client text - it is there to handle the case where the client is communicating with an older (3315 compliant) server. If we required all servers to be magically updated, we wouldn't need the client text.

And, yes, I was not trying to be too explicit about this because how a client choses to implement this is up to it. For example, it might just schedule timers to expire for each IA based on its T1/T2 times. But when the first timer goes off, it includes all bindings from that server in the Renew. So, in this case the client has no need to "compare" the T1/T2 times at all.

Perhaps that is a way to solve this problem - perhaps the text should focus on the behavior to say that:

"The client SHOULD Renew (or Rebind) all of the bindings at once, whatever the individual IA T1/T2 times might have been. How a client handles this (whether it determines one set of T1/T2 values to use across all bindings, initiates independent timers and the first one to go off results in a Renew (or Rebind) with all bindings, or some other approach), is up to the client implementation."

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
Sent: Friday, October 17, 2014 1:33 PM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: [dhcwg] Please review version -07 of draft-ietf-dhc-dhcpv6-stateful-issues

> If the client sent a Renew and the Reply has 0 lifetimes for EITHER (but not both) the IA_NA or IA_PD. What should the client do?

I've not considered all of the ramifications (and, frankly, I've not read all of this response closely), this breaks basic operational assumption (i.e., all lifetimes and T1/T2 should be same for all IAs), right?  If so, we might rather not try to be perfect but just make sure that client ends up with a valid state (like having T2 < T1) and leave other details open.

--
JINMEI, Tatuya

---

From: Marcin Siodelski <[email-masked]>
Date: Mon, 20 Oct 2014 13:24:52 +0200

How about this text:

   "To deal with the case where servers have not yet been updated
    to that, clients MUST select the T1/T2 times from a single IA
    option and the selected T1/T2 times must guarantee that the client
    will send Renew/Rebind messages not later than at T1/T2 times associated
    with any of the client's bindings. The details how the server
    chooses IA with the candidate T1/T2 times is out of scope for
    this document."

?

Marcin

---

From: 神明達哉 <[email-masked]>
Date: Mon, 20 Oct 2014 10:17:40 -0700

At Fri, 17 Oct 2014 19:01:30 +0000,

> This is the point about the client text - it is there to handle the case where the client is communicating with an older (3315 compliant) server. If we required all servers to be magically updated,…

I thought the mixed use of different IAs (especially of different
types) is largely unspecified and we cannot reasonably expect
interoperability anyway (in fact, hence this draft, right?).  And, if
we cannot expect a specific behavior from the server side, I don't see
much point in trying to specify how the client should deal with them.
It seems to be simpler if we just say

- if you want to deploy mixed use of IAs in an interoperable manner,
  make sure all servers and clients are updated according to this
  clarification.
- otherwise, such mixed use may or may not work.  do it at your own
  risk.

> "The client SHOULD Renew (or Rebind) all of the bindings at once, whatever the individual IA T1/T2 times might have been. How a client handles this (whether it determines one set of T1/T2 values to…

Looks good (enough) to me.  I'd also note that as long as servers are
implemented (and operated) based on this update (and that's the
recommended way of operation with mixed use of IAs), T1 and T2 should
have the same values for all IAs, and the client behavior should be
trivial and deterministic.

--
jinmei

---

From: 神明達哉 <[email-masked]>
Date: Mon, 20 Oct 2014 10:18:32 -0700

At Mon, 20 Oct 2014 13:24:52 +0200,

>     chooses IA with the candidate T1/T2 times is out of scope for

This also looks fine to me.

--
JINMEI, Tatuya

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 21 Oct 2014 21:04:24 +0000

I have been asleep at the wheel and should have posted this a long time ago.
Below are my comments based on the state of the document immediately
after the Toronto meeting. Not sure whether some/all of these are OBE.

Thanks - Fred
[email-masked]

Comments:
*********
1) Abstract, would it be better to say:

  "IPv6 Prefix Options for Dynamic Host Configuration Protocol
   (DHCP) version 6 has since shoe-horned a new option for Prefix
   Delegation into DHCPv6." ?

2) Introduction, first paragraph, same suggestion as 1).

3) Section 4.2, suggested replacement text for Section 17.1.3,
   should it also say:

     ...that contains no
     addresses (IAADDR options encapsulated in IA_NA or IA_TA options),
     no delegated prefixes (IAPREFIX options encapsulated in IA_PD
     options, see RFC 3633) nor any future options ...

4) Section 4.2, final paragraph, I notice in several places the
   document says "without any addresses and delegated prefixes".
   Would it be better at the top of the document to define
   "stateful information" as something like: "addresses, prefixes,
   and/or any future options". Then throughout the document, you
   can just talk about "stateful information" when you want to
   include all of the above. Just an organizational thought - not
   critical to the understanding of the document.

5) Section 4.4.3, third paragraph, again it says "for all IA_NA
   and IA_PD options" - should it also say "for all future
   options of this nature" ? Same as with comments 3) and 4),
   should the document as a whole be reworded to be more
   inclusive to talk about future options in addition to
   IA_NA and IA_PD? (Maybe not - up to you.)

6) Final paragraph of P.10 has text very much like what I was
   trying to infer in comments 3), 4), and 5) above where it
   says:

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

   Throughout the rest of the document, saying "or other option
   appropriate for the type of the resource" would satisfy the
   "future options" forward compatibility.

7) Near the bottom of page 13, I am having trouble parsing the
   following sentence:

     "In the case when the client included addresses in the IA,
     included addresses are appropriate for the link to which the
     client's interface is attached according to the server's explicit
     configuration information and they are not in use, the server MAY
     allocate these addresses to the client. "

   it looks like it is missing conjunctions, punctuation, or both,
   but it just doesn't "read well" to me. Could be a matter of
   personal opinion.

8) Section 4.5.2, final paragraph where it says:

                       "If the IA_PD contains no prefixes or
                       the prefixes are appropriate for the link to
                       which the requesting router's interface is
                       attached according to the delegating router's
                       explicit configuration information and if
                       prefixes are not in use, the delegating router
                       MAY assign prefixes to this IA_PD."

  Is "MAY" strong enough here? What if the client is depending
  on this particular type of behavior. Should it be a "SHOULD"
  instead?

9) Section 4.5.3, editorial, first sentence of paragraph 2 should
   say "The client also includes *an* IA option...".

---

From: Marcin Siodelski <[email-masked]>
Date: Wed, 22 Oct 2014 22:23:02 +0200

> not clear enough and suggested to clarify it in the text.

Jinmei,

To clarify your example. In case the client has both IA_NA and IA_PD,
the client will not send a Confirm message, but will rather use a Rebind
message and include both IA_NA and IA_PD in this Rebind message. From
the stateful issues draft:

"IA_PD requires verification that the server has the binding for the
   IAs.  In that case a client MUST use the Rebind message in place of
   the Confirm message and it MUST include all of its bindings, even
   address IAs."

As a result, the client will not receive a NotOnLink status code in this
case, because NotOnLink is not sent in response to a Rebind message.

Nevertheless, we agree that there are other cases when the client should
or must "restart the server discovery process" and RFC3315 is not
specific what the client should do with the valid bindings that the
client has been using so far. We believe that this is a generic problem
in the RFC3315 (not really specific to the scope of the stateful issues
draft) and the RFC3315bis is the best place to clarify it. I submitted
the ticket to cover it in the RFC3315bis doc:
http://trac.tools.ietf.org/group/dhcpv6bis/ticket/126

Marcin