What Should an Engineer Address when 'Selling' IPv6 to Executives?

Tue Mar 12 17:05:34 UTC 2013

Dual stack is a (very) temporary solution while waiting for some others to catch
up and deploy IPv6. Contemplating dual-stack as a permanent or long-term
solution ignores the extent to which IPv4 is utterly unsustainable at this point.

Owen

On Mar 12, 2013, at 02:45 , kpospisek at bigpond.com wrote:

> 
> I would be concerned in strongly spruiking advantages of IPv6 to
> executives if an IPv6 dual stack solution is actually being deployed.
> (ie. some given IPv6 SS advantages below do not apply to IPv6 DS)
> 
>> 	1.	Decreased application complexity:
>> 			Because we will be able to get rid of all that NAT traversal code,
>> 			we get the following benefits:
>> 
>> 			I.	Improved security
>> 				A.	Fewer code paths to test
>> 				B.	Lower complexity = less opportunity to introduce flaws
>> 			II.	Lower cost
>> 				A.	Less developer man hours maintaining (or developing) NAT traversal code
>> 				B.	Less QA time spent testing NAT traversal code
>> 				C.	No longer need to keep the lab stocked with every NAT implementation ever invented
>> 				D.	Fewer calls to support for failures in product's NAT traversal code
>> 	2.	Increased transparency:
>> 			Because addressing is now end-to-end transparent, we gain a
>> 			number of benefits:
>> 
>> 			I.	Improved Security
>> 				A.	Harder for attackers to hide in anonymous address space.
>> 				B.	Easier to track down spoofing
>> 				C.	Simplified log correlation
>> 				D.	Easier to identify source/target of attacks
>> 			II.	Simplified troubleshooting
>> 				A.	No more need to include state table dumps in troubleshooting
>> 				B.	tcpdump inside and tcpdump outside contain the same packets.
>> 
> 
> 
> There are two well documented advantages to IPv6 dual stack:
> 
> - responding to customers requesting IPv6 dual stack connectivity
> - excellent access to the IPv4 network
> 
> IPv6 is a *different* network to IPv4 even if both networks happen to be
> carried on the same platforms (thank you Cisco, F5, Juniper etc -
> without this, our execs would be seriously baulking at having to replace fairly
> modern hardware).
> 
> I have also noticed examples given of historic protocol changes. Not all of
> these are relevant as some of them only involved "middle" OSI layers, so
> do not apply very well to the IPv6->IPv6 transition.
> 
> 
> Greets
> Engineer Karl Pospisek (alias kpospisek at telstra.com)