(usagi-users 03410) Re: Any particular reason that IPV6_TCLASS/IPV6_RECVTCLASS is not implemented?

["Peder Chr. Norgaard" <Peder.Chr.Norgaard@xxxxxxxxxxxx>]

On Mon, 6 Jun 2005, David Stevens wrote:

>
> [Here's a copy of what I posted to netdev. It has the traffic class
> portion,
> and some of the other fixes needed, but doesn't include any sticky option
> support]

Thank you very much for the patches.  Adding sticky option support for
IPV6_TCLASS (which is what I needed) was exceedingly trivial - just take
the code from datagram_send_ctl in datagram.c and do the similar thing
in ipv6_setsockopt in ipv6_sockglue.c.  It works.

Have you considered how to introduce this in mainstream linux code?
There is a serious transition problem, that several standard program
packages (ipsec-tools and quagga in Debian linux) are compiled to use or
not to use 3542 semantics based on presence on non-presence of the RECV
symbols in the compilation - like

#ifdef IPV6_RECVPKTINFO	/* RFC3542 */

When I started the kernel with your patches, ipsec-tools and quagga broke
immediately.  Of course I can recompile them - I did, and it works,
because both packages have tested out on *BSD kernels - but this
introduces an extremely inconvenient dependency between kernel and
applications *within* the linux environment.

Immediately I would think that introducing a Linux-specific entry
somewhere in /proc/sys/net/ipv6 - something like bindv6only, only called
rfc3542 - would be the best solution.  The simple way is to make it
read-only - if it is present and has value "1", this kernel uses 3542
semantics, otherwise not.  The more complex solution would be to make it
run-time configurable - then you need more coding in the kernel.
Whatever solution, programs like ipsec-tools and quagga could depend on it
on run-time basis to detect kernel 3542 semantics.  Distributions like
Debian could deploy packages capable of detecting this before introducing
the kernel that can actually do it.

Second thought - maybe the /proc/sys/net/ipv6 entry should be called
rfc2292 - that offers a long range opportunity to get rid of the thing -
right now absence or presence and value = 0 means 2292, five years from
now, when everybody uses the entry in linux we could redefine that only
presence and value = 0 means 2292.

best regards
--
Peder Chr. Nørgaard        	Senior System Developer, M. Sc.
Ericsson Denmark A/S, Telebit Division
Skanderborgvej 232         	tel: +45 30 91 84 31
DK-8260 Viby J, Denmark         fax: +45 89 38 51 01
        e-mail: Peder.Chr.Norgaard@xxxxxxxxxxxx
(old e-mail 2000-2003: Peder.C.Norgaard@xxxxxxxxxxxxxxx)
         (old e-mail 1992-2000: pcn@xxxxxxx)