In your previous mail you wrote:

   Adding a 3rd set of options to receive a 3rd placement of destination
   options in the advanced API probably isn't too hard.

=> I agree but I can intepret Steve's comment as this is not the good
solution. But I don't know a good way to denote the position for
individual header.
   
   I don't think rfc2292bis says anything about the case
   when there are multiple destination options headers in each of these two
   logical locations.
   
=> merge them???

   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.
   
=> intermediate and final should give better names...

   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)?
   
=> this is the solution I use in my current code: a big buffer with the
whole option array but:
 - this is less flexible than individual header management (for instance
   the good way to insert a header is to pickup the current array before).
 - this doesn't work well with "transparent" headers like fragmentation
   or IPsecs.

   This would still have some problems since certain extension headers
   (fragmentation, AH, ESP) aren't passed up to the application.

=> exactly my second concern.

   Is that the path we should take or are there better suggestions?
   
=> I have followed this path then I can say we should look for a better
idea...

Thanks

[EMAIL PROTECTED]

PS: the issue is for the API itself, in the kernel you can add zero length
place holders in the header chain (you should do it according to RFC 2401
for incomming IPsec headers). Perhaps the good solution is to manage a
stack of headers directly (pop/push/gettop) with transparent headers too
(ie. to push a fragmentation header will only indicate the relative position
of adjacent headers)?
--------------------------------------------------------------------
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]
--------------------------------------------------------------------

Reply via email to