On 05/28/10 04:29 PM, Reddy, Joseph wrote:
Hi Erik,
Is there a reason why the unspecified address is not used for
the source ( and include the address in the ARO option ) like in
classic ND ?
RFC 4861 only allows the unspecified source address in NS message
for the purposes of DAD, which is integral to using multicast
packets for DAD.
Is there a reason to use the unspecified address in some new way?
[JSR] The reason would be the handling of neighbor cache on the
parent router. In the current draft, it is possible that an
inaccurate neigbor cache entry is temporarily created on a Router and
that could lead to potential problems.
Consider a scenario where Host1 registers its address with Router1
and succesfully undergoes multihop DaD
Now suppose Host2 attempts to register the same IP address with
Router2. While the multihop DaD is ongoing, Router2 will have a
neighbor cache entry with the duplicate IP address ( that actually
belongs to Host1 ) and the LL address of Host2 ( note that is
necessary for the Router2 to create a neighbor cache entry at this
stage, otherwise the SLLA of Host2 would not be available later to
send the NA ).
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.
This means that in the case of two hosts attached to the same 6LR try to
use the same IP address at the same time, then the 6LR might end up with
two unverified NCEs for the same IP address; at most one of those will
"win" as determined by the 6LBR(s). Thus when a response comes from the
6LBR the 6LR will use the IPv6 address plus the EUI-64 to find any
"unverified" NCE.
In any case, I don't see how using the unspecified source address would
make this any easier. The fundamental issue is that an 6LR needs to
retain sufficient information about a host while multihop DAD is in
progress, and not let that "in progress" information be confused with
authoritative and verified registrations.
Erik
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan