--Jl+DbTnyraiZ/loT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 22, 2005 at 05:16:43PM -0700, Jonathan Stone wrote:
>=20
> In message <20050422234711.GI12650@netbsd.org>Bill Studenmund writes
>=20
> >On Fri, Apr 22, 2005 at 03:18:56PM -0700, Jonathan Stone wrote:
> >>
> >> I have no clue what the motivation is here.  But I have a good working
> >> knowledge of IPv4, and with that knowledge (but no idea what you are
> >> trying to achieve), this entire proposal looks wrong, unacceptably
> >> wrong -- to the point where I would back out such a patch, with
> >> preduice, as being clearly wrong.
> >>
> >> In particular, trying to force IPv6-style "link local" semantics on to
> >> RFC-1918 or zeroconf addresses *is* incorrect, and will break valid
> >> uses of IPv4.
> >
> >How so?
>=20
> 1. Retroactively trying to force IPv6 semantics onto IPv4 is a
> prima-facie error.  Period.  End of story. In my own opinion, anyone
> commiting that error is just not qualified to hold an informed
> technicaln opinion on this matter. Sorry to be so blunt, but that's
> how it is.

The rigidity you are displaying does not serve you or your arguement.

I agree that just because IPv6 does something doesn't mean IPv4 should.

However as I understand this thread, it started out that folks thought=20
what IPv4 is doing is wrong. They flat out don't like it.

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.

The key difference as I see it is that the main, root issue is that folks=
=20
don't like what IPv4 does, not that IPv6 does something different. Yes,=20
that's a nit, but I think it's an important nit. If I felt this were a=20
"IPv6 should be like IPv4" arguement, I'd be agreeing with you. Strongly.=
=20
:-)

> 2. The proposal is a half-arsed version of Strong ES that will break
> ``real'' Strong ES.  I use Strong ES, I am working on better support
> for it, so I object to breaking it.  (See my earlier message (but
> after the one you respond to) for some discussion of Strong ES.)

Thank you, I did see that note (after I sent this one).

Three things immediately come to mind.

First, I don't believe that NetBSD supports Strong ES right now. So it is=
=20
a bit of a race as to which patch comes in first. I say that cautiously,=20
but we really need to see code to be able to judge the relative impacts of=
=20
changes.

Second, I'm not 100% sure how this will break Strong ES. I expect if we=20
add Strong ES support, we will have some sort of sysctl to control it.=20
Given that, I'd expect any of these changes could (actually should)=20
likewise be conditional on said sysctl, just in the opposite sense; these=
=20
things would be turned off if not appropriate.

Third, I'm not sure if it's really a Weak ES vs Strong ES model issue, as
I understood them to be different ways of handling multi-homed hosts. But
the issue of this discussion comes up in a single-NIC system. Consider the
following case:

We have one NIC with two IP addresses & netmasks:

10.0.0.2/255.255.0.0
172.26.0.18/255.255.255.240

I think the whole crux of this discussion is which of the two addresses do=
=20
you choose if you want to talk to something not on either net. Say=20
204.152.190.12 (www.netbsd.org) or 172.26.2.15 or 192.168.9.5 or 10.3.4.5.

One answer (which I wanted back when Zembu was around)is that 172.16/12=20
and 192.168/16 would use 172.26.0.8 and everything else would use=20
10.0.0.2. But that was me at that time.

> 3. It's a grody special-case hack. Special-purpose hacks aren't what
> we do: ``no code before its time''. In fairness, this is not entirely
> independent from #1. If you wish you could float the idea in a
> suitably-qualified audience, say e2e, e2e and see what it gets you.
> But please, please, don't mention my name.

I agree that the problem has been specified in ways that will most-likely=
=20
lead to a gross hack. However we don't have diffs yet, so we may yet be=20
pleasantly surprised. Also, this discussion may well lead us to a solution=
=20
that isn't a special-case hack.

Take care,

Bill

--Jl+DbTnyraiZ/loT
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFCaaTgWz+3JHUci9cRAip9AJ0S82yNaVenQ0dgy63yIzNFAhH4lACcCvpk
s8tdz5F1LNde8dF6C3lcqcc=
=UWaE
-----END PGP SIGNATURE-----

--Jl+DbTnyraiZ/loT--