[e2e] IP options over e2e path

[Xiaoming Fu]

Hi Lynne,

Lynne Jolitz wrote:
> Since the RFC is very clear, the question becomes "why do they drop
> packets in contravention to the RFC instead of simply passing them through"?
Due to historic reasons, I guess in practice some initial MUSTs are 
interpreted as SHOULD and vice versa; or updated/clarified by later 
RFCs. TCP's evolution probably also tells this 
(http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-roadmap-06.txt)

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

> Is it a deep technical reason, one of security, where, for example,
such an ability allows one to pass out-of-band information which elides
content filtering on firewalls?

There can be different implications for having an "unknown" option in 
different traffic, out-of-band (such as RSVP(TE) messages) or in-band 
(e.g., piggybacking options into data or connection setup packets by the 
tool TBIT which that paper uses). NATs and firewalls, for example, could 
perform different actions to different traffic.

> 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)?

I also doudt whether there is something like a test specification for 
IPv4 router products? (I just know a little bit about v6 case: yes).

> In any case, the Red Queen's Race problem is magnified by this
> failure  to comply with the RFC in the routers if new options are introduced.

Xiaoming
> Lynne Jolitz.