Le 15/03/2012 20:10, Ted Lemon a écrit :
On Mar 15, 2012, at 8:27 AM, Alexandru Petrescu
<alexandru.petre...@gmail.com <mailto:alexandru.petre...@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.
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
_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif
