On Mon, Aug 29, 2016 at 02:34:32AM +0800, Eli Cooper wrote: > Hello, > > > On 2016/8/29 1:18, Guillaume Nault wrote: > > On Sun, Aug 28, 2016 at 11:34:06AM +0800, Eli Cooper wrote: > >> 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
