Tim The IPV6_RTHDRDSTOPTS is a send side only option any more (at least thats how the spec reads). For the recieve side, IPV6_DSTOPTS gets you all the destination options.
I guess that might be considered another argument for removing this option... On the other hand, ordering of setsockopt() calls or ancillary data does not necessarily translate into ordering in the packet (however that's one way to implement it). In the end, it's probably easier to keep the option then to remove it, but I can live with either. -vlad Tim Hartrick wrote: > > > I have never and still don't see the need to disambiguate between destination > options which come before the routing header and those that come after. On > the send side it is easy to order your ancillary data or setsockopt calls > in a way that gets you what you want. On the receive side, if you one cares > whether an option was before or after the routing header one simply needs > to receive both destination options and routing headers. Lastly, the current > definition requires that at least two passes be made over the options when > preparing to deliver ancillary data. This is because IPV6_RTHDRDSTOPTS is > defined to be destination options which occur before the routing header. > Once can't tell what type of destination options one is delivering until the > entire datagram has been passed over to determine whether a routing header > is present. All around badness. > > Unfortunately, we have already been forced to write code that implements this > badness. I would welcome the options removal but I don't believe that we > should spend a lot of time debating the point. > -- ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tel: (603) 884-1079 Compaq Computer Corp. Fax: (435) 514-6884 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 -------------------------------------------------------------------- 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] --------------------------------------------------------------------
