Subject: RE: ICMPv3: Message Source Address Determination..

From: [email-masked]
Date: Mon, 17 May 2004 14:34:47 -0500

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-masked] 
> [mailto:[email-masked]]
> Sent: Monday, May 17, 2004 12:22 AM
> To: Gupta Mukesh (Nokia-NET/MtView)
> Cc: [email-masked]
> Subject: Re: ICMPv3: Message Source Address Determination..
> 
> 
> >>>>> On Thu, 13 May 2004 14:54:23 -0500, 
> >>>>> [email-masked] 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-masked]
> 

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

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 18 May 2004 12:24:48 +0900

>>>>> On Mon, 17 May 2004 14:34:47 -0500, 

> documented features in recycling work if it is

Before making detailed discussions, I'd repeat my position to avoid
confusion.  I can live with either action (remove or leave 2.2 (c)).
If I have the right to choose one, I'd remove that part (because that
part is not very useful and removing it will make the specification
simpler), but if someone wants to leave it, I won't fight against the
opinion.

> is not conformant with the RFC ?

I don't think so.  IMO, the requirement described in 2.2 (c) is not so
clear to detect conformance or non-conformance about a particular
implementation, especially from a look outside the implementation.
In fact, the RFC (or icmp-v3-03) says:

    (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.

This part uses "should", not "must", while the other rules (a, b and
d) say "must".

Second, the criteria to choose the address is "will be most helpful",
which is quite subjective.

And finally, the latter sentence is just an example, not a part of the
rule definition.

So, my understanding is that this part leaves great flexibility for
implementations on the interpretation of what "will be most helpful"
or how to realize that.  In that sense, any implementation can be
conformant with this requirement, IMO.

> address of I1 in this case.

That's probably true.  Just FYI: our latest implementation simply
applies the default address selection rules defined in RFC3483 to the
destination address of the ICMPv6 error packet (the source address of
the original packet).  Assuming the outgoing interface of the error
packet is I1 and I1 has an address with an appropriate scope for the
destination, it's very likely that an address on I1 is chosen.

But in any event, I don't think the above scenario is the intended one
described in the example of 2.2 (c).  The intended scenario, in my
understanding, is as follows:

(....) <--- I1 --->   A  <--I2--->  B
                    I3/I4

A receives a packet on I1 that needs to be forwarded to the next hop B
via I2.  A then detects that B is unreachable (after sending several
neighbor solicitations) and generates an ICMPv6 error.  According to
2.2(c), A will choose an address on I2 as the source address of the
error message in order to highlight that the error occurs in the
network attached to I2.

> "required" in the RFC if noone will be able to implement 

Answering the question in a literal sense, I'd say yes.

Again, (IMO), the "requirement" will not make "non-compliant"
implementations even for the implementation that does nothing about
2.2 (c) internally, as I said above.

Meanwhile, you may want to recall the discussion about "deprecating"
the M/O flags for rfc2462bis.  In that discussion, even with the fact
that almost no implementations behave on the flags as described in
RFC2462, many people were against deprecating the flags, saying "even
if we've not seen such an implementation, it doesn't mean there is
none", "do not break anything which is currently working well just
because it does not seem to be very useful", etc.  I myself won't
apply that logic in this case, though.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]