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

[Alexandru Petrescu <[e-mail]>]

Le 15/03/2012 20:10, Ted Lemon a écrit :
> On Mar 15, 2012, at 8:27 AM, Alexandru Petrescu
> <[e-mail] <mailto:[e-mail]>>
> 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.

I guess in some cases yes, and others no.

Not all plaforms benefit from the typical timer implementation as a
PC-class monolithic kernel offers.

> 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.

Again depends on the implementaiton.  Then all time is relative to
something anyways, be it 1970 earlier or later.

> 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.

SO there would _be_ a conversion needed, right?  This may need to be
specified.  Wouldn't be easier to specify that both lifetimes (from ND
and from DHCP) are represented in the same manner, thus no conversion?

Alex