Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ucla-cs!zen!ucbvax!DBNET.CS.WASHINGTON.EDU!randy
From: randy@DBNET.CS.WASHINGTON.EDU (Randy Day)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: IP options implementation
Message-ID: <8707021834.AA03576@dbnet.cs.washington.edu>
Date: Sat, 4-Jul-87 10:57:07 EDT
Article-I.D.: dbnet.8707021834.AA03576
Posted: Sat Jul  4 10:57:07 1987
Date-Received: Sat, 4-Jul-87 20:00:49 EDT
References: <8707021807.AA00878@ward.cs.washington.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 28

Been looking at this code in the last few days myself.

I've been looking at the 4.2BSD and 4.3BSD implementations of ip_output()
in /sys/netinet/ip_output.c.

As far as I can tell (and I feel fairly confident about this), the
4.2BSD code just ignores any options passed to the ip_output routine.

The 4.3 code replaces the initial call to m_free(opt) with
if (opt)
	m = ip_insertoptions(m, opt, &hlen);
Where ip_insertopitons() is a new function that does about what you
would expect: it inserts mbufs containing the options in the
data about to blasted out over the net.

The 4.3BSD "Changes to the Kernel in 4.3BSD" manual section says:
"Support was added for IP source routing and other IP options....IP properly
updates source-route and record-route options when forwarding (and leaves
them in the packet, unlike 4.2 which stripped them out after updating)."

The 4.2BSD networking code is brain damaged, and would certainly not
pass even the most modest validation suite if one existed for TCP/IP
implementations.

Randy Day.
Internet (ARPA): randy@dbnet.cs.washington.edu
CSNET: randy%washington@relay.cs.net
UUCP: {decvax|ihnp4}!uw-beaver!uw-june!randy