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

Replies to portions out of order for clarity.

On Sat, Apr 23, 2005 at 05:15:40PM -0700, Jonathan Stone wrote:
>=20
> In message <20050423012904.GL12650@netbsd.org>, Bill Studenmund writes:

> Bill, I genuinely don't understand why so many here have difficulty
> grasping simple facts, or difficulty accepting the consequences, or
> whatever- it-is that's not getting across here.

Then I strongly suggest you pause. Stop and think. If there is confusion,=
=20
find clarity before proceeding. Figure out what you want, then make sure=20
your words help you achieve it.

I think one problem is that you have lost sight of the forest for the=20
trees. It probably didn't help that you've had discussions like this=20
before that we don't know about, and many folks here may have mistaken the=
=20
forest for one tree... :-)

I don't think anyone else in this discussion is really as rigid as your=20
reactions seem to imply. I think very simple comments can (could have)=20
direct things in a direction everyone will find pleasant. And if they=20
really are that rigid, simple reasonable comments can ensure that bad=20
things don't happen; you'll have the audience on your side.

> >Given that, when they looked at how to fix it, they found that IPv6 has =
a=20
> >behavior that meets their needs. In this case, it seems reasonable to=20
> >suggest adding support to IPv4 of a feature that happens to be in IPv6.
>=20
> Bill,
>=20
> That's the whole problem: it is *not* reasonable for RFC1918 addresses.
> The semantics of RFC-1918 addresses simply doesn't match IPv6 scoping
> rules: there *is* no defined scope.  Thus we end up with situations
> where an organization deploys, say, 10/8 as the organization's own
> private network; and sub-groups or individuals within that
> organization use 192.168/16 as *their* own ``private'' network.

Then just say that. But say it differently.

Rather than saying, "This is why your idea is hideously broken," try,=20
"There *is* no defined scope, so different sites may make different, valid=
=20
choices about what scopes are and aren't the same. So you need to have=20
some may of implementing policy so that an admin can make the right=20
choices."

The difference is that rather than a, "don't do that," that commment is a,=
=20
"You're adding emphasis that isn't defined, so you need to be flexable."=20
It's a project requirement, if you will.

> Or consider an organization which has grown by acquistion, which has a
> mixture of private and (legacy?) globally-routable IPv4 addresses.
> To that organization, *all* those addresses are considered ``private''.
> Speciifc hosts may be multihomed onto multiple different RFC1918
> addresses, or multiple acquired `public' addresess or multihomed
> onto both.
>=20
> (Both such setups are, indeed, common cases.)
>=20
> The conclusion is obvious: a heurstic derived from IPv6 scoping rules
> simply *doesn't work* for RFC1918 addresses: they're just different
> beasts, deployed in different ways. Reasoning by analogy from the one
> to another just does not work. There *is* no well-defined scope for
> RFC1918 addresses, other than that they are ``private''.

I think the part I disagree with in the above is "just does not work." I
agree it's complicated, and one-size-fits-all certainly won't work. But
the concept of scopes and how you deal with them certainly can made (and
configured) to work.

> >First, I don't believe that NetBSD supports Strong ES right now.=20
>=20
> But of course we do. See sys/netinet/ip_input.c for the words ``Strong
> ES'' and ``hybrid'' and ``checkinterface''.  Yes, it says we support
> an odd hybrid.  But with unbound sockets, and the RFC-1122 behaviour
> of picking the address of the outbound interface, that goes a long way
> towards supporting strong ES.  As Thor observes, some of us do rely on
> that.

I do not think "odd hybrid" =3D=3D supports, since the "Strong" model is mo=
re=20
restrictive than the "Weak". Quite useful and effective and used, I'll=20
grant. And "good enough" in some places, I'll grant. But I don't think=20
that's really "supporting" Strong ES.

> >Second, I'm not 100% sure how this will break Strong ES. I expect if we
> >add Strong ES support,=20
>=20
> Adding David's patch, with David's proposed modification to ``scope''
> RFC1918 addresses for multi-homed hosts, _will_ break decades-old
> assumptions (definitions?)  about how IPv4 works.  It _will_ break
> extant configurations which rely on our existing partial strong-ES
> semantics. It _will_ break existing code that implicitly relies on
> those semantics, and has done for years.
>=20
> Thus, forcing IPv6 ``scope'' onto RFC1918 addresses is *not*
> reasonable.  (OTOH, doing so for zeroconf addreses may well be
> reasonable; but then I've never objected to that!)

I'm not sure what to say here. I immediately made the thought jump earlier
in this dicsussion that we're talking about policy, and policy is best=20
configured by the sysadmin. Perhaps it's because the biggest reason I am=20
interested in seeing something like this is a configuration from a=20
now-dead startup that wouldn't have worked with the hard RFC1918 scoping=20
initially described.

The upshot is that since it's policy, then it has to be configurable, and=
=20
"off" (or "it's all one big scope") certainly should be a valid=20
configuration.

Thus Strong ES folks should be able to keep going too.

> For those who do see utility in distinguishing ``first-class'' local
> IP[*] addresess from ``second-class'' addresses, I submit that
> expliclity marking individual addresses as ``second-class'' is so
> clearly a better approach than a heurisitc based on address prefix
> that its not even worth talking about. (Or maybe defaulting zeroconf
> addresses to be ``second-class?'')
>=20
> [*] v4, that is.

Take care,

Bill

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

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

iD8DBQFCaz2IWz+3JHUci9cRAvo0AJ9QxMvtb1ixHE8l+gjPrgGMCbbvIwCfS7o0
lYlSrrJU4wykRUIPVf9wpO0=
=Xond
-----END PGP SIGNATURE-----

--RIYY1s2vRbPFwWeW--