From owner-freebsd-net@FreeBSD.ORG Thu May 6 16:06:22 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D25516A4CE; Thu, 6 May 2004 16:06:22 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBCAD43D53; Thu, 6 May 2004 16:06:21 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (rwcrmhc12) with ESMTP id <2004050623062001400k35d8e>; Thu, 6 May 2004 23:06:21 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA86227; Thu, 6 May 2004 16:06:20 -0700 (PDT) Date: Thu, 6 May 2004 16:06:19 -0700 (PDT) From: Julian Elischer To: "David W. Chapman Jr." In-Reply-To: <04f001c433bd$cdc100f0$fd01a8c0@dwcjr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: Andre Oppermann Subject: Re: Default behaviour of IP Options processing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2004 23:06:22 -0000 On Thu, 6 May 2004, David W. Chapman Jr. wrote: > > You mean ip options not tcp, right? I do not understant why we > > invent a new mechanism if we already have one. Put an example in > > /etc/rc.firewall. > > Yes, I stand corrected, ip option it is :) > > > You mean "more obscure", right? Where net.inet.ip.process_options > > documented? How does it operate with f.e. IPSTEALTH? > > I definitely agree it should be documented, but that's just a minor detail > which can be easily taken care of. I know these are "options" but what does the standards say about not supporting them.. ? (I have seen non optional options before :-) also I dislike the all-or-nothing mechanism I would rather see: net.inet.ip.options.RR: 1 net.inet.ip.options.TS: 0 net.inet.ip.options.SECURITY 0 net.inet.ip.options.LSRR: 0 net.inet.ip.options.SATID: 0 net.inet.ip.options.SSRR: 0 net.inet.ip.options.RA: 0 where options we DON'T support exist and are stuck at 0. or maybe even: net.inet.ip.options.RecordRoute: 1 net.inet.ip.options.TimeStamp: 0 etc. if they are usually turned off then the test would only be done if that option exists and it would still be faster that actually doing the option. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >