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

Alexandru Petrescu <alexandru.petrescu@gmail.com> Thu, 23 July 2015 12:38 UTC

Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 647171A1A98 for <dhcwg@ietfa.amsl.com>; Thu, 23 Jul 2015 05:38:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Rsv1XkJiU-Qu for <dhcwg@ietfa.amsl.com>; Thu, 23 Jul 2015 05:38:42 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65A3D1AC3B0 for <dhcwg@ietf.org>; Thu, 23 Jul 2015 05:38:37 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr []) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id t6NCcZSt016814 for <dhcwg@ietf.org>; Thu, 23 Jul 2015 14:38:35 +0200
Received: from pisaure.intra.cea.fr (localhost []) by localhost (Postfix) with SMTP id 61338204920 for <dhcwg@ietf.org>; Thu, 23 Jul 2015 14:42:12 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr []) by pisaure.intra.cea.fr (Postfix) with ESMTP id 37230204B26 for <dhcwg@ietf.org>; Thu, 23 Jul 2015 14:42:12 +0200 (CEST)
Received: from [] ([]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id t6NCcYEA016587 for <dhcwg@ietf.org>; Thu, 23 Jul 2015 14:38:35 +0200
To: "dhcwg@ietf.org" <dhcwg@ietf.org>
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Message-ID: <55B0E04A.3060402@gmail.com>
Date: Thu, 23 Jul 2015 14:38:34 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/6tYV8Y0naCC3UbcgN9HwouYh9dU>
Subject: [dhcwg] two comments on draft-cui-dhc-dhcpv6-prefix-length-hint-issue
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jul 2015 12:38:43 -0000


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.