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