ipv6.7: IPV6_ROUTER_ALERT sockopt correction

Hi,

I discovered that the current description of the IPV6_ROUTER_ALERT sockopt in ipv6.7 is significantly wrong. A patch to fix the description is below. I sent a version of this earlier in the year to [email protected], but nothing happened with it at the time.

The correction is based on reading the relevant parts of the kernel source code, and backed up by some test programs. The main bits of code in the kernel (in case someone wants to double-check my update) are net/ipv6/ipv6_sockglue.c:ip6_ra_control() and net/ipv6/ip6_output.c:ip6_call_ra_chain().

The patch is against man-pages-2.66.

regards,

Andrew

@@ -233,10 +233,17 @@
 Argument is a pointer to boolean.
 .TP
 .B IPV6_ROUTER_ALERT
-Pass all forwarded packets containing an router alert option to
+Pass forwarded packets containing a router alert hop-by-hop option to
 this socket.
-Only allowed for datagram sockets and for root.
-Argument is a pointer to boolean.
+Only allowed for SOCK_RAW sockets.
+The tapped packets are not forwarded by the kernel, it is the
+user's responsibility to send them out again.
+Argument is a pointer to an integer.
+A positive integer indicates a router alert option value to intercept.
+Packets carrying a router alert option with a value field containing
+this integer will be delivered to the socket.
+A negative integer disables delivery of packets with router alert options
+to this socket.
 .TP
 .B IPV6_UNICAST_HOPS
 Set the unicast hop limit for the socket.

Took off linux-man from cc:,

Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

I disagree. This is basically the behaviour you want.

It might be an improvement to that sentence to simply say: "The tapped packets are not forwarded by the kernel." The second half of the sentence possibly suggests that you always want to forward the packet after router alert processing.

For why you don't want to packets to be forwarded, consider a simple example that applies to something like RSVP:
- packet hits router, identified as potentially interesting from router alert option
- packet passed to user space, confirmed as really interesting and processed
- create new packet (based on the one that came in and the RSVP processing you've done) and send it out

You don't want the original packet you received to be forwarded, only your new packet.

There is the possible case that you decide that you aren't interested in the packet once it has reached userspace, in which case the user will need to forward it themself. I can imagine ways of improving this (e.g. LSF/BPF filters that run before deciding not to forward the packet to reduce the likelihood of intercepting 'uninteresting' packets), but they would not completely remove this situation.

Andrew McDonald
E-mail: [email protected]
http://www.mcdonald.org.uk/andrew/

Router alert option on a hop-by-hop header means that every router on the path should process the option.

You did not mention the rationale why the it would be reasonable for a packet that would otherwise be forwarded by the Linux router and expected to be processed by every router on the path to be re-created at every step, and every user-space application have to do that.

In the specific case of RSVP packets, AFAIK (e.g., Path and PathTear messages), the content of the RSVP packet is expected to be the same at every hop.

Your argument might make sense in the case where the payload of the packet carrying router-alert option is expected to change at every hop. I believe that's not the intent of any router alert options that I'm aware of.

Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

I think I understand what you mean by "process the option", but it is a little ambiguous.

The abstract of RFC2711 says:
This memo describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP datagram. This option is useful for situations where a datagram addressed to a particular destination contains information that may require special processing by routers along the path.
note the "may require special processing by routers" - there is no expectation that /every/ router will want to do such "special processing".

For example, there is no expectation that every router supports RSVP. Non-RSVP routers are simply expected to look the router alert option, decide they aren't interested in it and forward it normally.

I'm confused by your description.

There is certainly no expectation that every router on the path would be interested in doing "special processing" on the contents of the packet.

The purpose of the IPV6_ROUTER_ALERT sockopt is so that a userspace application can say "I'm here, and I'm interested in packets with a router alert option with value field X." The default case where no application has expressed an interest in this way is to forward the packet normally. Anything else would be horrendously broken (though that does currently apply to some BSD stacks).

The first sentence of the introduction of RFC2711 (IPv6 Router Alert Option) clearly indicates that modification of packets can occur:
New protocols, such as RSVP, use control datagrams which, while addressed to a particular destination, contain information that needs to be examined, and in some case updated, by routers along the path between the source and destination.

To take a couple of examples in RSVP: The RSVP_HOP (PHOP) in a PATH message is expected to change at each RSVP-capable node. Its purpose is to tell the next hop the address of the previous hop, so that the RESV can be sent hop-by-hop back along the path followed by the PATH messages. The ADSPEC is designed to gather up information about available resources along the path, so also has to be mutable along the path in order to fulfil its purpose.

I hope that helps to clarify things.

Andrew McDonald
E-mail: [email protected]
http://www.mcdonald.org.uk/andrew/

Hello Andrew,

Hmmm -- somehow that message got dropped. I found it in my trash -- sorry about that.

I've applied your patch for 2.68.

Thanks,

Michael

Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7

Want to help with man page maintenance?  Grab the latest tarball at
http://www.kernel.org/pub/linux/docs/manpages/
read the HOWTOHELP file and grep the source files for 'FIXME'.