From owner-freebsd-net@FreeBSD.ORG Thu Jun 11 13:50:02 2015 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5356FC03 for ; Thu, 11 Jun 2015 13:50:02 +0000 (UTC) (envelope-from kp@vega.codepro.be) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1361B108C for ; Thu, 11 Jun 2015 13:50:01 +0000 (UTC) (envelope-from kp@vega.codepro.be) Received: from vega.codepro.be (unknown [172.16.1.3]) by venus.codepro.be (Postfix) with ESMTP id F085519354; Thu, 11 Jun 2015 15:49:58 +0200 (CEST) Received: by vega.codepro.be (Postfix, from userid 1001) id 31F1BF552; Thu, 11 Jun 2015 15:49:57 +0200 (CEST) Date: Thu, 11 Jun 2015 15:49:57 +0200 From: Kristof Provost To: Fernando Gont Cc: FreeBSD Net Subject: Re: PF support for IPv6 Extension Headers Message-ID: <20150611134957.GC2301@vega.codepro.be> References: <5578CECE.2050703@gont.com.ar> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5578CECE.2050703@gont.com.ar> X-Checked-By-NSA: Probably User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 13:50:02 -0000 (From a very quick look at the code) On 2015-06-10 20:57:02 (-0300), Fernando Gont wrote: > What's the level f support of PF wrt IPv6 Extension Headers? > It's pretty limited. There's code for a few specific header types (fragment, routing, AH, hopopts and dstopts) but nothing generic. That means that none of the things you described (filtering per EH type, EH size or number of EHs) are supported. > pf.conf(5) talks about an implicit block rule for packets employing the > routing header, ... > That appears to be only for the type 0 routing header. Packets with RH0 are always dropped, but other routing headers are left unmolested. See https://www.ietf.org/rfc/rfc5095.txt . Regards, Kristof