On 07/13/10 12:49 PM, Dario Tedeschi wrote:
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.
Given that the 6LR has a NCE for the same IPv6 address but a different
EUI-64, I think the 6LR can directly respond to the host with "duplicate".
Thus I don't think the steps below should happen in this case, but in
any case ...
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.
The 6LR should extract the MAC address of the host from the SLLAO in the
NA received from the 6LBR. I assume all sane protocol stacks have the
ability to send an IPv6 packet to a specific MAC address, thus there
should be no need to create any "temporary NCE" to send a NS to that MAC
address.
Erik
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
