|
Hi, I was wondering...wouldn't the flow label be a "better" field for storing this random number? If i remember correctly, early drafts of RPL were using it for loop detection (ok, in a very different way), although in the later ones a new option was chosen. Sure, RFC 3697 is very strict on its specification, sure SEND already uses the Nonce option, but since we are talking about ND only (=before any real src/dst flow) i would be interested to know the rationale behind of this decision; choosing an extra option instead of a mandatory -useless until recently- field. Maybe then, all ND messages could be supported (less impact on memory?). I may have missed some talks about this in the past (or maybe i'm talking nonsense ), so please forgive me if this is the case. Also, i have some comments... I know we are talking about DAD, but maybe it should be re-written as....When the IPv6 network interface issues a NS(DAD) message, the interface includes the Nonce Option in the NS(DAD) message and saves the nonce in local store. Subsequently if the interface receives an identical NS(DAD) message, the interface logs a system management message, updates any statistics counter, and drops the looped back NS(DAD). If the DupAddrDetectTransmits variable for the interface is greater than one, subsequent NS(DAD) messages for the same Target Address should be suppressed. If the interface receives a NS(DAD) message with a different nonce, the interface logs a DAD-failed system management message, updates any statistics, and behaves identical to the behavior specified in [RFC4862] for DAD failure. If the interface receives a NS(DAD) message with a different nonce but the same Target address, the interface logs a DAD-failed system management message, updates any statistics, and behaves identical to the behavior specified in [RFC4862] for DAD failure. The same applies here...Six bytes of random nonce is sufficiently large for nonce collisions. However if there is a collision because two nodes generated the same random nonce, then the algorithm will incorrectly detect a looped back NS(DAD) when the NS(DAD) was issued to signal a genuine duplicate. Since each looped back NS(DAD) event is logged to system management, the administrator of the network will have to intervene manually. However, if there is a collision because two nodes (that are using the same Target address in their NS(DAD)) generated the same random nonce, then the algorithm will incorrectly detect a looped back NS(DAD), while the NS(DAD) was issued to signal a genuine duplicate.
Also, some recommended changes about the above paragraph.If the node has been configured to use the algorithm of this document and an interface on the node receives any NS(DAD) message that matches the interface address (in tentative or optimistic state), the receiver MUST compare the nonce in the message with the saved nonce. If a match is found, the node SHOULD log a system management message, SHOULD update any statistics counter, and MUST drop the received message. If the received NS(DAD) message includes a nonce and no match is found with the saved nonce, the node SHOULD log a system management message for DAD- failed and SHOULD update any statistics counter. Lastly, i have a question about your example with the provider in "2. Introduction". Although i don't have the whole picture (the DAD proxying part confused me a little bit) and the term access concentrator isn't very clear to me (we use dsl, not cable), shouldn't there be a warning about duplicate mac or mac-flapping somewhere? I mean, if i understand correctly the topology, the NS(DAD) message followed the path AC => MODEM1 => HUB => MODEM2 => AC without changing its src mac. Unless the modems are also acting as ND proxies. Am i thinking something wrong? Regards, Tassos Hemant Singh (shemant) wrote on 14/10/2011 18:45: Folks, Please review this document. Thanks, Hemant -----Original Message----- From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] Sent: Friday, October 14, 2011 11:26 AM To: Hemant Singh (shemant) Cc: Hemant Singh (shemant) Subject: New Version Notification for draft-hsingh-6man-enhanced-dad-01.txt A new version of I-D, draft-hsingh-6man-enhanced-dad-01.txt has been successfully submitted by Hemant Singh and posted to the IETF repository. Filename: draft-hsingh-6man-enhanced-dad Revision: 01 Title: Enhanced Duplicate Address Detection Creation date: 2011-10-14 WG ID: Individual Submission Number of pages: 7 Abstract: Appendix A of [RFC4862] discusses Loopback Suppression and Duplicate Address Detection (DAD). However, [RFC4862] does not settle on one specific automated means to detect Loopback of Neighbor Discovery (ND) [RFC4861] messages used by DAD. Several service provider communities have expressed a need for automated detection of looped backed ND messages used by DAD. This document outlines an algorithm to automate detection of looped back IPv6 ND messages used by DAD. Further, for certain access networks the document automates resolving a specific duplicate address conflict. The IETF Secretariat -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- |
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
