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

[Marcin Siodelski <[e-mail]>]

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

On 09/07/14 21:01, 神明達哉 wrote:
> At Wed, 9 Jul 2014 17:07:40 +0000,
> "Bernie Volz (volz)" <[e-mail]> wrote:
> 
>> Yes, #2 is our hope.
> 
>>> The nuance is subtle here, so please let me be sure: which one is
>>> (more) correct?
>>> 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.
> 
> 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.

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

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

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.

> 
> - Section 3: s/An example/Examples/ or s/are/is/
>                                    stateful options.  An example of the
>                                    resources are: IPv6 address or an

Ok, thanks.

> 
> - Section 3: I don't understand what this refers to:
>                                    (see "identity association
>                                    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.

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

Probably "resources" would be better.

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

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

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.


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

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

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

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.


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

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

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

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

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

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.

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

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.

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

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.

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

It could.

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

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

Marcin