On 07/19/10 12:50 PM, Dario Tedeschi wrote:
Sorry, steps 7 & 8 in my previous example may have been misleading.
Here's a more accurate example to try explain why using GP16 in the
source address of an NS is problematic:
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 detects a duplicate address, because the EUI in the Neighbor
Cache Entry (NCE) for the address is different to the EUI in the
ARO. The NCE is pointing to Host[A].
8. How does the 6LR send the NA+ARO+duplicate to Host[B] when the NCE
is clearly pointing to Host[A]?
It has been suggested that the NA must be sent directly to the SLLA, and
that most IPv6 layers allow for explicitly directing a packet to a given
MAC address (even when an NCE for a packet's destination address is
pointing elsewhere). However, a couple of well-known stacks I've had a
look at don't seem to support this without a bit of hacking or tricks in
the network-interface driver.
I don't see any other path forward than getting those IPv6 stacks
improved to allow for sending to a link-layer address.
Do you have a working alternative approach?
Erik
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
