IPv6 Router Alert breaks forwarding

[Andrew McDonald]

Hi,

Currently the NetBSD IPv6 stack, when acting as a router and forwarding
traffic, treats any packet with a Router Alert hop-by-hop option as
'ours' and sends it to the local stack. This stops the packet from
being forwarded any further, and also results in ICMPv6 Destination
Unreachable message being sent back.

This isn't the behaviour specified by RFC2711, where the intention is
that "routers should examine this datagram more closely" with the
router's interest and actions being specified by particular protocol
RFCs. i.e. if the router isn't interested it should ignore the packet
and forward it as normal.

The responsible bit of code is in src/sys/netinet6/ip6_input.c:
/*
* accept the packet if a router alert option is included
* and we act as an IPv6 router.
*/
if (rtalert != ~0 && ip6_forwarding)
ours = 1;

A patch that went into FreeBSD to fix this can be found here:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet6/ip6_input.c.diff?r1=1.90;r2=1.91
Or in the KAME tree here:
http://www.kame.net/dev/cvsweb2.cgi/kame/kame/sys/netinet6/ip6_input.c.diff?r1=1.369;r2=1.370

This patch only treats packets as 'ours' if they are for MLD (Multicast
Listener Discovery).

A fuller solution would require interactions with userspace to
determine if there is something interested in processing the packet.
Linux uses a sockopt to indicate that a raw socket should receive
packets with the router alert option.

In the absence of a full fix, it would be good to see the freebsd/kame
patch incorporated to avoid NetBSD blocking IPv6 packets with router
alert set.

For reference, the IPv4 stack ignores Router Alert options, though it
does do special processing for IPPROTO_RSVP if there is a RSVP daemon
running.

[Greg Troxel]

Currently the NetBSD IPv6 stack, when acting as a router and forwarding
traffic, treats any packet with a Router Alert hop-by-hop option as
'ours' and sends it to the local stack. This stops the packet from
being forwarded any further, and also results in ICMPv6 Destination
Unreachable message being sent back.

That's definitely broken.

My understanding, which may be a bit off, is that router alert is
essentially a method to enable routers to skip a whole bunch of checks
that may be costly when the option is *not* present.

Do you know if MLD packets would be handled properly if there were no
router alert special treatment?

I would be inclined to commit a version of the FreeBSD patch (the one I
looked at since you listed it first). Are you set up to prepare and
test such a patch on NetBSD-current?


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Andrew McDonald]

Post by Andrew McDonald
Currently the NetBSD IPv6 stack, when acting as a router and forwarding
traffic, treats any packet with a Router Alert hop-by-hop option as
'ours' and sends it to the local stack. This stops the packet from
being forwarded any further, and also results in ICMPv6 Destination
Unreachable message being sent back.
That's definitely broken.
My understanding, which may be a bit off, is that router alert is
essentially a method to enable routers to skip a whole bunch of checks
that may be costly when the option is *not* present.

Yes. It's designed to be a quick way, implementable in the fast path,
for routers to decide whether or not the packet is potentially
'interesting' to them.

Post by Andrew McDonald
Do you know if MLD packets would be handled properly if there were no
router alert special treatment?

My understanding is that the router alert handling is needed for MLD to
work properly.

Post by Andrew McDonald
I would be inclined to commit a version of the FreeBSD patch (the one I
looked at since you listed it first). Are you set up to prepare and
test such a patch on NetBSD-current?

The FreeBSD and KAME patches are identical (it was written by JINMEI
Tatuya after some discussion on the FreeBSD list earlier in the year).

Unfortunately I haven't got the ability to test on NetBSD at the
moment. My end systems are running Linux - I'm seeing the problems from
other people's BSD boxes on the path.

However, I do have some test code which will generate packets with
router alert options, and so get the problem to manifest itself. I'm
using it on Linux, but I believe it should also run on NetBSD (it uses
the IPv6 advanced sockets API). Let me know if you would like a copy.

thanks for your help,

Andrew

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de