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.

-- 
Andrew McDonald
E-mail: andrew@mcdonald.org.uk
http://www.mcdonald.org.uk/andrew/