Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ucla-cs!zen!ucbvax!PARK-STREET.BBN.COM!brescia
From: brescia@PARK-STREET.BBN.COM.UUCP
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Question about IP options
Message-ID: <8709180335.AA00659@ucbvax.Berkeley.EDU>
Date: Thu, 17-Sep-87 23:36:23 EDT
Article-I.D.: ucbvax.8709180335.AA00659
Posted: Thu Sep 17 23:36:23 1987
Date-Received: Sat, 19-Sep-87 15:52:23 EDT
References: <12335457880.12.BILLW@MATHOM.CISCO.COM>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 23

Bill,

When I talked about processing IP options only if the packet was addressed to
the gateway, that was historically accurate for the LSI11 core gateways, which
did not implement record route, timestamping or security options.

Because of the extra overhead of doing a complete scan of the IP options at
every gateway hop, I propose, only slightly tongue-in-cheek, that we extend
the IP header by 8 (16? 32?) bits for a flag word indicating that certain
options are present and should be scanned.  Use bit[i] to indicate the
presence of an option whose value is "i".  Gateways which do not handle
security, for example, can rapidly dispose of (oops, forward :-) those packets
with only the security option bit on.

This is an extension of an earlier idea (source unknown) which used a single
bit in the IP header to declare the presence of options which needed
processing at every gateway.

Note: if you have any flames about the specifics of the proposal, I doubt that
I will answer them.  I did want to get in a bid for faster handling of
packets.  Maybe I am still too concerned with 'efficiency'.

    Mike