>>>>> On Wed, 13 Feb 2002 12:11:40 -0800 (PST),
>>>>> Tim Hartrick <[EMAIL PROTECTED]> said:
> 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.
I agree it is (or can be) easy for ancillary data, but I'm not sure
about the case of sticky (socket) option. What is your idea in this case?
> 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.
We've already removed IPV6_RECVRTHDRDSTOPTS and simplified the
receive side, so these issues should have gone (although we've lost
symmetric semantics between send and receive sides - this can be
another motivation to simplify the send side as well).
> 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.
I agree. If it is really easy to deal with the send side as you said,
it would be the best candidate (so I'd like to know the details).
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
