In a message written on Fri, Oct 19, 2007 at 01:23:17PM -0400, Valdis.Kletnieks@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@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org