Subject: Re: TCP and Ancillary data in RFC2292bis

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 06 Nov 2001 02:03:07 +0900

>>>>> On Wed, 31 Oct 2001 15:19:52 -0600 (CST), 
>>>>> Lilian Fernandes <[email-masked]> 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-masked]
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Lilian Fernandes <[email-masked]>
Date: Mon, 5 Nov 2001 14:57:54 -0600 (CST)

My question was in regard to the mapping of the packet data from the
arriving packet to the point in the bytestream when it is actually
'recv'd by the application. e.g. 2 packets of payload length 40 bytes each
may arrive, but be delivered to the application as a single 80 byte piece.
What is delivered to the application if both packets had different control
data?
Or is the intent that we save just the control information from the last
packet that arrived and return that as control data?

After re-reading section 4.1 of 2292bis-02, I have another question about
the "getsockopt" behavior. Is not the normal behavior of getsockopt to
just return whatever value was set with setsockopt? e.g. if I use
setsockopt to set the IPV6_HOPLIMIT to be 33, then getsockopt should
return 33.
It seemed to me that recvmsg will be the only way for an application to
retrieve data about arriving packets...can someone please clarify this
also?

Thanks again,
Lilian

> 					[email-masked]

_____________________________________________________________________

Lilian Fernandes
AIX TCP/IP Development - IBM Austin
Tel: 512-838-7966	Fax: 512-838-3509

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 6 Nov 2001 10:46:47 +0100 (CET)

> packet that arrived and return that as control data?

I don't recall the wording in the spec and the intent when 2292bis
was written, and I agree with Jimei's point that you can't
what extension headers etc were present in TCP segments without any data
bytes, but ...

For what it is worth, the Solaris implementation compares
the set of information the application has requested (using IPV6_RECV* socket
options) and determines when that informating changes from one TCP
data segment to the other. For the first data segment in the connection
(or the first after IPV6_RECV* has been enabled), as well as when there are 
any changes in the info from one data segment to the next, TCP
delivers the ancillary data.

So in your example the application would see recvmsg returning the
first 40 bytes and the next recvmsg would return the second 40 bytes
with the new ancillary data.

This means that e.g. if the sender switches from using one routing header
content to another routing header content in the middle of the
connection, the application would be able to observe this.
(But it can't observe anything if it is on the side that is only receiving
ACK packets.)

So I don't know how useful this is in practice.

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.

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.

> setsockopt to set the IPV6_HOPLIMIT to be 33, then getsockopt should

In general that is true. (I think that if hoplimit is set to -1 for "default"
the getsockopt might actually return the default value that is being
used instead of returning -1).

> retrieve data about arriving packets...can someone please clarify this

Yes, that is the intent.

  Erik

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 07 Nov 2001 00:56:06 +0900

>>>>> On Tue, 6 Nov 2001 10:46:47 +0100 (CET), 
>>>>> Erik Nordmark <[email-masked]> said:

> because the extension header content can by definition not change during 

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.

> that need this ability with TCP. So we are stumbling around in the dark

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

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

---

From: Lilian Fernandes <[email-masked]>
Date: Tue, 6 Nov 2001 12:58:02 -0600 (CST)

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 08 Nov 2001 18:21:34 +0900

>>>>> On Tue, 6 Nov 2001 12:58:02 -0600 (CST), 

> return an error of some sort.

Good point.  Actually, I was thinking about the issue, too, and I'm
going to clarify this so that issuing IPV6_PKTINFO setsockopt on a TCP
socket will fail.

					JINMEI, Tatuya

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 8 Nov 2001 14:29:04 +0100 (CET)

> going to clarify this so that issuing IPV6_PKTINFO setsockopt on a TCP

Being able to use IPV6_PKTOPTIONS for TCP to e.g. set the outbound interface
when using a global address seems consistent with the intent of the option
and the way it is used with UDP.

  Erik

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 08 Nov 2001 22:45:50 +0900

>>>>> On Thu, 8 Nov 2001 14:29:04 +0100 (CET), 

> Being able to use IPV6_PKTOPTIONS for TCP to e.g. set the outbound interface
                    ^^^^^^^^^^^^^^^should be IPV6_PKTINFO
> and the way it is used with UDP.

Ah, yes...though I don't see practical usage for the TCP case, I don't
see the strong reason to prohibit it either.  So a reasonable
clarification would be:

  for a TCP socket,
  - the address part should be ignored (or must be "::")
  - the interface index part will be used as the outgoing interface

					JINMEI, Tatuya