[ppml] 240/4

In a message written on Fri, May 04, 2007 at 02:15:52PM +0000, vixie at vix.com wrote:
> > *** /usr/src/sys/netinet/in.h.orig      Fri May  4 08:58:10 2007
> > --- /usr/src/sys/netinet/in.h   Fri May  4 08:58:38 2007
> > ***************
> > *** 341,349 ****
> > - #define       IN_EXPERIMENTAL(i)      (((u_int32_t)(i) & 0xf0000000) == 0xf0000000)
> > - #define       IN_BADCLASS(i)          (((u_int32_t)(i) & 0xf0000000) == 0xf0000000)
> 
> you can't remove these macros.  just make them always-return-zero.

I realized after the fact that making these return 0 always is
probably a better (short term?) solution.  Although grep showed
that FreeBSD's /kernel/ didn't use them anywhere else, user land
utilities and third party programs may use those macros.  Making
them return 0 will "fix" all of those problems with a simple
recompile.

Perhaps best of both worlds, is return 0 with a compile time warning
pointing to the new RFC.

So yes, the vendors need to get the appropriate developers in the
room, decide on an approach, and fix the code.  However, the code
fix should be trivial for this one.

Least you mistake the vendors hesitation, let me also explain their
real motivation.

Deploying IPv6:

1) On "newish" hardware, it's simply a code upgrade.  Generally
   covered under existing support contracts, with no incremental
   revenue.

2) On "old" hardware, IPv6 isn't useful, as you loose hardware
   acceleration if it can run v6 code at all.  This means you buy
   a new router, the vendor gets incremental hardware revenue.

Deploying the IPv4 Patch:

1) On all hardware, ship a new image.  Generally covered under
   existing support contracts with no incremental revenue.  Plus,
   given there will be a time when both old and new code is in
   production, they will have to take support calls (also no
   incremental revenue) on people doing dumb things that don't work.

Even though this is a one or two line change for the vendor, and
the cost to write the patch is as close to zero as they get, there
are costs to support it with zero offset in incremental revenue.

With IPv6, the costs are higher, but they are offset with incremental
revenue which also has the nice side effect to deploying newer
hardware that's easier to support, and enables upsale to other
services.  There's lots of incremental revenue to go after.

And that's the real story why the vendors want you to believe this is
"hard".

-- 
       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://lists.arin.net/pipermail/arin-ppml/attachments/20070504/8920f2b6/attachment.bin