Robert, On Oct 8, 2010, at 2:35 PM, Robert Cragie wrote:
> Just to reiterate on ND: The creation of an NCE to hold the unconfirmed IP/LL > address of the joining node does not make sense for the reasons Colin has > clearly outlined. It also contradicts generally the usage of options to carry > information where statelessness is required, e.g. RS/RA. Therefore, as I have > said many times before, it makes more sense to carry this (these) addresses > in the options. Please go back and check http://tools.ietf.org/html/draft-ietf-6lowpan-nd-10. Notice that in this version there was no tentative NCE made while multihop-DAD was being performed. Instead all the needed information was carried in an ARO + SLLAO combination, and the NCE was made only after a successful response came back from the 6LBR. Then the WG asked us to change that, and instead make a tentative NCE (which appeared in -11). My person view is that if the WG does not see a need for the tentative NCE, and just finds it confusing, then I would have no problem removing that and instead carrying the L2 address with the ARO similar to what was done in -10. Notice that this doesn't enable the 6LR to detect a duplicate while an address is being checked by the 6LBR, but it will be detected by the 6LBR instead. A rare case anyways, so I don't see it as an issue. Note that this issue is orthogonal to the NS/NA+ARO exchange between the 6LN and 6LR. Zach -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
