> I searched in the web for old discussions and I think I found the > answer to the question 1. (You can check the discussion at the > following URL > http://www.wcug.wwu.edu/lists/ipng/199803/threads.html > with the subject "Advanced Sockets API Issue")
Thanks for digging up the history - I couldn't recall all the details. > And, the reason for the change in rfc2292bis-03 is as follows (I know > the reasons are controversial and someone have an objection): > 3. there are currently RFC2292-style applications deployed. It is easy > for such applications to migrate to rfc2292bis-03 than to > rfc2292bis-02. (The opposite argument may apply for > rfc2292bis-02-style applications, of course.) 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). > As for the symmetric behavior in the original motivation, we've > already solved it by separating IPV6_XXX and IPV6_RECVXXX. So, there > is no reason to use recvmsg() + ancillary data on TCP sockets for this > reason. Yes, but the semantics of IPV6_RECV* on UDP and raw is to enable receipt which is quite different that actually receiving the content. Thus they are boolean (int32_t) socket options. *If* there is a need to have socket options to extract the received extension headers from the kernel I think it would make sense to use different socket options and not overloading the existing ones. 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] --------------------------------------------------------------------
