[100275] in North American Network Operators' Group
Re: Some thoughts on 240/4
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Sat Oct 20 19:20:29 2007
Date: Sat, 20 Oct 2007 19:18:30 -0400
From: Leo Bicknell <bicknell@ufp.org>
To: nanog@nanog.org
Mail-Followup-To: nanog@nanog.org
In-Reply-To: <6017.1192814597@turing-police.cc.vt.edu>
Errors-To: owner-nanog@merit.edu
--huq684BweRXVnRxX
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In a message written on Fri, Oct 19, 2007 at 01:23:17PM -0400, Valdis.Kletn=
ieks@vt.edu wrote:
> The fun is trying to prove you in fact nailed *every* reference. Notice
> the mention today of an Ubuntu box that had different results for adding
> a route and binding an IP to an interface. Obviously, it's more than a
> one-line tweak, it's a one-line tweak in an unknown number of places.
This depends highly on your OS and the quality of your previous code.
Now that I'm back at my home computer, I was able to find the FreeBSD
patch (and, I'm actually fairly sure there's a more offical one,
from a FreeBSD core team member floating around now), which I don't
think has been circulated before. I posted it originally on the
ARIN PPML mailing list, and Mr Vixie made a small correction.
My post: http://lists.arin.net/pipermail/ppml/2007-May/006865.ht=
ml
Vixie's correction: http://lists.arin.net/pipermail/ppml/2007-May/006866.ht=
ml
And actually, after reflection with some other people I think the
correct thing to do is keep the IN_EXPERIMENTAL macro as is, and
make IN_BADCLASS return 0.
Some people have been looking at FreeBSD and this fixes the kernel
and virtually all of the OS utilities (I won't say all, because I
don't know that they have all been tested).
But back to your original response. I find it offensive to suggest
this should make IPv6 features "slip". If this change impacts
time lines for a vendor I would expect they would pull something
much less important than IPv6 support in order to make it happen.
The better a job a vendor has done doing things like the FreeBSD
folks have with macros and the like, the simpler the change is to
make.
What we need in this case is for vendors to make the change sooner
rather than later, so we have a high probability of having it when
we need it. While the resource impact is not zero, I strongly
suggest that sending a message to a vendor that we're willing to
wait years for this change, or that they can put off supporting
IPv6 if they offer up this feature is the wrong message to send to
vendors.
They need to follow their internal processes, change it, and do it
right. There's no excuse in this case for that to have impact on
major features like IPv6 support; and only minimal excuse for it
to impact minor features. This change has no impact on IPv6, so they
should be able to do this in parallel with different resources.
If we want to be ready when the time comes we all need to send the
right messages to our vendors. Pick the time line your comfortable
with, 3 months; 6 months; a year and tell them after that you won't
purchase code without this fix. My point here is that when you
pick that time line don't feel bad for your vendor giving them 6 or
12 months, it's plenty of time to do the work at hand.
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
--huq684BweRXVnRxX
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)
iD8DBQFHGozGNh6mMG5yMTYRAmmKAKCChiuYj6Ka1iWhfA760llE9keBigCcD6iO
gzku4cpNVUrm7ARj47NlT0c=
=AJON
-----END PGP SIGNATURE-----
--huq684BweRXVnRxX--
