>>>>> On Fri, 21 Dec 2001 01:23:45 +0100 (CET),
>>>>> Erik Nordmark <[EMAIL PROTECTED]> said:
>> 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).
Okay, compatibility to existing applications should actually not
matter.
>> 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.
I'm not sure I can get this argument...in the 03 behavior (as well as
in 02), the IPV6_RECVXXX options always set/get an integer, regardless
of the socket type (TCP/UDP/raw). These options just tell the kernel
if the application wants to receive the incoming extension headers (or
other optional info). Then, in 03, UDP or raw sockets get the
information as ancillary data and TCP sockets get it via a separate
socket option "IPV6_PKTOPTIONS." I think there is no overloading
here.
Anyway, I think I provided all information to make a decision. If we
can reach consensus on a single behavior through all the information,
I'll put it in the next revision of the draft. Otherwise, I'll just
leave this part unspecified (perhaps with some background.)
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]
--------------------------------------------------------------------
