Actually, you can extend my comment about socket demux'ing below to include
raw sockets and IPPROT selectors as well....

Randy

-----Original Message-----
From: Randy Turner
To: 'itojun@iijlab.net '; Randy Turner
Cc: ''paul@whooppee.com ' '; ''Darren Reed ' '; ''tech-net@netbsd.org ' '
Sent: 7/22/01 8:10 PM
Subject: RE: Router Alert IPv4 Option 

 
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.

Randy


-----Original Message-----
From: itojun@iijlab.net
To: Randy Turner
Cc: 'paul@whooppee.com '; 'Darren Reed '; 'tech-net@netbsd.org '
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
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

itojun