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

Randy

-----Original Message-----
From: itojun@iijlab.net
To: paul@whooppee.com
Cc: Darren Reed; tech-net@netbsd.org
Sent: 7/22/01 5:28 PM
Subject: Re: Router Alert IPv4 Option 

>> hmmm, maybe this is exposing my ignorance about it :)  nearly all the
>> Ipv4 options are manipulated in one way or another vis setsockopt &
>> getsockopt.  What's required?

>Well, setscokopt would be a good way to have programs set the option.

	setsockopt/getsockopt to enable/disable it, correct.

	for example - you are a router.
	a packet to address X comes in with router alert set.
	you need to inspect it as well as forward it.
	- which socket will the packet come up?  raw, tcp, udp,
whatever?
	  (note that in_laddr won't match as the address X is not on
this
	  router)
	- will the packet get forwarded inside the kernel, or will it
just
	  come up to the userland?  i guess the latter, as otherwise you
	  won't have control over forwarding behavior.
	- if you need to forward it, then, how do you really forward the
	  packet?  how can you preserve the form of original packet and
send
	  it out?  ip_stripoptions() should have stripped the ip
options,
	  there are header field reordering like ip_len (darren you know
	  this well:-), 

	we need to think about these gory details, yes.

itojun