Subject: Re: sin6_flowinfo and sendto/recvfrom

From: Erik Nordmark <[email-masked]>
Date: Wed, 21 Jun 2000 10:47:28 -0700 (PDT)

> >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-masked]
--------------------------------------------------------------------

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Thu, 22 Jun 2000 08:17:30 +0900

>I don't see the need for that restriction.

	just to clarify, the quoted portion was not my thinking, just a summary
	of past discussion.

itojun