>>>>> On Wed, 31 Oct 2001 15:19:52 -0600 (CST),
>>>>> Lilian Fernandes <[EMAIL PROTECTED]> said:
> RFC2292bis-02 states that applications using TCP can use ancillary data to
> receive IPv6 and extension header information (Section 4.1 - TCP Implications)
> What are other implementations doing about this? Is there a common
> strategy that most implementations have adopted?
I'm not sure about the "common strategy", but KAME's implementation
does this. Basically, it is not so tricky about the implementation;
it just appends the optional information as control data to the
receiving socket.
However, I'm not sure if this specification really makes sense. Even
with the per-segment control data, it still does not follow all
changes about the optional information during a TCP session. Also, if
the TCP socket does not receive actual data (i.e. it only receives
SYN, FIN, and ACK-only segments), the socket cannot receive any
information. Although the new spec can reduce the polling overhead
that RFC2292 had, I myself tend to revive the old behavior...
> Also, what could be a reason for delivering data like "destination
> address" as ancillary data? This will always be constant as part of the
> TCP connection's 4-tuple.
I think it's just for consistency with the UDP/raw socket
specification, and there is no practical usage of the data for a TCP
socket.
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]
--------------------------------------------------------------------
