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

tianxiang li <peter416733@gmail.com> Thu, 20 August 2015 07:25 UTC

Return-Path: <peter416733@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A851A0358 for <dhcwg@ietfa.amsl.com>; Thu, 20 Aug 2015 00:25:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOrsPyjsSx0D for <dhcwg@ietfa.amsl.com>; Thu, 20 Aug 2015 00:25:25 -0700 (PDT)
Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFE951A0338 for <dhcwg@ietf.org>; Thu, 20 Aug 2015 00:25:24 -0700 (PDT)
Received: by lahi9 with SMTP id i9so17104588lah.2 for <dhcwg@ietf.org>; Thu, 20 Aug 2015 00:25:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=uNKD/FuaqZv8NcEzUjVUsMXZRRbHXCJlGwhXFEy40lI=; b=WDhL0tQAukp2KMxgT3k2iQ9omcGgjC6Z2vBGAVu6fsGw29cIEzB8kEdfHCUaKWP34Y s4q8b5UNLIpix1qqqsm8rEaP/4rNs6kRrvQ4erv+h9Xor2/j4PrdUKPoao6m6qFBGaPr g1/jC7LEEzr8tbeJ9DP1CLcOFcSz5p/aqpsGT1zsrN/qZgSwpiAWzjFgtV2GAUQtuqcb qixbq/jEjII6P7JrFutBPlLOEYbDY868yba517c8j8URdbyLKrNNDLGXp4kh8nTOzmQ/ wEQNAAvyLeP1ARTfvYmm93YricvtXc+rFSbic7OfzY3jk//x8pgfh0ndzibvqVW0EhRS H1hw==
MIME-Version: 1.0
X-Received: by 10.152.206.41 with SMTP id ll9mr1589357lac.103.1440055523155; Thu, 20 Aug 2015 00:25:23 -0700 (PDT)
Received: by 10.25.165.66 with HTTP; Thu, 20 Aug 2015 00:25:23 -0700 (PDT)
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1CC4057B@xmb-rcd-x04.cisco.com>
References: <20150706121444.25867.9398.idtracker@ietfa.amsl.com> <CAFx+hEPdO98t+PQXD+b5K3FFSd9q_G3J0Ch+eEN1pFEP7eYaww@mail.gmail.com> <489D13FBFA9B3E41812EA89F188F018E1CC4057B@xmb-rcd-x04.cisco.com>
Date: Thu, 20 Aug 2015 15:25:23 +0800
Message-ID: <CAFx+hENMuktns-MaVnRwne7oq0qYAz9B7Aroubx2_4nNo1W6Og@mail.gmail.com>
From: tianxiang li <peter416733@gmail.com>
To: "Bernie Volz (volz)" <volz@cisco.com>, dhcwg@ietf.org
Content-Type: multipart/alternative; boundary="001a1133af6aea23d2051db90da0"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/YAtiYDHm9gcy0Jx7nZDXxKFq8kU>
Subject: Re: [dhcwg] Fwd: New Version Notification for draft-cui-dhc-dhcpv6-prefix-length-hint-issue-00.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Aug 2015 07:25:29 -0000

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) <volz@cisco.com>:

> Here’s some comments on the draft (and to clarify, these are my individual
> comments).
>
>
>
> 3.1 Creation of Solicit Messages by Client
>
>
>
> 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?


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

4.5 Receipt of Renew Message by the Server
>
>
>
> 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:dhcwg-bounces@ietf.org] *On Behalf Of *tianxiang li
> *Sent:* Tuesday, July 07, 2015 9:40 AM
> *To:* dhcwg@ietf.org
> *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
>
> ---------- Forwarded message ----------
> From: <internet-drafts@ietf.org>
> 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 <gnocuil@gmail.com>, Yong Cui <yong@csnet1.cs.tsinghua.edu.cn>,
> Tianxiang Li <peter416733@gmail.com>
>
>
>
> 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
>
>
> 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
>
>
>