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

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

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