Subject: RE: Router Alert IPv4 Option
To: 'firstname.lastname@example.org ' <email@example.com>
From: Randy Turner <firstname.lastname@example.org>
Date: 07/22/2001 17:42:53
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.
Cc: Darren Reed; email@example.com
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,
(note that in_laddr won't match as the address X is not on
- will the packet get forwarded inside the kernel, or will it
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
it out? ip_stripoptions() should have stripped the ip
there are header field reordering like ip_len (darren you know
we need to think about these gory details, yes.