Subject: Re: (Somewhat OT) Re: INET6 in GENERIC
To: J. Scott Kasten <jscottkasten@yahoo.com>
From: Thomas E. Spanjaard <tgen@netphreax.net>
List: tech-net
Date: 02/23/2006 01:01:10
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigCF5C653AEB48E106C7F41D92
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

J. Scott Kasten wrote:
> On Wed, 22 Feb 2006, Thomas E. Spanjaard wrote:
>> However, besides the address space 
>> exhaustion issue present in the rest of the world, IPv6 has other 
>> merits as well, which are a real tangible benefit to all of us (some 
>> related to the huge address space, like simple prefix routing because 
>> there's so many space). I think these merits are underlit currently.
> Routing, standardized IPSec, QOS, etc...  Many benefits besides just 
> more addresses.

Indeed. :)

>> Then, there's the booming internet media distribution market, which 
>> requires media playback devices to have access. With that, there's 
>> numbers of those 'business opportunities' that will thrive only if the 
>> Internet can sustain the number of devices connected. It's easy to see 
>> the 32-bit IPv4 address
> And that is precisely where the argument fails with most managers and 
> executives.  They look at that and ask, "What does that have to do with 
> my product?" (Assume printer, copier, fax, or other appliance.)  It 
> becomes difficult to describe just what the value add is for simple 
> products like that.  

Well, these arguments go for every device that is connected to a network 
that is ultimately connected to a network so large it is not within 
their control anymore, like the Internet, or other large WANs of the past.

> The execs feel like you are talking about the pie 
> in the sky world. They are concerned about whether this is going to 
> bring in additional revenue in the next product release when this is 
> going to add $500,000 to the development cost now.  (Think two 
> developers hacking code for months, a user inteface team spending months 
> figuring out what easy configuration would look like then running teams 
> of people through usability testing, an entire quality assurance team 
> developing new regression tests, and spending months actually testing it.)

The number of $ 0.5 million seems a lot to me, but I guess you have 
experience with that. I'm no corporate guy :). But still, do you think 
the argument still holds that developing for IPv6 now is cheaper than 
stacking hack on hack on hack for the next X years?

>> space won't suffice. Now, there are technologies like NAT, but they're 
>> just a hack on a standard that didn't cater for it. An ugly hack at 
>> that. Now for all those cost-conscious 'decision-makers' out there, 
>> I'd like to ask if it's worth throwing money at making applications 
>> work with NAT each and every time you invent them, now, and in the 
>> future, on a regular basis? Or throw money at a new standard once for 
>> a prolonged period? I think the choice is easy...
> From the technical standpoint, I agree with you totally.  But an 
> executive will "play it safe" by bolting something else on to what he already 
> thinks he has rather than go invent something new.  Product sales is 
> about variations on a theme - you don't mess with something that is 
> already selling well.  NAT, how ever ugly it is, looks like a simple add 
> on to an executive.  He's not the poor network admin that has to spend 
> weeks figuring out how to rebuild the server room to make it work in 
> real life. That's a hidden cost that is not easily measured.

That smells of the often-seen lack of knowledge of manager types 
(Dilbert anyone?).

Thanks for the comments,
-- 
         Thomas E. Spanjaard
         tgen@netphreax.net

--------------enigCF5C653AEB48E106C7F41D92
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (NetBSD)

iD8DBQFD/Qla6xCMwBJ+1+sRA9AtAJ0X754OBpwEwOyQW3xFoRZ8XqTI3gCePydH
GpsVO3zQ+lEoPucTkRIhbfw=
=jXqN
-----END PGP SIGNATURE-----

--------------enigCF5C653AEB48E106C7F41D92--