[e2e] IP options over e2e path
fu at cs.uni-goettingen.de
Wed Mar 29 11:47:54 PST 2006
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
> 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
> 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.
> Lynne Jolitz.
More information about the end2end-interest