IPV6_RTHDR with a type-0 routing header

IPV6_RTHDR with a type-0 routing header

[Steinar H. Gunderson]

Hi,

I've tried attaching a type-0 routing header to my IPv6 packets with
setsockopt(..., IPV6_RTHDR, ...), but the kernel just returns EINVAL.
looking at the source, it seems it simply refuses anything that's not type-2;
should that really be right? I found the following commit:

  http://kerneltrap.org/mailarchive/linux-netdev/2008/11/11/4064594

However, it only seems to change EPERM into EINVAL. I don't see any
reasonable explanation why it should not be simply success; in fact, RFC 3452
only seems to talk about using type-0 headers with this option.

Any ideas?

/* Steinar */
-- 
Homepage: http://www.sesse.net/

Re: IPV6_RTHDR with a type-0 routing header

[Jens Rosenboom]

On Thu, 2009-08-20 at 13:11 +0200, Steinar H. Gunderson wrote:
> Hi,
> 
> I've tried attaching a type-0 routing header to my IPv6 packets with
> setsockopt(..., IPV6_RTHDR, ...), but the kernel just returns EINVAL.
> looking at the source, it seems it simply refuses anything that's not type-2;
> should that really be right? I found the following commit:
> 
>   http://kerneltrap.org/mailarchive/linux-netdev/2008/11/11/4064594
> 
> However, it only seems to change EPERM into EINVAL. I don't see any
> reasonable explanation why it should not be simply success; in fact, RFC 3452
> only seems to talk about using type-0 headers with this option.
> 
> Any ideas?

How about RFC5095?

Re: IPV6_RTHDR with a type-0 routing header

[Rémi Denis-Courmont]

On Thu, 20 Aug 2009 13:11:52 +0200, "Steinar H. Gunderson"
<sgunderson@bigfoot.com> wrote:
> I've tried attaching a type-0 routing header to my IPv6 packets with
> setsockopt(..., IPV6_RTHDR, ...), but the kernel just returns EINVAL.
> looking at the source, it seems it simply refuses anything that's not
> type-2;
> should that really be right? I found the following commit:

RT0 headers have been deprecated by IETF. The kernel refuses to use then on
purpose.

-- 
Rémi Denis-Courmont

Re: IPV6_RTHDR with a type-0 routing header

[Steinar H. Gunderson]

On Thu, Aug 20, 2009 at 01:29:09PM +0200, Rémi Denis-Courmont wrote:
>> I've tried attaching a type-0 routing header to my IPv6 packets with
>> setsockopt(..., IPV6_RTHDR, ...), but the kernel just returns EINVAL.
>> looking at the source, it seems it simply refuses anything that's not
>> type-2;
>> should that really be right? I found the following commit:
> RT0 headers have been deprecated by IETF. The kernel refuses to use then on
> purpose.

Hm, OK. And no replacement has been proposed, the deprecation RFC just refers
to "future routing headers"...

/* Steinar */
-- 
Homepage: http://www.sesse.net/

Re: IPV6_RTHDR with a type-0 routing header

[Steinar H. Gunderson]

On Thu, Aug 20, 2009 at 02:18:20PM +0200, Steinar H. Gunderson wrote:
> Hm, OK. And no replacement has been proposed, the deprecation RFC just refers
> to "future routing headers"...

It looks like I can use destination options instead, but those don't seem to
be too easy to use either. The kernel seems to demand that I put eight bytes
of padding at the end?

  #define ipv6_optlen(p)  (((p)->hdrlen+1) << 3)

Why the +1? 

FWIW, the program I try to run is at http://home.samfundet.no/~sesse/v6fun.c .
If I replace "len" in the setsockopt call by "len + 8", the program runs and
the packets get the right option attached -- but also eight padding bytes.
 
/* Steinar */
-- 
Homepage: http://www.sesse.net/

Re: IPV6_RTHDR with a type-0 routing header

[Jens Rosenboom]

On Thu, 2009-08-20 at 14:39 +0200, Steinar H. Gunderson wrote:
> On Thu, Aug 20, 2009 at 02:18:20PM +0200, Steinar H. Gunderson wrote:
> > Hm, OK. And no replacement has been proposed, the deprecation RFC just refers
> > to "future routing headers"...
> 
> It looks like I can use destination options instead, but those don't seem to
> be too easy to use either. The kernel seems to demand that I put eight bytes
> of padding at the end?
> 
>   #define ipv6_optlen(p)  (((p)->hdrlen+1) << 3)
> 
> Why the +1? 

Because that matches the definition of the hdrlen field in RFC2460.

> FWIW, the program I try to run is at http://home.samfundet.no/~sesse/v6fun.c .
> If I replace "len" in the setsockopt call by "len + 8", the program runs and
> the packets get the right option attached -- but also eight padding bytes.

ERROR 404: Not Found.

Re: IPV6_RTHDR with a type-0 routing header

[Steinar H. Gunderson]

On Thu, Aug 20, 2009 at 02:53:44PM +0200, Jens Rosenboom wrote:
>> It looks like I can use destination options instead, but those don't seem to
>> be too easy to use either. The kernel seems to demand that I put eight bytes
>> of padding at the end?
>> 
>>   #define ipv6_optlen(p)  (((p)->hdrlen+1) << 3)
>> 
>> Why the +1? 
> Because that matches the definition of the hdrlen field in RFC2460.

Hm, in that case I guess it's glibc that has one too much indeed (I never
write this field).

>> FWIW, the program I try to run is at http://home.samfundet.no/~sesse/v6fun.c .
>> If I replace "len" in the setsockopt call by "len + 8", the program runs and
>> the packets get the right option attached -- but also eight padding bytes.
> ERROR 404: Not Found.

Sorry, http://home.samfundet.no/~sesse/v6opt.c

/* Steinar */
-- 
Homepage: http://www.sesse.net/

Re: IPV6_RTHDR with a type-0 routing header

[Steinar H. Gunderson]

On Thu, Aug 20, 2009 at 03:00:09PM +0200, Steinar H. Gunderson wrote:
>> Because that matches the definition of the hdrlen field in RFC2460.
> Hm, in that case I guess it's glibc that has one too much indeed (I never
> write this field).

Yes indeed. It's fixed in more recent glibc:

   [BZ #5760]
   * inet/inet6_opt.c (inet6_opt_init): Fix ip6h_len computation.
   Patch by Roland Bless <roland@bless.de>.

/* Steinar */
-- 
Homepage: http://www.sesse.net/

Re: IPV6_RTHDR with a type-0 routing header

[Shan Wei]

Steinar H. Gunderson wrote, at 08/20/2009 07:11 PM:
> Hi,
> 
> I've tried attaching a type-0 routing header to my IPv6 packets with
> setsockopt(..., IPV6_RTHDR, ...), but the kernel just returns EINVAL.
> looking at the source, it seems it simply refuses anything that's not type-2;
> should that really be right? I found the following commit:
> 
>   http://kerneltrap.org/mailarchive/linux-netdev/2008/11/11/4064594
> 
> However, it only seems to change EPERM into EINVAL. I don't see any

About the cause of changing EPERM into EINVAL, can refer to 
http://marc.info/?l=linux-netdev&m=122046709502496&w=3.

-- 
Best Regards
Shan Wei

> reasonable explanation why it should not be simply success; in fact, RFC 3452
> only seems to talk about using type-0 headers with this option.
> 
> Any ideas?
> 
> /* Steinar */