Hello Jun While I agree that the snooping behavior allows operations without changing protocols and that is a real plus, experience from the real world proves you wrong on the robustness of snooping in WLANs. Ap ND has benefits to WiFi too. The future will say if it gets adopted there or not.
My ask is that you indicate exactly the above: - snooping may not be able to track rapid movements and may miss some for a while -We can have a better reliability but that requires a protocol change; for this a pointer on AP ND is useful. - in the meantime snooping is deployed and people should be aware of it Regards, Pascal Le 4 nov. 2018 à 20:34, Jun Bi <[email protected]<mailto:[email protected]>> a écrit : Dear Pascal， Many Thanks for your review comment ! Please see the reply below and the attached draft revision version. Best Regards, Jun Bi Comments from Pascal Thubert I agree with Lorenzo, this scheme is at a high level what we can find in commercial products, and I have first-hand experience on that. As an informational document, this RFC could be a useful reference to consider if we were to change the protocols in a way that would impact those existing and non-standard snooping behaviors. Snooping has proven to be very useful, but as one may guess, it is not reliable; it may miss packets, may fail to create bindings, may point on an incorrect location as well. So I’d say that if we publish as RFC, we should also indicate that with draft-ietf-6lo-ap-nd, we (will) have a more robust solution for devices that are willing to announce themselves. Reply: Thank you for your comment. Regarding reliability issues of snooping in our case like DAD packet loss, please see responses to Lorenzo above. While draft-ietf-6lo-ap-nd proposes a security solution for low-power and lossy network (LLN), we focus on WLAN networks in this draft. WLAN network is much more stable than LLN. And with solutions proposed for handling DAD message loss, the draft gives a mechanisms that is robust enough for source address validation in WLAN networks. Also, the proposed solution doesn’t affect existing protocols nor does it require any modifications to existing protocols. <draft-bi-savi-wlan-16(1).txt>
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
