>>>>> 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]
--------------------------------------------------------------------
