Subject: Re: destination option update

From: Tim Hartrick <[email-masked]>
Date: Fri, 15 Dec 2000 14:45:29 -0800 (PST)

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-masked]
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 17 Dec 2000 21:56:22 -0800 (PST)

> That would seem to be understood given that the application is receiving the
> datagram.  If appropriate security wasn't applied the datagram should have

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.

> problem(s) as I currently understand them.

Any suggestions on how to specify this on the send side?

  Erik

---

From: Francis Dupont <[email-masked]>
Date: Mon, 18 Dec 2000 19:10:10 +0100

In your previous mail you wrote:

=> I understand your opinion but we have to provide a way to denote
the position for the sending side.

=> if you have both note 1 and note 3 destination option headers to send
you need a way to code this. The kernel should not have to parse headers
in order to understand what you want according to options.

[email-masked]

PS: at ETSI bake-off an implementor panel asked for this (summary: ok to
add a new position but please cleanup this, two are already too many,
three will be a real mess).
PPS: more I think about this, more the stack API seems to good path...
--------------------------------------------------------------------
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]
--------------------------------------------------------------------