Subject: RE: sin6_flowinfo and sendto/recvfrom

From: Richard Draves <[email-masked]>
Date: Wed, 21 Jun 2000 16:56:52 -0700

My assumption was that recvfrom() and accept() should return sin6_flowinfo
from the received packet, and connect() and sendto() should take
sin6_flowinfo and put it into sent packets.

For bind(), I'd say either error if sin6_flowinfo is non-zero, or ignore
sin6_flowinfo.

Rich

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]]
> Sent: Wednesday, June 21, 2000 10:47 AM
> To: Jun-ichiro itojun Hagino
> Cc: [email-masked]
> Subject: Re: sin6_flowinfo and sendto/recvfrom
> 
> 
> 
> > >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]
> --------------------------------------------------------------------
> 
--------------------------------------------------------------------
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: Francis Dupont <[email-masked]>
Date: Thu, 22 Jun 2000 11:59:33 +0200

In your previous mail you wrote:

   
=> this is reasonable but we need rules for getsockname() and getpeername()
too (note that accept() and getpeername() often are the same thing then
it will be hard to agree about getsockname()).

Regards

[email-masked]