Re: [dhcwg] Fwd: New Version Notification for draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02.txt

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

Hi:

(These are my personal comments – i.e., with WG chair hat off.)

Thanks for updating the document. I think the organization is much improved.

I read over this document and have mostly nits:


1.       I think it would be useful if this document actually used “OPTION_IAPREFIX”. While is does reference it by its name in RFC 3633 (IA_PD Prefix Option), actually making use of it would be good – such as for google searches.

2.       In section 1. Introduction:

   DHCPv6 Prefix Delegation [RFC3633<https://tools.ietf.org/html/rfc3633>] allows a requesting router to
   include a prefix-length hint value in the message sent to the
   delegating router, to indicate a preference for the size of the
   prefix to be delegated.  A prefix-length hint is communicated by a
   requesting router to the delegating router by including an IA_PD
   Prefix Option, encapsulated in an IA_PD option, with the "IPv6
                ^ insert “(OPTION_IAPREFIX)” here?
   prefix" field set to zero and the "prefix-length" field set to a non-
   zero value.  The delegating routers are free to ignore the hint
   values depending on server policy.  This would not cause problems for
   some hint values such as T1 and T2 lifetimes, but it would be an
                                                        ^ could?
       (note also that we are planning on deprecating T1/T2/lifetime hints
        and saying “such as T1, T2, and lifetimes” would be more proper?)
   issue for the prefix-length hint.  Some requesting routers can't
   function normally when they're provided with a prefix which length is
   different from what they requested.  E.g. if the requesting router is
   asking for a /56 and the delegating router returns a /64, the
   functionality of the requesting router might be limited because it
   might not be able to split the prefix for all its interfaces.  The
   requesting routers usually have higher preference on the prefix-
   length hint than the other option hints, and it should be given more
   consideration.
        (I think this last sentence as no value so would recommend dropping)

   The current specification is unclear about how the requesting router
   ^^^^^^^^^^^^^^^^^^^^^^^^^ [RFC3633]
        (Current is unclear – does it refer to this document or ? So why
         not replace with [RFC3633]?)
   and delegating router should act in different situations involving


3.       While minor, there are several places where “/30,/48, and /56” is used … add space before /48?

4.       In section 3.2, “only provides prefixes pf lengths” … pf should be of?

5.       In section 3.4, “delegating routers might not” … “Delegating routers might not”.

And, later space is missing after “.” in “during Renew/Rebind.[RFC3633]”.

Also, again “IA_PD Prefix Options” could just be “OPTION_IAPREFIX”?

And, “This is to extend [the] lifetime”. (Add the.)

6.       In section 3.5, in the solution, I think it would be good to clarify that there are two OPTION_IAPREFIX options:

   Upon the receipt of Renew message, if the requesting router included
   in the IA_PD both the delegated prefix value and a prefix-length hint
   value, the delegating router should check to see whether it could
   extend the lifetime of the original delegated prefix and whether it
   has any available prefix matching the prefix-length hint, or as close
   a possible to the requested length, within the delegating router's
   limit.



Perhaps reword to something like:


   Upon the receipt of Renew message, if the requesting router included
   in the IA_PD both OPTION_IAPREFIX option with the delegated prefix
   and an OPTION_IAPREFIX option for a prefix-length hint, the delegating
   router should check to see whether it could extend the lifetime of the
   original delegated prefix and whether it has any available prefix
   matching the prefix-length hint, or as close a possible to the
   requested length, within the delegating router's limit.

Later in this section assign is misspelled (asssign).


-          I think you also need to take a first pass at the Security Considerations. It may be possible to just state that this document introduces no new security considerations over those already discussed in [RFC3633] as the document is providing guidance on how requesting routers and delegating routers interact with regard to the prefix-length hint mechanism introduced in [RC3633].

Hopefully others will comment on this document and we can soon move to doing a WG call for adoption?


-          Bernie

From: dhcwg [mailto:[e-mail]] On Behalf Of tianxiang li
Sent: Saturday, November 14, 2015 12:57 AM
To: dhcwg <[e-mail]>
Subject: [dhcwg] Fwd: New Version Notification for draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02.txt

Hi all,

We have updated a new version of the DHCPv6 Prefix Length Hint Issues draft, according to the comments from the ietf94 meeting and the mailinglist.

Main changes:

1. Changed text structure, problem statement and solution are now written in the same section.

2. Changed document type from Standards Track to Informational.

3. Changed terms "client/server" to "requesting router/delegating router", to keep text unified with RFC3633.

4. In the solution part of section 3.5.  Receipt of Renew/Rebind Message, we added an additional server solution choice. A server could assign a new prefix and not mention the old prefix in the Reply message.

5. In the solution part of section 3.3.  Receipt of Advertise Message, added reference to RFC7550 for the situation where the client requested for both IA_NA and IA_PD options, and the server could not honor the prefix-length hint of the IA_PD option.

Comments and reviews are appreciated.

Regards,
Tianxiang Li

---------- Forwarded message ----------
From: <[e-mail]<mailto:[e-mail]>>
Date: 2015-11-14 13:54 GMT+08:00
Subject: New Version Notification for draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02.txt
To: Tianxiang Li <[e-mail]<mailto:[e-mail]>>, Yong Cui <[e-mail]<mailto:[e-mail]>>, Cong Liu <[e-mail]<mailto:[e-mail]>>



A new version of I-D, draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02.txt
has been successfully submitted by Tianxiang Li and posted to the
IETF repository.

Name:           draft-cui-dhc-dhcpv6-prefix-length-hint-issue
Revision:       02
Title:          DHCPv6 Prefix Length Hint Issues
Document date:  2015-11-13
Group:          Individual Submission
Pages:          9
URL:            https://www.ietf.org/internet-drafts/draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02.txt
Status:         https://datatracker.ietf.org/doc/draft-cui-dhc-dhcpv6-prefix-length-hint-issue/
Htmlized:       https://tools.ietf.org/html/draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-cui-dhc-dhcpv6-prefix-length-hint-issue-02

Abstract:
   DHCPv6 Prefix Delegation [RFC3633] allows a requesting router to
   include a prefix-length hint value in the IA_PD option to indicate a
   preference for the size of the prefix to be delegated, but is unclear
   about how the requesting router and delegating router should act in
   different situations involving the prefix-length hint.  This document
   provides a summary of the existing problems with the prefix-length
   hint and guidance on what the requesting router and delegating router
   could do in different situations.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat