Date: Fri, 16 Aug 2002 18:43:53 -0700 From: Luigi Rizzo <luigi@FreeBSD.ORG> To: Julian Elischer <julian@elischer.org> Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/netinet ip_fw2.c src/sbin/ipfw ipfw.8 ipfw2.c Message-ID: <20020816184353.A10565@iguana.icir.org> In-Reply-To: <Pine.BSF.4.21.0208161030540.32737-100000@InterJet.elischer.org>; from julian@elischer.org on Fri, Aug 16, 2002 at 10:36:10AM -0700 References: <200208161031.g7GAVmQ7053775@freefall.freebsd.org> <Pine.BSF.4.21.0208161030540.32737-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 16, 2002 at 10:36:10AM -0700, Julian Elischer wrote: > I do object a bit to an mbuf flag being assigned for something that > is protocol specific. > ipfw is an IP specific thing. The only "protocol specific" thing in ipfw is the "ip" prefix in the name, and that one is there only for historical reasons; we would probably be better off calling it "netfw", but it is only an issue of a name. Secondly, i do not understand the objection -- m_flags has been used for a long time for both generic (M_PKTHDR, M_EOR...) and protocol-specific (M_PROTO*) flags; so we have precedents for both uses. Third -- the problem remains: protocol-specific flags can be used to prevent loops in a single layer, but you can have loops spanning two or more layers which can only be prevented using non-protocol-specific packet annotations (and flags are a cheap way to store them). > ipfw in bridging is a hack that should have been done differently. > is should be 'macfw' with an option to firther call ipfw of the protocol > turns out to be ip. Each protcol should have the oportunity to > supply their own firewall. the current method has been apractical forst > step but it needs to be ripped out and re-implemented properly. > We are breaking layers all over the place. The "option to further call ipfw ..." (which you suggest because you know it is useful) is nothing but layer violation. Plus, ipfw has always been breaking layers: it can match on interface names (layer 1), IP header fields (layer 3), TCP/UDP header fields (layer 4), uid/gid (layer 5). Divert is bypassing layer 4. Transparent forwarding (which you introduced!) is routing using layer 1-3-4-5 info. Frankly, i don't see much of a reason to be upset; the addition of MAC header filtering is merely filling the gap :) cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020816184353.A10565>