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

Marcin Siodelski <> Mon, 27 July 2015 14:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9ED4A1A8893 for <>; Mon, 27 Jul 2015 07:21:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sio0mqmuZsWQ for <>; Mon, 27 Jul 2015 07:21:10 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AB7881B2E60 for <>; Mon, 27 Jul 2015 07:20:17 -0700 (PDT)
Received: by lahh5 with SMTP id h5so49940175lah.2 for <>; Mon, 27 Jul 2015 07:20:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ea/eCfs9/ifKHEpKVmRdXcEVoJ9JLzJmV62kXEXiy0w=; b=jjVrpSyNcG9Ifiu0vioUWxGfO1fl15+URDMsMOfJIa6PDdRkQ3JnzD4lG9OsjhjPgi AkWYHH0oGKwEEC9fqE0Mhxaml6fxBkm2z5NRjEw35LwTEBKY9V2dycXubSsHcZk4uxVs JEej2Apdi3W1nP3zLlzs5duzY1o8YyvXqoB2ZyxhIeDgQhexudEqeFZitQa9HflD+Zhg kPyWBeZPsKjVMNSr1dF0Web4fXCOAwnRZM8ch9DyD5u0V4fG9ZZGNildgMSOfyJ4XfHZ VCqgb7Fs8nQ8+oQQoPc9d89qv+I2YliW3VgmlAtQVoRxIo5ME6uK5j4n9DoBJicV0F30 a9iQ==
X-Received: by with SMTP id db5mr27824814lac.55.1438006816191; Mon, 27 Jul 2015 07:20:16 -0700 (PDT)
Received: from MacBook-Pro-Marcin.local ( []) by with ESMTPSA id rp10sm3977691lbb.8.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Jul 2015 07:20:15 -0700 (PDT)
Message-ID: <>
Date: Mon, 27 Jul 2015 16:20:58 +0200
From: Marcin Siodelski <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Alexandru Petrescu <>, "" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
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 14:21:11 -0000


On 23.07.2015 14:38, 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.

Where is this stated in the draft that the prefix will be used on the
interface on which the Solicit has been issued?

Per this section of RFC3633:

"   Upon the receipt of a valid Reply message, for each IA_PD the
   requesting router assigns a subnet from each of the delegated
   prefixes to each of the links to which the associated interfaces are
   attached, with the following exception: the requesting router MUST
   NOT assign any delegated prefixes or subnets from the delegated
   prefix(es) to the link through which it received the DHCP message
   from the delegating router."

the requesting router must not use the prefix on the server facing

> 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