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

In practice, Router Alerts are used to receive packets that need to be
processed by some process on the box, but which have a destination address
that would normally cause the box to forward or drop the packets (i.e. the
packets aren't addressed to the box).  Only Router Alert packets which
some process has expressed an interest in receiving should be received
this way, all others should be processed (and forwarded or discarded)
normally.

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

This is the right behaviour, but it is wrong to do this unconditionally.  You
only want to receive Router Alert packets that some process on the box has
expressed an interest in seeing (i.e. that have a particular protocol, or
protocol/port number, value).  All other Router Alert packets need to be
forwarded normally.

> 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?

Note that what you are describing (I don't know about the code) is wrong
even for RSVP.  You only want to capture RSVP Router Alert packets when
RSVP is actually running on the box; otherwise you want to forward them
normally.

What we do is open a socket that receives the packets we are interested in
(e.g. a raw socket receiving RSVP or IGMP packets), and then set a socket
option which indicates that we are also interested in receiving matching
Router Alert packets as well.  When the socket closes, the Router Alert
packets go back to being forwarded normally.  To be fully general you
might wish to register a protocol/port number if the protocol is UDP,
but since the only users of the Router Alert option so far in real life
are RSVP and IGMP it is currently sufficient to just track IP protocols
where it is desired to receive router alert packets, forwarding the rest
normally.

By the way, you probably don't need to use this generic mechanism for
IGMP packets currently since multicast forwarding is currently handled
by a wretched, bag-on-the-side hack that just knows what to do with
these packets anyway.  If you ever rationalized multicast forwarding
so that it isn't special-cased, however, you'd need to recognize TTL=1
IGMP packets, as well as those bearing Router Alerts, as packets that
need to be received locally as well since the Router Alert was a relatively
late addition to IGMP.

Dennis Ferguson