Subject: Re: sin6_flowinfo and sendto/recvfrom

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

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

---

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

hello,

>Clarifying this in RFC2553 would be good.

	RFC2553 does not really talk about endian issue.  i agree clarification
	would be nice.  summary is like below:

sin6_len	(44BSD only) single byte, so order does not matter
sin6_family	non-44BSD: host order, 44BSD: single bye
sin6_port	net order
sin6_flowinfo	net order
sin6_addr	net order
sin6_scope_id	host order

	the last one may be wrong.  i remember there were some discussons on
	this, and the conclusion was (IIRC) that sin6_scope_id is host endian
	since it does not appear on the wire.

>I don't think the receiving TCP should care.

	yes, i was concerned about the issue.  i'm okay TCP should not care
	as long as it is documented.  this rejects (b) in question (5),

>for that. So either a) or c) are fine with me.

itojun

---

From: Francis Dupont <[email-masked]>
Date: Thu, 22 Jun 2000 11:52:46 +0200

=> 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...

   
=> 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.

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

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