Default behaviour of IP Options processing

[Julian Elischer]

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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>