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

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

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:[e-mail]] On Behalf Of Bernie Volz (volz)
Sent: Thursday, October 16, 2014 2:14 PM
To: 神明達哉
Cc: [e-mail]
Subject: Re: [dhcwg] Please review version -07 of draft-ietf-dhc-dhcpv6-stateful-issues

Hi:

Regarding:

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

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: [e-mail] [mailto:[e-mail]] On Behalf Of ????
Sent: Thursday, October 16, 2014 1:34 PM
To: Bernie Volz (volz)
Cc: Marcin Siodelski; [e-mail]
Subject: Re: [dhcwg] Please review version -07 of draft-ietf-dhc-dhcpv6-stateful-issues

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

> First, I have a couple of higher level points to discuss:
>
> - 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.

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

> - 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). [...]
>
> ** 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.

> - Section 1, regarding the same text and this one:
[...]
>   IMO, this document should talk a bit more about the "framework".
[...]
> ** 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.

Okay.

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

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

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

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

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.

> ** Comments about this issue (and perhaps additional case analysis if appropriate) would be useful.
>
> - 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.
>
> ** 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.

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
_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg