On Tue, 16 Oct 2007, Andrew McDonald wrote:
For why you don't want to packets to be forwarded, consider a simple
example that applies to something like RSVP:
- packet hits router, identified as potentially interesting from router
alert option
- packet passed to user space, confirmed as really interesting and
processed
- create new packet (based on the one that came in and the RSVP
processing you've done) and send it out
You don't want the original packet you received to be forwarded, only
your new packet.
Router alert option on a hop-by-hop header means that every router on
the path should process the option.
You did not mention the rationale why the it would be reasonable for a
packet that would otherwise be forwarded by the Linux router and
expected to be processed by every router on the path to be re-created
at every step, and every user-space application have to do that.
In the specific case of RSVP packets, AFAIK (e.g., Path and PathTear
messages), the content of the RSVP packet is expected to be the
same at every hop.
Your argument might make sense in the case where the payload of the
packet carrying router-alert option is expected to change at every
hop. I believe that's not the intent of any router alert options that
I'm aware of.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
