aboutsummaryrefslogtreecommitdiff
path: root/arch/h8300
diff options
context:
space:
mode:
authorMathieu Desnoyers2020-10-12 10:50:15 -0400
committerJakub Kicinski2020-10-14 17:14:23 -0700
commit272928d1cdacfc3b55f605cb0e9115832ecfb20c (patch)
tree5911b0deb04a33df2a2f67763e77ad74101a6a79 /arch/h8300
parente1e84eb58eb494b77c8389fc6308b5042dcce791 (diff)
ipv6/icmp: l3mdev: Perform icmp error route lookup on source device routing table (v2)
As per RFC4443, the destination address field for ICMPv6 error messages is copied from the source address field of the invoking packet. In configurations with Virtual Routing and Forwarding tables, looking up which routing table to use for sending ICMPv6 error messages is currently done by using the destination net_device. If the source and destination interfaces are within separate VRFs, or one in the global routing table and the other in a VRF, looking up the source address of the invoking packet in the destination interface's routing table will fail if the destination interface's routing table contains no route to the invoking packet's source address. One observable effect of this issue is that traceroute6 does not work in the following cases: - Route leaking between global routing table and VRF - Route leaking between VRFs Use the source device routing table when sending ICMPv6 error messages. [ In the context of ipv4, it has been pointed out that a similar issue may exist with ICMP errors triggered when forwarding between network namespaces. It would be worthwhile to investigate whether ipv6 has similar issues, but is outside of the scope of this investigation. ] [ Testing shows that similar issues exist with ipv6 unreachable / fragmentation needed messages. However, investigation of this additional failure mode is beyond this investigation's scope. ] Link: https://tools.ietf.org/html/rfc4443 Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Reviewed-by: David Ahern <dsahern@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'arch/h8300')
0 files changed, 0 insertions, 0 deletions