In your previous mail you wrote:
> 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.
=> my concern about sin6_flowinfo is the fact there are two flowinfos
per PCB, one for incoming packets (this one cannot be set) and one
for outgoing packets...
> (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.
=> I use it for a d) (:-): if the flowID is set then outgoing packets will
get a non-zero flowID, for instance new connections to a TCP service will
have a (new/random *) ip6->ip6_flow in outgoing packets.
(*) each connection has its own flow ID, ie. the sin6_flowinfo field is used
as a flag.
> (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.
=> I agree with Itojun, the rationate is that things which appear on the wire
are in the wire byte order, others are in the host byte order.
Regards
[EMAIL PROTECTED]
PS: I think we should find concrete usage of flow ID before conclude this
discussion. For instance I don't know if we need to be able to set flowIDs
or if per default flow IDs should be zero or not. Of course to leave the
whole stuff nearly unspecified as it is today is not the best thing to do
too...
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
