On 06/22/10 03:59 AM, Zach Shelby wrote:
On Jun 21, 2010, at 11:44 AM, Daniel Gavelle wrote:
In section 8.2.6 of 6LowPAN-ND-10, it is the responsibility of the
6LR to retry if forwarding a special NS message to the 6LBR does
not result in a corresponding NA.
I think it would be more efficient if the host were responsible for
the retry. The host will need to retry the special NS message
anyway, to cover the case where the message is lost between the
host and the 6LR or the forwarded NA is lost in the other
direction.
If the 6LR didn't need to retry on behalf of the host, it wouldn't
need a table of pending nodes. It could implement NS/NA forwarding
in a stateless manner, much like a REST HTTP implementation. This
would not require any other change to the specification because the
state information (the SLLAO of the host) is already carried in
the messages.
> WFM. What do others think?
There is still a need to track pending AFAICT, because the 6LRs need to
know which multihop DAD replies it should trust, and as a result add the
SLLA to the neighbor cache.
But I agree that driving things from the host's retransmissions makes
more sense than what is in 8.2.6.
Also, the last sentence in 8.2.6 to say "OK" after retransmissions fail
seem quite dangerous if multihop DAD is used to claim and defend short
addresses. It is better to have the host keep on retrying forever.
Erik
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
