IPv6 Router Alert breaks forwarding

[Andrew McDonald]

On Thu, Apr 05, 2007 at 03:07:43PM +0900, JINMEI Tatuya / ?$B?@L at C#:H wrote:
> At Wed, 4 Apr 2007 22:18:15 +0100,
> Andrew McDonald <andrew at mcdonald.org.uk> wrote:
> 
> > In the absence of a full fix, it would probably be a good idea to
> > remove this unconditional check. This would avoid FreeBSD blocking IPv6
> > packets with router alert set. However, I'm not sure if this would have
> > an impact on MLD.
> 
> It does, so (while I see your point) the fix is not that trivial.
> 
> Just out of curiosity, do you have any specific application that
> relies on the router alert option and suffers from the current
> behavior?  Or are you just talking about stringent compliance with the
> specification?

I'm primarily interested in the current IETF NSIS work, which uses
router alert for path-coupled signalling. Although my systems aren't
using FreeBSD, I'm seeing problems from KAME-derived IPv6 stacks in
routers on the path.

Thinking about it a bit, there is a simple fix that leaves MLD working
(but currently doesn't provide a way for other applications to use
router alert). The IPv6 Router Alert Option (RAO) has a 16-bit value
field. For MLD this is zero. Other uses would contain different values
(as per RFC2711).

rtalert contains the contents of this value field, or (u_int32_t)~0 if
there is no router alert option. So, if we change the check to:
	/*
	 * accept the packet if a router alert option with value 0
	 * is included and we act as an IPv6 router.
	 */
	if (rtalert == 0 && ip6_forwarding)
		ours = 1;
we'll only pick up packets containing ipv6 router alerts with value 0
(i.e. MLD router alerted packets).

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