>>>>> On Mon, 17 May 2004 14:34:47 -0500,
>>>>> [EMAIL PROTECTED] said:
> I agree that we should not try to remove already
> documented features in recycling work if it is
> not causing any harm.
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.
> 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 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.
> 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.
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.
> 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 ?
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 PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
