> 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.
But the application might very well want to know what destination options
were protected by ESP. The security checks will presumably only tell the
application that, in the case of transport mode, that the tranport
header and data was protected.
Thus the application can't tell if the destination options where covered
by ESP or not using the APIs.
> 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.
Any suggestions on how to specify this on the send side?
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]
--------------------------------------------------------------------
