> From [EMAIL PROTECTED] Tue Jun 26 01:50:32 2001
> Received: from roll.mentat.com (roll [192.88.122.129])
> by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id BAA23124
> for <tim@leo>; Tue, 26 Jun 2001 01:50:32 -0700 (PDT)
> Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
> by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id BAA29739
> for <[EMAIL PROTECTED]>; Tue, 26 Jun 2001 01:50:29 -0700 (PDT)
> Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
> by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA16729;
> Tue, 26 Jun 2001 02:49:17 -0600 (MDT)
> Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
> by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id
>BAA06117;
> Tue, 26 Jun 2001 01:49:07 -0700 (PDT)
> Received: from sunroof.eng.sun.com (localhost [127.0.0.1])
> by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id
>f5Q8lqdP007714
> for <[EMAIL PROTECTED]>; Tue, 26 Jun 2001 01:47:52 -0700 (PDT)
> Received: (from majordomo@localhost)
> by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5Q8lqiD007712
> for ipng-dist; Tue, 26 Jun 2001 01:47:52 -0700 (PDT)
> X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to
>[EMAIL PROTECTED] using -f
> Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
> by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id
>f5Q8lhdP007691
> for <[EMAIL PROTECTED]>; Tue, 26 Jun 2001 01:47:43 -0700 (PDT)
All,
Everyone of BSD, Solaris, Linux and Winsock define slightly different
behavior of bind(2) and SO_REUSEADDR/SO_REUSEPORT. We can certainly classify
the differences but to what end? None of the differences in behavior are
going to be rectified. We aren't going to arrive at a common understanding.
What will happen is absurd chest beating about market share and how everyone
should change their implementations to conform with whoever claims to have
the larger market or better understanding of security issues or better grasp
of what is "right". In fact, I see it is already happening....
All the discussions which are occuring in this thread have occurred before.
The outcome of those discussions is in RFC 2553. We aren't going to achieve
agreement on how bind(2) and SO_REUSEADDR/SO_REUSEPORT should behave because
no implementor worth their salt is going to risk breaking applications that
may depend on the particular idiosyncrasies of their implementation.
It is ridculous to even suggest the idea that RFC 2553 should be thrown out
simply because someone has arrived late to the party. The price of arriving
late to the party is accepting the work that has come before and making your
implementation conform. If you want to be in on the design you need to get
to the party early.
With regard to the IPV6_V6ONLY option, it made and makes little difference to
me what value the option defaults to. No matter which we choose code will
break. We have also had this discussion before. I see that Erik and Brian
are for changing the default value to true. If that is the consensus I can
live with that. It will, however, break existing code. How much and how
badly depends on where you sit. It is easy for those that don't have code
to be in favor of changes.
Let's make a call and move on.
Tim Hartrick
Mentat Inc.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
