This once again quickly reduces to a question of real-life need in
my mind. What proportion of useful traffic actually carries IP
options these days? Who uses them other than fooling around with
the occasional source-routing or RR exercise, if their local
infrastructure even permits it to be sent? Many sites just
firewall off all that stuff because in real life they never
use it or need it. For them it's more trouble than it would
be worth trying to process correctly, especially in a security
context, so that's their accepted real-life practice.
Clearly, those who design the routing iron are well aware of
such practice because they optimized the hardware to process
the far more typical no-options day to day traffic. While
they still accomodate options it's evidently done as kind of
an add-on bandaid way outside of the normal path.
Now you have to ask yourself where the people making the iron
cheaped out -- should they have designed in the ability to handle
all these corner cases at their normal wire speed, or should they
have dismissed such foolishness and concentrated on what they
knew the industry actually requires? How much additional cost
does anyone think ASICs to deal with options and other seldom-
seen conditions at the same transit rates would incur? I think
the most common answer would be "f'geddaboudit".
The TTL=1 is an interesting one, but really, under normal
conditions shouldn't happen that often. People tracerouting
certainly shouldn't expect 100% reliability on getting the "expired"
ICMP back, and automatically throttling the rate of errors from
routing loops might have certain benefits so why try to handle
*every* expired TTL that comes along?
It seems like taking anything out of the fast-path should only
be done if the slow path is good and ready to accept it, and if
someone's trying to hammer the box with stupid stuff then most
of it should simply be dropped. Handling it should be near the
bottom of the main processor's priority list ... and rather
than allow the fast iron to pile way too much crap in its inbox to
be dealt with, process-switching should have a VERY short queue
and be able to tell the lower levels "not now" and simply increment
some obscure counter for "stupid packets dropped" without letting
that impinge on the more important tasks at hand. Having the whole
box fall over is the *least* acceptable result.