Date: Mon, 31 Mar 2008 13:25:31 +0100 From: Bruce M Simpson <bms@incunabulum.net> To: freebsd-net@FreeBSD.org, dhartmei@FreeBSD.org, Max Laier <max@love2party.net> Cc: Pavlin Radoslavov <pavlin@icir.org> Subject: Unbreaking igmp with pf. Message-ID: <47F0D83B.7070506@incunabulum.net>
next in thread | raw e-mail | index | archive | help
Hi all,
Just to follow up on my message last week.
If I don't hear further feedback, I am likely to commit code which
allows IP Router Alert options through the pf firewall by default.
For further background read on.
cheers
BMS
----------------
The lack of support for allowing the IP Router Alert option
(henceforth: RA)
by default in pf is problematic for the widespread deployment of IGMPv3.
It's also bit some people who have been trying to set up multicast capable
routers, even without IGMPv3, as FreeBSD sends RA by default in IGMP and has
done since the 3.x era.
Currently, PF has no capability to parse IP options, and defaults to
dropping
traffic which contains them. In day to day deployment, the most used option
is in fact RA.
The meaning of RA is quite simple: all routers on the path must examine the
datagram. It is described in RFC 2113. Currently FreeBSD's forwarding plane
performs no special processing of RA.
Whilst RA came into existence well into after, RFC 3376 extends the
notion of
IGMP to make the use of RA mandatory. It's reasonable to do this, given that
vendor kit is intended to do it. It also helps IGMP snooping switches spot
the group joins. It is also used with MPLS and RSVP.
"So what?", I hear you cry. Yes, but if outgoing IGMP is being squelched
at the host, it breaks IP multicasting for everything but the most
trivial cases (i.e. service discovery at 1 hop, pfsync, etc).
Furthermore... if you don't send IGMP for link-scope groups (224.0.0.0/24),
it will break them anyway if the switch is configured to prune link-layer
multicast traffic.
Options:
1. Change default in FreeBSD pf import to ip options enabled.
2. Add code to pf to simply allow the RA option by default.
[I'm happiest with this one.]
3. Add code to the options path in pf to decode options, if and only if
options are allowed, and add a mask specifying the allowed values.
For reference, the IANA list of IP option numbers is here:
http://www.iana.org/assignments/ip-parameters
...most of those are never used in practice. RA is. There are 30
possibilities specified for an 8-bit-wide space; the minimal mask fits
in 32 bits; the maximal mask is therefore 256 bits.
There is some overlap between 2 and 3; FreeBSD's kernel only tacks on 4
bytes
to the IP header in outgoing router alert traffic, userland apps may do
different things.
So, if I don't hear more feedback from folk, I am likely to commit code
which
implements option 2.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47F0D83B.7070506>