[patch] ipv6.7: IPV6_ROUTER_ALERT sockopt correction

[patch] ipv6.7: IPV6_ROUTER_ALERT sockopt correction

[Andrew McDonald]

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
mtk-manpages@gmx.net, 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


--- man7/ipv6.7.orig	2007-10-14 11:59:46.000000000 +0100
+++ man7/ipv6.7	2007-10-14 12:05:15.000000000 +0100
@@ -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.

Re: [patch] ipv6.7: IPV6_ROUTER_ALERT sockopt correction

[Pekka Savola]

Took off linux-man from cc:,

On Sun, 14 Oct 2007, Andrew McDonald wrote:
> +The tapped packets are not forwarded by the kernel, it is the
> +user's responsibility to send them out again.

This is probably incompliant (and from users' perspective, 
unacceptible) behaviour that IMHO should be fixed.

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

Re: [patch] ipv6.7: IPV6_ROUTER_ALERT sockopt correction

[Andrew McDonald]

On Mon, Oct 15, 2007 at 08:51:16AM +0300, Pekka Savola wrote:
> Took off linux-man from cc:,
> 
> On Sun, 14 Oct 2007, Andrew McDonald wrote:
> >+The tapped packets are not forwarded by the kernel, it is the
> >+user's responsibility to send them out again.
> 
> This is probably incompliant (and from users' perspective, 
> unacceptible) behaviour that IMHO should be fixed.

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: andrew@mcdonald.org.uk
http://www.mcdonald.org.uk/andrew/

Re: [patch] ipv6.7: IPV6_ROUTER_ALERT sockopt correction

[Pekka Savola]

On Tue, 16 Oct 2007, Andrew McDonald wrote:
> 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.

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

Re: [patch] ipv6.7: IPV6_ROUTER_ALERT sockopt correction

[Andrew McDonald]

On Wed, Oct 17, 2007 at 09:19:15AM +0300, Pekka Savola wrote:
> Router alert option on a hop-by-hop header means that every router on 
> the path should process the option.

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.

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

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

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

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: andrew@mcdonald.org.uk
http://www.mcdonald.org.uk/andrew/

Re: [patch] ipv6.7: IPV6_ROUTER_ALERT sockopt correction

[Michael Kerrisk]

Hello Andrew,

> 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
> mtk-manpages@gmx.net, but nothing happened with it at the time.

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

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

> --- man7/ipv6.7.orig	2007-10-14 11:59:46.000000000 +0100
> +++ man7/ipv6.7	2007-10-14 12:05:15.000000000 +0100
> @@ -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.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-man" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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