Tatuya, I have a minor process question. If yesterday we were told, we have 12 hours left to close on 2462bis, I believe those 12 hours have expired. So why are you suggesting another revised proposal? Can we take it now that you have another x number of hours left to make any changes to 2462bis? I am just trying to understand as a newbie how does IETF I-D editing timeline works when I-D's are in AUTH48 state. Seems like the 12 hour timeline is flexible for a showstopper editorial change?
Thanks. Hemant -----Original Message----- From: JINMEI Tatuya / ???? [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 10, 2007 4:39 AM To: James Carlson Cc: Vlad Yasevich; [email protected]; Suresh Krishnan Subject: Re: Revisit: one remaining corner case in DAD At Mon, 9 Jul 2007 16:04:39 -0400, James Carlson <[EMAIL PROTECTED]> wrote: > I disagree a bit with this resolution. These sorts of undetected > duplicate addresses do happen in practice, due to network partition/ > repair and the effect of things like Spanning Tree's default port > blocking. > > As a result, what I've done in the Solaris implementation is to > 'defend' the address once -- by sending out my own advertisement in > reply to the received one -- but setting a flag. If I see another > duplicate advertisement within some period of time (~10), then shut > the address down. I'm not sure if we are talking about the same thing, so please let me check. Are you saying "if a Solaris node happens to receive an NA targeting an address assigned on the receiving interface, the node will 'respond' to the NA with another NA (probably sent to ff02::1) targeting the same address"? In any case, I'd not disagree with trying to handle an address duplicate that has not been detected in the initial DAD as a general topic. But I'd say it's basically beyond the scope of 2462bis. In fact, 2462(bis) simply admits DAD is not completely reliable (in section 5.4) and doesn't specify any behavior to improve the reliability. Note also that this particular case (receiving an NA targeting one of the receiver's own addresses) is a very minor case among such undetected duplicates since an unsolicited NA is sent only in very limited cases; if we were to do that within this spec, we'd have to cover more likely scenarios such as receiving an RA with the source address equal to a link-local address of the receiving interface. (But I don't think we wanted to address such cases in the 2462bis revision) What we've actually been discussing in this thread is how to fix a clear error in the 2462bis (and RFC2462/1971) text: it talked about "how to handle a *solicitation*" in the "Receiving Neighbor Advertisement" section. It was an unfortunate side effect that we hit the minor, yet pretty substantial, issue of undetected duplicates while trying to resolve the seemingly editorial error. So, in this particular context, I'd like to focus on solving the obvious error within the scope of 2462bis; I don't want to go into the possibly controversial discussion of how to deal with undetected duplicates in this context. Another revised proposal based on this view is as follows. How about that? On receipt of a valid Neighbor Advertisement message on an interface, node behavior depends on whether the target address is tentative or matches a unicast or anycast address assigned to the interface: 1. If the target address is tentative, the tentative address is not unique. 2. If the target address matches a unicast address assigned to the receiving interface, it would possibly indicate that the address is a duplicate but it has not been detected by the Duplicate Address Detection procedure (recall that Duplicate Address Detection is not completely reliable). How to handle such a case is beyond the scope of this document, but care should be taken so that the advertisement will not affect the normal Neighbor Discovery [RFC4861] processing. 3. Otherwise, the advertisement is processed as described in [RFC4861]. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] p.s. one additional comment that is irrelevant to the original issue of this topic: > - The DoS issue is a red herring. NDP doesn't have security, and > attackers can forge up bad advertisements any time they want. > It's not a matter of "shutting down" the address -- confusing the > peers on the network is sufficient to disrupt normal operation, > and there's just no way to stop that. On one hand, I agree; (pure) NDP is inherently vulnerable to on-local attacks, so it may not really be reasonable to take account of local attacks in the protocol design too much. On the other hand, I'd point out the same argument could apply to the "two-hour" rule adopted in RFC2462 and kept in 2462bis. The consensus at that time (IIRC) was that even though we knew it's an on-link only attack the forced shut-down of an available global addresses was serious enough to mitigate within the protocol specification. And since an unsolicited NA is a very rare event, I'd suspect it's more likely an attack than an actual duplicate that happens to have been undetected. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
