Thanks for the quick replies. I have one more question - this time about the setsockopt portion for TCP in 2292bis.
If an application does a setsockopt IPV6_PKTINFO on a TCP socket, is the setting of the source address restricted only to an unconnected socket? What should the behavior be once a connection is established? Since we cannot change the local IPv6 address during a connection, I am guessing return an error of some sort. Thanks again, Lilian Fernandes On Wed, 7 Nov 2001, JINMEI Tatuya / [ISO-2022-JP] 神明達哉 wrote: > >>>>> On Tue, 6 Nov 2001 10:46:47 +0100 (CET), > >>>>> Erik Nordmark <[EMAIL PROTECTED]> said: > > > Just being able to capture the "last received" extension headers > > might not be useful either - it depends for what the application is using the > > extension headers. > > For instance, if security depends on it then presumably the TCP needs > > to be able to "latch in" a given content i.e. be able to reject packets > > which do not have the extension header content that was used to create the > > connection. > > And in such a "latch in" case a the "last received" semantics make sense > > because the extension header content can by definition not change during > > the connection. > > That's true, but I think security-conscious applications would want to > check the contents of the extension headers in ack-only segments as > well as in data segments. Thus, the current specification cannot > satisfy such applications. > > > So the problem is that while we have applications using the ancillary data > > for ICMP (and perhaps UDP) to ensure that the hoplimit is 255 > > and that there is no routing header, we do not have similar applications > > that need this ability with TCP. So we are stumbling around in the dark > > a bit. > > Yes, that's the point. And, I tend to feel that (= treat TCP like > UDP/raw-IP6 on this point) is an impossible goal, because applications > essentially cannot get access to TCP data per segment basis (some > segments do not contain actual data, some can be silently discarded in > the kernel due to duplication/overlapping/etc). > > So, IMO, we should admit that this kind of mechanism can only be > provided in lower layer filtering, and the optional information passed > from a TCP stack to an application should be used just as some hints. > > Based on this view, my current feeling is that the best way is to fall > back to a single get-only socket option like RFC2292's IPV6_PKTOPTIONS > (though the option could be "set" in the RFC) with the simple "keep > the last received ones" logic. > > Although this change can cause backward compatibility issues with > existing applications that rely on the former versions of rfc2292-bis, > I personally think it is negligible. We implemented the older > versions of the API almost two years ago, but I've not seen any > TCP applications that rely on the spec. > > What do other implementors think? Does this change make sense? > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > [EMAIL PROTECTED] > > p.s. sine some might be wondering about the current situation of the > spec...I'm now editting a revised version of the spec, which will be > available before the cut-off date for the next IETF meeting. > -------------------------------------------------------------------- > 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] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
