#87: GP16 as source address in initial NS
--------------------------------+-------------------------------------------
Reporter: z...@… | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: nd | Version:
Severity: - | Keywords:
--------------------------------+-------------------------------------------
From ZigBee IP interop:
Still some potential issues using GP16 in source address of
initial NS from joining node to parent router and NA back to
joining node from parent router on initial multihop-DAD. If parent
router has the same GP16 as the one randomly chosen by the joining
node in its routing tables (i.e a valid node already exists more
than one hop away), it has to make sure this new colliding GP16 is
properly addressed in preference to attempting to send it through
the routing mechanism. The parent router itself could also have the
same duplicate address as the chosen GP16. This would mean you are
trying to send back to itself.
Furthermore, multihoming device could be an issue
– may send on another interface if it’s done through routing.
RFC2462 also states that tentative address (i.e. not been through
DAD) is not assigned to the interface, so strictly it can’t be
used. To comply with 4861, choices are are LL64 or unspecified.
The authors have discussed this issue more, and think it can be solved
with better clarification in the draft:
Using GP16 as the src IPv6 address is not an issue - as specified in
section 8.2:
"For the synchronous multihop DAD the 6LR MUST NOT add a Neighbor
Cache entry for the address until it receives a successful ARO option
from the 6LBRs."
Thus the router would not be confused by the duplicate address until it is
known that the address is not a duplicate. Perhaps we also need to make it
clear that the router must not create any routing state for the address
until it has received the success?
Section 8.2 also tries to make it clear how the router responds by saying
"Note that the 6LR does not create a Neighbor Cache entry until it
receives a successful ARO back from a 6LBR. Instead it uses the SLLA
option of the NA from the 6LBR to reach the host."
6lowpan-nd avoids 4861 constraints by the rules specified in section 8.2
and elsewhere. Basically, an NS with a SLLAO does not modify an existing
NCE, nor does it create a NCE, until it is known that the address is not a
duplicate. The multicast DAD in 4861 works differently.
--
Ticket URL: <http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/87>
6lowpan <http://tools.ietf.org/6lowpan/>
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
