>>>>> On Wed, 19 Dec 2001 13:31:28 -0500, >>>>> Vladislav Yasevich <[EMAIL PROTECTED]> said:
> I've been thinking about the suggestiong of removing > the tcp handling from the document and keep comming up > with the following 2 questions: > 1. Why was the change made origianlly in the 2292bis? > and > 2. Why change now back to the original 2292 definition? > I don't know the answere to 1 (may be Eric can help?) and > noone has sufficiently answered 2. Okay, they are reasonable questions. 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") The very first motivation was that (old) IPV6_PKTOPTIONS was not symmetric, that is, it was used to specify sticky options for outgoing packets with setsockopt(), while it was used to retrieve received optional information with getsockopt(). The proposed solution was to change the semantics of getsockopt() side so that it would just return the content specified by setsockopt(). With this change, we'd need a separate mechanism to provide the ability to retrieve received optional information. Using recvmsg() (for TCP sockets as well) was proposed for this purpose. Another reason was to provide a single, uniform interface to retrieve the received optional info, i.e., recvmsg() + ancillary data. There was also discussion on if we should provide the ability to trace changes on the optional information for TCP sockets and if the kernel should check the changes to omit passing ancillary data for efficiency reasons. I didn't see consensus on this discussion in the list archive. And, the reason for the change in rfc2292bis-03 is as follows (I know the reasons are controversial and someone have an objection): 1. despite the change, the rfc2292bis-02 behavior did not provide a TCP socket with the complete ability that is available for UDP and raw-IPv6 sockets. For example, it did not provide the ability to trace the changes. Thus, there was less advantage to introduce the change. 2. the rfc2292bis-02 behavior did not provide a send-only TCP application with the ability to retrieve optional receive info, while RFC2292 provided the ability. In other words, rfc2292bis-02 was not upper-compatible to RFC2292 in terms of its function. 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.) Finally, the following is my personal opinion (and preference) based on all of above. 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. As for the motivation of a single and uniform interface, I see some benefit. However, I'm not sure if this really helps application programmers. Due to differences between TCP and UDP/raw-IPv6 (more accurately, differences between STREAM and DGRAM) we cannot provide both type of sockets with exact the same behavior. Also, most application programmers are not familiar with using recvmsg() for TCP sockets, as far as I know. Even with the fact this is an "advanced" API, I'd rather separate the retrieving mechanism for TCP and others with clearly stating that the getsockopt() approach can only be used for TCP sockets. In summary, I'd still support the 03 behavior if we had to choose one. However, since the usage of receiving the optional info on TCP sockets is relatively a minor issue, I'm okay with leaving it unspecified if we cannot reach consensus. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] -------------------------------------------------------------------- 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] --------------------------------------------------------------------
