There's still the problem of sending an NA back to yourself, if you are
a router and happen to have the same address as the one being
registered. Also, section 8.2 (as indicated in the ticket) does not fix
the problem of sending and NA to a duplicate GP16 address: Here's an
example of the problem:
1. Host[A] sends NS+ARO (with GP16 source address) to a 6LR
2. 6LR sends NS+ARO+address to 6LBR.
3. 6LBR sends NS+ARO+address+success to 6LR. 6LR adds Neighbor Cache
entry.
4. 6LR sends NA+ARO+success to Host[A]. All good so far.
5. Sometime passes
6. Host[B] sends NS+ARO (with source as Host[A]'s GP16 address) to
the same 6LR. This is a duplicate address registration.
7. 6LR sends NS+ARO+address to 6LBR.
8. 6LBR sends NS+ARO+address+failure to 6LR. There is already a
Neighbor Cache entry for this GP16 address (pointing to Host[A]).
9. This is where it goes wrong: How does the 6LR send the ARO failure
to Host[B] when the Cache entry is clearly pointing to Host[A]?
Sure, one could come up with a hack to make this work, but
wouldn't it be cleaner and simpler to always include the address
field in the ARO. That way, an ARO is the same for all NS/NA
messages (single or multi hop), and the unique LL64 can be used in
the source address of an NS.
Dario
6lowpan issue tracker wrote:
#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.
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
