From owner-freebsd-net@FreeBSD.ORG Mon Mar 31 12:25:33 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 870FE106564A; Mon, 31 Mar 2008 12:25:33 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 49B198FC24; Mon, 31 Mar 2008 12:25:33 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id B94F4E46CF; Mon, 31 Mar 2008 08:25:32 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 31 Mar 2008 08:25:32 -0400 X-Sasl-enc: fsSfxK1KalipsDCaTWI4pzoag1sd1K1K6SspjfBe2Baf 1206966332 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 026CF2B42C; Mon, 31 Mar 2008 08:25:31 -0400 (EDT) Message-ID: <47F0D83B.7070506@incunabulum.net> Date: Mon, 31 Mar 2008 13:25:31 +0100 From: Bruce M Simpson User-Agent: Thunderbird 2.0.0.9 (X11/20080207) MIME-Version: 1.0 To: freebsd-net@FreeBSD.org, dhartmei@FreeBSD.org, Max Laier Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pavlin Radoslavov Subject: Unbreaking igmp with pf. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2008 12:25:33 -0000 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.