On Mon, Aug 29, 2016 at 02:34:32AM +0800, Eli Cooper wrote:

Hello,


On 2016/8/29 1:18, Guillaume Nault wrote:

quoted

On Sun, Aug 28, 2016 at 11:34:06AM +0800, Eli Cooper wrote:

quoted

According to RFC 1885 2.2(c), the source address of ICMPv6
errors in response to forwarded packets should be set to the
unicast address of the forwarding interface in order to be helpful
in diagnosis.

FWIW, this behaviour has been deprecated ten years ago by RFC 4443:
"The address SHOULD be chosen according to the rules that would be used
 to select the source address for any other packet originated by the
 node, given the destination address of the packet."

The door is left open for other address selection algorithms but, IMHO,
changing kernel's behaviour is better justified by real use cases
than by obsolete RFCs.

I agree, sorry for the obsoleted RFC. This is actually motivated by a
real use case: Say a Linux box is acting as a router that forwards
packets with policy routing from two local networks to two uplinks,
respectively. An outside host from is performing traceroute to a host on
one of the LAN. If the kernel's default route is via the other LAN's
uplink, it will send ICMPv6 packets with the source address that has
nothing to do with the network in question, yet the message probably
will reach the outside host.

Here using the address of inbound or exiting interface as source address
is evidently "a more informative choice." I surmise this is the reason
why the comment reads "Force OUTPUT device used as source address" when
dealing with hop limit exceeded packets in ip6_forward(), although not
effectively so. The current behaviour not only confuses diagnosis, but
also might be undesirable if the addresses of the networks are best kept
secret from each other.

That makes more sense indeed. Would be nice to have this use case in
the commit message rather than the blind reference to the obsolete RFC.

Regards,

Guillaume