Subject: Re: default route and private networks 
In-reply-to: Your message of "Fri, 22 Apr 2005 18:29:04 PDT."
             <20050423012904.GL12650@netbsd.org> 
--------
In message <20050423012904.GL12650@netbsd.org>Bill Studenmund writes


[...]


>Given that, when they looked at how to fix it, they found that IPv6 has a
>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.

Well, its nto clear to me whether the observation of how IPv6 works
came before or after the idea to break IPv4.

Whichever order it went, the fallacy here is to try to retroactively
force IPv4 semantics onto IPv6.  The folks committing that error may,
until now, have had not know that was an error; but it *is* an error.
(in other words, they've lost ignorance as a defense, and will have to
fall back to stupidity.)


>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
>:-)

That is all I see here.  IF IPv4 doens't meet their pet needs: sorry,
but tough. More on that later.  



>> 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. 

No, but I have code that does. 

>=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.

Nope. I state again, for for the record: the proposed change is
*broken*. It should not be committed. If it is committed anyway, I
fully intend to back it out as breaking Strong-ES as described in
RFC-1122.  On that, you can fairly call me being rigid.