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

"Peder Chr. Norgaard" <[email protected]>
Newsgroups gmane.linux.ipv6.usagi.users
Message-ID <[email protected]>
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: [email protected]
(old e-mail 2000-2003: [email protected])
         (old e-mail 1992-2000: [email protected])
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.