[e2e] IP options inserted in transit
David P. Reed
dpreed at reed.com
Thu Aug 7 09:16:21 PDT 2003
I presume to speak for no one but myself, but the "end to end" content of
the IP datagram is the data, its length, and the extended header (source
and destination addresses). The options and other fields are not
guaranteed to be preserved end-to-end, and shouldn't be expected to remain
So your proposed idea is consonant with the "spirit" of the IP layer design.
I do recall a historical argument that encouraged the design where the
source created space in the datagram for intermediate processing, because
it saved copying and so forth in the intermediate gateways, reducing the
performance hit and decreasing the link-level reliability. It may well be
that lots of gateways are unprepared to be able to insert or delete options
in their packet processing, so I'd argue that it is a bad idea to propose
such a thing as a general, good idea.
At 11:17 AM 8/7/2003 -0400, Craig Partridge wrote:
>I've been reading through some of the IP options text in RFCs 791 and 1122
>and I can't seem to find a definitive answer to the following question:
> Can a router (or other intermediate device) add and remove IP options
> from a datagram?
>In particular, if I define a new option -- say a datagram sequencing option
>that might allow me to put datagrams sent over different paths back in
>can a router that's splitting traffic over multiple channels put the option
>in, and then a router near the destination that is receiving from those
>multiple channels, take the option out?
>It appears to be legal, yet all the options text I've seen speaks in terms
>of a host putting the option in the IP datagram (including enough space
>for intermediate systems to place data in the option), so there's a
>E-mail: craig at aland.bbn.com or craig at bbn.com
More information about the end2end-interest