> >The conclusion: sin6_flowinfo mbz in recvfrom(), and may contain
> >only class bits in sendto(). It is much more convenient to make with
> >setsockopt() or ancillary data.
My take it also that accept() should behave the same as recvfrom,
since a native application might take the address returned by accept() and
use it in a subsequent connect() or sendto().
But why do you think that you can only use the traffic class component
in sendto()? (and connect() I assume)
I don't see the need for that restriction.
> It seems to me that Eric is more in sync with the current documents,
> since there's no standard setsockopt nor ancillary data to manipulate
> traffic class/flow label fields.
>
> i'd love to see it clarificed in near future 2553bis/2292bis.
This has recently come up as a potential porting issue: applications
which use the IP_TOS setsockopt with IPv4 to set the diffserv bits
can't easily be ported to IPv6.
Should we add an IPV6_TCLASS socket option?
Presumably if we do it can be used both with setsockopt
and as ancillary data.
How about a separate IPV6_FLOWID socket option to be complete?
Since recv*() can't set sin6_flowinfo do we need a way for an application
to retrieve the tclass and flowid?
That would imply additional IPV6_RECV* options to enable the receipt of
ancillary data.
Erik
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
