Subject: ICMPv3: Message Source Address Determination..

From: [email-masked]
Date: Thu, 13 May 2004 14:43:44 -0500

Hi All,

[Please express your opinion.  It is needed to make
the informed decision.]

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 ?

The decision that I want to make is to whether we should
keep it in the draft or remove it.

Here is the text for quick reference.
====================================================
(c) If the message is a response to a message sent to 
    an address that does not belong to the node, the 
    Source Address should be that unicast address 
    belonging to the node that will be most helpful 
    in diagnosing the error. For example, if the message
    is a response to a packet forwarding action that 
    cannot complete successfully, the Source Address 
    should be a unicast address belonging to the 
    interface on which the packet forwarding failed.
====================================================

and here is the link to the current draft for quick 
reference.
http://ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-v3-03.txt

Comments would be highly appreciated.

Regards
Mukesh

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Markku Savela <[email-masked]>
Date: Mon, 17 May 2004 01:02:50 +0300

> From: [email-masked]

> Here is the text for quick reference.

Currently I have following simple logic

a) src address is the destination address of the packet to which ICMP
 is related.

b) if the address of step (a) is not a valid address on the interface
to which the ICMP is destined, the new valid source address is
selected.

I don't think it is good for *any* RFC to require a stack to send
packets with wrong source address. Thus, if the ICMP draft seems to
require such illegal thing, I think the draft needs revision.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 17 May 2004 16:21:55 +0900

>>>>> On Thu, 13 May 2004 14:54:23 -0500, 
>>>>> [email-masked] said:

> 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-masked]