[e2e] IP options over e2e path

[Mikael.Latvala@nokia.com]

Hello, 

First of all, thank you for the comments.
http://www.icir.org/tbit/TCPevolution-Mar2005.pdf was indeed very
interesting. Few comments about the paper.

1. It would be interesting to know whether routers along the packet path
or the receiving server dropped the packets with different IP options. 

2. I disagree with "One concern is that the use of IP options may
significantly increase the overhead in routers, because
in some cases packets with IP options are processed on the slow path of
the forwarding engine." because as RFC1812 says that routers can ignore
the IP option, excluding source route, if so configured. This type of
logic is very easy to implement on the fast path.

3. I also disagree with "A third concern is that of possible denial of
service attacks that may be caused by packets with invalid IP options
going to network routers." as any well-desinged software should not be
vulnerable to such attacks.

4. Finally, I cannot follow to logic in "These concerns, together with
the fact that the generation and processing of IP options is
nonmandatory at both the routers and the end hosts, have led routers,
hosts, and middleboxes to simply drop packets with unknown IP options,
or even to drop packets with standard and properly formed options."

The fact that processing of IP options is nonmandatory does not justify
the behavior where a router drops packets with IP options. Especially
when this is very clearly spelled out in RFC1812 and has not been
updated in any later RFC.

>> Is it a business reason - one of anticompetitive tactics (I 
>heard this  
>> from a businessman)?
>(As also told by some operator folks), if I am a network 
>provider, why I should allow incoming traffic from another 
>provider to potentially change some behaviors or collect some 
>information of the routers in its own network?  Certainly, for 
>traffic traversing within my own network provider I probably 
>don't care much whether an option is encountered and processed.
>

It looks like the authors of RFC1812 though about this by making the
processing of Recourd Route Option optional. So this sounds more like a
FUD factor than a valid reason.

>
>> Or is it simply that product development groups, given a set of
>product reqs, tested only against a certain set of IP packets 
>for compliance, and dropped things that didn't matter (and 
>yes, it does happen)?
>

It's somewhat sad to see this type of behavior in the Internet is
silently approved. No wonder its hard to specify the Internet
architecture, not to mention to fix some major flaws in it or introduce
new features.

/Mikael