Subject: Re: complete the advanced API (rfc2292bis)

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 07 Aug 2001 05:20:35 +0900

>>>>> On Thu, 26 Jul 2001 23:52:42 +0200 (CEST), 
>>>>> Erik Nordmark <[email-masked]> 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-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]
--------------------------------------------------------------------