Some thoughts on 240/4

Sat Oct 20 23:18:30 UTC 2007

In a message written on Fri, Oct 19, 2007 at 01:23:17PM -0400, Valdis.Kletnieks at 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.html
Vixie's correction: http://lists.arin.net/pipermail/ppml/2007-May/006866.html

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.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20071020/94615e8b/attachment.sig>