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

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E91571B2D12 for <>; Mon, 27 Jul 2015 06:11:29 -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 NLDksvCN__Jg for <>; Mon, 27 Jul 2015 06:11:28 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DAE2D1B2D10 for <>; Mon, 27 Jul 2015 06:11:27 -0700 (PDT)
Received: by lbbqi7 with SMTP id qi7so52992311lbb.3 for <>; Mon, 27 Jul 2015 06:11:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=ETI5r/S2hJB06oC0oTbTEu6WN/2cY2pk2M/t/f4Nq1w=; b=vtcVmDw/Jl2ipYcxtCQoQhBbBs66g9572v02AJWyWw569qZ2lWbGZ9965zWkLn0O4R TyrQdxVpLl3doD3DtZpF7SlhXvMofAICUKDRYzvmPDkDbJgykq5ZEEV4nfTG0l275x5p wW8vhAereFMtXrkgm55/x0RWXQNZZ2lQc4uIMkf0DUmAh+sm41hIPaJt+B+u9SlGil39 KkzwQeh6MaLur3z0CNIOZIcU7RhszqDtcioTt4W2G4iSaOAIMiR6Agf7kd4ggwmmlVLF rFTyJHykv3HzjSjHroI1yZIfoXC+O9eWjUAjzNsqVvbcJ1Xt9zEAUUGyISD825ngOE/0 o6NQ==
MIME-Version: 1.0
X-Received: by with SMTP id dj1mr19005832lac.53.1438002686378; Mon, 27 Jul 2015 06:11:26 -0700 (PDT)
Received: by with HTTP; Mon, 27 Jul 2015 06:11:26 -0700 (PDT)
Date: Mon, 27 Jul 2015 21:11:26 +0800
Message-ID: <>
From: tianxiang li <>
To: "Bernie Volz (volz)" <>,, Dan.Seibel@TELUS.COM
Content-Type: multipart/alternative; boundary="001a113493144ec8b9051bdb1748"
Archived-At: <>
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 13:11:30 -0000

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

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