Jinmei, I agree that we should not try to remove already documented features in recycling work if it is not causing any harm.
But the current RFC says "If the node has more than one unicast address, it must choose the Source Address of the message as follows:". It is not MUST in all caps but if an implementation is not using point (c) to determine the source IP address, can we say that the implementation is not conformant with the RFC ? I don't seem to understand the logic in that point. Let say we have the following network. (...) <-- I1 --> A <-- I2/I3/I4 --> (...) and A receives a packet on I1 that needs to be forwarded to one of I2/I3 or I4. The packet forwarding fails because A does not have a route for the destination. Now A generates the ICMP error. Is the point (c) suggesting to use the src address from I2, I3 or I4 ? Or it is suggesting to use the src from I1 ? From the text, it seems like it suggests to use the src address of the interface where the packet should have been forwarded but as we don't have a route, we don't know where it was to be forwarded. I think, most of the implementations would use the src address of I1 in this case. So my question is that is it ok to leave this point as "required" in the RFC if noone will be able to implement it ? Regards Mukesh > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: Monday, May 17, 2004 12:22 AM > To: Gupta Mukesh (Nokia-NET/MtView) > Cc: [EMAIL PROTECTED] > Subject: Re: ICMPv3: Message Source Address Determination.. > > > >>>>> On Thu, 13 May 2004 14:54:23 -0500, > >>>>> [EMAIL PROTECTED] said: > > > Pekka raised a concern about the usability of one of the > > methods (section 2.2 (c)) to select the source address > > of the ICMPv3 packet. I want to know if anyone has > > implemented it ? or how useful and practical this > > method is in your opinion ? > > I've once tried to implement this case, particularly for the scenario > where a router is sending an ICMPv6 destination unreachable message > when it finds the next hop is unreachable. However, I personally > haven't find this very useful, and, in fact, I've even not known > whether it was really working. After several revises, our current > code does not have this trick. > > Regarding the revise for icmp-v3, I have no particular opinion. > Although I personally see no clear benefits of 2.2. (c), I don't see > clear disadvantage either. And, through my recent experiences on the > rfc2462bis work, people seem to disagree on removing an > already-documented feature in a recycling work unless the feature is > clearly shown to be harmful. > > In the end, I can live with or without removing 2.2 (c). > > 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 --------------------------------------------------------------------
