(sorry for the delayed response. I'm just back from a short vacation.)
>>>>> On Thu, 14 Feb 2002 10:57:45 -0800 (PST),
>>>>> Tim Hartrick <[EMAIL PROTECTED]> said:
>> 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).
> I had missed the change in receive side semantics. More badness. Why
Let me confirm, did you say the change in the receive side was "more
bad"? I don't get the relationship between the change in the receive
side and the rest of your message...
> can't the order of the setsockopt calls establish the order of the
> routing header and the destination options? I don't see why it isn't that
> simple except in the case where ancillary data and sticky options are
> intermingled.
I don't think it is a good idea to assume the relationship of two
separate (and different) socket options and make application
programmers take care of the ordering. This approach is in fact
essentially the same thing as IPV6_RTHDRDSTOPTS with additional
confusion; for example, it is not clear on what happens when we remove
a routing header after specifying a couple of destination options
headers. It is also unclear on how to remove a particular destination
options header after specifying a couple of ones....
I'd rather prefer IPV6_RTHDRDSTOPTS to this approach.
> This is another reason why it was better to allow ancillary data to override
> ALL sticky options rather than just like sticky options. This change has
> substantially complicated the implementation for little benefit. Oh well.
> Just put this mess to bed.
I still strongly believe that the current overriding rule is more
natural for application programmers with the fact we've separated
sticky options as a separate set of single socket options. Here is a
recap of an old message of mine (in a private discussion). I think
this is still reasonable enough, and do not think the result is
"little benefit":
Anyway, first I thought that the previous behavior was natural.
On the second thought, however, I changed my mind. The previous
overriding scheme is reasonable in RFC2292, because we can only
specify a "set" of options in a single sticky option; IPV6_PKTOPTIONS.
But, in rfc2292bis, we have separated each option so that it could be
specified as a single sticky option. Additionally, we have much more
ancillary data items/sticky options than in RFC2292, and there is an
"ancillary-only" option (IPV6_REACHCONF). Perhaps due to all of these
points, some applications use both an ancillary data item and a sticky
option expecting that both of them can be enabled at the same time.
BIND 9 is an example; it uses IPV6_USE_MIN_MTU as a sticky option for
the UDP socket as well as IPV6_PKTINFO ancillary data items to specify
the source address. If the underlying kernel strictly follows
rfc2292bis-02, the IPV6_USE_MIN_MTU sticky option would be disabled.
Of course, we could say that "it's a bug and the application should be
corrected." However, I think such a usage of BIND 9 is quite natural
to application programmers, and what should be changed is the API
specification.
===
Through the discussion so far, my feeling on this issue is that we
should just go with the current specification. It's true that
IPV6_RTHDRDSTOPTS is useless at least for now and will probably be
in the foreseeable future. However, the current spec is clear enough
and is consistent with the policy of adopting the "recommended" order
described in RFC 2460 as a limitation within this particular API spec.
As everyone admits (I believe so), we do not need a "perfect"
specification; the most important thing is to provide application
programmers with a uniform API that can cover today (and the
foreseeable future)'s typical applications. We should be able to live
with the spec as long as it is clear enough.
If necessary, we can add a note that there is no use of
IPV6_RTHDRDSTOPTS as of writing the API and that applications will
only need IPV6_DSTOPTS in most cases.
Can we agree with this?
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]
--------------------------------------------------------------------
