#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
