>>>>> On Thu, 26 Jul 2001 23:52:42 +0200 (CEST),
>>>>> Erik Nordmark <[EMAIL PROTECTED]> said:
>> 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).
Ah, yes. We may need this stuff as well. I meant this additional
stuff in my message above, but I was not enough clear, sorry. Anyway,
it's not so complicated, and I think we do not see much trouble to
reach consensus on this.
>> 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.)
Through the succeeding discussion, I guess the reasonable way is
- fix the current spec with as small changes as possible
(i.e. basically #2 above), and
- try to get further generalization (i.e. the #1 above) as a separate
spec.
Now we are about to compile the todo list and to write a new revision.
So let's concentrate on the 1st step for now, and discuss it after the
new revision is out.
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]
--------------------------------------------------------------------
