#81: RA Router Lifetime field
--------------------------------+-------------------------------------------
Reporter: z...@… | Owner: z...@…
Type: defect | Status: new
Priority: minor | Milestone:
Component: nd | Version:
Severity: - | Keywords:
--------------------------------+-------------------------------------------
Comment(by z...@…):
Proposed fix:
* Allow Router Lifetime values up to 0xFFFF (18 hours)
* Clarify the behaviour on waking up if a default router times out while
sleeping longer than 18 hours.
Some background explanation from Erik:
NUD would merely mark the Neighbor Cache entry for the router as
unreachable, but it would not remove it in general. We could make hosts
remove it on NUD failure, but for routers we have said that Neighbor Cache
entries must not be removed until the registration times out. That would
mean that someone who implements host and router in the same code would be
confused of how to handle a NUD failure.
If a host sleeps for more than 18 hours, then I'd expect when it comes up
it would 1) unicast a RS to the router to refresh the router lifetime and
2) unicast a NS to the router to refresh its registration.
It is safe to do that even if the host has slept a lot longer than 18
hours.
One might argue that it is inefficient and that we should allow ARO in
RS/RA messages avoid the multiple messages above, but such an optimization
might be premature.
Even if we somehow allow lot longer default router lifetimes, those would
still be decoupled from the registration lifetime. Thus a host still needs
to be prepared to both refresh the RA (by sending an RS) and refresh its
registration(s), when it wakes up.
--
Ticket URL: <http://wiki.tools.ietf.org/wg/6lowpan/trac/ticket/81#comment:1>
6lowpan <http://tools.ietf.org/6lowpan/>
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
