Catching up on email after some vacation...
> I've just read the previous discussion. It seems to me that we've
> basically reached a consensus for the receiving side; obsolete the
> IPV6_RECVRTHDRDSTOPTS option, and let the kernel send all headers (if
> requested) to applications in the receiving order.
As I recall this isn't sufficient. Some applications will need to be able
to tell e.g. whether a destination options header was before or after an ESP
header. For constency it would make sense to also be able to tell the
location of AH headers.
A possible solution would be to define IPV6_RECVESPHDR/IPV6_RECVAHHDR
and IPV6_ESPHDR/IPV6AHHDR. The latter two would be passed up as ancillary
data items of zero length (i.e. they would just be markers identifying
the location of the ESP/AH headers in the received packet).
> For the sending side, which would be the difficult part, I think we
> have two possible approaches.
>
> 1. try to realize the full flexibility about the header chain; the API
> allows applications to specify any combination of headers (in any
> order).
> 2. only loosen the restriction about destination options headers;
> (e.g.) add another ancillary data type/socket option to specify the
> relationship between a destination options header and a fragment
> header.
I think #2 is sufficient as a goal.
But assuming we want to solve this both for sticky options and
ancillary data it might turn out that a resonable solution would
actually solve #1 as well.
(For instance, the sticky option case could be solved by making the option
buffer carry an addition"index" identifying which extension header the
setsockopt refers to in the sequence starting with the IPv6 header (1st, 2nd,
etc). Such a solution would allow specifying any order.)
Erik
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
