--DBIVS5p969aUjpLe
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Apr 23, 2005 at 01:04:38AM -0700, Jonathan Stone wrote:
>=20
> In message <20050423062817.GH27204@che.ojctech.com>David Young writes
>=20
> >On Fri, Apr 22, 2005 at 04:47:11PM -0700, Bill Studenmund wrote:
>=20
> >> We thus at present have an
> >> ambiguity as to which IP to choose.=20
>=20
> So Bill says. But the *BSD stack and derivatives have a _long_ history
> of ``pick the first one''.  I know of several pieces of code which
> relies on that ordering to implicitly distinguish ``primary'' or
> ``first-class'' IP addresses from ``secondary'' addresses.  David's
> proposal will break such code.

Your arguement has switched in the above.

The point I was trying to make was that the RFC doesn't say which address=
=20
should be chosen. I gather from the fact that you refer to a historical=20
behavior that my point was correct.

The reason I mention this is that I believe that if we don't fully
implement Strong ES, then we are, strictly speaking, a Weak ES system.
Weak ES doesn't make promises about which IP address will be used (I think
that's a huge part of the point..), so we can change the IP selecting
process and still be RFC-compliant. Correct?

I agree that we should consider things carefully when changing an old
behavior, especially as some folks use the current behavior to implement a
"close-enough-to-Strong ES" model. But changing a "we've always done it
this way" behavior is different from changing an RFC-dictated behavior.

> Tho' I dont know if it works anymore on NetBD, with hashed lookup of
> local-IP-addrs it certainly does on other BSD derivatves. If it truly
> isn't predictable on NetBSD, then that strikes me as a darn good
> reason to distinguish first-class local addresses from
> explicitly-marked secondary or "alias" addresses.

And what if we want multiple "first-class" addresses?

Take care,

Bill

--DBIVS5p969aUjpLe
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFCbUarWz+3JHUci9cRAlNeAJ4pz77lEP5rMkYNyJ4+05geirAHXACeIaGN
sDrYG8RghQVtApI5lbEx7Mg=
=VkUA
-----END PGP SIGNATURE-----

--DBIVS5p969aUjpLe--