Re: [mif] #6: Lifetime field length should be 16bit for ND compatibility

[Alexandru Petrescu <[e-mail]>]

MIF WG, Tomek,

What would text towards resolution of this issue look like?

In section 5.2:
> Route lifetime  32-bit unsigned integer.  Specifies lifetime of the
> route information, expressed in seconds (relative to the time the
> packet is sent).  There are 2 special values defined. 0 means that
> route is no longer valid and must be removed by clients.  A value of
>  all one bits (0xffffffff) represents infinity. means infinity.

Suggest new:

> Route lifetime  32-bit unsigned integer.
>
> Specifies lifetime of the route information, expressed in seconds
> (relative to the time the packet is sent). There are 2 special
> values defined. 0 means that route is no longer valid and must be
> removed by clients. A value of all one bits (0xffffffff) represents
> infinity.
>
> If compatibility with the Default Router List data structure of
> Neighbour Discovery is desired, and if this lifetime relates to a
> default route then the value 0 should not appear in this field; and
> the maximum value of this field should be 9000. The conversion
> between the 32-bit unsigned integer (required above) and the 16-bit
> unsigned integer (required by some ND implementations) can be
> realized in programming by cast operations. If the value of this
> Route lifetime field is larger than 9000 then the receiving Host (or
> Router) should use the value 9000 instead. If the value of this Route
> lifetime fielD is 0 then the receiving Host (or Router) should drop
> this packet.

What do you think?

Alex






Le 01/08/2012 14:01, mif issue tracker a écrit :
> #6: Lifetime field length should be 16bit for ND compatibility
>
> Currently draft-ietf-mif-dhcpv6-route-option-04 specifies that the
> lifetime of a route (and implicitely of a default route) is to be
> 32bit length field.
>
> On another hand, the currently implemented default routes are
> implemented according to ND Neighbor Discovery, which uses route_r_
> lifetime on 16bit (RFC 4861 search "Router Lifetime").
>
> I think this is an issue.  It generates additional work to the
> implementer.  If one agrees that it is good to store the DHCP
> default route in the existing ND data structures, then one notices a
>  conversion is needed.  If these lifetime fields were expressed in
> the same number of bits (preferably 16bit, because that exists
> already) then the implementer would be relieved from conversion
> work.
>