> more questions (I could not find answer from my archive):
> (4) what happens if we connect(2) with sin6_flowinfo filled?
> my guess is that sin6_flowinfo sticks into pcb, and
> will be attached to every packet we will send.
My assumption is the same as your guess.
> (5) what happens if we bind(2) with sin6_flowinfo filled?
> my guess is (a) to raise some error, or (b) accept packets
> only if they carry specified ip6->ip6_flow field.
Or c) silently ignore the sin6_flowinfo field.
Doing b) adds code to the critical lookup code, and I don't see any need
for that. So either a) or c) are fine with me.
> (6) what is the endian of sin6_flowinfo?
> I guess it is network byte order, since it appears on the wire.
Doesn't the basic API say that everything is in network byte order?
There used to be some macros to take apart the flowinfo into a tclass
and a flowlabel but I can't find those in 2553 for 2292bis.
Those macros were different based on byte order which indicates that the
interpretation was network byte order for sin6_flowinfo.
Clarifying this in RFC2553 would be good.
> (7) what happens if the peer transmits packets with ip6->ip6_flow set,
> and it is connection oriented socket (SOCK_STREAM)?
Are you concerned about different packets arriving with different tclass or
flowlabel for a single connection?
I don't think the receiving TCP should care.
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]
--------------------------------------------------------------------
