From owner-freebsd-ipfw Thu Aug 15 12: 0:23 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA1F537B401 for ; Thu, 15 Aug 2002 12:00:19 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAD8943E3B for ; Thu, 15 Aug 2002 12:00:18 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020815190018.UEHR1746.rwcrmhc51.attbi.com@InterJet.elischer.org>; Thu, 15 Aug 2002 19:00:18 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA27732; Thu, 15 Aug 2002 11:49:43 -0700 (PDT) Date: Thu, 15 Aug 2002 11:49:41 -0700 (PDT) From: Julian Elischer To: Luigi Rizzo Cc: ipfw@FreeBSD.ORG Subject: Re: RFC: new mbuf flag bit needed In-Reply-To: <20020815113824.B30190@iguana.icir.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 15 Aug 2002, Luigi Rizzo wrote: > On Thu, Aug 15, 2002 at 10:49:22AM -0700, Julian Elischer wrote: > ... > > A bit to force non testing in a firewall might be useful in other places.. > > I'd however like to float an idea that maybe there should be more > > specific bits for input and output processing. > > unfortunately bits are a scarce resource in struct m_hdr which we > do not want to change in RELENG_4. Plus, many of the cases you are > mentioning are already taken care of with m_tag/annotations because > you need additional information: e.g. in the "fwd" you need the > fwd address anyways, same for divert (you need the 'next rule'), > and dummynet when you want multiple passes. > > The problem with protocol-specific bits is that you'll end up > overloading them, and once you pass the packets to a multi-protocol > module (such as netgraph, or ipfw2) you are in trouble. > E.g. M_PROTO1 has been overloaded by device drivers to report > some vlan-related info. The other M_PROTO* are all taken by > the KAME code. > > cheers > luigi > protocols should not expect to store flags there on packets that cross a protocol boundary. it would be for passing state around within a single protocol family.. such as you suggest. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message