>>>>> On Tue, 6 Jul 2004 12:08:49 +0900 (JST), >>>>> [EMAIL PROTECTED] (Jun-ichiro itojun Hagino) said:
> i have objection to 5.4.5 "when duplicated address detection fails". > the text suggest that hardware-address-based linklocal address fails > on DAD test, "the interface SHOULD be disabled". > first of all, what does it mean by "disable interface"? Good question, but I guess we need to discuss more fundamental one (below) first, so I'll make a separate response for this. > moreover, even when DAD test fails for hardware-address-based linklocal > address, there are number of routes we can take: > - try again with random-number-generated linklocal address > - beep beep, call operator > - etc I'd first like to revisit the discussion that led to the current text of rfc2462bis. If anyone who wants to join this particular thread is not familiar with the past discussion, please first go through it. Christian Huitema started the previous discussion, which targeted the original text of RFC2462 section 5.4.5: - http://www1.ietf.org/mail-archive/web/ipv6/current/msg00926.html After some discussion, Thomas Narten clarified the original motivation of the specification: - http://www1.ietf.org/mail-archive/web/ipv6/current/msg00949.html I then proposed the current text of rfc2462bis based on the clarification: - http://www1.ietf.org/mail-archive/web/ipv6/current/msg01514.html Several people agreed on the change, including those who seemed to have opposed to the idea of "disabling" the interface. Hence the current text is now in the wg last call. The main point Thomas made is that DAD failure for an EUI-64 based address is likely to indicate MAC address collision, in which case disabling the entire interface is better rather than trying hopeless recovery which may even make it harder to diagnose the real problem. (I believe the current text of rfc2462bis clearly made the point, BTW) In that sense, "try again with random-number-generated linklocal address" doesn't make sense. We could "call operator with a beep", but we'd not be able to do that via network if the MAC address collides. So, IMO, it is not very convincing to argue we could rely on such an outbound mechanism in a discussion about a network protocol specification. Meanwhile, we could also make a more fundamental question on whether the analysis that Thomas provided (i.e., DAD failure for EUI-64 based address probably means MAC collision) is valid. If not, this can be another reason to reconsider the current text. I personally think his analysis is quite reasonable though. In any event, I understand this is a trade-off issue. One can validly support Thomas's analysis and argue that it's even better or safer to disable the entire interface. At the same time, others can validly say it's overkilling. So it's not surprising that we cannot get 100% agreement on either side. So far, it seems to me a majority of people agreed on the current text with the rationale, and, while I'd respect your concern, the points you provided do not seem to me strong enough to reverse the decision. Of course, I'm still open to others's opinions and/or further source to reconsider the decision. > suggested change: replace "the interface SHOULD be disabled" by the > following: Thanks for the suggestion, but I guess it's too early to discuss specific change at the moment. If we decide to change the past decision, I'll come back to the proposal. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
