Subject: [6lowpan] #66: Clarification of Section 8.2 assumptions

From: "6lowpan issue tracker" <[email-masked]>
Date: Sat, 29 May 2010 11:56:11 -0000

#66: Clarification of Section 8.2 assumptions
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |       Owner:     
     Type:  enhancement         |      Status:  new
 Priority:  minor               |   Milestone:     
Component:  nd                  |     Version:     
 Severity:  -                   |    Keywords:     
--------------------------------+-------------------------------------------
 The optional Section 8.2 DAD mechanism requires that the DAD tables of all
 6LBRs advertising the same prefix are checked for duplicates in order to
 work correctly. Currently the text is not clear enough about that, and the
 following text should be added to the end of the first paragraph of
 Section 8.2 and to the Section 1.3 assumptions:

 "This assumes that the 6LRs either register with all the 6LBRs, or that
 the network uses some out-of-scope mechanism to keep the 6LBRs
 synchronized."

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

---

From: "6lowpan issue tracker" <[email-masked]>
Date: Sun, 30 May 2010 20:05:41 -0000

#66: Clarification of Section 8.2

Comment(by zach@…):

 Some further clarifications to the Section 8.2 text have been identified
 by Erik:

 - The synchronous check against the 6LBR only needs to happen on the first
 ARO from a host.

 - The 6LR(s) need to maintain the DAD table in the 6LBRs, for instance by
 tracking how much is left of the lifetime they registered with the 6LBRs,
 and transmit multihop DAD messages appropriately.

 - I see some more care is needed in the specification around multihop DAD.
 In the case of multihop DAD I don't think the 6LR should create a Neighbor
 Cache entry until DAD has been verified. A possible way to handle not
 forgetting the SLLA (to be able to respond as you point out) would be to
 create a NCE but mark it as "unverified". Then an unverified NCE can be be
 used to send the response to the host, and if the response was "ok" then
 the unverified NCE would become a normal NCE, otherwise it would be
 deleted.

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