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

"Peder Chr. Norgaard" <[email protected]> wrote on 
06/21/2005 10:47:50 AM:

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

        The sticky options have issues of their own to resolve (probably
not TCLASS so much), but the reason care is needed is because there are
a lot of cases where they interact with other things, some of them
that aren't part of the POSIX standard. For example, PKTINFO allows
you to set the source address for sends (AKA "bind"), and/or the
receiving device (Linux's SO_BINDTODEVICE). Resolving possible
conflicts among the choices in a reasonable way (and testing them)
takes a bit of effort, but should prevent unexpected interactions
down the line. Corking, and TCP support (which is undefined in
RFC 3542) are other areas that add complications.
        Yoshifuji-san has made some suggestions which I've incorporated
in patches I've posted to [email protected] for some of the
2292 vs 3542 issues, but clearly the two API's are not binary
compatible and at some point old source code will need to be fixed.
        I'm continuing to work on this, and also have some API tests
I'll be contributing to LTP (300 so far) and, I hope, the needed
support in glibc and glibc-headers, with the end goal of full
support for RFC 3542. So, more to come from me, and others are
free to contribute, too, of course, but it'll probably be at least
a few months before all of it is there.

                                                        +-DLS