Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00

Alexandru Petrescu <> Tue, 13 September 2011 18:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8B0A711E80B3 for <>; Tue, 13 Sep 2011 11:04:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.112
X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=-0.463, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_42=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hr95mL2+YBhj for <>; Tue, 13 Sep 2011 11:04:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D026E11E808E for <>; Tue, 13 Sep 2011 11:04:07 -0700 (PDT)
Received: from ( []) by (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p8DI6D7d022470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Sep 2011 20:06:13 +0200
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id p8DI6CGJ008879; Tue, 13 Sep 2011 20:06:12 +0200 (envelope-from
Received: from [] ([]) by (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p8DI69qS024966; Tue, 13 Sep 2011 20:06:12 +0200
Message-ID: <>
Date: Tue, 13 Sep 2011 20:06:09 +0200
From: Alexandru Petrescu <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Ted Lemon <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "<>" <>
Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 Sep 2011 18:04:08 -0000

Le 13/09/2011 19:55, Ted Lemon a écrit :
> On Sep 13, 2011, at 1:26 PM, Alexandru Petrescu wrote:
>> Does this explanation add to clarity of my initially short phrase?
> I think so, yes. I think it's fine to have an option in the config
> file that specifies a default route, or routes in general. Putting a
>  lifetime on that, I think, is impractical.

I can see the impracticality aspect reflected in the difference
16bit-vs-32bit ND-DHCP.

But when a Client receives a DHCP Advertise with fields about a default
router then it should copy these fields into local existing data
structures.  These data structures about the default route are what ND
maintains, and that includes a lifetime field.

A Client could ignore that lifetime field of the ND data structure, and
consider that entry permanent forever.

Or it could try to manage the time of life of that default router entry
in a coherent manner DHCP+ND, which implies deciding, among other
things, what to do when lifetime expires.

If the expiration of the DHCP lifetime implies triggering _only_ DHCP
messaging that would be less advantageous.

> If the administrator wants a short lifetime on these routes, they
> should be setting a short lifetime on the addresses offered by the
> DHCP server, so that renewals come often enough to meet this need.

I find it to be a stretch to link the lifetime of addresses to lifetime
of routes in the routing table.

It is possible that a Client does not have any address assigned by DHCP,
but needs a default router assigned by DHCP.  E.g. when using link-local
addresses (self formed) and be part of some global multicast group.