Subject: [6lowpan] #81: RA Router Lifetime field

From: "6lowpan issue tracker" <[email-masked]>
Date: Tue, 06 Jul 2010 08:20:44 -0000

#81: RA Router Lifetime field
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |       Owner:  zach@…            
     Type:  defect              |      Status:  new               
 Priority:  minor               |   Milestone:                    
Component:  nd                  |     Version:                    
 Severity:  -                   |    Keywords:                    
--------------------------------+-------------------------------------------
 From Daniel Gavelle:

 This ticket is for a clarification on the interpretation of the router
 lifetime field. rfc4861 states the router lifetime in the RA must not be
 zero if the router is to be used as a default router. An issue was brought
 up at Zigbee IP testing:

 If the router lifetime is set it to the maximum value in rfc4861 which is
 9000 seconds.  This only gives 2.5 hours.  Even setting it to 0xffff only
 gives just over 18 hours. Do you think this field should be used in
 6LowPAN-ND or should we allow it to be set to zero / ignored?  Parameters
 like the context and prefix have their own 32 bit lifetime fields but
 there isn't a 32 bit lifetime for the router its self.

 The problem is that if the ARO lifetime is longer than 2.5 hours
 currently, then the default router effectively times out while sleeping.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/81>
6lowpan <http://tools.ietf.org/6lowpan/>

---

From: "6lowpan issue tracker" <[email-masked]>
Date: Thu, 08 Jul 2010 13:25:09 -0000

Comment(by zach@…):

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

---

From: "6lowpan issue tracker" <[email-masked]>
Date: Mon, 12 Jul 2010 19:52:33 -0000

#81: RA Router Lifetime field
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |        Owner:  zach@…            
     Type:  defect              |       Status:  closed            
 Priority:  minor               |    Milestone:                    
Component:  nd                  |      Version:                    
 Severity:  -                   |   Resolution:  fixed             
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by zach@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 - Fixed in nd-11

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/81#comment:2>
6lowpan <http://tools.ietf.org/6lowpan/>