IETF Logo Mail Archive

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

Ted Lemon <Ted.Lemon@nominum.com> Tue, 13 September 2011 12:59 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8656321F8B4A for <mif@ietfa.amsl.com>; Tue, 13 Sep 2011 05:59:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.593
X-Spam-Level:
X-Spam-Status: No, score=-106.593 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWRXwBaMw1PH for <mif@ietfa.amsl.com>; Tue, 13 Sep 2011 05:59:44 -0700 (PDT)
Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id C2CA721F8B42 for <mif@ietf.org>; Tue, 13 Sep 2011 05:59:43 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTm9UNv6qLJe5dsAbZJLwWb/wedwgcVal@postini.com; Tue, 13 Sep 2011 06:01:50 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 234E7F8020 for <mif@ietf.org>; Tue, 13 Sep 2011 06:01:42 -0700 (PDT)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 6289B190061; Tue, 13 Sep 2011 06:01:40 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.01.0289.001; Tue, 13 Sep 2011 06:01:40 -0700
From: Ted Lemon <Ted.Lemon@nominum.com>
To: maximilien mouton <maximilien.mouton@gmail.com>
Thread-Topic: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00
Thread-Index: AcxxClosDL9zuhm1Q+CTqXShqzwWxAAw84cAAAfxtgAABv0IAAARg+mA
Date: Tue, 13 Sep 2011 13:01:39 +0000
Message-ID: <CFDF82EE-052B-4A61-AE1B-152337822B6E@nominum.com>
References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com>
In-Reply-To: <4E6EDEA8.3080108@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [173.162.214.218]
Content-Type: multipart/alternative; boundary="_000_CFDF82EE052B4A61AE1B152337822B6Enominumcom_"
MIME-Version: 1.0
Cc: "<mif@ietf.org>" <mif@ietf.org>
Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Sep 2011 12:59:44 -0000

On Sep 13, 2011, at 12:40 AM, maximilien mouton wrote:
In this case an Information-Request when client's lifetime expires (or
is close to) is sufficient especially if lifetime's upper limit is
higher.

One thing to be crystal clear about is that even if an option is added that contains a lifetime, it would be a major extension of the DHCP protocol to propose that the client include that lifetime in its calculations for when to renew.   Adding an option is a minor extension.   I would oppose a major extension for this purpose; I don't know how the working group as a whole would feel about it, but I suspect there would be a great deal of skepticism.

The way lifetimes of configuration information are handled is either with the IRT, in the case of stateless DHCPv6, or with the lease renewal timer, in the case of stateful.   So if you put a lifetime in a route option, I don't see what good it would do.

v2.23.0 | Report a Bug | By Email