Subject: RE: Router Alert IPv4 Option
To: 'email@example.com ' <firstname.lastname@example.org>
From: Randy Turner <email@example.com>
Date: 07/22/2001 20:10:21
I was operating from a traditional layering perspective, being as the point
at which IP options are examined is logically a long way from where a
"socket" is known about. It's where you're deciding to do "fast-path"
routing (if a fast-path exists in the implementation). When you demultiplex
incoming data into a socket (probably using a TCP/UDP port selector), you've
long ago "processed" the router alert option.
I understand the value of having certain routing daemons in userland, it's
just I'm not sure why they would care about setting a socket option for the
router alert option.
To: Randy Turner
Cc: 'firstname.lastname@example.org '; 'Darren Reed '; 'email@example.com '
Sent: 7/22/01 5:48 PM
Subject: Re: Router Alert IPv4 Option
>I wouldn't think setsockopt() would be the right "level" to implement
>router alert option. For the dominant cases (rsvp, igmpv2) you may need
assuming data will come up from the socket (for userland process
inspect it), set/getsockopt looks right. and i guess you are
objecting to use socket for data manipulation (as you seem to
some kernel module to handle these).
>access to kernel resources or do other things with the packet that
>control that you don't have in userland. This option seems like it
>dedicated kernel modules, and that the router alert option processing
>enable/disable flag would be global (and settable via something like
>under solaris, et.al.). If you push this up to userland, you may have
>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
will you implement PIM as kernel module? :-p