[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
What Should an Engineer Address when 'Selling' IPv6 to Executives?
On 3/5/2013 7:15 PM, Owen DeLong wrote:
> On Mar 5, 2013, at 6:46 PM, Mukom Akong T. <mukom.tamon at gmail.com> wrote:
>> On Wed, Mar 6, 2013 at 12:34 AM, Mike. <the.lists at mgm51.com> wrote:
>>> I would lean towards
>>> f) Cost/benefit of deploying IPv6.
>> I certainly agree, which is why I propose understanding you organisation's
>> business model and how specifically v4 exhaustion will threaten that. IPv6
>> is the cast as a solution to that, plus future unknown benefits that may
>> result from e-2-e and NAT elimination.
>> I have no clue how to sell 'benefit' of IPv6 in isolation as right now even
>> for engineers, there's not much of a benefit except more address space.
> I'm not so sure about that?
> Admittedly, most of these are too technical to be suitable for management consumption, but:
> 1. Decreased application complexity:
Yeah. After IPv4 goes entirely away. Which is a long, long, LONG time
from now. Until then...
> Because we will be able to get rid of all that NAT traversal code,
> we get the following benefits:
No, we keep the NAT traversal code.
> I. Improved security
> A. Fewer code paths to test
And now we have to test end-to-end IPv4-IPv4 (with and without NAT),
IPv4-IPv6 through relays, IPv4-IPv6 in the presence of NAT64, IPv6-IPv6,
at the very least.
> B. Lower complexity = less opportunity to introduce flaws
> II. Lower cost
> A. Less developer man hours maintaining (or developing) NAT traversal code
Nope. All the same man-hours plus all the NAT64/DNS64 cases need to be
covered, plus any other transition technologies that get popular
(DS-Lite, 6RD, etc.) and screw with NAT traversal *plus* all the extra
work required to operate in certain CGN environments which may become
even more common than IPv6 in some place.
> B. Less QA time spent testing NAT traversal code
See above about all the interworking cases.
> C. No longer need to keep the lab stocked with every NAT implementation ever invented
Nope, now you also need to buy all the much more expensive gear to test
CGN, NAT64, DS-Lite, 6RD, and any number of other transition/customer
> 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:
Assuming NAT66 isn't mandated in some environments for "security"... but
even so, none of these benefits apply in the customer NAT, CGN, or NAT64
> I. Improved Security
> A. Harder for attackers to hide in anonymous address space.
What?!? It is much easier for attackers to rotate addresses when IPv6 is
> B. Easier to track down spoofing
Don't see how. (See below). (Never mind that BCP38 should have prevented
this long ago)
> C. Simplified log correlation
Yes, if only you didn't also have to do it for all the CGN and NAT64 cases.
> D. Easier to identify source/target of attacks
Again, I doubt it. Identifying the single IP address assigned to a
customer who has an on-premise NAT appears to be just as easy/hard as
identifying the block of IP addresses assigned to a customer running
IPv6. And for privacy reasons, end-user hosts won't have stable
addresses within that block any more than port numbers are stable on the
outside of a NAT in the IPv4 case.
> II. Simplified troubleshooting
> A. No more need to include state table dumps in troubleshooting
Not true. Lots of failure cases will still involve firewall
configuration... tracking down the "my SIP phone registers but RTP
doesn't work but only when I receive calls, not when I send calls" is
identical in the IPv4 and IPv6 stateful firewall cases.
> B. tcpdump inside and tcpdump outside contain the same packets.
Unless you have almost any firewall, which will be adjusting all sorts
of things for you.
> Finally? There are 7 billion people on the planet. There are 2 billion currently on the internet.
> The other 5 billion won't fit in IPv4. If you want to talk to them, you'll need IPv6.
Or a very big CGN.
> It doesn't matter how many IPv4 addresses you have. What matters is how many people/places/things you want to reach or you want to be reachable from that don't have any. Today, that's a small number, but it's growing. The growth in that number will only accelerate in the coming years.
This is the actual argument. IPv6 must be supported because as the
Internet grows, it will get to the point where some of it MUST be
IPv6-only. Unfortunately there will be a long time in the interim where
you need to do more than 2x the work you are doing now in the
IPv4+end-user-NAT Internet we currently have.
Trying to sell this to smart engineers writing code or testing it as
"less work" is just going to get you laughed out of the room as the
crazy IPv6 zealot.