>>>>> On Tue, 9 Apr 2002 13:54:19 -0700,
>>>>> Toerless Eckert <[EMAIL PROTECTED]> said:
> If we would change the default for applications that don't explicitly
> configure any value of IPV6_USE_MIN_MTU to now be the value of "-1",
> then this extension would give us something, otherwise not (the
> main incentive is to change the default behavior for multicast packets).
I'm not sure if I understand the nuance of the sentence above, but I
intended in my proposal that "we do change the default for
applications that don't explicitly configure any value of
IPV6_USE_MIN_MTU to now be the value of -1".
> Even with -1 as a default i think that i would prefer a cleaner API and quite
> frankly i don't think that we are so short into the life of IPv6 that it
> doesn't really make too much sense to obfuscate such rather exotic
> API pieces for the sake of backward compatibility (i.e.: there's so little
> application already written using that API compared to what we in the
> future want to see being written but using a clean API).
I'm sorry, but I have a quite different view about the deployment
status of IPv6 and the advanced API. (As you may have known) many
major OSes (including Windows, Solaris, Linux and BSDs) have officially
supported IPv6. Some major network vendors have already shipped
IPv6-ready routers. We'll see (or even have seen) nation-wide IPv6
commercial services here in Japan within this year. Also, I know at
least one OS (BSD/OS) has already shipped with the rfc2292bis API. I
also hear that Solaris has (at least partly) adopted rfc2292bis. I
don't know the situation about other OSes, but I guess BSD/OS and
Solaris are not the only instance. BIND 9 uses the IPV6_USE_MIN_MTU
socket option in its release versions since more than a year before.
Unfortunately, rfc2292bis has lost compatibility to its ancestor, RFC
2292, in many points. The current situation where some OSes provide
RFC 2292 and some provide rfc2292bis is really confusing for
application programmers. This is another reason why we want to fix
and publish the API spec as soon as possible. Adding another socket
option surely introduces a delay of the process. Frankly, I really
want to keep the delay as short as possible, as long as the API spec
provides the "correct" behavior (in this case, it means the default
behavior for multicasted packets will fragment the packets at the
minimum MTU).
Also, I don't think the approach I proposed obfuscates the API spec if
we describe the background well, and I'd rather prefer the advantage to
keep the number of options than introducing the "clean" API. (This is
just my thoughts. I know you may have a different opinion, on which
we can perhaps not reach consensus.)
Considering all of this above, I'd very much like to go with the
approach I proposed. I'll hear from others for while, but could you
agree with the decision if there is no other strong objection?
Thanks,
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]
--------------------------------------------------------------------
