Erik,
>
> The above is quite complex to describe to the user of the API.
> Adding another IPV6_DSTOPTSAFTERIPSEC(?) concept that is conditional
> would make it even harder to describe.
>
I am generally against this proliferation of new option types and extension
headers. Processing and packing all this ancillary data is hairy enough
as it is.
> So ...
> perhaps it would be easier if we instead passed these routing headers
> to the application in the order they where received with all of them
> being tagged with the same ancillary data type (IPV6_DSTOPTS)?
>
I believed before and believe now that this is the better way to go.
I never really liked the IPV6_RTHDRDSTOPTS option.
> This would still have some problems since certain extension headers
> (fragmentation, AH, ESP) aren't passed up to the application.
> Thus if the packet has
> IP header
> dstopt
> frag hdr
> dstopt
> ESP
> dstopt
>
> or if it has
> IP header
> dstopt
> frag hdr
> dstopt
> dstopt
> ESP
>
> the application would in both cases see 3 IPV6_DSTOPT ancillary data items
> with no intervening ancillary data items, so the application can't tell
> the important difference.
>
I don't know that the receiving application needs to know any of this. It
merely needs to know that the appropriate security was applied by the system.
That would seem to be understood given that the application is receiving
the datagram. If appropriate security wasn't applied the datagram should have
been discarded before it reached the application.
I think that the problem is on the send side for things like the home address
option and the encapsulation limit option. In those cases the application
wants to send:
IP header
dstopt
upper layer
but the application wants the dstopt to be in the *non-fragmentable* part
of the datagram. Given the current API and partially because of the
fragmentation algorithm in the IPv6 base specification that isn't possible.
In these cases the "application" may be a kernel tunneling driver or something.
If we can enhance the API to allow the application to specify where it
wants the non-fragmentable part of the datagram to end that would fix the
problem(s) as I currently understand them.
> The upshot of this is that either way we go the receive side interface
> will be quite complex, unless we somehow can represent the location of
> the extension headers (especially AH and ESP) that have been removed as
> part of processing the packet.
>
As I said, I don't believe that this is necessary. Of course I may be
completely misunderstanding the nature of the problems.
tim
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
