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 protected] [mailto:[email protected]] On > Behalf Of 6lowpan issue tracker > Sent: Sunday, June 06, 2010 10:50 PM > To: [email protected] > Cc: [email protected] > Subject: Re: [6lowpan] #66: Clarification of Section 8.2 > > #66: Clarification of Section 8.2 > --------------------------------+------------------------------------------- > Reporter: z...@… | Owner: z...@… > Type: enhancement | Status: assigned > Priority: minor | Milestone: > Component: nd | Version: > Severity: - | Keywords: > --------------------------------+------------------------------------------- > Changes (by z...@…): > > * owner: => z...@… > * 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/> > > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
