> The working group has just decided the flawn is not in the specs but
> in the advanced API then either:
> - or we found a good way to encode positions (I have no idea of how)
> - or we arbitrary restrict the advanced API expressiveness to
> some common cases (as it is done today but we already need to
> add a new position for destination option headers).
> As I don't know if the first goal is possible to archieve I suggest
> to go to the second if no progress is done before a reasonnable delay.
Adding a 3rd set of options to receive a 3rd placement of destination
options in the advanced API probably isn't too hard.
However, I'm a bit concerned on how to define the semantics
when there are 1 or 2 destopt headers in the packet.
The current semantics is that IPV6_RTHDRDSTOPTS contains the destination
options before a routing header, which only make sense when there
is a routing header and a destopts header that preceeds the routing header.
When there is no routing header IPV6_DSTOPTS contains the destination options
header, and when there is a routing header IPV6_DSTOPTS contains the
destination options header after the routing header. So basically this
separates out the destination options header into those that appear before and
after a routing 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.
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.
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 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.
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.
Is that the path we should take or are there better suggestions?
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]
--------------------------------------------------------------------
