Re: [dhcwg] dhcwg Digest, Vol 135, Issue 23

tianxiang li <> Mon, 27 July 2015 13:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 99BC91B2D3C for <>; Mon, 27 Jul 2015 06:32:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IlR2INAoBV_G for <>; Mon, 27 Jul 2015 06:32:13 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1586A1A6F30 for <>; Mon, 27 Jul 2015 06:32:12 -0700 (PDT)
Received: by lbbzr7 with SMTP id zr7so53500658lbb.1 for <>; Mon, 27 Jul 2015 06:32:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IzEb1Hzg2TJQ1pX8p1fQLpD2BS7R2EY/Ym6GK0XELFc=; b=P42d9EMtOTykRj9M9iXI5362QqxRVoPxxSBDNEhhPWR7UISbfLnOrY/wMsiNcoIsh6 tuKm8sGru+1wncFb30CjUZA4JO7nkNwqpg08UXj8VBZU0TYVdWlLnA/cqFzECU8K398O zgI3cs1Cir1CGbDLMOg/MOhuKU+qrnvDVTe/JF+9U9EXaWSLvxNxkNmEZ12o2kfefw0r 1Vcr2Nqk7tmL6DYVwCZ+PqwQZRrRPYwUMaAxTN6f/1aooa+Gv2QMIwZuMFM06OdSdMXh foUka75k0W+Z5f+ZfkAn1MCpjcMsZF+M7Bzowfl2UZxMUY0EC1bQqODp7zC9wEkzupov OEfQ==
MIME-Version: 1.0
X-Received: by with SMTP id qf12mr26460138lbc.98.1438003931284; Mon, 27 Jul 2015 06:32:11 -0700 (PDT)
Received: by with HTTP; Mon, 27 Jul 2015 06:32:11 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Mon, 27 Jul 2015 21:32:11 +0800
Message-ID: <>
From: tianxiang li <>
To: "Bernie Volz (volz)" <>,, Dan.Seibel@TELUS.COM
Content-Type: multipart/alternative; boundary="001a1134de7882894b051bdb6147"
Archived-At: <>
Subject: Re: [dhcwg] dhcwg Digest, Vol 135, Issue 23
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 13:32:15 -0000

Sorry about my typing error in the last mail message

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

1. For servers which *do not *support prefix delegation, if they cannot
provide a prefix to the client, they will not include an IA_PD option in
the Advertise message.

2. For servers which *do* support prefix delegation, but cannot provide a
prefix to the client at the time being, they 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