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

"Bernie Volz (volz)" <> Thu, 23 July 2015 13:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5290A1ACD4A for <>; Thu, 23 Jul 2015 06:41:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 B1J1suLV4bWu for <>; Thu, 23 Jul 2015 06:41:51 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9229C1ACD19 for <>; Thu, 23 Jul 2015 06:41:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3303; q=dns/txt; s=iport; t=1437658893; x=1438868493; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=M67RT5Vazq7r0ZW9uV2+PlKjYSkX2W/IHO4ANSjRrw0=; b=F9nJ4lIR/QAVppM2UN0qPKAXZyjXWDkwp2dz7A/PzOIgMOf7GFh3Gdil hylMpOIFYPkDng0e7O6lmQJCMfEjllxTJc2kYnP3QwWj94W7lTn5lCne+ tNl2+K6PidfgPbRF2D7EdwLjzXqC1/mUpZMjASOuVHDE8ohog16cQzXxk c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.15,530,1432598400"; d="scan'208";a="171158456"
Received: from ([]) by with ESMTP; 23 Jul 2015 13:41:32 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t6NDfWPK023492 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Jul 2015 13:41:32 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Thu, 23 Jul 2015 08:41:32 -0500
From: "Bernie Volz (volz)" <>
To: Dan Seibel <Dan.Seibel@TELUS.COM>, Alexandru Petrescu <>
Thread-Topic: [dhcwg] two comments on draft-cui-dhc-dhcpv6-prefix-length-hint-issue
Thread-Index: AdDFRrdjXTPklsqLRL6xeayAmMxnggABbH2A
Date: Thu, 23 Jul 2015 13:41:32 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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: Thu, 23 Jul 2015 13:41:57 -0000

Actually for IA_PD you would get NoPrefixAvail (and that is in the Status Code option encapsulated in the IA_PD).

I think there may be servers that do not support (implement) IA_PD at all, which would result in no IA_PD in the Advertise (or Reply).

So a client should handle both cases.


Also, the best way to assure a completely new delegated prefix (or an address), is to send a new IAID in the IA_PD. This assures the device would get a new delegated prefix. The client can release the old one or just let it gracefully expire.

There are some negative consequences with this changing the IAID of the IA_PD if the device has no persistent storage since rebooting the device would cause it to use the original IAID on the IA_PD and then it would either get another prefix or the original one back (if the original hadn't been released or expired, ignoring any kind of grace time issues that a server might use).

- Bernie

-----Original Message-----
From: dhcwg [] On Behalf Of Dan Seibel
Sent: Thursday, July 23, 2015 8:55 AM
To: Alexandru Petrescu
Subject: Re: [dhcwg] two comments on draft-cui-dhc-dhcpv6-prefix-length-hint-issue

For #1 I would think sending a solicit with IA_PD is how you can find out if the server supports it.  If it does you will get a prefix returned, if not you will get a Noaddrsavail for the IA.

> On Jul 23, 2015, at 6:38 AM, Alexandru Petrescu <> 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 mailing list