Date: Thu, 6 May 2004 16:06:19 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: "David W. Chapman Jr." <dwcjr@inethouston.net> Cc: Andre Oppermann <andre@freebsd.org> Subject: Re: Default behaviour of IP Options processing Message-ID: <Pine.BSF.4.21.0405061557410.82978-100000@InterJet.elischer.org> In-Reply-To: <04f001c433bd$cdc100f0$fd01a8c0@dwcjr>
next in thread | previous in thread | raw e-mail | index | archive | help
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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0405061557410.82978-100000>