On Fri, Apr 07, 2000 at 09:54:34AM -0400, Billy Mullins wrote:

 > Both. :)

..getting back to this..

I'm curious what sort of semantics Router Alert should have in the
context of NetBSD's packet forwarding machinery.

If Router Alert is to notify a router that it should pay closer attention
to the packet (and not just toss it through the fast-path).  The RFC doesn't
specify what sort of "closer attention" it really means.

The IPv6 Router Alert processing code in the NetBSD tree does "ours = 1"
if the Router Alert option is present.  Later on, all packets that are
"ours" are passed right up the stack.

Now, in the case of IPPROTO_RSVP packets (the case the RFC mentions), this
is great, as its then passed up to the RSVP input layer.  However, in the
case of e.g. IPPROTO_UDP, you actually want that packet to be *forwarded*,
whereas in the current implementation of Router Alert in netinet6, the
packet would be dropped (or, worse yet, processed as if it were actually
destined for the router, in some circumstances[*]).  Is this what is intended
by Router Alert or is this a bug in our implementation?

[*] It seems to me that you could mount some sort of attack against an
intervening router which uses our current implementation by abusing Router
Alert with a protocol not intended to be used with Router Alert.

 > It seems most of the dates in the networking code haven't changed
 > in several years.  How much of the implementation has changed, 
 > since say around '96?

Oh, lots and lots of code has changed in the NetBSD networking stack
since '96.  Those 1995 and 1996 dates in the SCCS IDs are for historic
reference to the Berkeley code from which it came, and nothing more.

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>