IETF Logo Mail Archive

Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 published

Ted Lemon <Ted.Lemon@nominum.com> Thu, 15 March 2012 19:10 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 B03F621E8059 for <mif@ietfa.amsl.com>; Thu, 15 Mar 2012 12:10:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.963
X-Spam-Level:
X-Spam-Status: No, score=-103.963 tagged_above=-999 required=5 tests=[AWL=-2.365, BAYES_00=-2.599, GB_SUMOF=5, 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 63-vrbO-GNPB for <mif@ietfa.amsl.com>; Thu, 15 Mar 2012 12:10:11 -0700 (PDT)
Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 9019121E8064 for <mif@ietf.org>; Thu, 15 Mar 2012 12:10:10 -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 DSNKT2I+kuK5lRDyoy5zkC8NnnjCxcqTfnFJ@postini.com; Thu, 15 Mar 2012 12:10:10 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 605321B8321 for <mif@ietf.org>; Thu, 15 Mar 2012 12:10:09 -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 55EE719005C; Thu, 15 Mar 2012 12:10:09 -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.02.0247.003; Thu, 15 Mar 2012 12:10:09 -0700
From: Ted Lemon <Ted.Lemon@nominum.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Thread-Topic: [mif] draft-ietf-mif-dhcpv6-route-option-04 published
Thread-Index: AQHM8uBsQi4512i5cE6t8t5dPnex2ZZnd0OAgAACEYCABGRggIAAcFuA
Date: Thu, 15 Mar 2012 19:10:08 +0000
Message-ID: <DF5F4B7B-7486-4878-A096-084BDA1CB7C4@nominum.com>
References: <20120224101611.22703.52041.idtracker@ietfa.amsl.com> <4F47688B.10508@gmail.com> <4F5E2F61.9040009@gmail.com> <611FBED3-349A-43E7-B4B9-0BC313EA4F7A@nominum.com> <4F61E04F.4020800@gmail.com>
In-Reply-To: <4F61E04F.4020800@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.1.10]
Content-Type: multipart/alternative; boundary="_000_DF5F4B7B74864878A096084BDA1CB7C4nominumcom_"
MIME-Version: 1.0
Cc: "<mif@ietf.org>" <mif@ietf.org>
Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 published
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: Thu, 15 Mar 2012 19:10:11 -0000

On Mar 15, 2012, at 8:27 AM, Alexandru Petrescu <alexandru.petrescu@gmail.com<mailto:alexandru.petrescu@gmail.com>> wrote:
It may be an issue if DHCP Server sends a 32bit lifetime of a default
route and the Client stores this in its ND default router list
structures lifetime 16bit, no?

I think this is a non-problem.   The RA lifetime may be represented as a 16-bit offset in transit, but when it is stored in a table on the node, the node has to know when the lifetime ends, not how long it is.   So the implementation must necessarily convert the 16-bit offset to something like a time_t, which is either 32 or 64 bits, and represents an absolute time, not a relative time.

Consequently, there will be no problem with receiving a 32-bit offset from the DHCP server, other than that if the sum of the current absolute time and offset overflows, the implementation needs to truncate the result to the maximum time value.   This same behavior is necessary for 16-bit offsets; it's just that the range of dates during which it might occur is smaller.

v2.23.0 | Report a Bug | By Email