WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

Bernie Volz (volz)

Hello:

 

The co-authors believe that all of the issues reported for the last August WGLC on draft-ietf-dhc-rfc3315bis-05 have now been resolved. But, because of the large number of changes, the DHC WG co-chairs feel another “WGLC” is appropriate.

 

Please review this document and provide your comments and whether you support the document moving forward by May 30th, 2017. The DHC WG co-chairs will again ask Ralph to evaluate the responses. We are doing a 3 week WGLC as the document is rather large and important to get right!

 

Please see https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-08.

 

If you’d like to see the differences from the 05 version, use the diff tool at https://tools.ietf.org/rfcdiff:

 

https://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-dhc-rfc3315bis-08.txt&url2=https://tools.ietf.org/id/draft-ietf-dhc-rfc3315bis-05.txt

 

The list of issues we recorded and action/assignee details are at https://docs.google.com/spreadsheets/d/1c3obOwmRQDldw0u_kv85B5Q4LnjnmvUp2MmsHDGmW98 (some additional issues are in https://trac.tools.ietf.org/group/dhcpv6bis/report).

 

One very recent change to highlight is https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-08#section-18.2.12 – this was to address a criticism that DHCPv6 is not responsive enough for some network configuration changes.

 

The co-authors thank those that reviewed this document during the previous WGLC and hope that those same reviewers (and hopefully more) will endeavor to do one more thorough review of the document.

 

-          Tomek & Bernie


_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

kkinnear
Folks,

I did a pretty complete review of the document, and while most of the
first issues I found were editorial, I found a number of technical
issues as I went along.  Of the 33 issues I found (all of which I felt
important enough to write down), the following stand out as
particularly important:

Editorial: #8, #23

Technical: #10, #14, #15, #16, #17, #20.5, #21, #22, #26
           #27, #28, #30, #31, #32

I have read this document, and I approve its moving forward.

I would very much like to see the issues I've highlighted above
addressed, either by taking my suggested corrections, or by explaining
why the document is correct as it stands.  

As it happens, a few of the issues I found were from RFC 3315
and not added by the -bis process.  But, as I commented below,
that doesn't make them correct.  

Here are the issues:

1. Section 11, para 2, "such are those" -> "such as those"

2. Section 11, para 3, last sentence, "as specfic in" -> "as specified in"

3. Section 13.2, para 4, "... with additional condition that the new
   address is not duplicated with any assigned addresses" ->
   "... with the additional condition that any new address is not
   the same as any assigned address."

4. Section 13.2, para 7, "of temporary address is unlinkability of different
   actions over time." -> "of a temporary address is to make it
   difficult to link the address to different actions over time."

5. Same as above, "though DHCP provides such possibility" ->
   "though DHCP provides for such a possibility"

6. Section 14.2, list with 3 elements.  I think we want to remove
   the ", and" at the end of item 2, the comma at the end of item
   1, and the period at the end of item 3.  In particular, the
   ", and" kind of implies that item 2 and item 3 are linked, but I
   don't think they are.

7. [retracted correction: diff had a problem not present in the actual draft]

8. Section 18, para 5.  Paragraph beginning with "The client has many..."
   and containing a list with 4 elements.  This list appears to have been
   moved to the first part of the section and slightly improved there,
   and it looks like this older version of the list should have been
   deleted.

9. Section 20.4.1.  para 3 (or 2, depending on how you count).  
   "The format of the Authentication information..."
   -> "The format of the authentication information ...".  In the option
   description (21.11), "authentication information" is not capitalized.

10. Section 20.4.3, para 1, "... in the initial Reply ..." -> "... in an
    Authentication option in the initial Reply ..."

11. Section 21.4, para 2 after table after Figure 15. "Each IA_NA ... attached
    to." -> "Each IA_NA carries one "set" of non-temporary addresses; it is up
    to the server policy to determine how many addresses are assgined,
    but typically at most one address is assigned from each prefix assigned to
    the link to which the client is attached."  Note removal of double quote
    before 'it' as well as improved wording.

12. Section 21.5, para 6 after table after Figure 16. "... MAY request that
    valid lifetime ..." -> "... MAY request that the valid lifetimes ...".
    Two changes, added "the", and made lifetime plural.  I'm not positive
    about making lifetime plural here, please validate that.

13. Same para as #12, "Extending only valid but not preferred ..." ->
    "Extending only the valid but not the preferred ..."

14. Section 21.6, para 1.  The last sentence "The Options fields
    of the IA_NA or IA_TA option encapsulates those options that are
    specific to this address." hasn't changed since the -05 draft, but
    it *is* different from RFC 3315, which said: "The Options field
    encapsulates those options that are specific to this address."
    I find the current language confusing.  Why would the Options
    field of the IA_NA or IA_TA encapsulate options that are specific
    to this address, when there can be multiple IA Address options in
    an IA_NA or IA_TA?  I would have expected this sentence to read
    "The IAaddr-options field encapsulates those options that are
    specific to this address.", since there seems to be no other
    point to having an IAaddr-options field.  But in any case, this needs
    to be figured out and fixed, as it is plenty confusing as it now
    stands.

15. Section 21.7, para 1 after table after Figure 18.  

    Sections 21.24 and 21.25 state that the SOL_MAX_RT and
    INF_MAX_RT options MUST always be in every Option Request option.
    But this is contradicted by Table 1, which says that they MUST
    only appear for certain message types.  I believe that Table 1
    is in fact more correct than the statements in Section 21.24 and 21.25.
    In which case, I would suggest that a new sentence be added here:
    "For certain message types, some Option codes MUST be included
    in the Option Request option, see Table 1 for details."

    And, Sections 21.24 and Section 21.25 should be corrected to
    mention the message type qualification:

    Section 21.24, para 1 after table after Figure 38:
    "A DHCP client ... it sends." -> "A DHCP client ... it sends in
    a SOLICIT message."

    Section 21.25, para 1 after table after Figure 39:
    "A DHCP client ... it sends." -> "A DHCP client ... it sends in
    an Information-request message."

16. Section 21.7, para 2 after table after Figure 18. "Only container
    options MUST appear in the Option Request," --- I think that this
    is simply incorrect.  The better way to say this would be "Only container
    options MAY appear in the Option Request option,", but that is also
    incorrect.  I believe that the statement is "Only top-level options
    MAY appear in the Option Request option."  The next sentence
    should then be: "Options encapsulated in a container option MUST
    NOT appear in an Option Request option, see [RFC7598] as an
    example of container options."  

17. same as #16.  I think the last sentence should be replaced with
    "Options MAY be defined which specify exceptions to the restriction
    on including encapsulated options in an Option Request option.  For
    example, the Option Request option MAY be used to signal support for
    a feature even when that option is encapsulated, as in the case of the
    Prefix Exclude option [RFC6603].  See Table 1."

18. Section 21.11, Authentication Option.  In Figure 22, there is
   "auth-info" at the start of the "authentication information" section.
   I would remove the "auth-info", since this field is actually known
   as "authentication information" in the table below Figure 22.  I
   don't think the "auth-info" label adds any value, and is rather
   inconsistent and might be confusing.

19. Section 21.14, DISCUSSION, para 1.  Last sentence, RFC references
    have extraneous () around references.

20. Same as #19, para 2.  Replace with "The problem of unused leases can be
    minimized by designing the DHCP service so that only one server responds
    to the Solicit, by using relatively short lifetimes for newly assigned
    leases, or by having DHCP clients release unused leases using the
    Release message."  Whether or not this paragraph is used, the
    word "initiatively" isn't commonly used, and some references
    label it "nonstandard" and others show it from the late 1700's.
    I don't think it belongs in an RFC.

20.5 Section 21.16, last sentence.  "Each instance of
     OPTION_VENDOR_CLASS can carry multiple sub-options."  I see
     no sub-options at all here, using the definition of sub-option
     from RFC 7227 (see item #21 for a link to the relevant section
     of this RFC).  I see two possible things that this sentence
     could be trying to say:

     a) "Each instance of OPTION_VENDOR_CLASS can carry multiple
        enterprise-number and vendor-class-data pairs."

     b) "Each instance of OPTION_VENDOR_CLASS can carry multiple
        instances of vendor-class-data, all relating to the same
        enterprise-number."

    I don't know which was intended, if either. Or, possibly, both.
    I know that (b) is true, and I'm pretty sure that (a) is true
    but I could be wrong about that.  If it is true, then it would
    be really good to confirm it here.  This sentence is new since
    RFC 3315.

21. Section 21.17.  This section uses the term "encapsulated options"
    throughout, which I believe is technically incorrect.  See:
    https://tools.ietf.org/html/rfc7227#section-9 
    which explains the distinction between "encapsulated options"
    and "sub-options" really well.  I believe that this section
    should be discussing "sub-options", not "encapsulated options",
    per RFC 7227.   My suggestion would be to rename the "option-data"
    field in Figure 30 as "sub-option-data", to distinguish it from
    the "option-data" field in Figure 31.  And replace the "option-data"
    line in the table after Figure 30 with:

    "sub-option-data    Sub-options, interpreted by vendor-specific
                        code on the clients and servers."
   
    I would replace the paragraph before Figure 31 with:
    "The sub-option-data field MUST be encoded as a sequence of
    code/length/value fields identical in format to the DHCP
    options field (see Section 21.1).  The sub-option codes are defined
    by the vendor identified in the enterprise-number field, and are
    not managed by IANA.  See Section 9 of [RFC7227].
    Each of the sub-options is formatted as follows:"

    In the table below Figure 31:

    "opt-code           The code for the sub-option.

    option-len          An unsigned integer giving the length of the
                        option-data field in this sub-option in
                        octets.

    option-data         The data area for the sub-option."

    Replace the last line of the para 1 after the table after Figure 31:
    "... MAY contain multiple encapsulated options." -> "... MAY contain
    multiple sub-options."

22. Section 21.21, para 6 after table after Figure 35.  This paragraph
    makes no sense.  In RFC 3633 (the PD RFC), this paragraph talked
    about which numbers to put in T1 and T2.  Now, it talks about
    T1 and T2 "fields" and T1 and T2 "parameters".  The way it comes
    out now, it seems like it is talking about what the *client*
    should be doing with the T1 and T2 fields, not the server.  In
    which case, the sentence should start out "In a message sent
    by a server to a client, the client MUST use..." This is exactly
    what the text in the IA_NA option says, for what that is worth.

    But as it is, it can't be correct.

23. Section 21.22, para 3 after table after Figure 36.  This sentence
    also appears (slightly differently) in Section 21.6, the IA
    Address option.  "A client discards any prefixes for which the
    preferred lifetine is greater than the valid lifetime."  Shouldn't
    this be "A client MUST discard any prefixes..." in both
    sections?  

24. Section 23, para 1, sentence 2.  Replace "of said document" with
    "of that document".

25. Section 27.1, Normative References.  I think that RFC 7227
    should be normative because if its discussion of the distinction
    between encapsulated options and sub-options in Section 9
    of RFC 7227.

26. Appendix B., Info Refresh Time column.  I don't understand why
    this option is shown for the Inform. message.  I believe that
    the option code for it MUST be in an Option Request option for
    an Inform. message.  But not that the option itself must be in
    the Inform. message, which is what this table is all about.
    Section 21.23 says directly that this option "MUST only appear
    in the top level option area of Reply messages.", so something
    is wrong in one of these places.  I think the table in Appendix
    B is the one that is wrong, and that the * for Info Refresh
    Time should be removed from the row titled Inform.

27. Appendix B., SOL_MAX_RT column.  I believe that the option code
    for the SOL_MAX_RT option MUST appear in an Option Request option
    in a Solicit message, but this table isn't about the Option Request
    option, it is about messages.  So I believe that this is wrong,
    and that the * for SOL_MAX_RT should be removed from the Solicit
    message row.

28. Appendix B., INF_MAX_RT column.  I can see no reason why this is
    listed as an option to appear in the Advertise message.  I think
    this is simply an error and should be removed.

29. Appendix B. Interesting that the document mentions User Class,
    Vendor Class, and Vendor Specific Options as all valid for
    Relay-Forward and Relay-Reply messages.  I'm not saying that
    isn't OK, but I didn't see anything in this document that would
    suggest anything other than an Interface Id option would go in
    a Relay-Forward or Relay-Reply message.  Maybe I missed it.

30. Appendix C.  This table is only relative to this
    document.  Some of these options can appear in other DHCPv6
    options defined in other RFC's.  That exist today, not just
    future ones.  Perhaps replacing the existing sentence "The
    following ... other options:" with "The following table indicates
    with a "*" where options defined in this document can appear
    in the options field of other options defined in this document.
    Other RFC's define additional situations where options defined
    in this document are encapsulated in other options." would make
    it more clear that this isn't the final word on what options
    can appear inside of what other options.

31. Appendix C.  The sentence describing this table is moderately
    misleading.  "where options can appear in the options field of
    other options." would seem to indicate that the column headings
    along the top of the table are all options.  However, the first
    column isn't the name of an option, it is (presumably) the
    options field of any message.  I think that we should remove
    this column, since any information that it contains is already
    covered (and in more correct detail) by the information in
    Appendix B, which discusses precisely which options can appear
    in the options field of individual messages.  If I'm wrong about
    what the "Option Field" column represents, then it would be
    good to explain it more clearly.

32. Appendix C.  Columns Relay-Forw, Relay-Reply, and Note.
    The note is just wrong, near as I can tell.  There are no
    Relay-Forw or Relay-Reply options.  There are Relay-Forward and
    Relay-Reply messages.  I think having a Relay-Forw and Relay-Reply
    column in this table is very misleading, since as I said above,
    this table seems to be for options.  These aren't options, they
    are messages.   We already have the Relay Message option allowed
    in the Relay-Forward message and Relay-Reply message in Appendix
    B.  In addition, the data there conflicts with the data here
    for the Relay-Forward and Relay-Reply messages.  I don't know
    what someone was trying to communicate here, but I think that we
    need to remove the Relay-Forw and Relay-Reply columns, and
    the Note.

    I recognize that this is left over from RFC 3315 and wasn't
    something added as part of the current process, but that doesn't
    make it right.

33. Appendix C.  If we remove the first and last two columns, as
    I think makes sense, since this information is already covered
    in Appendix B, we are left with 3 options in the left column
    that have any * in any of the right 4 columns.  Not the end of
    the world, but we could probably explain this with a sentence
    or two.  For instance: "Several options may themselves appear
    in the options field of other options defined in this document.
    The IA Address options may appear in the options field of either
    the Identity Association for Non-temporay Addresses option or
    the Identity Association for Temporary Addresses option.  The
    IA Prefix option may appear in the options field of the Identity
    Association for Prefix Delegation option.  The Status Code
    option may appear in the options field of any of the three
    Identity Association options just discussed."  I have no
    particular preference toward either approach (i.e., keep the
    table or replace it with the above paragraph), but offer the
    paragraph to show one possibility.


Thanks -- Kim

> On May 9, 2017, at 10:52 AM, Bernie Volz (volz) <[hidden email]> wrote:
>
> Hello:
>  
> The co-authors believe that all of the issues reported for the last August WGLC on draft-ietf-dhc-rfc3315bis-05 have now been resolved. But, because of the large number of changes, the DHC WG co-chairs feel another “WGLC” is appropriate.
>  
> Please review this document and provide your comments and whether you support the document moving forward by May 30th, 2017. The DHC WG co-chairs will again ask Ralph to evaluate the responses. We are doing a 3 week WGLC as the document is rather large and important to get right!
>  
> Please see https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-08.
>  
> If you’d like to see the differences from the 05 version, use the diff tool at https://tools.ietf.org/rfcdiff:
>  
> https://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-dhc-rfc3315bis-08.txt&url2=https://tools.ietf.org/id/draft-ietf-dhc-rfc3315bis-05.txt
>  
> The list of issues we recorded and action/assignee details are at https://docs.google.com/spreadsheets/d/1c3obOwmRQDldw0u_kv85B5Q4LnjnmvUp2MmsHDGmW98(some additional issues are in https://trac.tools.ietf.org/group/dhcpv6bis/report).
>  
> One very recent change to highlight is https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-08#section-18.2.12 – this was to address a criticism that DHCPv6 is not responsive enough for some network configuration changes.
>  
> The co-authors thank those that reviewed this document during the previous WGLC and hope that those same reviewers (and hopefully more) will endeavor to do one more thorough review of the document.
>  
> -          Tomek & Bernie
> _______________________________________________
> dhcwg mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

神明達哉
In reply to this post by Bernie Volz (volz)
On Tue, May 9, 2017 at 7:52 AM, Bernie Volz (volz) <[hidden email]> wrote:

> The co-authors believe that all of the issues reported for the last August
> WGLC on draft-ietf-dhc-rfc3315bis-05 have now been resolved. But, because of
> the large number of changes, the DHC WG co-chairs feel another “WGLC” is
> appropriate.
>
> Please review this document and provide your comments and whether you
> support the document moving forward by May 30th, 2017. The DHC WG co-chairs
> will again ask Ralph to evaluate the responses. We are doing a 3 week WGLC
> as the document is rather large and important to get right!

I'd still abstain about whether to advance the document as I stated
for the previous WGLC:
https://www.ietf.org/mail-archive/web/dhcwg/current/msg17577.html
but I've checked if the 08 version has addressed my LC comments.

I found some of them still open (perhaps they are intentionally left
open or unchanged, but it's not clear to me).  I'm listing them below,
with followup comments for some of them.

>> - I'm okay with deprecating the delayed authentication protocol,
>> but I'm not sure if it's okay to ship the spec with no built-in
>> authentication (the reconfigure key protocol is very limited and
>> too weak).

>> - I wonder whether we should still keep IA_TA.

>>   link-local address        An IPv6 address having a link-only scope,
>>                             indicated by having the prefix (FE80::/10),
>>  You might want to lower-case the prefix (i.e., to "fe80::/10").

This is not fully addressed as the case is still mixed (Sections 7.1
and 24 use upper case hex).

>> - Section 5.2
>>   the "stateful address autoconfiguration protocol" for IPv6 [RFC2462].
>>  s/RFC2462/RFC4862/.

and there are still more references to RFC2462.

>> - Section 5.4
>> [...] the requesting router MUST set the valid lifetime in those
>> advertisements to be no later than the valid lifetime specified in
>> the IA_PD Prefix option.
>>  "no later than" sounds awkward as the lifetime is a duration, not
>>  a particular point in time.

This is simply open as before.

>> - Section 8.1
[...]

>> site-scope unicast address has been deprecated.  Also, the phrase
>> "global or ULA" is awkward as ULA is a global (scoped) address.

The 08 version states:

                           This is typically a globally unique
                           address or unique local address (ULA)
                           [RFC4193],

This is still awkward to me, since in a sense ULAs are also "globally
unique" (even if the uniqueness is not 100% guaranteed).  Personally
I'd simply avoid mentioning ULAs unless there is a specific to reason
to refer to it in the context (and I don't see such a reason here),
but if we want to refer to ULAs here, I'd say, e.g., "a global address
(including unique local addresses)".

>> - Section 10

>> [...] The DUID is designed to be unique across all DHCP clients and
>> servers, and stable for any specific client or server - that is,
>> the DUID used by a client or server SHOULD NOT change over time if
>> at all possible;

>> I guess this property is now changing because of the privacy
>> concerns.

The main change that may be related to this comment is probably the
following new sentence:

   [...]  The client may change its DUID as specific in [RFC7844].

I personally don't think this fully addresses the point of the
comment, although I can live with it.  btw, I believe  there's a typo:
s/specific/specified/.

>> - Section 15.11

>>   -  the message was not unicast to the client.

>> I'm not sure why we bother to say this, and only for Reconfigure.
>> Is there any case where a DHCPv6 message to a client isn't
>> unicasted at all?

There doesn't seem to be any change regarding this comment.  I was not
sure if it was intentional or oversight.

>> - Section 17.1.10.1
>> "no later than" sounds awkward for these lifetimes (see also Sec
>> 5.4).

>> - Section 17.1.10.1
[...]
>> Specifically, the bullet description seems to lead to multiple
>> separate state machines for different bindings.

These two don't seem to be addressed.

>> - Section 18.1.1
>>  s/global, ULA [RFC4193] or site-scoped/global/ (see comment on Sec 8.1)

The revised text still has an issue:

   If the relay agent received the message to be relayed from a client,
   the relay agent places a global or unique local [RFC4193] address

"global or unique local" is redundant since ULAs are global addresses
(scope wise).

>> - Section 18.1.2
>> s/global or site-scoped/global/ (see above)

Same here.

>> - Section 19.4
[...]
>> This statement now sounds awkward since this is now the only
>> defined authentication protocol. (see also comment on Section
>> 17.2.2)

There doesn't seem to be any change to address this point.

>> - Section 20.7
>>   encapsulated in the container MUST NOT by in the Option Request, see
>>  s/Option Request/Option Request option/

'option' (after 'Request') is still missing.

>> - Section 20.22
[...]
>> This choice of valid/preferred lifetime in an IA prefix and the
>> (possible) relationship between them and those lifetimes advertised
>> in the delegated site do not make perfect sense to me. [...]

I don't think the revised version addresses the main point.  The new
text simply avoids saying specifics about these lifetimes, but then
it's even more unclear about what these lifetimes are (especially the
preferred lifetime).

>> - Section 20.23
[...]
>> The expected usage is not very clear to me here.  Is it intended to
>> be used for Advertise and apply the value to the ongoing
>> Solicit-Advertise exchange?  Or is it mainly intended to be used
>> for a possible subsequent restart of a DHCPv6 session?

I guess it was supposed to be addressed by the newly added paragraph
at the end of the section:

   The requirement for the client to request SOL_MAX_RT serves two
   purposes.  First, it distinguishes between legacy and modern clients.
   Second, it allows modern clients to take advantage of the
   configurable SOL_MAX_RT values, even if the server is a legacy one.

of which I don't understand the second purpose: if the server is
legacy, how the client can benefit from the option?

--
JINMEI, Tatuya

_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

Bernie Volz (volz)
Hi Jinmei:

Thanks for reviewing. Comments from me inline below (BV>).

You can view the changes to the XML made from these comments at:

https://github.com/dhcwg/rfc3315bis/commit/357e98d84f728e5909598a82672562b0889f1f13

- Bernie

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of ????
Sent: Tuesday, May 23, 2017 4:18 PM
To: Bernie Volz (volz) <[hidden email]>
Cc: [hidden email]; Ralph Droms <[hidden email]>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

On Tue, May 9, 2017 at 7:52 AM, Bernie Volz (volz) <[hidden email]> wrote:

> The co-authors believe that all of the issues reported for the last
> August WGLC on draft-ietf-dhc-rfc3315bis-05 have now been resolved.
> But, because of the large number of changes, the DHC WG co-chairs feel
> another “WGLC” is appropriate.
>
> Please review this document and provide your comments and whether you
> support the document moving forward by May 30th, 2017. The DHC WG
> co-chairs will again ask Ralph to evaluate the responses. We are doing
> a 3 week WGLC as the document is rather large and important to get right!

I'd still abstain about whether to advance the document as I stated for the previous WGLC:
https://www.ietf.org/mail-archive/web/dhcwg/current/msg17577.html
but I've checked if the 08 version has addressed my LC comments.

I found some of them still open (perhaps they are intentionally left open or unchanged, but it's not clear to me).  I'm listing them below, with followup comments for some of them.

>> - I'm okay with deprecating the delayed authentication protocol, but
>> I'm not sure if it's okay to ship the spec with no built-in
>> authentication (the reconfigure key protocol is very limited and too
>> weak).

BV> We are working on sedhcpv6 but this has not been so simple and quick. And, DHCPv6 is in use and deployed today without an authentication protocol. There are other actions that can be taken such as stated in section 22:

   Many of these rogue server attacks can be mitigated by making use of
   the mechanism described in [RFC7610].

>> - I wonder whether we should still keep IA_TA.

BV> We decided as a WG not to remove IA_TA. See https://trac.tools.ietf.org/group/dhcpv6bis/ticket/124.

>>   link-local address        An IPv6 address having a link-only scope,
>>                             indicated by having the prefix
>> (FE80::/10),  You might want to lower-case the prefix (i.e., to "fe80::/10").

This is not fully addressed as the case is still mixed (Sections 7.1 and 24 use upper case hex).

BV> OK. The FF0x: cases were just missed. This is now fixed.

>> - Section 5.2
>>   the "stateful address autoconfiguration protocol" for IPv6 [RFC2462].
>>  s/RFC2462/RFC4862/.

and there are still more references to RFC2462.

BV> This is by design. RFC4862 does not mention the M & O bits so we can't reference that RFC. We documented the reason for this in Appendix A:

   26.  ...
                                        Note that in a few
        places, older obsoleted RFCs (such as RFC2462 related to M and O
        bit handling) are still referenced as the material cited was not
        added in the replacement RFC.

BV> The other place we uses is when mentioning "stateful address autoconfiguration protocol" as RFC 4862 does not use this terminology except in Appendix C:

   o  Avoided the wording of "stateful configuration", which is known to
      be quite confusing, and simply used "DHCPv6" wherever appropriate.

BV> I hope this explains to you why we leave this reference in the 4 places (excepting Appendix A) where it is still used.


>> - Section 5.4
>> [...] the requesting router MUST set the valid lifetime in those
>> advertisements to be no later than the valid lifetime specified in
>> the IA_PD Prefix option.
>>  "no later than" sounds awkward as the lifetime is a duration, not  a
>> particular point in time.

This is simply open as before.

BV> Unless you suggest some text, we will leave this be. I think the point of the text is rather clear.

>> - Section 8.1
[...]

>> site-scope unicast address has been deprecated.  Also, the phrase
>> "global or ULA" is awkward as ULA is a global (scoped) address.

The 08 version states:

                           This is typically a globally unique
                           address or unique local address (ULA)
                           [RFC4193],

This is still awkward to me, since in a sense ULAs are also "globally unique" (even if the uniqueness is not 100% guaranteed).  Personally I'd simply avoid mentioning ULAs unless there is a specific to reason to refer to it in the context (and I don't see such a reason here), but if we want to refer to ULAs here, I'd say, e.g., "a global address (including unique local addresses)".

BV> Unless you suggest some text, we will leave it be. I don't see that this is necessarily in conflict - yes, ULA is in the "global address space". But I also think it adds value to explicitly mention ULAs here as otherwise someone could confuse the subtly that ULA is allowed.


>> - Section 10

>> [...] The DUID is designed to be unique across all DHCP clients and
>> servers, and stable for any specific client or server - that is, the
>> DUID used by a client or server SHOULD NOT change over time if at all
>> possible;

>> I guess this property is now changing because of the privacy
>> concerns.

The main change that may be related to this comment is probably the following new sentence:

   [...]  The client may change its DUID as specific in [RFC7844].

I personally don't think this fully addresses the point of the comment, although I can live with it.  btw, I believe  there's a typo:
s/specific/specified/.

BV> Thanks for catching typo, will be fixed. As you can live with it, we will leave alone otherwise.

>> - Section 15.11

>>   -  the message was not unicast to the client.

>> I'm not sure why we bother to say this, and only for Reconfigure.
>> Is there any case where a DHCPv6 message to a client isn't unicasted
>> at all?

There doesn't seem to be any change regarding this comment.  I was not sure if it was intentional or oversight.

BV> This is intentional as the specification clearly does NOT allow for multicast Reconfigure to be valid. Perhaps a future draft will support this, but for now this prohibition is appropriate.

>> - Section 17.1.10.1
>> "no later than" sounds awkward for these lifetimes (see also Sec
>> 5.4).

BV> See above.

>> - Section 17.1.10.1
[...]
>> Specifically, the bullet description seems to lead to multiple
>> separate state machines for different bindings.

BV> I believe we addressed this by other text in the document - for example, see in 18.2.4 the following text:

   The server controls the time at which the client should contact the
   server to extend the lifetimes on assigned leases through the T1 and
   T2 parameters assigned to an IA.  However, as the client Renews/
   Rebinds all IAs from the server at the same time, the client MUST
   select a T1 and T2 time from all IA options, which will guarantee
   that the client will send Renew/Rebind messages not later than at the
   T1/T2 times associated with any of the client's bindings (earliest
   T1/T2).

These two don't seem to be addressed.

>> - Section 18.1.1
>>  s/global, ULA [RFC4193] or site-scoped/global/ (see comment on Sec
>> 8.1)

The revised text still has an issue:

   If the relay agent received the message to be relayed from a client,
   the relay agent places a global or unique local [RFC4193] address

"global or unique local" is redundant since ULAs are global addresses (scope wise).

BV> See comment earlier as I think mention both does no harm and helps to clarify that it would be either.

>> - Section 18.1.2
>> s/global or site-scoped/global/ (see above)

Same here.

BV> See comment earlier as I think mention both does no harm and helps to clarify that it would be either.

>> - Section 19.4
[...]
>> This statement now sounds awkward since this is now the only defined
>> authentication protocol. (see also comment on Section
>> 17.2.2)

There doesn't seem to be any change to address this point.

BV> While it does sound a bit awkward, we left this in given seDHCPv6 work as there would be little point in using RKAP if that was used. We can remove "the client and server are not using any other authentication protocol" and assume the seDHCPv6 will make this clear.

>> - Section 20.7
>>   encapsulated in the container MUST NOT by in the Option Request,
>> see  s/Option Request/Option Request option/

'option' (after 'Request') is still missing.

BV> OK, this must have just been missed.

>> - Section 20.22
[...]
>> This choice of valid/preferred lifetime in an IA prefix and the
>> (possible) relationship between them and those lifetimes advertised
>> in the delegated site do not make perfect sense to me. [...]

I don't think the revised version addresses the main point.  The new text simply avoids saying specifics about these lifetimes, but then it's even more unclear about what these lifetimes are (especially the preferred lifetime).

BV> Unless you provide text, I think we'll leave this alone as mentioned earlier we feel that this document is not the one that should describe how these lifetimes are to be used.

>> - Section 20.23
[...]
>> The expected usage is not very clear to me here.  Is it intended to
>> be used for Advertise and apply the value to the ongoing
>> Solicit-Advertise exchange?  Or is it mainly intended to be used for
>> a possible subsequent restart of a DHCPv6 session?

I guess it was supposed to be addressed by the newly added paragraph at the end of the section:

   The requirement for the client to request SOL_MAX_RT serves two
   purposes.  First, it distinguishes between legacy and modern clients.
   Second, it allows modern clients to take advantage of the
   configurable SOL_MAX_RT values, even if the server is a legacy one.

of which I don't understand the second purpose: if the server is legacy, how the client can benefit from the option?

BV> I'm not sure why we would want this paragraph at all. So I think best to just remove it.
BV> You original question was I think about why SOL_MAX_RT MUST be in ORO. It MUST be as per RFC 7083 so that clients can get updated SOL_MAX_RT values. And, yes, the idea is that the Advertise with the SOL_MAX_RT value is used (even if it offers no leases) so that the client applies this value for any future requests. I don't see the need for this to be spelled out?

--
JINMEI, Tatuya
_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

Bernie Volz (volz)
In reply to this post by Bernie Volz (volz)

Hi:

 

I have reviewed the document and while there are some minor issues, I did not find anything major. Therefore, I do support this document moving forward (once the minor issues are corrected).

 

Most of my issues are minor typos or wording improvements and I suspect Kim and/or Jinmei’s review got most of them, so I will not waste the time to document them (I will apply the changes to the XML in the GitHub repository soon). Here are other comments which might require some discussion (at least among the co-authors):

 

[Page numbers are based on https://tools.ietf.org/pdf/draft-ietf-dhc-rfc3315bis-08.pdf.]

 

Page 25, section 8: We don’t define the “size” of the msg-type and transaction-id fields; might be worth clarifying these (1-octet and 3-octets, respectively).

 

Page 27, section 9.1: Same as above, msg-type (1-octet), hop-count (1-octet), link-address/peer-address (16-octets).

 

Page 44, section 16.11: “the message does not include DHCP authentication …”, should we explicitly say RKAP or leave general? We might also want to just say uses RKAP or some other (yet to be developed, such as <ref to sedhcpv6>) authentication?

 

Page 44, section 17: What does this 1 paragarph section intend to say/mean? (“Client’s behavior is different depending on the purpose of the configuration.”) Can we drop it? Should we say something else/more?

 

Page 45, section 8 (Kim mentioned this): There’s a bunch of text duplicated in this section (more than just the list). I do think “The client has many” and the list following should be removed. I also wonder if the later paragraph (The client is responsible for creating IAs …) should be moved up as part of the Solicit exchange (but it would need to be edited/merged in to that earlier material). The duplicated instance of “A server may initiate a message exchange” should be dropped.

 

Page 50, section 18.2 (last paragraph): The “and duplicate responses by servers” doesn’t make any sense in this regard. Unicast can only be used for instances where a single server is being addressed so it makes no sense to say this.

 

Page 51,section 18.2.1: The “after a power outage” is technically wrong as it should be “after recovery from a power outage”? We should double check if used elsewhere and correct.

 

Page 57, section 18.2.4 (last paragraph): So this says “If the terminated Renew exchange was not initiated as a result of receiving a Reconfigure message, the client begins Rebind message exchange…”. But isn’t this true even it was initiate by receiving a Reconfigure? The Renew is terminated at (earlist) T2 and a Rebind would start then anyway? This doesn’t make sense to me. I think we should just drop the “was not initiated as a result of receiving a Reconfigure message”? Or what does happen in that case that is different?

 

Page 63, section 18.2.10: (Top of page paragraph) – “The client resends the original message using multicast”. So should we qualify this to only happen if the client was using unicast (otherwise a storm could occur if “server” sends use Multicast and client retransmits using multicast)? Other option might be to say that retransmission doesn’t happen until normal timer expires? Perhaps we can let client implementers chose either one depending on what’s easier to implement for them?

 

Page 63, section 18.2.10: (2nd to last paragraph of section) – “This behavior does not apply to other IA containers, and their processing is described in detail on other parts of this document.”. I’m not exactly sure where that is described. Could we add references? Or was this intended to reference other documents that might describe containers?

 

Page 67, section 18.2.11: (top of page) “Subsequent Reconfigure messages cause the client to initiate a new exchange.” Subsequent here is a bit confusing since the text preceding just said “the client MUST ignore any additional Reconfigure messages until the exchange is complete”. Perhaps we should change subsequent to “After the exchange is complete, …”?

 

Page 68, section 18.3: (2nd to last paragraph on page) I think we can say “These Advertise and Reply messages MUST” (instead of just “This reply”)?

 

Page 68, section 18.3 (top of page paragraph) I think “reply message” should be “response message” (that was used on previous page).

 

Page 68, section 18.3 (1st full paragraph, end) I think the printing and new software examples probably aren’t that hot? DHCPv6 has no printing options so why would printing impact client configuration. And, while software might be OK given the BOOTFILE options, but it seems unlikely. Perhaps we just say when “other configuration options are updated, perhaps because servers are moved, added, or removed” or something more general?

 

Page 78 & 80, sections 18.3.9, 18.3.11: I suggest cleaning this up a bit as follows:

-          Change 18.3.9 title to remove transmission (so just “Creation of Advertise Messages”)

-          Change 18.3.9 to remove the last two paragarphs (perhaps replace with text to say “Transmission of the Advertise message is described in the next section.”)

-          Change 18.3.10 title to “Transmission of Advertise and Reply Messages”

-          Change text in 18.3.10 from using “Reply” to “Advertise or Reply”.

-          Add a reference to section 19.3 as that talks about how the server should response. This is probably better reference than just to 21.10 (which could be moved to 19.3).

 

Pages 85 & 86, sections 20.2 and 20.3 – Merge these as we could just remove the section break and the first paragraph of 20.3.

 

Page 95, section 21.6 – Drop the last sentence of first paragraph; seems broken.

 

Page 117, section 21.24 (also 118 and 21.25): Replace “in the main body of the message to client” with “top-level option”? We have “top-level option” in terminology section.

 

Page 121, section 24: Remove “IANA is requested to add a column to the DHCPv6 Option table” as next paragraph asks them to add two columns and this should be been deleted.

 

Page 136, Appendix B: The “Auth.” Option was incorrectly marked as being used in an Information-Request, but it should have been in the Reconfigure (1 line earlier). So, this needs to be moved “up”.

 

-          Bernie

 

From: dhcwg [mailto:[hidden email]] On Behalf Of Bernie Volz (volz)
Sent: Tuesday, May 09, 2017 10:53 AM
To: [hidden email]
Cc: Ralph Droms <[hidden email]>
Subject: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

 

Hello:

 

The co-authors believe that all of the issues reported for the last August WGLC on draft-ietf-dhc-rfc3315bis-05 have now been resolved. But, because of the large number of changes, the DHC WG co-chairs feel another “WGLC” is appropriate.

 

Please review this document and provide your comments and whether you support the document moving forward by May 30th, 2017. The DHC WG co-chairs will again ask Ralph to evaluate the responses. We are doing a 3 week WGLC as the document is rather large and important to get right!

 

Please see https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-08.

 

If you’d like to see the differences from the 05 version, use the diff tool at https://tools.ietf.org/rfcdiff:

 

https://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-dhc-rfc3315bis-08.txt&url2=https://tools.ietf.org/id/draft-ietf-dhc-rfc3315bis-05.txt

 

The list of issues we recorded and action/assignee details are at https://docs.google.com/spreadsheets/d/1c3obOwmRQDldw0u_kv85B5Q4LnjnmvUp2MmsHDGmW98 (some additional issues are in https://trac.tools.ietf.org/group/dhcpv6bis/report).

 

One very recent change to highlight is https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-08#section-18.2.12 – this was to address a criticism that DHCPv6 is not responsive enough for some network configuration changes.

 

The co-authors thank those that reviewed this document during the previous WGLC and hope that those same reviewers (and hopefully more) will endeavor to do one more thorough review of the document.

 

-          Tomek & Bernie


_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

神明達哉
In reply to this post by Bernie Volz (volz)
On Fri, May 26, 2017 at 10:56 AM, Bernie Volz (volz) <[hidden email]> wrote:

>>> - I'm okay with deprecating the delayed authentication protocol, but
>>> I'm not sure if it's okay to ship the spec with no built-in
>>> authentication (the reconfigure key protocol is very limited and too
>>> weak).
>
> BV> We are working on sedhcpv6 but this has not been so simple and quick. And, DHCPv6 is in use and deployed today without an authentication protocol. There are other actions that can be taken such as stated in section 22:
>
>    Many of these rogue server attacks can be mitigated by making use of
>    the mechanism described in [RFC7610].

I personally wouldn't argue that it's a blocking issue, and, to be
clear, I'm not requesting sedhcpv6 be specified as *the*
authentication protocol in rfc3315bis.  But I'd suggest chairs to
explicitly leave notes about the point for security ADs when the doc
is sent to the IESG.

>>> - Section 5.2
>>>   the "stateful address autoconfiguration protocol" for IPv6 [RFC2462].
>>>  s/RFC2462/RFC4862/.
>
> and there are still more references to RFC2462.
>
> BV> This is by design. RFC4862 does not mention the M & O bits so we
> can't reference that RFC. We documented the reason for this in
> Appendix A:

I believe at least the reference to RFC2462 in Section 6.2 is not
really appropriate:

   This model of operation was the original motivation for DHCP and is
   the "stateful address autoconfiguration protocol" for IPv6 which is
   discussed in [RFC2462].

Simply because RFC4862 doesn't use the term "stateful address
autoconfiguration protocol" doesn't make this text appropriate.
RFC2462 used the term "stateful address autoconfiguration protocol"
just because DHCPv6 wasn't fully standardized at that time.  RFC4862
just replaced it with the term "DHCPv6".  If you want suggested text,
my suggestion is simply remove the second half the sentence:

   This model of operation was the original motivation for DHCP.  It
   is appropriate for situations where stateless address
   autoconfiguration alone is insufficient or impractical, e.g.,
   because of network policy, additional requirements such as dynamic
   updates to the DNS, or client-specific requirements.

As for the references to RFC2462 due to M/O RA flags, I still think it
can be rather misleading.  The sad fact is that M/O flags are dead -
all previous attempts at the 6man wg of making them workable failed,
and different implementations handle these flags very differently.
You simply cannot rely on these flags, and it doesn't make sense to me
newer protocol documents like rfc3315bis still talk about them simply
because its predecessor talked about them.

Now, if you want suggested text, this is my suggestion:

Section 18
OLD
   A client initiates a message exchange with a server or servers to
   acquire or update configuration information of interest.  A client
   has many reasons to initiate the configuration exchange:
...
   3.    when required by Stateless Address Autoconfiguration (as
         defined in [RFC2462] Section 5.2),
NEW1 (my preferred suggestion) remove this bullet
NEW2
   3.    when Router Advertisement indicates DHCPv6 is available for
         address configuration (see [RFC4861] Section 4.2)

(unrelated) side note: there's a duplicate bullet #4 here.

Section 18
OLD
   The client has many reasons to initiate the configuration exchange:
...
   3.    when required by Stateless Address Autoconfiguration (as
         defined in [RFC2462])
NEW1 (my preferred suggestion) remove this bullet
NEW2
   3.    when Router Advertisement indicates DHCPv6 is available for
         address configuration (see [RFC4861] Section 4.2)

Section 18.2.1
OLD:
   In the case of a Solicit message transmitted when DHCP is initiated,
   the delay gives the amount of time to wait after IPv6 Neighbor
   Discovery causes the client to invoke the stateful address
   autoconfiguration protocol (see section 5.5.3 of [RFC2462]).  This
   random delay desynchronizes clients which start at the same time (for
   example, after a power outage).

NEW: I actually suggest removing this paragraph.  Especially given M&O
flags are "dead", I don't see a strong reason for retaining it in
addition to its previous paragraph (which also talks about the delay
and for the case of power outage).  If we still want to say something
about the interaction with RA, my suggestion is to revise the previous
paragraph as follows:

   The first Solicit message from the client on the interface SHOULD be
   delayed by a random amount of time between 0 and SOL_MAX_DELAY.  This
   mechanism is essential for devices that are not battery powered, as
   they may suffer from power failure.  After recovering from a power
   outage, many devices may start their transmission at the same time.
   This is much less of a concern for battery powered devices.  This
   random delay also helps descynronize clients which start DHCPv6
   session by seeing it available in Router Advertisement messages
   (see Section 4.2 of [RFC4861]).

Note that if all of the above suggestions are adopted, there will be
no reference to RFC2462.  So you can also remove it from the
Refereneces section.

>>> - Section 5.4
>>> [...] the requesting router MUST set the valid lifetime in those
>>> advertisements to be no later than the valid lifetime specified in
>>> the IA_PD Prefix option.
>>>  "no later than" sounds awkward as the lifetime is a duration, not  a
>>> particular point in time.
>
> This is simply open as before.
>
> BV> Unless you suggest some text, we will leave this be. I think the
> point of the text is rather clear.

If you want suggestion, this can be fixed easily:
NEW:
 [...] the requesting router MUST set the valid lifetime in those
 advertisements to be no larger than the valid lifetime specified in
 the IA_PD Prefix option.

i.e., s/later/larger/

>>> - Section 8.1
> [...]
>
>>> site-scope unicast address has been deprecated.  Also, the phrase
>>> "global or ULA" is awkward as ULA is a global (scoped) address.
>
> The 08 version states:
>
>                            This is typically a globally unique
>                            address or unique local address (ULA)
>                            [RFC4193],
>
> This is still awkward to me, since in a sense ULAs are also "globally unique" (even if the uniqueness is not 100% guaranteed).  Personally I'd simply avoid mentioning ULAs unless there is a specific to reason to refer to it in the context (and I don't see such a reason here), but if we want to refer to ULAs here, I'd say, e.g., "a global address (including unique local addresses)".
>
> BV> Unless you suggest some text, we will leave it be. I don't see that this is necessarily in conflict - yes, ULA is in the "global address space". But I also think it adds value to explicitly mention ULAs here as otherwise someone could confuse the subtly that ULA is allowed.

I've already suggested text (I admit the point may be a bit pedantic,
though).

>>> - Section 17.1.10.1
>>> "no later than" sounds awkward for these lifetimes (see also Sec
>>> 5.4).
>
> BV> See above.

Ditto:-)

>>> - Section 17.1.10.1
> [...]
>>> Specifically, the bullet description seems to lead to multiple
>>> separate state machines for different bindings.
>
> BV> I believe we addressed this by other text in the document - for example, see in 18.2.4 the following text:
>
>    The server controls the time at which the client should contact the
>    server to extend the lifetimes on assigned leases through the T1 and
>    T2 parameters assigned to an IA.  However, as the client Renews/
>    Rebinds all IAs from the server at the same time, the client MUST
>    select a T1 and T2 time from all IA options, which will guarantee
>    that the client will send Renew/Rebind messages not later than at the
>    T1/T2 times associated with any of the client's bindings (earliest
>    T1/T2).

Hmm...this is one of the things why I can't be confident about this
spec without actually trying to implement it from the text.  But I
don't have enough time to check if the concern is addressed in the
entire context, I'll simply give up with it.

>>> - Section 20.22
> [...]
>>> This choice of valid/preferred lifetime in an IA prefix and the
>>> (possible) relationship between them and those lifetimes advertised
>>> in the delegated site do not make perfect sense to me. [...]
>
> I don't think the revised version addresses the main point.  The new
> text simply avoids saying specifics about these lifetimes, but then
> it's even more unclear about what these lifetimes are (especially
> the preferred lifetime).
>
> BV> Unless you provide text, I think we'll leave this alone as
> mentioned earlier we feel that this document is not the one that
> should describe how these lifetimes are to be used.

This is not just about wording.  It's about actual protocol behavior,
and I don't even know if we have common consensus on it.  I also think
we can't simply ignore the issue by being silence, since it could
result in a bad situation like a site keeps advertising a prefix in RA
as a preferred one even when it's already "deprecated" or even
"invalidated" in terms of prefix delegation.  I'll see if I can offer
something more concrete, but I'd like to raise it as a possible
blocking issue.

>>> - Section 20.23
> [...]
>>> The expected usage is not very clear to me here.  Is it intended to
>>> be used for Advertise and apply the value to the ongoing
>>> Solicit-Advertise exchange?  Or is it mainly intended to be used for
>>> a possible subsequent restart of a DHCPv6 session?
[...]
> BV> You original question was I think about why SOL_MAX_RT MUST be
> in ORO. It MUST be as per RFC 7083 so that clients can get updated
> SOL_MAX_RT values. And, yes, the idea is that the Advertise with the
> SOL_MAX_RT value is used (even if it offers no leases) so that the
> client applies this value for any future requests. I don't see the
> need for this to be spelled out?

I'd think it's worth explaining, but I'll leave it to you.

--
JINMEI, Tatuya

_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

Tomek Mrugalski
In reply to this post by Bernie Volz (volz)
Here are the comments I received from Shawn Routhier. He asked me to
relay them to the DHC list due to some e-mail issues.

Nits:

Section 1.1
"Service for IPv6s" => "Service for IPv6"
"errata filled" => "errata filed"

Section 4.2
DHCP Client: "it may feature the" => "it may include the"
DHCP Server: "it may also feature the" => "it may also include the"
Feature isn't wrong but it is a bit odd.

IA: "and identity association for" => "an identity association for"

singleton option: "once as a the" => "once as a"

It probably would have been useful to include a definition
of "other configuration"

5.3
"updates its configuration" => "update its configuration"

6
"the servers via specific interface," => "the servers via a specific
interface,"

6.6 para 3
"to request larger prefix" => "to request a larger prefix"

7.3
REPLY: "Solicit, Request, Renew, Rebind" => "Solicit, Request, Renew or
Rebind"

11 para 2
"such are those defined" => "such as those defined"

16 para 2
"ignore such message completely" => "ignore such a message completely"

18.2.4
"include IA Prefix option with the IPv6-prefix" => "include an IA Prefix
option with the IPv6-prefix

"is terminated when earliest time T2" => "is terminated when the
earliest time T2"

18.2.10, para 2
"options in an Reply" => "options in a Reply"

Not quite nits, but still not major

6.3, last paragraph
The text goes from client to router and back to client.  It might be a
bit better as

   If the client assigns a delegated prefix to a link to which the
   client is attached as a router, and begins to send router
   advertisements for the

6.6
This section discusses multiple addresses via multiple IA_NA or IA_TAs
should it include any text about multiple addresses per IA_NA or IA_TA
(even if that text is simply to discourage it)?

12.2
This section has the line "A client must create at least one distinct
IA_PD" It would be useful to qualify that to only clients that want a PD
need to have an IA_PD.

18.2.4
I'm unclear why the last paragraph (about moving from renew to rebind
at T2) has the the extra text about reconfigure.  It seems to be it
could be stated a bit more bluntly:

  The message exchange is terminated when the earliest time T2 is
  reached and The client begins a Rebind message exchange (see Section
  18.2.5). If the client was responding to a Reconfigure, the client
  ignores and discards the Reconfigure message.

18.3 para 3
"a Reply in response to a Request," => "a Reply in response to Request,"

18.3.2
There are a couple of typos in this ppart of the text and I'm not sure
what "the presence" refers to.
   Currently sending this option in Reply is technically redundant, as
   the use of the reconfiguration mechanism requires an authentication
   and currently the only defined one is Reconfigure Key Authentication
   Protocol (see Section 20.4 for details) and the presence or
   reconfigure key signals support for Reconfigure acceptance.  However,

I think this is what it is trying to say

   Currently sending this option in Reply is technically redundant, as
   the use of the reconfiguration mechanism requires authentication
   and currently the only one defined is Reconfigure Key Authentication
   Protocol (see Section 20.4 for details) and the presence of a
   reconfigure key signals support for Reconfigure acceptance.  However,

21.4
'non-temporary addresses; "it is up' => 'non-temporary addresses; it is up'

(there is an extra double quote in the sentence)

Tomek Mrugalski
(on behalf of Shawn Routhier)

_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

Tomek Mrugalski
In reply to this post by Bernie Volz (volz)
Here are the comments I received from Shawn Routhier. He asked me to
relay them to the DHC list due to some e-mail issues.

Nits:

Section 1.1
"Service for IPv6s" => "Service for IPv6"
"errata filled" => "errata filed"

Section 4.2
DHCP Client: "it may feature the" => "it may include the"
DHCP Server: "it may also feature the" => "it may also include the"
Feature isn't wrong but it is a bit odd.

IA: "and identity association for" => "an identity association for"

singleton option: "once as a the" => "once as a"

It probably would have been useful to include a definition
of "other configuration"

5.3
"updates its configuration" => "update its configuration"

6
"the servers via specific interface," => "the servers via a specific
interface,"

6.6 para 3
"to request larger prefix" => "to request a larger prefix"

7.3
REPLY: "Solicit, Request, Renew, Rebind" => "Solicit, Request, Renew or
Rebind"

11 para 2
"such are those defined" => "such as those defined"

16 para 2
"ignore such message completely" => "ignore such a message completely"

18.2.4
"include IA Prefix option with the IPv6-prefix" => "include an IA Prefix
option with the IPv6-prefix

"is terminated when earliest time T2" => "is terminated when the
earliest time T2"

18.2.10, para 2
"options in an Reply" => "options in a Reply"

Not quite nits, but still not major

6.3, last paragraph
The text goes from client to router and back to client.  It might be a
bit better as

   If the client assigns a delegated prefix to a link to which the
   client is attached as a router, and begins to send router
   advertisements for the

6.6
This section discusses multiple addresses via multiple IA_NA or IA_TAs
should it include any text about multiple addresses per IA_NA or IA_TA
(even if that text is simply to discourage it)?

12.2
This section has the line "A client must create at least one distinct
IA_PD" It would be useful to qualify that to only clients that want a PD
need to have an IA_PD.

18.2.4
I'm unclear why the last paragraph (about moving from renew to rebind
at T2) has the the extra text about reconfigure.  It seems to be it
could be stated a bit more bluntly:

  The message exchange is terminated when the earliest time T2 is
  reached and The client begins a Rebind message exchange (see Section
  18.2.5). If the client was responding to a Reconfigure, the client
  ignores and discards the Reconfigure message.

18.3 para 3
"a Reply in response to a Request," => "a Reply in response to Request,"

18.3.2
There are a couple of typos in this ppart of the text and I'm not sure
what "the presence" refers to.
   Currently sending this option in Reply is technically redundant, as
   the use of the reconfiguration mechanism requires an authentication
   and currently the only defined one is Reconfigure Key Authentication
   Protocol (see Section 20.4 for details) and the presence or
   reconfigure key signals support for Reconfigure acceptance.  However,

I think this is what it is trying to say

   Currently sending this option in Reply is technically redundant, as
   the use of the reconfiguration mechanism requires authentication
   and currently the only one defined is Reconfigure Key Authentication
   Protocol (see Section 20.4 for details) and the presence of a
   reconfigure key signals support for Reconfigure acceptance.  However,

21.4
'non-temporary addresses; "it is up' => 'non-temporary addresses; it is up'

(there is an extra double quote in the sentence)

Tomek Mrugalski
(on behalf of Shawn Routhier)

_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

Bernie Volz (volz)
In reply to this post by kkinnear
Kim:

Thanks for the thorough review. I think I did (almost) all of these. You will see them in the -09 when published.

One that I skipped is #19 as we use this convention in other places (total of 7) in the document when the reference is just for informational purposes (following the reference isn't key to the point being made and is just "For Your Information" if you case). I have raised it for the co-authors to discuss to see if we want to remove the parenthesis everywhere, switch to commas, or leave as is. We may also just punt this to see what the RFC-Editor may do.

For Appendix B and C, there were a bunch of issues with these and I think they have been corrected (there a few other issues). I also wonder whether we should just drop these as I'm not they add much value -- and likely if something if "off" in them, may cause more confusion. So, another point to be raised to the co-authors.

The co-authors are expecting to discuss the issues on Wed June 14th @ 0800 EDT. Those interested in participating in that discussion can contact me for meeting details (https://jitsi.tools.ietf.org/dhcpv6 or webex in case jitsi has issues - it sometimes does).

- Bernie

-----Original Message-----
From: Kim Kinnear (kkinnear)
Sent: Thursday, May 18, 2017 3:15 PM
To: [hidden email]; Ralph Droms <[hidden email]>
Cc: Kim Kinnear (kkinnear) <[hidden email]>; Bernie Volz (volz) <[hidden email]>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

Folks,

I did a pretty complete review of the document, and while most of the
first issues I found were editorial, I found a number of technical
issues as I went along.  Of the 33 issues I found (all of which I felt
important enough to write down), the following stand out as
particularly important:

Editorial: #8, #23

Technical: #10, #14, #15, #16, #17, #20.5, #21, #22, #26
           #27, #28, #30, #31, #32

I have read this document, and I approve its moving forward.

I would very much like to see the issues I've highlighted above
addressed, either by taking my suggested corrections, or by explaining
why the document is correct as it stands.  

As it happens, a few of the issues I found were from RFC 3315
and not added by the -bis process.  But, as I commented below,
that doesn't make them correct.  

Here are the issues:

1. Section 11, para 2, "such are those" -> "such as those"

2. Section 11, para 3, last sentence, "as specfic in" -> "as specified in"

3. Section 13.2, para 4, "... with additional condition that the new
   address is not duplicated with any assigned addresses" ->
   "... with the additional condition that any new address is not
   the same as any assigned address."

4. Section 13.2, para 7, "of temporary address is unlinkability of different
   actions over time." -> "of a temporary address is to make it
   difficult to link the address to different actions over time."

5. Same as above, "though DHCP provides such possibility" ->
   "though DHCP provides for such a possibility"

6. Section 14.2, list with 3 elements.  I think we want to remove
   the ", and" at the end of item 2, the comma at the end of item
   1, and the period at the end of item 3.  In particular, the
   ", and" kind of implies that item 2 and item 3 are linked, but I
   don't think they are.

7. [retracted correction: diff had a problem not present in the actual draft]

8. Section 18, para 5.  Paragraph beginning with "The client has many..."
   and containing a list with 4 elements.  This list appears to have been
   moved to the first part of the section and slightly improved there,
   and it looks like this older version of the list should have been
   deleted.

9. Section 20.4.1.  para 3 (or 2, depending on how you count).  
   "The format of the Authentication information..."
   -> "The format of the authentication information ...".  In the option
   description (21.11), "authentication information" is not capitalized.

10. Section 20.4.3, para 1, "... in the initial Reply ..." -> "... in an
    Authentication option in the initial Reply ..."

11. Section 21.4, para 2 after table after Figure 15. "Each IA_NA ... attached
    to." -> "Each IA_NA carries one "set" of non-temporary addresses; it is up
    to the server policy to determine how many addresses are assgined,
    but typically at most one address is assigned from each prefix assigned to
    the link to which the client is attached."  Note removal of double quote
    before 'it' as well as improved wording.

12. Section 21.5, para 6 after table after Figure 16. "... MAY request that
    valid lifetime ..." -> "... MAY request that the valid lifetimes ...".
    Two changes, added "the", and made lifetime plural.  I'm not positive
    about making lifetime plural here, please validate that.

13. Same para as #12, "Extending only valid but not preferred ..." ->
    "Extending only the valid but not the preferred ..."

14. Section 21.6, para 1.  The last sentence "The Options fields
    of the IA_NA or IA_TA option encapsulates those options that are
    specific to this address." hasn't changed since the -05 draft, but
    it *is* different from RFC 3315, which said: "The Options field
    encapsulates those options that are specific to this address."
    I find the current language confusing.  Why would the Options
    field of the IA_NA or IA_TA encapsulate options that are specific
    to this address, when there can be multiple IA Address options in
    an IA_NA or IA_TA?  I would have expected this sentence to read
    "The IAaddr-options field encapsulates those options that are
    specific to this address.", since there seems to be no other
    point to having an IAaddr-options field.  But in any case, this needs
    to be figured out and fixed, as it is plenty confusing as it now
    stands.

15. Section 21.7, para 1 after table after Figure 18.  

    Sections 21.24 and 21.25 state that the SOL_MAX_RT and
    INF_MAX_RT options MUST always be in every Option Request option.
    But this is contradicted by Table 1, which says that they MUST
    only appear for certain message types.  I believe that Table 1
    is in fact more correct than the statements in Section 21.24 and 21.25.
    In which case, I would suggest that a new sentence be added here:
    "For certain message types, some Option codes MUST be included
    in the Option Request option, see Table 1 for details."

    And, Sections 21.24 and Section 21.25 should be corrected to
    mention the message type qualification:

    Section 21.24, para 1 after table after Figure 38:
    "A DHCP client ... it sends." -> "A DHCP client ... it sends in
    a SOLICIT message."

    Section 21.25, para 1 after table after Figure 39:
    "A DHCP client ... it sends." -> "A DHCP client ... it sends in
    an Information-request message."

16. Section 21.7, para 2 after table after Figure 18. "Only container
    options MUST appear in the Option Request," --- I think that this
    is simply incorrect.  The better way to say this would be "Only container
    options MAY appear in the Option Request option,", but that is also
    incorrect.  I believe that the statement is "Only top-level options
    MAY appear in the Option Request option."  The next sentence
    should then be: "Options encapsulated in a container option MUST
    NOT appear in an Option Request option, see [RFC7598] as an
    example of container options."  

17. same as #16.  I think the last sentence should be replaced with
    "Options MAY be defined which specify exceptions to the restriction
    on including encapsulated options in an Option Request option.  For
    example, the Option Request option MAY be used to signal support for
    a feature even when that option is encapsulated, as in the case of the
    Prefix Exclude option [RFC6603].  See Table 1."

18. Section 21.11, Authentication Option.  In Figure 22, there is
   "auth-info" at the start of the "authentication information" section.
   I would remove the "auth-info", since this field is actually known
   as "authentication information" in the table below Figure 22.  I
   don't think the "auth-info" label adds any value, and is rather
   inconsistent and might be confusing.

19. Section 21.14, DISCUSSION, para 1.  Last sentence, RFC references
    have extraneous () around references.

20. Same as #19, para 2.  Replace with "The problem of unused leases can be
    minimized by designing the DHCP service so that only one server responds
    to the Solicit, by using relatively short lifetimes for newly assigned
    leases, or by having DHCP clients release unused leases using the
    Release message."  Whether or not this paragraph is used, the
    word "initiatively" isn't commonly used, and some references
    label it "nonstandard" and others show it from the late 1700's.
    I don't think it belongs in an RFC.

20.5 Section 21.16, last sentence.  "Each instance of
     OPTION_VENDOR_CLASS can carry multiple sub-options."  I see
     no sub-options at all here, using the definition of sub-option
     from RFC 7227 (see item #21 for a link to the relevant section
     of this RFC).  I see two possible things that this sentence
     could be trying to say:

     a) "Each instance of OPTION_VENDOR_CLASS can carry multiple
        enterprise-number and vendor-class-data pairs."

     b) "Each instance of OPTION_VENDOR_CLASS can carry multiple
        instances of vendor-class-data, all relating to the same
        enterprise-number."

    I don't know which was intended, if either. Or, possibly, both.
    I know that (b) is true, and I'm pretty sure that (a) is true
    but I could be wrong about that.  If it is true, then it would
    be really good to confirm it here.  This sentence is new since
    RFC 3315.

21. Section 21.17.  This section uses the term "encapsulated options"
    throughout, which I believe is technically incorrect.  See:
    https://tools.ietf.org/html/rfc7227#section-9 
    which explains the distinction between "encapsulated options"
    and "sub-options" really well.  I believe that this section
    should be discussing "sub-options", not "encapsulated options",
    per RFC 7227.   My suggestion would be to rename the "option-data"
    field in Figure 30 as "sub-option-data", to distinguish it from
    the "option-data" field in Figure 31.  And replace the "option-data"
    line in the table after Figure 30 with:

    "sub-option-data    Sub-options, interpreted by vendor-specific
                        code on the clients and servers."
   
    I would replace the paragraph before Figure 31 with:
    "The sub-option-data field MUST be encoded as a sequence of
    code/length/value fields identical in format to the DHCP
    options field (see Section 21.1).  The sub-option codes are defined
    by the vendor identified in the enterprise-number field, and are
    not managed by IANA.  See Section 9 of [RFC7227].
    Each of the sub-options is formatted as follows:"

    In the table below Figure 31:

    "opt-code           The code for the sub-option.

    option-len          An unsigned integer giving the length of the
                        option-data field in this sub-option in
                        octets.

    option-data         The data area for the sub-option."

    Replace the last line of the para 1 after the table after Figure 31:
    "... MAY contain multiple encapsulated options." -> "... MAY contain
    multiple sub-options."

22. Section 21.21, para 6 after table after Figure 35.  This paragraph
    makes no sense.  In RFC 3633 (the PD RFC), this paragraph talked
    about which numbers to put in T1 and T2.  Now, it talks about
    T1 and T2 "fields" and T1 and T2 "parameters".  The way it comes
    out now, it seems like it is talking about what the *client*
    should be doing with the T1 and T2 fields, not the server.  In
    which case, the sentence should start out "In a message sent
    by a server to a client, the client MUST use..." This is exactly
    what the text in the IA_NA option says, for what that is worth.

    But as it is, it can't be correct.

23. Section 21.22, para 3 after table after Figure 36.  This sentence
    also appears (slightly differently) in Section 21.6, the IA
    Address option.  "A client discards any prefixes for which the
    preferred lifetine is greater than the valid lifetime."  Shouldn't
    this be "A client MUST discard any prefixes..." in both
    sections?  

24. Section 23, para 1, sentence 2.  Replace "of said document" with
    "of that document".

25. Section 27.1, Normative References.  I think that RFC 7227
    should be normative because if its discussion of the distinction
    between encapsulated options and sub-options in Section 9
    of RFC 7227.

26. Appendix B., Info Refresh Time column.  I don't understand why
    this option is shown for the Inform. message.  I believe that
    the option code for it MUST be in an Option Request option for
    an Inform. message.  But not that the option itself must be in
    the Inform. message, which is what this table is all about.
    Section 21.23 says directly that this option "MUST only appear
    in the top level option area of Reply messages.", so something
    is wrong in one of these places.  I think the table in Appendix
    B is the one that is wrong, and that the * for Info Refresh
    Time should be removed from the row titled Inform.

27. Appendix B., SOL_MAX_RT column.  I believe that the option code
    for the SOL_MAX_RT option MUST appear in an Option Request option
    in a Solicit message, but this table isn't about the Option Request
    option, it is about messages.  So I believe that this is wrong,
    and that the * for SOL_MAX_RT should be removed from the Solicit
    message row.

28. Appendix B., INF_MAX_RT column.  I can see no reason why this is
    listed as an option to appear in the Advertise message.  I think
    this is simply an error and should be removed.

29. Appendix B. Interesting that the document mentions User Class,
    Vendor Class, and Vendor Specific Options as all valid for
    Relay-Forward and Relay-Reply messages.  I'm not saying that
    isn't OK, but I didn't see anything in this document that would
    suggest anything other than an Interface Id option would go in
    a Relay-Forward or Relay-Reply message.  Maybe I missed it.

30. Appendix C.  This table is only relative to this
    document.  Some of these options can appear in other DHCPv6
    options defined in other RFC's.  That exist today, not just
    future ones.  Perhaps replacing the existing sentence "The
    following ... other options:" with "The following table indicates
    with a "*" where options defined in this document can appear
    in the options field of other options defined in this document.
    Other RFC's define additional situations where options defined
    in this document are encapsulated in other options." would make
    it more clear that this isn't the final word on what options
    can appear inside of what other options.

31. Appendix C.  The sentence describing this table is moderately
    misleading.  "where options can appear in the options field of
    other options." would seem to indicate that the column headings
    along the top of the table are all options.  However, the first
    column isn't the name of an option, it is (presumably) the
    options field of any message.  I think that we should remove
    this column, since any information that it contains is already
    covered (and in more correct detail) by the information in
    Appendix B, which discusses precisely which options can appear
    in the options field of individual messages.  If I'm wrong about
    what the "Option Field" column represents, then it would be
    good to explain it more clearly.

32. Appendix C.  Columns Relay-Forw, Relay-Reply, and Note.
    The note is just wrong, near as I can tell.  There are no
    Relay-Forw or Relay-Reply options.  There are Relay-Forward and
    Relay-Reply messages.  I think having a Relay-Forw and Relay-Reply
    column in this table is very misleading, since as I said above,
    this table seems to be for options.  These aren't options, they
    are messages.   We already have the Relay Message option allowed
    in the Relay-Forward message and Relay-Reply message in Appendix
    B.  In addition, the data there conflicts with the data here
    for the Relay-Forward and Relay-Reply messages.  I don't know
    what someone was trying to communicate here, but I think that we
    need to remove the Relay-Forw and Relay-Reply columns, and
    the Note.

    I recognize that this is left over from RFC 3315 and wasn't
    something added as part of the current process, but that doesn't
    make it right.

33. Appendix C.  If we remove the first and last two columns, as
    I think makes sense, since this information is already covered
    in Appendix B, we are left with 3 options in the left column
    that have any * in any of the right 4 columns.  Not the end of
    the world, but we could probably explain this with a sentence
    or two.  For instance: "Several options may themselves appear
    in the options field of other options defined in this document.
    The IA Address options may appear in the options field of either
    the Identity Association for Non-temporay Addresses option or
    the Identity Association for Temporary Addresses option.  The
    IA Prefix option may appear in the options field of the Identity
    Association for Prefix Delegation option.  The Status Code
    option may appear in the options field of any of the three
    Identity Association options just discussed."  I have no
    particular preference toward either approach (i.e., keep the
    table or replace it with the above paragraph), but offer the
    paragraph to show one possibility.


Thanks -- Kim

> On May 9, 2017, at 10:52 AM, Bernie Volz (volz) <[hidden email]> wrote:
>
> Hello:
>  
> The co-authors believe that all of the issues reported for the last August WGLC on draft-ietf-dhc-rfc3315bis-05 have now been resolved. But, because of the large number of changes, the DHC WG co-chairs feel another “WGLC” is appropriate.
>  
> Please review this document and provide your comments and whether you support the document moving forward by May 30th, 2017. The DHC WG co-chairs will again ask Ralph to evaluate the responses. We are doing a 3 week WGLC as the document is rather large and important to get right!
>  
> Please see https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-08.
>  
> If you’d like to see the differences from the 05 version, use the diff tool at https://tools.ietf.org/rfcdiff:
>  
> https://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-dhc-rfc3315bis-08.txt&url2=https://tools.ietf.org/id/draft-ietf-dhc-rfc3315bis-05.txt
>  
> The list of issues we recorded and action/assignee details are at https://docs.google.com/spreadsheets/d/1c3obOwmRQDldw0u_kv85B5Q4LnjnmvUp2MmsHDGmW98(some additional issues are in https://trac.tools.ietf.org/group/dhcpv6bis/report).
>  
> One very recent change to highlight is https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-08#section-18.2.12 – this was to address a criticism that DHCPv6 is not responsive enough for some network configuration changes.
>  
> The co-authors thank those that reviewed this document during the previous WGLC and hope that those same reviewers (and hopefully more) will endeavor to do one more thorough review of the document.
>  
> -          Tomek & Bernie
> _______________________________________________
> dhcwg mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

Bernie Volz (volz)
In reply to this post by 神明達哉
Jinmei:

We are working to get the -09 version out before the July 3rd IETF-99 cutoff. And, I think we're waiting on text for you regarding one item:

-- start

>>> - Section 20.22
> [...]
>>> This choice of valid/preferred lifetime in an IA prefix and the
>>> (possible) relationship between them and those lifetimes advertised
>>> in the delegated site do not make perfect sense to me. [...]
>
> I don't think the revised version addresses the main point.  The new
> text simply avoids saying specifics about these lifetimes, but then
> it's even more unclear about what these lifetimes are (especially the
> preferred lifetime).
>
> BV> Unless you provide text, I think we'll leave this alone as
> mentioned earlier we feel that this document is not the one that
> should describe how these lifetimes are to be used.

This is not just about wording.  It's about actual protocol behavior, and I don't even know if we have common consensus on it.  I also think we can't simply ignore the issue by being silence, since it could result in a bad situation like a site keeps advertising a prefix in RA as a preferred one even when it's already "deprecated" or even "invalidated" in terms of prefix delegation.  I'll see if I can offer something more concrete, but I'd like to raise it as a possible blocking issue.
-- end

For reference this is section 21.22 in the -08 version.

And, added a few comments below (BV>) as to actions we did or did not take.

Again, thanks for the suggestions and review!

- Bernie

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of ????
Sent: Thursday, June 01, 2017 2:53 PM
To: Bernie Volz (volz) <[hidden email]>
Cc: [hidden email]; Ralph Droms <[hidden email]>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

On Fri, May 26, 2017 at 10:56 AM, Bernie Volz (volz) <[hidden email]> wrote:

>>> - I'm okay with deprecating the delayed authentication protocol, but
>>> I'm not sure if it's okay to ship the spec with no built-in
>>> authentication (the reconfigure key protocol is very limited and too
>>> weak).
>
> BV> We are working on sedhcpv6 but this has not been so simple and quick. And, DHCPv6 is in use and deployed today without an authentication protocol. There are other actions that can be taken such as stated in section 22:
>
>    Many of these rogue server attacks can be mitigated by making use of
>    the mechanism described in [RFC7610].

I personally wouldn't argue that it's a blocking issue, and, to be clear, I'm not requesting sedhcpv6 be specified as *the* authentication protocol in rfc3315bis.  But I'd suggest chairs to explicitly leave notes about the point for security ADs when the doc is sent to the IESG.

BV> We discussed with Ralph and he plans to note it in the shepherd document.


>>> - Section 5.2
>>>   the "stateful address autoconfiguration protocol" for IPv6 [RFC2462].
>>>  s/RFC2462/RFC4862/.
>
> and there are still more references to RFC2462.
>
> BV> This is by design. RFC4862 does not mention the M & O bits so we
> can't reference that RFC. We documented the reason for this in
> Appendix A:

I believe at least the reference to RFC2462 in Section 6.2 is not really appropriate:

   This model of operation was the original motivation for DHCP and is
   the "stateful address autoconfiguration protocol" for IPv6 which is
   discussed in [RFC2462].

Simply because RFC4862 doesn't use the term "stateful address autoconfiguration protocol" doesn't make this text appropriate.
RFC2462 used the term "stateful address autoconfiguration protocol"
just because DHCPv6 wasn't fully standardized at that time.  RFC4862 just replaced it with the term "DHCPv6".  If you want suggested text, my suggestion is simply remove the second half the sentence:

   This model of operation was the original motivation for DHCP.  It
   is appropriate for situations where stateless address
   autoconfiguration alone is insufficient or impractical, e.g.,
   because of network policy, additional requirements such as dynamic
   updates to the DNS, or client-specific requirements.

As for the references to RFC2462 due to M/O RA flags, I still think it can be rather misleading.  The sad fact is that M/O flags are dead - all previous attempts at the 6man wg of making them workable failed, and different implementations handle these flags very differently.
You simply cannot rely on these flags, and it doesn't make sense to me newer protocol documents like rfc3315bis still talk about them simply because its predecessor talked about them.

BV> OK, cleaned up text as recommended and there are no more references to 2462.


Now, if you want suggested text, this is my suggestion:

Section 18
OLD
   A client initiates a message exchange with a server or servers to
   acquire or update configuration information of interest.  A client
   has many reasons to initiate the configuration exchange:
...
   3.    when required by Stateless Address Autoconfiguration (as
         defined in [RFC2462] Section 5.2),
NEW1 (my preferred suggestion) remove this bullet
NEW2
   3.    when Router Advertisement indicates DHCPv6 is available for
         address configuration (see [RFC4861] Section 4.2)

BV> Used NEW2. There are probably existing implementations that follow the old recommendations.

(unrelated) side note: there's a duplicate bullet #4 here.

Section 18
OLD
   The client has many reasons to initiate the configuration exchange:
...
   3.    when required by Stateless Address Autoconfiguration (as
         defined in [RFC2462])
NEW1 (my preferred suggestion) remove this bullet
NEW2
   3.    when Router Advertisement indicates DHCPv6 is available for
         address configuration (see [RFC4861] Section 4.2)

BV> This second version of the list was removed. I think it was left behind by accident during an editing session.

Section 18.2.1
OLD:
   In the case of a Solicit message transmitted when DHCP is initiated,
   the delay gives the amount of time to wait after IPv6 Neighbor
   Discovery causes the client to invoke the stateful address
   autoconfiguration protocol (see section 5.5.3 of [RFC2462]).  This
   random delay desynchronizes clients which start at the same time (for
   example, after a power outage).

NEW: I actually suggest removing this paragraph.  Especially given M&O flags are "dead", I don't see a strong reason for retaining it in addition to its previous paragraph (which also talks about the delay and for the case of power outage).  If we still want to say something about the interaction with RA, my suggestion is to revise the previous paragraph as follows:

   The first Solicit message from the client on the interface SHOULD be
   delayed by a random amount of time between 0 and SOL_MAX_DELAY.  This
   mechanism is essential for devices that are not battery powered, as
   they may suffer from power failure.  After recovering from a power
   outage, many devices may start their transmission at the same time.
   This is much less of a concern for battery powered devices.  This
   random delay also helps descynronize clients which start DHCPv6
   session by seeing it available in Router Advertisement messages
   (see Section 4.2 of [RFC4861]).

BV> I used this suggested paragraph.

Note that if all of the above suggestions are adopted, there will be no reference to RFC2462.  So you can also remove it from the Refereneces section.

BV> Correct, they are now all gone.

>>> - Section 5.4
>>> [...] the requesting router MUST set the valid lifetime in those
>>> advertisements to be no later than the valid lifetime specified in
>>> the IA_PD Prefix option.
>>>  "no later than" sounds awkward as the lifetime is a duration, not  
>>> a particular point in time.
>
> This is simply open as before.
>
> BV> Unless you suggest some text, we will leave this be. I think the
> point of the text is rather clear.

If you want suggestion, this can be fixed easily:
NEW:
 [...] the requesting router MUST set the valid lifetime in those  advertisements to be no larger than the valid lifetime specified in  the IA_PD Prefix option.

i.e., s/later/larger/

BV> Done.

>>> - Section 8.1
> [...]
>
>>> site-scope unicast address has been deprecated.  Also, the phrase
>>> "global or ULA" is awkward as ULA is a global (scoped) address.
>
> The 08 version states:
>
>                            This is typically a globally unique
>                            address or unique local address (ULA)
>                            [RFC4193],
>
> This is still awkward to me, since in a sense ULAs are also "globally unique" (even if the uniqueness is not 100% guaranteed).  Personally I'd simply avoid mentioning ULAs unless there is a specific to reason to refer to it in the context (and I don't see such a reason here), but if we want to refer to ULAs here, I'd say, e.g., "a global address (including unique local addresses)".
>
> BV> Unless you suggest some text, we will leave it be. I don't see that this is necessarily in conflict - yes, ULA is in the "global address space". But I also think it adds value to explicitly mention ULAs here as otherwise someone could confuse the subtly that ULA is allowed.

I've already suggested text (I admit the point may be a bit pedantic, though).

BV> We decided to say "global address (including unique local addresses, [RFC4193])" or something very close to that.

>>> - Section 17.1.10.1
>>> "no later than" sounds awkward for these lifetimes (see also Sec
>>> 5.4).
>
> BV> See above.

Ditto:-)

BV> Done.

>>> - Section 17.1.10.1
> [...]
>>> Specifically, the bullet description seems to lead to multiple
>>> separate state machines for different bindings.
>
> BV> I believe we addressed this by other text in the document - for example, see in 18.2.4 the following text:
>
>    The server controls the time at which the client should contact the
>    server to extend the lifetimes on assigned leases through the T1 and
>    T2 parameters assigned to an IA.  However, as the client Renews/
>    Rebinds all IAs from the server at the same time, the client MUST
>    select a T1 and T2 time from all IA options, which will guarantee
>    that the client will send Renew/Rebind messages not later than at the
>    T1/T2 times associated with any of the client's bindings (earliest
>    T1/T2).

Hmm...this is one of the things why I can't be confident about this spec without actually trying to implement it from the text.  But I don't have enough time to check if the concern is addressed in the entire context, I'll simply give up with it.

BV> We believe we are ok with this as is.

>>> - Section 20.22
> [...]
>>> This choice of valid/preferred lifetime in an IA prefix and the
>>> (possible) relationship between them and those lifetimes advertised
>>> in the delegated site do not make perfect sense to me. [...]
>
> I don't think the revised version addresses the main point.  The new
> text simply avoids saying specifics about these lifetimes, but then
> it's even more unclear about what these lifetimes are (especially the
> preferred lifetime).
>
> BV> Unless you provide text, I think we'll leave this alone as
> mentioned earlier we feel that this document is not the one that
> should describe how these lifetimes are to be used.

This is not just about wording.  It's about actual protocol behavior, and I don't even know if we have common consensus on it.  I also think we can't simply ignore the issue by being silence, since it could result in a bad situation like a site keeps advertising a prefix in RA as a preferred one even when it's already "deprecated" or even "invalidated" in terms of prefix delegation.  I'll see if I can offer something more concrete, but I'd like to raise it as a possible blocking issue.

BV> See top of the message and main reason for sending it!

>>> - Section 20.23
> [...]
>>> The expected usage is not very clear to me here.  Is it intended to
>>> be used for Advertise and apply the value to the ongoing
>>> Solicit-Advertise exchange?  Or is it mainly intended to be used for
>>> a possible subsequent restart of a DHCPv6 session?
[...]
> BV> You original question was I think about why SOL_MAX_RT MUST be
> in ORO. It MUST be as per RFC 7083 so that clients can get updated
> SOL_MAX_RT values. And, yes, the idea is that the Advertise with the
> SOL_MAX_RT value is used (even if it offers no leases) so that the
> client applies this value for any future requests. I don't see the
> need for this to be spelled out?

I'd think it's worth explaining, but I'll leave it to you.

BV> We think we're OK with this as is.

--
JINMEI, Tatuya
_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

神明達哉
At Wed, 14 Jun 2017 20:13:56 +0000,
"Bernie Volz (volz)" <[hidden email]> wrote:

> We are working to get the -09 version out before the July 3rd
> IETF-99 cutoff. And, I think we're waiting on text for you regarding
> one item:

I don't think I promised I would offer text :-) but I admit I should
have provided some followup much earlier.

> > > BV> Unless you provide text, I think we'll leave this alone as
> > > mentioned earlier we feel that this document is not the one that
> > > should describe how these lifetimes are to be used.
>
> > This is not just about wording.  It's about actual protocol
> > behavior, and I don't even know if we have common consensus on it.
> > I also think we can't simply ignore the issue by being silence,
> > since it could result in a bad situation like a site keeps
> > advertising a prefix in RA as a preferred one even when it's
> > already "deprecated" or even "invalidated" in terms of prefix
> > delegation.  I'll see if I can offer something more concrete, but
> > I'd like to raise it as a possible blocking issue.

As I said before (in the quoted text) I actually suspect it's
premature to talk about specific text before discussion.  So let me
talk about what I think is an issue more specifically.

First off, what's this preferred lifetime in the first place?  Section
21.22 simply says:

      preferred-lifetime   The recommended preferred lifetime for the
                           prefix in the option, expressed in units of
                           seconds.  A value of 0xFFFFFFFF represents
                           infinity.

What does this "recommended" mean?  As far as I can see it's not
explained anywhere else in the draft.  But one possible, or likely,
interpretation would be that it's a recommendation for addresses
configured from this prefix.  More specifically, it would be to use it
as the preferred lifetime of a prefix information option (PIO) of RA
for the delegated prefix (or prefixes derived from the delegated
prefix).  Assuming that, consider some more concrete issue:

Assume a PD client gets an /64 IA_PD prefix with preferred lifetime
being 1 week (an arbitrary choice).  If T1/T2 of the IA_PD follows the
recommended value of Section 21.21, the client will try to renew it in
3.5 days.

Meanwhile, this prefix is typically advertised in the downstream link
in the prefix information option (PIO) of RA.  Assuming the above
interpretation of "recommendation", a straightforward implementation
of it is to set the preferred lifetime of the PIO to 6 days.  End
hosts receiving this prefix will configure their addresses, resetting
its preferred lifetime to 6 days every time it receives the PIO (which
is periodically advertised, usually every several minutes).

In 3.5 days the PD client starts renewing the prefix.  But, now suppose
this exchange doesn't succeed (even after the client switches to
REBOUND).  Then what should happen in 6 days?  Should the delegated
prefix now be considered "deprecated"?  And what would that mean?
Should the preferred lifetime value of the corresponding RA PIO be
reset to 0 from this point?

And, what if the PD client can't even RENEW/REBOUND until the valid
lifetime expires?  If, like above, the valid lifetime value is copied
from IA_PD prefix to RA PIO, end hosts will have an address with a
pretty large valid lifetime (in this example scenario, at least 6
days) at the time of expiration due to the periodic RA advertisements.
And, even if the advertised PIO valid lifetime is set to 0 at that
point, end clients will still keep using the address for two hours
(see RFC4862).

I actually don't know whether/how existing implementations deal with
cases like this, but I wouldn't be surprised if there are naive
implementation that simply copies the preferred/valid lifetimes from
PD to RA, potentially having the problems described above.  I suspect
we've not heard problem reports in the actual deployment simply
because the lifetimes are sufficiently long compared to possible
network outage periods, and also perhaps because if this problem
happens because the upstream becomes unreachable, then it doesn't
matter much anyway if the end clients keep using "expired" addresses.
Still, as a protocol design I think it's a kind of defect and we
cannot just rely on the operational conditions.

So, can we agree there's a potential problem as some of the
definitions and the usage are not clear enough, aside from whether
that should be addressed in rfc3315bis?

--
JINMEI, Tatuya

_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

神明達哉
(Sorry, I've noticed a minor but possibly very confusing typo in my
previous message.  I'm replacing the whole text with correcting it
below.  Please ignore the previous one)

At Wed, 14 Jun 2017 20:13:56 +0000,
"Bernie Volz (volz)" <[hidden email]> wrote:

> We are working to get the -09 version out before the July 3rd
> IETF-99 cutoff. And, I think we're waiting on text for you regarding
> one item:

I don't think I promised I would offer text :-) but I admit I should
have provided some followup much earlier.

> > > BV> Unless you provide text, I think we'll leave this alone as
> > > mentioned earlier we feel that this document is not the one that
> > > should describe how these lifetimes are to be used.
>
> > This is not just about wording.  It's about actual protocol
> > behavior, and I don't even know if we have common consensus on it.
> > I also think we can't simply ignore the issue by being silence,
> > since it could result in a bad situation like a site keeps
> > advertising a prefix in RA as a preferred one even when it's
> > already "deprecated" or even "invalidated" in terms of prefix
> > delegation.  I'll see if I can offer something more concrete, but
> > I'd like to raise it as a possible blocking issue.

As I said before (in the quoted text) I actually suspect it's
premature to talk about specific text before discussion.  So let me
talk about what I think is an issue more specifically.

First off, what's this preferred lifetime in the first place?  Section
21.22 simply says:

      preferred-lifetime   The recommended preferred lifetime for the
                           prefix in the option, expressed in units of
                           seconds.  A value of 0xFFFFFFFF represents
                           infinity.

What does this "recommended" mean?  As far as I can see it's not
explained anywhere else in the draft.  But one possible, or likely,
interpretation would be that it's a recommendation for addresses
configured from this prefix.  More specifically, it would be to use it
as the preferred lifetime of a prefix information option (PIO) of RA
for the delegated prefix (or prefixes derived from the delegated
prefix).  Assuming that, consider some more concrete issue:

Assume a PD client gets an /64 IA_PD prefix with preferred lifetime
being 7 days (an arbitrary choice).  If T1/T2 of the IA_PD follows the
recommended value of Section 21.21, the client will try to renew it in
3.5 days.

Meanwhile, this prefix is typically advertised in the downstream link
in the prefix information option (PIO) of RA.  Assuming the above
interpretation of "recommendation", a straightforward implementation
of it is to set the preferred lifetime of the PIO to 7 days.  End
hosts receiving this prefix will configure their addresses, resetting
its preferred lifetime to 7 days every time it receives the PIO (which
is periodically advertised, usually every several minutes).

In 3.5 days the PD client starts renewing the prefix.  But, now suppose
this exchange doesn't succeed (even after the client switches to
REBOUND).  Then what should happen in 7 days?  Should the delegated
prefix now be considered "deprecated"?  And what would that mean?
Should the preferred lifetime value of the corresponding RA PIO be
reset to 0 from this point?

And, what if the PD client can't even RENEW/REBOUND until the valid
lifetime expires?  If, like above, the valid lifetime value is copied
from IA_PD prefix to RA PIO, end hosts will have an address with a
pretty large valid lifetime (in this example scenario, at least 7
days) at the time of expiration due to the periodic RA advertisements.
And, even if the advertised PIO valid lifetime is set to 0 at that
point, end clients will still keep using the address for two hours
(see RFC4862).

I actually don't know whether/how existing implementations deal with
cases like this, but I wouldn't be surprised if there are naive
implementation that simply copies the preferred/valid lifetimes from
PD to RA, potentially having the problems described above.  I suspect
we've not heard problem reports in the actual deployment simply
because the lifetimes are sufficiently long compared to possible
network outage periods, and also perhaps because if this problem
happens because the upstream becomes unreachable, then it doesn't
matter much anyway if the end clients keep using "expired" addresses.
Still, as a protocol design I think it's a kind of defect and we
cannot just rely on the operational conditions.

So, can we agree there's a potential problem as some of the
definitions and the usage are not clear enough, aside from whether
that should be addressed in rfc3315bis?

--
JINMEI, Tatuya

_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

Bernie Volz (volz)
In reply to this post by 神明達哉
Jinmei:

My reaction is you are wrong – the PIO would, whenever sent, be sent with the preferred and valid lifetime REMAINING on the PD lease. So, sure a PIO sent just after the PD lease started would have (close) to the full values, but the values sent an hour later would be 1 hour less than they were.

Thus, I don’t see a problem as the preferred and valid lifetime of the PIO run down as the time of the lease runs down. At T1 (if 50 % of the preferred lifetime), a PIO sent would have ½ preferred lifetime (preferred lifetime – T1) and a valid lifetime of the original valid lifetime – T1.

This is different than if you explicit configured a manual prefix on a router with preferred/valid lifetimes – those would always be advertised in PIOs with the same values. But, when a lease is involved, the values run down and thus the PIO must contain just the remaining times.

Thus, it all works out nicely?

I will take another look at the IAPREFIX preferred/valid lifetime definitions as perhaps we need to tweak them a bit.

- Bernie

On 6/16/17, 2:28 PM, "[hidden email] on behalf of 神明達哉" <[hidden email] on behalf of [hidden email]> wrote:

    At Wed, 14 Jun 2017 20:13:56 +0000,
    "Bernie Volz (volz)" <[hidden email]> wrote:
   
    > We are working to get the -09 version out before the July 3rd
    > IETF-99 cutoff. And, I think we're waiting on text for you regarding
    > one item:
   
    I don't think I promised I would offer text :-) but I admit I should
    have provided some followup much earlier.
   
    > > > BV> Unless you provide text, I think we'll leave this alone as
    > > > mentioned earlier we feel that this document is not the one that
    > > > should describe how these lifetimes are to be used.
    >
    > > This is not just about wording.  It's about actual protocol
    > > behavior, and I don't even know if we have common consensus on it.
    > > I also think we can't simply ignore the issue by being silence,
    > > since it could result in a bad situation like a site keeps
    > > advertising a prefix in RA as a preferred one even when it's
    > > already "deprecated" or even "invalidated" in terms of prefix
    > > delegation.  I'll see if I can offer something more concrete, but
    > > I'd like to raise it as a possible blocking issue.
   
    As I said before (in the quoted text) I actually suspect it's
    premature to talk about specific text before discussion.  So let me
    talk about what I think is an issue more specifically.
   
    First off, what's this preferred lifetime in the first place?  Section
    21.22 simply says:
   
          preferred-lifetime   The recommended preferred lifetime for the
                               prefix in the option, expressed in units of
                               seconds.  A value of 0xFFFFFFFF represents
                               infinity.
   
    What does this "recommended" mean?  As far as I can see it's not
    explained anywhere else in the draft.  But one possible, or likely,
    interpretation would be that it's a recommendation for addresses
    configured from this prefix.  More specifically, it would be to use it
    as the preferred lifetime of a prefix information option (PIO) of RA
    for the delegated prefix (or prefixes derived from the delegated
    prefix).  Assuming that, consider some more concrete issue:
   
    Assume a PD client gets an /64 IA_PD prefix with preferred lifetime
    being 1 week (an arbitrary choice).  If T1/T2 of the IA_PD follows the
    recommended value of Section 21.21, the client will try to renew it in
    3.5 days.
   
    Meanwhile, this prefix is typically advertised in the downstream link
    in the prefix information option (PIO) of RA.  Assuming the above
    interpretation of "recommendation", a straightforward implementation
    of it is to set the preferred lifetime of the PIO to 6 days.  End
    hosts receiving this prefix will configure their addresses, resetting
    its preferred lifetime to 6 days every time it receives the PIO (which
    is periodically advertised, usually every several minutes).
   
    In 3.5 days the PD client starts renewing the prefix.  But, now suppose
    this exchange doesn't succeed (even after the client switches to
    REBOUND).  Then what should happen in 6 days?  Should the delegated
    prefix now be considered "deprecated"?  And what would that mean?
    Should the preferred lifetime value of the corresponding RA PIO be
    reset to 0 from this point?
   
    And, what if the PD client can't even RENEW/REBOUND until the valid
    lifetime expires?  If, like above, the valid lifetime value is copied
    from IA_PD prefix to RA PIO, end hosts will have an address with a
    pretty large valid lifetime (in this example scenario, at least 6
    days) at the time of expiration due to the periodic RA advertisements.
    And, even if the advertised PIO valid lifetime is set to 0 at that
    point, end clients will still keep using the address for two hours
    (see RFC4862).
   
    I actually don't know whether/how existing implementations deal with
    cases like this, but I wouldn't be surprised if there are naive
    implementation that simply copies the preferred/valid lifetimes from
    PD to RA, potentially having the problems described above.  I suspect
    we've not heard problem reports in the actual deployment simply
    because the lifetimes are sufficiently long compared to possible
    network outage periods, and also perhaps because if this problem
    happens because the upstream becomes unreachable, then it doesn't
    matter much anyway if the end clients keep using "expired" addresses.
    Still, as a protocol design I think it's a kind of defect and we
    cannot just rely on the operational conditions.
   
    So, can we agree there's a potential problem as some of the
    definitions and the usage are not clear enough, aside from whether
    that should be addressed in rfc3315bis?
   
    --
    JINMEI, Tatuya
   

_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

JINMEI Tatuya / 神明達哉-6
At Sat, 17 Jun 2017 02:27:39 +0000,
"Bernie Volz (volz)" <[hidden email]> wrote:

> My reaction is you are wrong – the PIO would, whenever sent, be sent
> with the preferred and valid lifetime REMAINING on the PD lease. So,
> sure a PIO sent just after the PD lease started would have (close)
> to the full values, but the values sent an hour later would be 1
> hour less than they were.

Actually I agreed.  I guess what we're different is the view on how
obvious it is.  I suspect this is not so obvious and there are
actually implementations that can cause the situation where
deprecated/invalidated addresses are used.  There may even be an
implementation that naively copies the lifetimes from PD to RA PIO.

I've monitored RAs advertised in my apartment room.  The ISP is
Comcast and the default router is Apple time capsule.  The lifetimes
advertised in RA PIO are constant and do not decrease as I monitored
it in multiple consecutive RAs.  Of course, it doesn't immediately
mean the time capsule device uses the 'naive' approach.  I actually
don't even know if PD is used or the time capsule is the PD client.
And the time capsule might actually have some safety buffer period and
use a much lower lifetimes for PIO than those provided in PD.  Still,
I think this can be a potential anecdote to suggest there might be a
problematic implementation.

So I don't think it at least doesn't harm if we say that lifetimes of
site addresses derived from the delegated prefix MUST NOT exceed the
remaining time of the lifetimes in the last-received corresponding
PD.  (I don't think we have to specify exactly how to implement this
restriction).

--
JINMEI, Tatuya

_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

Bernie Volz (volz)
I’ve added Tim Winters as perhaps he can shed some light on this in terms of what is tested at the NH Interoperability Lab for PD / CPEs?

Even if a device doesn’t follow this (running down the lifetimes), what’s likely to happen when the PD expires is that the traffic will hopefully no longer be forwarded by the router (and with a ICMP destination unreachable notification) and perhaps RAs will be sent with 0 lifetimes to attempt to deprecate the prefix (and any assigned addresses) use as quickly as possible?

Ralph or Ole might also have a comment with respect to what they expected a requesting router to do based on the original RFC 3633? I don’t think this 3315bis document itself caused this potential confusion to exist?

- Bernie

On 6/19/17, 1:55 PM, "JINMEI Tatuya / 神明達哉" <[hidden email]> wrote:

    At Sat, 17 Jun 2017 02:27:39 +0000,
    "Bernie Volz (volz)" <[hidden email]> wrote:
   
    > My reaction is you are wrong – the PIO would, whenever sent, be sent
    > with the preferred and valid lifetime REMAINING on the PD lease. So,
    > sure a PIO sent just after the PD lease started would have (close)
    > to the full values, but the values sent an hour later would be 1
    > hour less than they were.
   
    Actually I agreed.  I guess what we're different is the view on how
    obvious it is.  I suspect this is not so obvious and there are
    actually implementations that can cause the situation where
    deprecated/invalidated addresses are used.  There may even be an
    implementation that naively copies the lifetimes from PD to RA PIO.
   
    I've monitored RAs advertised in my apartment room.  The ISP is
    Comcast and the default router is Apple time capsule.  The lifetimes
    advertised in RA PIO are constant and do not decrease as I monitored
    it in multiple consecutive RAs.  Of course, it doesn't immediately
    mean the time capsule device uses the 'naive' approach.  I actually
    don't even know if PD is used or the time capsule is the PD client.
    And the time capsule might actually have some safety buffer period and
    use a much lower lifetimes for PIO than those provided in PD.  Still,
    I think this can be a potential anecdote to suggest there might be a
    problematic implementation.
   
    So I don't think it at least doesn't harm if we say that lifetimes of
    site addresses derived from the delegated prefix MUST NOT exceed the
    remaining time of the lifetimes in the last-received corresponding
    PD.  (I don't think we have to specify exactly how to implement this
    restriction).
   
    --
    JINMEI, Tatuya
   

_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

Timothy Winters
Hi Bernie,

We have CE Routers that countdown from when the IA_PD is received, and others that always transmit the lifetime received in the IA_PD in RA (Always the same).   It's about 50/50 at the moment.   When we were working on testing for 6024/7084 this was a topic that was discussed but it wasn't clear answer on what to do with the lifetimes.

You are correct that when the prefix timeout from the IA_PD it will stop forwarding and transmit a Destination Unreachable message.   

Regards,
Tim

On Mon, Jun 19, 2017 at 2:10 PM, Bernie Volz (volz) <[hidden email]> wrote:
I’ve added Tim Winters as perhaps he can shed some light on this in terms of what is tested at the NH Interoperability Lab for PD / CPEs?

Even if a device doesn’t follow this (running down the lifetimes), what’s likely to happen when the PD expires is that the traffic will hopefully no longer be forwarded by the router (and with a ICMP destination unreachable notification) and perhaps RAs will be sent with 0 lifetimes to attempt to deprecate the prefix (and any assigned addresses) use as quickly as possible?

Ralph or Ole might also have a comment with respect to what they expected a requesting router to do based on the original RFC 3633? I don’t think this 3315bis document itself caused this potential confusion to exist?

- Bernie

On 6/19/17, 1:55 PM, "JINMEI Tatuya / 神明達哉" <[hidden email]> wrote:

    At Sat, 17 Jun 2017 02:27:39 +0000,
    "Bernie Volz (volz)" <[hidden email]> wrote:

    > My reaction is you are wrong – the PIO would, whenever sent, be sent
    > with the preferred and valid lifetime REMAINING on the PD lease. So,
    > sure a PIO sent just after the PD lease started would have (close)
    > to the full values, but the values sent an hour later would be 1
    > hour less than they were.

    Actually I agreed.  I guess what we're different is the view on how
    obvious it is.  I suspect this is not so obvious and there are
    actually implementations that can cause the situation where
    deprecated/invalidated addresses are used.  There may even be an
    implementation that naively copies the lifetimes from PD to RA PIO.

    I've monitored RAs advertised in my apartment room.  The ISP is
    Comcast and the default router is Apple time capsule.  The lifetimes
    advertised in RA PIO are constant and do not decrease as I monitored
    it in multiple consecutive RAs.  Of course, it doesn't immediately
    mean the time capsule device uses the 'naive' approach.  I actually
    don't even know if PD is used or the time capsule is the PD client.
    And the time capsule might actually have some safety buffer period and
    use a much lower lifetimes for PIO than those provided in PD.  Still,
    I think this can be a potential anecdote to suggest there might be a
    problematic implementation.

    So I don't think it at least doesn't harm if we say that lifetimes of
    site addresses derived from the delegated prefix MUST NOT exceed the
    remaining time of the lifetimes in the last-received corresponding
    PD.  (I don't think we have to specify exactly how to implement this
    restriction).

    --
    JINMEI, Tatuya





--

Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR


_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

Bernie Volz (volz)

Thanks Tim. That’s useful, and shows that we do need to be more explicit.

 

There are two places in draft-ietf-dhc-rfc3315bis-08 (section 6.3 and 18.2.10.1) where we have the following text:

 

      If the client assigns a delegated prefix to a link to which the

      router is attached, and begins to send router advertisements for

      the prefix on the link, the client MUST set the valid lifetime in

      those advertisements to be no later than the valid lifetime

      specified in the IA_PD option.  A client MAY use the preferred

      lifetime specified in the IA_PD option.

 

The “no later” has been changed to “no larger”. And, actually the IA_PD option is wrong (it should be IAPREFIX option, as that holds the lifetimes).

 

Perhaps what we really should say is something like:

 

      If the client assigns a delegated prefix to a link to which the

      router is attached, and begins to send router advertisements for

      the prefix on the link, the valid lifetime in those advertisements

      MUST be no larger than the remaining valid lifetime

      for the delegated prefix.  A client MAY use the preferred

      lifetime as originally received in the IAPREFIX option, provided that whatever

      value is used is less than or equal to the valid lifetime to be sent in the

      router advertisement.

 

That text doesn’t by itself provide any good way to specify a shorter preferred lifetime so that the prefix is marked deprecated before it becomes invalid, but at least it assures that what is send for the preferred and valid meets the basic requires: preferred <= valid in the RA, and the valid is <= what is specified in the IAPREFIX.

 

  • Bernie

 

 

From: Timothy Winters <[hidden email]>
Date: Monday, June 19, 2017 at 2:32 PM
To: Bernie Volz <[hidden email]>
Cc: JINMEI Tatuya /
神明達哉 <[hidden email]>, "[hidden email]" <[hidden email]>, Ralph Droms <[hidden email]>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

 

Hi Bernie,

 

We have CE Routers that countdown from when the IA_PD is received, and others that always transmit the lifetime received in the IA_PD in RA (Always the same).   It's about 50/50 at the moment.   When we were working on testing for 6024/7084 this was a topic that was discussed but it wasn't clear answer on what to do with the lifetimes.

 

You are correct that when the prefix timeout from the IA_PD it will stop forwarding and transmit a Destination Unreachable message.   

 

Regards,

Tim

 

On Mon, Jun 19, 2017 at 2:10 PM, Bernie Volz (volz) <[hidden email]> wrote:

I’ve added Tim Winters as perhaps he can shed some light on this in terms of what is tested at the NH Interoperability Lab for PD / CPEs?

Even if a device doesn’t follow this (running down the lifetimes), what’s likely to happen when the PD expires is that the traffic will hopefully no longer be forwarded by the router (and with a ICMP destination unreachable notification) and perhaps RAs will be sent with 0 lifetimes to attempt to deprecate the prefix (and any assigned addresses) use as quickly as possible?

Ralph or Ole might also have a comment with respect to what they expected a requesting router to do based on the original RFC 3633? I don’t think this 3315bis document itself caused this potential confusion to exist?

- Bernie


On 6/19/17, 1:55 PM, "JINMEI Tatuya / 神明達哉" <[hidden email]> wrote:

    At Sat, 17 Jun 2017 02:27:39 +0000,
    "Bernie Volz (volz)" <[hidden email]> wrote:

    > My reaction is you are wrong – the PIO would, whenever sent, be sent
    > with the preferred and valid lifetime REMAINING on the PD lease. So,
    > sure a PIO sent just after the PD lease started would have (close)
    > to the full values, but the values sent an hour later would be 1
    > hour less than they were.

    Actually I agreed.  I guess what we're different is the view on how
    obvious it is.  I suspect this is not so obvious and there are
    actually implementations that can cause the situation where
    deprecated/invalidated addresses are used.  There may even be an
    implementation that naively copies the lifetimes from PD to RA PIO.

    I've monitored RAs advertised in my apartment room.  The ISP is
    Comcast and the default router is Apple time capsule.  The lifetimes
    advertised in RA PIO are constant and do not decrease as I monitored
    it in multiple consecutive RAs.  Of course, it doesn't immediately
    mean the time capsule device uses the 'naive' approach.  I actually
    don't even know if PD is used or the time capsule is the PD client.
    And the time capsule might actually have some safety buffer period and
    use a much lower lifetimes for PIO than those provided in PD.  Still,
    I think this can be a potential anecdote to suggest there might be a
    problematic implementation.

    So I don't think it at least doesn't harm if we say that lifetimes of
    site addresses derived from the delegated prefix MUST NOT exceed the
    remaining time of the lifetimes in the last-received corresponding
    PD.  (I don't think we have to specify exactly how to implement this
    restriction).

    --
    JINMEI, Tatuya



 

--

Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR


_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

Bernie Volz (volz)

Hi:

 

Any feedback on this proposed text?

 

It would be nice to be able to publish an -09 before the 7/3 deadline for IETF-99, and perhaps even send this document on to the IESG (assuming Ralph believes there is consensus to do so).

 

An alternative, which in retrospect I think I would prefer, would be for the PIO to use the remaining preferred and valid lifetime on the lease and just say that explicitly. That may be cleanest? So, that proposed text would be:

 

      If the client assigns a delegated prefix to a link to which the

      router is attached, and begins to send router advertisements for

      the prefix on the link, the preferred and valid lifetime in those advertisements

      MUST be no larger than the remaining preferred and valid lifetimes, respectively,

      for the delegated prefix at the time the router advertisement is sent.

 

Please let me know which of the two versions you’d prefer, or suggest an alternative.

 

-          Bernie

 

From: Bernie Volz (volz)
Sent: Monday, June 19, 2017 3:28 PM
To: Timothy Winters <[hidden email]>; JINMEI Tatuya /
神明達哉 <[hidden email]>
Cc: [hidden email]; Ralph Droms <[hidden email]>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

 

Thanks Tim. That’s useful, and shows that we do need to be more explicit.

 

There are two places in draft-ietf-dhc-rfc3315bis-08 (section 6.3 and 18.2.10.1) where we have the following text:

 

      If the client assigns a delegated prefix to a link to which the

      router is attached, and begins to send router advertisements for

      the prefix on the link, the client MUST set the valid lifetime in

      those advertisements to be no later than the valid lifetime

      specified in the IA_PD option.  A client MAY use the preferred

      lifetime specified in the IA_PD option.

 

The “no later” has been changed to “no larger”. And, actually the IA_PD option is wrong (it should be IAPREFIX option, as that holds the lifetimes).

 

Perhaps what we really should say is something like:

 

      If the client assigns a delegated prefix to a link to which the

      router is attached, and begins to send router advertisements for

      the prefix on the link, the valid lifetime in those advertisements

      MUST be no larger than the remaining valid lifetime

      for the delegated prefix.  A client MAY use the preferred

      lifetime as originally received in the IAPREFIX option, provided that whatever

      value is used is less than or equal to the valid lifetime to be sent in the

      router advertisement.

 

That text doesn’t by itself provide any good way to specify a shorter preferred lifetime so that the prefix is marked deprecated before it becomes invalid, but at least it assures that what is send for the preferred and valid meets the basic requires: preferred <= valid in the RA, and the valid is <= what is specified in the IAPREFIX.

 

-          Bernie

 

 

From: Timothy Winters <[hidden email]>
Date: Monday, June 19, 2017 at 2:32 PM
To: Bernie Volz <[hidden email]>
Cc: JINMEI Tatuya /
神明達哉 <[hidden email]>, "[hidden email]" <[hidden email]>, Ralph Droms <[hidden email]>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

 

Hi Bernie,

 

We have CE Routers that countdown from when the IA_PD is received, and others that always transmit the lifetime received in the IA_PD in RA (Always the same).   It's about 50/50 at the moment.   When we were working on testing for 6024/7084 this was a topic that was discussed but it wasn't clear answer on what to do with the lifetimes.

 

You are correct that when the prefix timeout from the IA_PD it will stop forwarding and transmit a Destination Unreachable message.   

 

Regards,

Tim

 

On Mon, Jun 19, 2017 at 2:10 PM, Bernie Volz (volz) <[hidden email]> wrote:

I’ve added Tim Winters as perhaps he can shed some light on this in terms of what is tested at the NH Interoperability Lab for PD / CPEs?

Even if a device doesn’t follow this (running down the lifetimes), what’s likely to happen when the PD expires is that the traffic will hopefully no longer be forwarded by the router (and with a ICMP destination unreachable notification) and perhaps RAs will be sent with 0 lifetimes to attempt to deprecate the prefix (and any assigned addresses) use as quickly as possible?

Ralph or Ole might also have a comment with respect to what they expected a requesting router to do based on the original RFC 3633? I don’t think this 3315bis document itself caused this potential confusion to exist?

- Bernie


On 6/19/17, 1:55 PM, "JINMEI Tatuya / 神明達哉" <[hidden email]> wrote:

    At Sat, 17 Jun 2017 02:27:39 +0000,
    "Bernie Volz (volz)" <[hidden email]> wrote:

    > My reaction is you are wrong – the PIO would, whenever sent, be sent
    > with the preferred and valid lifetime REMAINING on the PD lease. So,
    > sure a PIO sent just after the PD lease started would have (close)
    > to the full values, but the values sent an hour later would be 1
    > hour less than they were.

    Actually I agreed.  I guess what we're different is the view on how
    obvious it is.  I suspect this is not so obvious and there are
    actually implementations that can cause the situation where
    deprecated/invalidated addresses are used.  There may even be an
    implementation that naively copies the lifetimes from PD to RA PIO.

    I've monitored RAs advertised in my apartment room.  The ISP is
    Comcast and the default router is Apple time capsule.  The lifetimes
    advertised in RA PIO are constant and do not decrease as I monitored
    it in multiple consecutive RAs.  Of course, it doesn't immediately
    mean the time capsule device uses the 'naive' approach.  I actually
    don't even know if PD is used or the time capsule is the PD client.
    And the time capsule might actually have some safety buffer period and
    use a much lower lifetimes for PIO than those provided in PD.  Still,
    I think this can be a potential anecdote to suggest there might be a
    problematic implementation.

    So I don't think it at least doesn't harm if we say that lifetimes of
    site addresses derived from the delegated prefix MUST NOT exceed the
    remaining time of the lifetimes in the last-received corresponding
    PD.  (I don't think we have to specify exactly how to implement this
    restriction).

    --
    JINMEI, Tatuya



 

--

Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR


_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

Bernie Volz (volz)

Hi:

 

2nd try to see if there’s any comments on this. Trying to close out the -09 version before the IETF-99 deadline (7/3).

 

-          Bernie

 

From: dhcwg [mailto:[hidden email]] On Behalf Of Bernie Volz (volz)
Sent: Saturday, June 24, 2017 2:29 PM
To: Timothy Winters <[hidden email]>; JINMEI Tatuya /
神明達哉 <[hidden email]>
Cc: [hidden email]; Ralph Droms <[hidden email]>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

 

Hi:

 

Any feedback on this proposed text?

 

It would be nice to be able to publish an -09 before the 7/3 deadline for IETF-99, and perhaps even send this document on to the IESG (assuming Ralph believes there is consensus to do so).

 

An alternative, which in retrospect I think I would prefer, would be for the PIO to use the remaining preferred and valid lifetime on the lease and just say that explicitly. That may be cleanest? So, that proposed text would be:

 

      If the client assigns a delegated prefix to a link to which the

      router is attached, and begins to send router advertisements for

      the prefix on the link, the preferred and valid lifetime in those advertisements

      MUST be no larger than the remaining preferred and valid lifetimes, respectively,

      for the delegated prefix at the time the router advertisement is sent.

 

Please let me know which of the two versions you’d prefer, or suggest an alternative.

 

-          Bernie

 

From: Bernie Volz (volz)
Sent: Monday, June 19, 2017 3:28 PM
To: Timothy Winters <[hidden email]>; JINMEI Tatuya /
神明達哉 <[hidden email]>
Cc: [hidden email]; Ralph Droms <[hidden email]>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

 

Thanks Tim. That’s useful, and shows that we do need to be more explicit.

 

There are two places in draft-ietf-dhc-rfc3315bis-08 (section 6.3 and 18.2.10.1) where we have the following text:

 

      If the client assigns a delegated prefix to a link to which the

      router is attached, and begins to send router advertisements for

      the prefix on the link, the client MUST set the valid lifetime in

      those advertisements to be no later than the valid lifetime

      specified in the IA_PD option.  A client MAY use the preferred

      lifetime specified in the IA_PD option.

 

The “no later” has been changed to “no larger”. And, actually the IA_PD option is wrong (it should be IAPREFIX option, as that holds the lifetimes).

 

Perhaps what we really should say is something like:

 

      If the client assigns a delegated prefix to a link to which the

      router is attached, and begins to send router advertisements for

      the prefix on the link, the valid lifetime in those advertisements

      MUST be no larger than the remaining valid lifetime

      for the delegated prefix.  A client MAY use the preferred

      lifetime as originally received in the IAPREFIX option, provided that whatever

      value is used is less than or equal to the valid lifetime to be sent in the

      router advertisement.

 

That text doesn’t by itself provide any good way to specify a shorter preferred lifetime so that the prefix is marked deprecated before it becomes invalid, but at least it assures that what is send for the preferred and valid meets the basic requires: preferred <= valid in the RA, and the valid is <= what is specified in the IAPREFIX.

 

-          Bernie

 

 

From: Timothy Winters <[hidden email]>
Date: Monday, June 19, 2017 at 2:32 PM
To: Bernie Volz <[hidden email]>
Cc: JINMEI Tatuya /
神明達哉 <[hidden email]>, "[hidden email]" <[hidden email]>, Ralph Droms <[hidden email]>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

 

Hi Bernie,

 

We have CE Routers that countdown from when the IA_PD is received, and others that always transmit the lifetime received in the IA_PD in RA (Always the same).   It's about 50/50 at the moment.   When we were working on testing for 6024/7084 this was a topic that was discussed but it wasn't clear answer on what to do with the lifetimes.

 

You are correct that when the prefix timeout from the IA_PD it will stop forwarding and transmit a Destination Unreachable message.   

 

Regards,

Tim

 

On Mon, Jun 19, 2017 at 2:10 PM, Bernie Volz (volz) <[hidden email]> wrote:

I’ve added Tim Winters as perhaps he can shed some light on this in terms of what is tested at the NH Interoperability Lab for PD / CPEs?

Even if a device doesn’t follow this (running down the lifetimes), what’s likely to happen when the PD expires is that the traffic will hopefully no longer be forwarded by the router (and with a ICMP destination unreachable notification) and perhaps RAs will be sent with 0 lifetimes to attempt to deprecate the prefix (and any assigned addresses) use as quickly as possible?

Ralph or Ole might also have a comment with respect to what they expected a requesting router to do based on the original RFC 3633? I don’t think this 3315bis document itself caused this potential confusion to exist?

- Bernie


On 6/19/17, 1:55 PM, "JINMEI Tatuya / 神明達哉" <[hidden email]> wrote:

    At Sat, 17 Jun 2017 02:27:39 +0000,
    "Bernie Volz (volz)" <[hidden email]> wrote:

    > My reaction is you are wrong – the PIO would, whenever sent, be sent
    > with the preferred and valid lifetime REMAINING on the PD lease. So,
    > sure a PIO sent just after the PD lease started would have (close)
    > to the full values, but the values sent an hour later would be 1
    > hour less than they were.

    Actually I agreed.  I guess what we're different is the view on how
    obvious it is.  I suspect this is not so obvious and there are
    actually implementations that can cause the situation where
    deprecated/invalidated addresses are used.  There may even be an
    implementation that naively copies the lifetimes from PD to RA PIO.

    I've monitored RAs advertised in my apartment room.  The ISP is
    Comcast and the default router is Apple time capsule.  The lifetimes
    advertised in RA PIO are constant and do not decrease as I monitored
    it in multiple consecutive RAs.  Of course, it doesn't immediately
    mean the time capsule device uses the 'naive' approach.  I actually
    don't even know if PD is used or the time capsule is the PD client.
    And the time capsule might actually have some safety buffer period and
    use a much lower lifetimes for PIO than those provided in PD.  Still,
    I think this can be a potential anecdote to suggest there might be a
    problematic implementation.

    So I don't think it at least doesn't harm if we say that lifetimes of
    site addresses derived from the delegated prefix MUST NOT exceed the
    remaining time of the lifetimes in the last-received corresponding
    PD.  (I don't think we have to specify exactly how to implement this
    restriction).

    --
    JINMEI, Tatuya



 

--

Now offering testing for SDN applications and controllers in our SDN switch test bed. Learn more today http://bit.ly/SDN_IOLPR


_______________________________________________
dhcwg mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

Re: WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

神明達哉
At Tue, 27 Jun 2017 18:15:29 +0000,
"Bernie Volz (volz)" <[hidden email]> wrote:

> 2nd try to see if there’s any comments on this. Trying to close out
> the -09 version before the IETF-99 deadline (7/3).

Sorry for the delay, I've been offline.  As for your proposed text:

      If the client assigns a delegated prefix to a link to which the
      router is attached, and begins to send router advertisements for
      the prefix on the link, the preferred and valid lifetime in
      those advertisements MUST be no larger than the remaining
      preferred and valid lifetimes, respectively, for the delegated
      prefix at the time the router advertisement is sent.

it addresses my main concern.  I'd personally generalize it a bit,
though.  For example:

   If the client uses a delegated prefix to configure addresses on
   interfaces on itself or other nodes behind it, the preferred and
   valid lifetimes of those addresses MUST be no larger than the
   remaining preferred and valid lifetimes, respectively, for the
   delegated prefix at any time.  In particular, if the delegated
   prefix or a prefix derived from it is advertised for stateless
   address autoconfiguration [RFC4862], the advertised valid and
   preferred lifetimes MUST NOT exceed the corresponding remaining
   lifetimes of the delegated prefix.

Here I tried to not limit the use of lifetimes to SLAAC (for example,
they could be used in DHCPv6 for the delegated site), while explicitly
noting the SLAAC case as we now know there are implementations that
violate it.

I'd also update the description of the PD 'preferred-lifetime'
(Section 21.22 in the 08 version) from:

      preferred-lifetime   The recommended preferred lifetime for the
                           prefix in the option, expressed in units of
                           seconds.  A value of 0xFFFFFFFF represents
                           infinity.

to, for example:

      preferred-lifetime   The preferred lifetime for the
                           prefix in the option, expressed in units of
                           seconds.  This lifetime does not affect the
                           protocol behavior of prefix delegation, but
                           has implication on addresses generated
                           using the prefix (see below).  A value of
                           0xFFFFFFFF represents infinity.

Here I avoided the term "recommended" as it's not clear what it means
(I asked this before in this thread but no one answered) and provided
the description of this value I envision.  "see below" refers to the
additional note we're discussing above.

--
JINMEI, Tatuya

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