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

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

(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: <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>>, Yong Cui <[e-mail]<mailto:[e-mail]>>, Tianxiang Li <[e-mail]<mailto:[e-mail]>>

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
…