Le 27/03/2012 17:54, William Herrin a écrit :
On Tue, Mar 27, 2012 at 8:01 AM, Alexandru Petrescu
<alexandru.petre...@gmail.com>  wrote:
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.

I wanted to ask the oppinion of the WG about this issue.


I'm new to the questions surrounding DHCPv6, so my apologies if this
has already been discussed.

It's common practice to issue IPv4 DHCP lifetimes in excess of 24
hours (86400 seconds). I have to think that supporting common
configurations outweighs preserving ND data structures.

However... why would DHCP issue a router lifetime which is different
from the overall lifetime anyway? What's the use case for different
components of the DHCP message having different lifetimes?

Bill,

The ND use of Router Lifetime is sometimes to distinguish among multiple
default routers.  I.e., if the Host has two default routes each with a
different lifetime, it may prefer the one with longer lifetime.

Also, the Router Lifetime has distinctive treatment of the value '0'.
Depending on it the Router is considered good as default or not.

This semantics is there already, but I wonder how it applies to the
lifetime 32bit communicated by DHCP.

One may wonder how that default route is inserted in the existing
data structures and what happens when the lifetime expires - should it
issue an RS or a DHCP Request?

Alex


Thanks, Bill



_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif

Reply via email to