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

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 17 Aug 2015 16:23:44 +0000

(Resent with less of email chain as otherwise too big for dhcwg mailer. If responding to this email, you may want to remove most of the original message.)

Here’s some comments on the draft (and to clarify, these are my individual comments).

First, thanks to Tianxiang and the other co-authors for writing up this draft to the prefix length issues that were raised during the RFC 3315/3633 bis work (see http://trac.tools.ietf.org/group/dhcpv6bis/ticket/114). This document is a great start.

And now for the comments:

1.       Introduction

Probably wise to get a reference to RFC 3633 into this material as prefix delegation is specified in that RFC, not 3315.

-          Early on ..

Not sure exactly where the best place is (perhaps in section 3) or end of 1, but I think it would be wise to clarify how the prefix length hint is communicated. i.e., A prefix length hint is communicated by a client to the server by including an IAPREFIX option, encapsulated in an IA_PD, that has all 0’s in the “IPv6 prefix” field and a non-zero value in the “prefix-length” field.

3.1 Creation of Solicit Messages by Client

Change “what the client should do” to “what should the client do”? (And add a question mark at the end of the sentence?)

Also, it is not clear to me how a client can “deprecate the old prefix after some time interval”. There isn’t any way for a client to prevent a server from renewing existing “leases” – even not including the “lease” in the Renew or Rebind doesn’t guarantee that the server would not renew it.

And, given recommendations from RFC 7550, I’m not sure what case this is to cover anyway? If this is a Solicit, what is this “currently using” prefix?

I think for a Solicit, the only case that exists is the that the client didn’t get a prefix length that is at least as short as it requested (a shorter prefix length must be handled, but is not as much an issue as a longer prefix length than it requested).

3.2 Receipt of Solicit message by the Server

The first sentence is a bit odd … remove “with” and do you really need “if the same client requested a prefix from the server”?

3.3 Receipt of Advertise Message by the Client

I think you want to say “or continue to ask for its preferred prefix length.”? (i.e., add length?)

And replace “continue to solicit” with “continues to Solicit”?

3.4 Creation of Renew/Rebind Message by the Client

In 2nd paragraph, wouldn’t RFC 3633 be a better reference? None of the 3315 hints really is similar here. And, it isn’t 100% clear that RFC 3633 prohibits this since it only uses hint once – in section 7:
   The requesting router may include prefixes in the IA_PDs as a hint to
   the delegating router about specific prefixes for which the
   requesting router has a preference.

Yet, the above context is clearly for a Solicit. However, in the IAPREFIX definition there is:

   In a message sent by a requesting router to a delegating router, the
   values in the fields can be used to indicate the requesting router's
   preference for those values.  The requesting router may send a value
   of zero to indicate no preference.  A requesting router may set the
   IPv6 prefix field to zero and a given value in the prefix-length
   field to indicate a preference for the size of the prefix to be
   delegated.

So this is more broadly “in a message”.

Thus, I think the “[RFC3315] does not allow a client to include … hint …” seems a bit too strong a statement. I’m not sure whether removing this sentence is best, or whether say “[RFC3633] is not completely clear on whether a client is allowed”?

3.6 Receipt of Rebind Message by the Server

I think you want to say “prefix hint length value” (instead of prefix length value)? Perhaps a review of the text at some point to be sure it uses consistent usage is important.

I also think you can remove “the client can find” from “The Rebind message is sent to any available servers”. As the message is multicast, the client does not “find” anything but sees what it gets back.

4.1 Creation of Solicit Message by the Client (& 4.2 & 4.4/4.5)

I think RFC 7550 (Stateful Issues) may change some of this, since we are recommending not to Solicit (but Renew even with a new IA_* option – though there are backwards compatibility considerations).

Also, the change IAID, while simple in concept, has some nasty repercussions for  some clients. It requires stable storage. Think of what happens if a client boots and starts using IAID 1. Later, it does what you say and uses IAID 2. It is going along but then reboots (power cycles) …. It will start back at using IAID 1 unless it has some stable storage to note that it was using IAID 2, not 1. And, if the original lease is still active in the server,  it may well give it back that old lease (see section 3.2).

Thus, I think this requires some more thought as to how best to handle (especially since requiring stable storage for this might be an issue for some kinds of devices).

BTW: Perhaps at the end of the section, referencing RFC 7083 (SOLMAX) would be best?

My own feeling is that the client should simply send a RENEW with the same IA_PD and include a prefix-length hint IAPREFIX option. It would then be up to the server which could:

1.       Renew just the original delegated prefix.

2.       Renew the original delegated prefix and assign a new one of the requested length (within the server’s limits).

3.       Mark the original delegated prefix as invalid (0 lifetimes) and assign a new one of the requested length (with the server’s limits).
Which of the 3 a server does is up to it (i.e., up it is policy).

Note that obvious 3 has a negative consequence as this may “break” all of the existing “connections” for the subscriber. But it also gives the subscriber what was desired and avoids the complexities with handling multiple delegated prefixes.

4.2 Receipt of Solicit message by the Server

See above. Also “time being” is a bit odd in the places used here? I think you can just use “time”.

Adding something here (or elsewhere were prefix hint lengths are ‘used’) to say that a server should provide the shortest prefix length possible that is closest to what the client requested (and the server’s policy allows).

4.4 Creation of Renew Message by the Client

See above (4.1…) as I think this should be a SINGLE IA_PD with normal IAPREFIX plus a prefix length hint with IAPREFIX.

4.5 Receipt of Renew Message by the Server

The “to9” is a typo.

The shorter lifetime for the “old” delegated prefix is certainly a “nice” option, but again it may not be worth the complexity involved (i.e., handling multiple prefixes). And it also isn’t clear when the server would discard this (and this would require extra “information” in the server to know it was ‘deprecating’ this prefix and not to renew it on subsequent requests). Think of the next Renew which might include both IAPREFIXes – how is the server to remember which was the client’s “preferred prefix length hint”??

We may want to get feedback/input from various operators about how they feel about whether the ‘graceful’ transitioning is worth it. One brief discussion I had with an operator indicated they would be OK with (prefer) no graceful transition as they’d prefer to have only one delegated prefix to deal with and didn’t expect this to be a common event.

-          Bernie

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: 2015-07-06 20:14 GMT+08:00
Subject: New Version Notification for draft-cui-dhc-dhcpv6-prefix-length-hint-issue-00.txt
To: Cong Liu <[email-masked]<mailto:[email-masked]>>, Yong Cui <[email-masked]<mailto:[email-masked]>>, Tianxiang Li <[email-masked]<mailto:[email-masked]>>

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

Name:           draft-cui-dhc-dhcpv6-prefix-length-hint-issue
Revision:       00
Title:          DHCPv6 Prefix Length Hint Issues
Document date:  2015-07-06
Group:          Individual Submission
Pages:          9
URL:            https://www.ietf.org/internet-drafts/draft-cui-dhc-dhcpv6-prefix-length-hint-issue-00.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-00
…

---

From: tianxiang li <[email-masked]>
Date: Thu, 20 Aug 2015 15:25:23 +0800

Hi Bernie,

Thank you for the thorough review of the document. The comments are very
helpful, and I will include them into the next version of the draft, which
I'm currently working on. Some parts of the draft might need further
discussion. Please see comments inline.

Regards,
Tianxiang

2015-08-18 0:19 GMT+08:00 Bernie Volz (volz) <[email-masked]>:

> Also, it is not clear to me how a client can “deprecate the old prefix
> after some time interval”. There isn’t any way for a client to prevent a
> server from renewing existing “leases” – even not including the “lease” in
> the Renew or Rebind doesn’t guarantee that the server would not renew it.
>

This refers to the client sending a Release message to stop using the old
prefix. The client could either release the old prefix right away, or the
client could use the two prefixes at the same time and release the old
prefix after some time interval, or just wait for it to expire.

> And, given recommendations from RFC 7550, I’m not sure what case this is
> to cover anyway? If this is a Solicit, what is this “currently using”
> prefix?
>
>
>
This is the situation where the client has already been delegated a prefix,
but would like to switch to a new prefix of different length (e.g. due to
configuration change). I was wondering whether a client could send a
Solicit message with a different IAID to request for the new prefix.
However, this would create a separate DHCP session for the new prefix,
which is something RFC7550 tries to avoid. And it also requires stable
storage of the different IAID.

> I think for a Solicit, the only case that exists is the that the client
> didn’t get a prefix length that is at least as short as it requested (a
> shorter prefix length must be handled, but is not as much an issue as a
> longer prefix length than it requested).
>
>
>
This issue is covered in section 4.3 (Receipt of Advertise Message by the
Client), discussing how the client should handle prefixes different from
what it requested. Maybe we should add more details into this section
regarding cases when the delegated prefix is shorter or longer than the
prefix-length hint. Would there be a problem for the client if it got a
prefix shorter than the length it requested?

> I think RFC 7550 (Stateful Issues) may change some of this, since we are
> recommending not to Solicit (but Renew even with a new IA_* option – though
> there are backwards compatibility considerations).
>
>
>
Sending a Solicit would result in separate DHCP session for the new prefix,
which would cause a number of issues, as mentioned in RFC7550. The client
could also request a new prefix during Renew, but the client would have to
wait until t1 to do that. In the case where a client needs to switch to a
new prefix right away, would it be better to use Solicit?

> Also, the change IAID, while simple in concept, has some nasty
> repercussions for  some clients. It requires stable storage. Think of what
> happens if a client boots and starts using IAID 1. Later, it does what you
> say and uses IAID 2. It is going along but then reboots (power cycles) ….
> It will start back at using IAID 1 unless it has some stable storage to
> note that it was using IAID 2, not 1. And, if the original lease is still
> active in the server,  it may well give it back that old lease (see section
> 3.2).
>
>
>
Using a different IAID would cause problems regarding stable storage, more
thought need to be put here. What if the client sends a Solicit message
using the same IAID and containing a prefix-length hint, how would the
server interpret that case? Would the server consider this as the client
wanting to release the old prefix and get a new prefix?

> My own feeling is that the client should simply send a RENEW with the same
> IA_PD and include a prefix-length hint IAPREFIX option.
>
>
>
Here, do you mean to include two IAPREFIX options in the IAPD option, one
containing the original delegated prefix and the other one containing the
prefix-length hint? Or do you mean to include both the original delegated
prefix and the prefix-length hint in one IAPREFIX option?

Another option would be for the server to include the prefix-length hint in
a new IAPD option. This is similar to the client requesting for a new IA
during Renew, as stated in RFC7550.

Section 4.4.6. of RFC7550:

*For each IA for which the server cannot find a client entry, the server
has the following choices *
*depending on the server's policy and configuration information:*

*     -  If the server is configured to create new bindings as a result*
*        of processing Renew messages, the server SHOULD create a binding*
*        and return the IA with allocated addresses with lifetimes and,*
*        if applicable, T1/T2 times and other information requested by*
*        the client.  The server MAY use values in the IA Address option*
*        (if included) as a hint. *

>
>
>
> The shorter lifetime for the “old” delegated prefix is certainly a “nice”
> option, but again it may not be worth the complexity involved (i.e.,
> handling multiple prefixes). And it also isn’t clear when the server would
> discard this (and this would require extra “information” in the server to
> know it was ‘deprecating’ this prefix and not to renew it on subsequent
> requests). Think of the next Renew which might include both IAPREFIXes –
> how is the server to remember which was the client’s “preferred prefix
> length hint”??
>
>
>
Here, maybe the client should decide when to stop using a prefix, by
sending a Release message. The server should simply extend lifetimes of the
prefixes, without having to know which one it should discard or how long it
should wait before discarding. This way, the server wouldn’t have to keep
extra information. Of course if we don’t use graceful renumbering, this
complexity could be avoided, the client would only keep one delegated
prefix, but this depends on the need of the operators.

>
>
> We may want to get feedback/input from various operators about how they
> feel about whether the ‘graceful’ transitioning is worth it. One brief
> discussion I had with an operator indicated they would be OK with (prefer)
> no graceful transition as they’d prefer to have only one delegated prefix
> to deal with and didn’t expect this to be a common event.
>
>
>
> -          Bernie
>
>
>
>
>
> *From:* dhcwg [mailto:[email-masked]] *On Behalf Of *tianxiang li
> *Sent:* Tuesday, July 07, 2015 9:40 AM
> *To:* [email-masked]
> *Subject:* [dhcwg] Fwd: New Version Notification for
> draft-cui-dhc-dhcpv6-prefix-length-hint-issue-00.txt
>
>
>
> Hi all,
>
>
>
> We have submitted a new draft providing a summary of the existing problems with the prefix length hint and guidance on what the client and server could do in the different situation involving the the prefix length hint.
>
>
>
> The document might not cover all of the existing issues with the prefix length hint, and we hope you can provide your valuable suggestions to make the document more complete. We proposed some possible solutions, but they're not perfect, and we'd really appreciate any comments on how it could be improved.
>
>
>
> Comments and reviews are appreciated.
>
>
>
>
>
> Best Regards,
>
> Tianxiang Li
>
> From: <[email-masked]>
> Subject: New Version Notification for
> draft-cui-dhc-dhcpv6-prefix-length-hint-issue-00.txt
> To: Cong Liu <[email-masked]>, Yong Cui <[email-masked]>,
> Tianxiang Li <[email-masked]>
>
>
>
> URL:
> https://www.ietf.org/internet-drafts/draft-cui-dhc-dhcpv6-prefix-length-hint-issue-00.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-00
>
>
> Abstract:
>    DHCPv6 Prefix Delegation [RFC3633] allows a client to set a hint
>    value in the prefix-length field of the IA_PD option to indicate a
>    preference for the size of the prefix to be delegated, but is unclear
>    about how the client and server 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 client and server could do in the different situation
>    involving the the prefix length hint.
>
>
>
>
> 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.
>
> The IETF Secretariat
>
>
>