Re: [dhcwg] two comments on draft-cui-dhc-dhcpv6-prefix-length-hint-issue

"Bernie Volz (volz)" <> Mon, 27 July 2015 14:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D8FAC1B2E67 for <>; Mon, 27 Jul 2015 07:55:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3adBta5gxJEo for <>; Mon, 27 Jul 2015 07:55:46 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5FCEC1B2E54 for <>; Mon, 27 Jul 2015 07:55:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=27034; q=dns/txt; s=iport; t=1438008946; x=1439218546; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QtJBPhmvYZj4j8ofoTIbmkwL6kvv7t6zZyvKQjvmge4=; b=R5w73K09DjJAIRrive6LQj+pw4nG3UVwQoybsDD2dMpd8gNHJ/3C1njH bcRsjiFR+Uh3y7lgBXssf7S2XT814l3t0vcgGXwD1MB4fzXAukok+2Vb8 WYYr9TPe3OTAy5wDLh5wKQbT8AoTe+kRdVAh1XCGRGZm9C6DWl+1zAVWk U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.15,554,1432598400"; d="scan'208,217"; a="19100770"
Received: from ([]) by with ESMTP; 27 Jul 2015 14:55:45 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t6REtje1028171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 27 Jul 2015 14:55:45 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Mon, 27 Jul 2015 09:55:44 -0500
From: "Bernie Volz (volz)" <>
To: tianxiang li <>, "" <>, "Dan.Seibel@TELUS.COM" <Dan.Seibel@TELUS.COM>
Thread-Topic: [dhcwg] two comments on draft-cui-dhc-dhcpv6-prefix-length-hint-issue
Thread-Index: AQHQyG3D57vh4oLBlkqnsHurQzNNTp3vZe1w
Date: Mon, 27 Jul 2015 14:55:44 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1CB8BFDAxmbrcdx04ciscoc_"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [dhcwg] two comments on draft-cui-dhc-dhcpv6-prefix-length-hint-issue
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Jul 2015 14:55:49 -0000

Please let’s keep this document focused on the prefix length hint issue. It already is clear that this is only applicable when implementing RFC 3633.

   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.

I’d also like to stay away from other issues (such as sending RAs). That should already be pretty clear – it would be dumb to send RAs about a prefix which has been released or is no longer valid (valid lifetime has expired) and is not a new problem related to the hints but normal operation when prefixes change (through some configuration mechanism) and is not really related to DHCPv6 at all. If you want to work on those issues, I would recommend you consider 6man.

And again, just for correctness, NoPrefixAvail is the Status Code related to PD.

-          Bernie

From: tianxiang li []
Sent: Monday, July 27, 2015 9:11 AM
To: Bernie Volz (volz);; Dan.Seibel@TELUS.COM
Subject: Re: [dhcwg] two comments on draft-cui-dhc-dhcpv6-prefix-length-hint-issue

Thank you for providing the comments.

For #1 I agree with Bernie and Alexandru. There are two cases when a server cannot provide a prefix:

1.  Servers which support prefix delegation, will not include an IA_PD option in the Advertise   message.
2. Servers which support prefix delegation but cannot provide a prefix and the time being, will return a status code of Noaddrsavail in the IA_PD option.

The current document does assume all the servers could support prefix delegation. I think we could add some text in “Receipt of Advertise message by the Client” (section 3.3&4.3) describing these cases.

For #2 Yes, the client should stop sending RAs on its other interfaces. I think we could add this text to section 4.1 “Creation of Solicit Message by the Client”

> On Jul 23, 2015, at 6:38 AM, Alexandru Petrescu <alexandru.petrescu at<>> wrote:


> Hello,


> I just read draft-cui-dhc-dhcpv6-prefix-length-hint-issue-00.


> I am happy this draft exists and I have two comments.  One is more

> general question in this context, and the other a potential improvement,

> but not a request.


> The draft assumes the Client is a Host which may request a prefix len at

> some point, and another one maybe later.  It seems the prefix is to be

> used on the interface which has issued that Solicit.  And it seems to

> face a Server sure to be willing to deliver a prefix.


> 1. What is the best way to query a DHCPv6 Server to ask it whether or

> not it supports Prefix Delegation at all?


> 2. when this Router changes mind and requests a different prefix, maybe

> with a different length, a specification like

> draft-cui-dhc-dhcpv6-prefix-length-hint-issue could recommend to

> deprecate that prefix with specific consideration to below it, not just

> to the Server.


> I mean this something like this:


> Current text:

>> 1.Deprecate the old prefix right away by sending a Release message to

>> the server, and switch over to the new prefix.


> New text:

>> 1.Deprecate the old prefix right away by sending a Release message to

>> the server, and switch over to the new prefix.  And by stopping

>> sending RAs on its other interfaces with the old prefix, stop

>> propagating it in the routing protocol.


> Alex


> _______________________________________________

> dhcwg mailing list

> dhcwg at<>