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

From: "6lowpan issue tracker" <[email-masked]>
Date: Sun, 06 Jun 2010 20:50:29 -0000

#66: Clarification of Section 8.2
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |       Owner:  zach@…            
     Type:  enhancement         |      Status:  assigned          
 Priority:  minor               |   Milestone:                    
Component:  nd                  |     Version:                    
 Severity:  -                   |    Keywords:                    
--------------------------------+-------------------------------------------
Changes (by zach@…):

  * owner:  => zach@…
  * status:  new => assigned

Comment:

 The clarficiations in this ticket have now been added except this one:

 "- 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. "

 It is unclear from the mailing list if we decided to go for this
 "unverified" flag in the Neighbor Cache or to include the SLAA in the
 multihop NS/NA as later suggested on the list?

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 7 Jun 2010 18:32:38 +0200

Hi Zach:

I support pushing the SLLA up to the LBR.

As you remember, a unique ID and a sequence number are useful to differentiate duplicates, multiple registrations, and movement.
The draft I just updated for the backbone piece has some text about that, though your own DAD table probably needs something similar:

The unique ID defined in 
http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router-02#section-4

And the various cases are sorted out in
http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router-02#section-5.4

if and once we get the unique ID and the sequence number, we'll still be missing the capability to assess that a node is still there as described in
http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router-02#section-5.5

best,

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of 6lowpan issue tracker
> Sent: Sunday, June 06, 2010 10:50 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [6lowpan] #66: Clarification of Section 8.2
> 
> Ticket URL:
> <https://svn.tools.ietf.org/wg/6lowpan/trac/ticket/66#comment:2>
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

---

From: "6lowpan issue tracker" <[email-masked]>
Date: Thu, 10 Jun 2010 19:35:36 -0000

Priority:  trivial             |   Milestone:                    

  * priority:  minor => trivial

Comment:

 One further clarification from Erik on Section 8.2:

 - If a set of 6LBRs behave as a single one (using mechanisms out of scope
 of this document) so that the prefixes and contexts and ABRO sequence
 number will be the same from all the 6LBRs, then those 6LBRs can pick a
 single IP address to use in the ABRO option.

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

---

From: "6lowpan issue tracker" <[email-masked]>
Date: Fri, 11 Jun 2010 13:49:33 -0000

#66: Clarification of Section 8.2
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |        Owner:  zach@…            
     Type:  enhancement         |       Status:  closed            
 Priority:  trivial             |    Milestone:                    
Component:  nd                  |      Version:                    
 Severity:  -                   |   Resolution:  fixed             
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by zach@…):

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

Comment:

 Ticket closed in nd-10:

 - SLLA option added to NS/NA used for DAD.[[BR]]
 - Text about coordination of context across multiple 6LBRs added to
 Section 8.2.[[BR]]

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