[e2e] IP options inserted in transit

[David P. Reed]

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 
the same.

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:

>Hi folks:
>
>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 
>order --
>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
>disconnect here.
>
>Thanks!
>
>Craig
>
>E-mail: craig at aland.bbn.com or craig at bbn.com