> > Are there TCP applications which use RFC 2292 style for accessing received > > extension headers? > > I thought we had concluded that no TCP applications existed that access > > the received stuff (even tough telnet can set things like routing headers > > for transmit). > > Okay, compatibility to existing applications should actually not > matter.
I had a more fundamental question: does there exist even one TCP application which receives extension headers? I haven't seen one. You seemed to say that such exist. If they do it would be useful to look at those TCP applications to see what they are trying to do and which flavor of the API fits better. And if they exist it might not make sense to remove everything about TCP applications receiving extension headers from the spec. > I'm not sure I can get this argument...in the 03 behavior (as well as > in 02), the IPV6_RECVXXX options always set/get an integer, regardless > of the socket type (TCP/UDP/raw). These options just tell the kernel > if the application wants to receive the incoming extension headers (or > other optional info). Then, in 03, UDP or raw sockets get the > information as ancillary data and TCP sockets get it via a separate > socket option "IPV6_PKTOPTIONS." I think there is no overloading > here. You're right. I seemed to have read that a getsockopt of IPV6_RECV* would return the information. Using IPV6_PKTOPTIONS does not have overloading problems. 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] --------------------------------------------------------------------
