[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: ICMPv3: Message Source Address Determination..


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 ?


> -----Original Message-----
> From: jinmei@isl.rdc.toshiba.co.jp 
> [mailto:jinmei@isl.rdc.toshiba.co.jp]
> Sent: Monday, May 17, 2004 12:22 AM
> To: Gupta Mukesh (Nokia-NET/MtView)
> Cc: ipv6@ietf.org
> Subject: Re: ICMPv3: Message Source Address Determination..
> >>>>> On Thu, 13 May 2004 14:54:23 -0500, 
> >>>>> Mukesh.Gupta@nokia.com 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.
> 					jinmei@isl.rdc.toshiba.co.jp

IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6