Subject: Re: Router Alert IPv4 Option
To: Randy Turner <email@example.com>
From: None <firstname.lastname@example.org>
Date: 07/23/2001 09:48:08
>I wouldn't think setsockopt() would be the right "level" to implement the
>router alert option. For the dominant cases (rsvp, igmpv2) you may need to
assuming data will come up from the socket (for userland process to
inspect it), set/getsockopt looks right. and i guess you are
objecting to use socket for data manipulation (as you seem to prefer
some kernel module to handle these).
>access to kernel resources or do other things with the packet that implies
>control that you don't have in userland. This option seems like it requires
>dedicated kernel modules, and that the router alert option processing
>enable/disable flag would be global (and settable via something like "ndd"
>under solaris, et.al.). If you push this up to userland, you may have to
>create a whole other set of APIs that allow control over otherwise
>non-exposed kernel resources or entry points.
many of multicast routing daemons (like PIM) needs to inspect it.
will you implement PIM as kernel module? :-p