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

Owen DeLong owen at delong.com
Wed Mar 6 04:20:52 UTC 2013


On Mar 5, 2013, at 7:55 PM, Matthew Kaufman <matthew at matthew.at> wrote:

> 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…
> 
I don't think so. I think IPv4's demise as a supported internet protocol is certainly less than 10 years away and likely less than 5. I say this because IPv6 deployment is a bit of a variable here and we're faced with one of two outcomes as a result:

	1.	IPv6 deployment continues to accelerate and achieves relative ubiquity before IPv4 becomes
		completely unsustainable. In this case, IPv4 will be gracefully, but rapidly decommissioned
		because of the extreme costs involved in keeping it running vs. the limited benefit of doing so.

		Sure, there will be isolated pockets of IPv4 for a very long time, but application developers will
		stop supporting IPv4 NAT traversal in new products or new product updates fairly soon after
		this point. In this case, we're probably looking at around 5 years.

or

	2.	IPv6 deployment doesn't reach relative ubiquity before IPv4 becomes utterly unsustainable.
		We scramble to simultaneously shore up IPv4 as best we can will deploying IPv6 in a
		complete panic. There is widespread disruption, costs are high, reliability is low for several
		years, pretty much the worst case scenario. In this case, it's probably about 8 years before
		we completely splatter against the wall with IPv4 and another 2 years of scrambling to
		deploy the rest of IPv6.


>> 			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.
> 

Why? I doubt any software vendor will continue to maintain NAT traversal code much after IPv4 is no longer the common inter-domain protocol of choice.

>> 
>> 			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.

Only for a couple of years. Once IPv4 disappears from the inter domain world, which will happen fairly quickly, I think you'll see little or no focus on these areas and support for most of them will be mothballed.
> 
>> 				B.	Lower complexity = less opportunity to introduce flaws
> 
> See above.

See above debunking of the flawed assumptions.

> 
>> 			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.

Nope… Maybe for a very short period of time, but precisely because IPv4 no longer provides benefit, only cost at this point, it will be rapidly decommissioned at least from the inter-domain world. In the intra-domain world, NAT traversal is mostly not relevant. Almost certainly not relevant enough to garner continuing support from ISVs.

> 
>> 				B.	Less QA time spent testing NAT traversal code
> 
> See above about all the interworking cases.

See above about why nobody is actually going to be that dumb.

> 
>> 				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 deployment models.

Nope… See above.

> 
>> 				D.	Fewer calls to support for failures in product's NAT traversal code
> 
> Doubt it.

Doubt it all you want. Once it's gone, it stops generating support calls, or they become very short:

C: "Hi, my application isn't working through my NAT."
TSR: "Hi… Get IPv6, we don't support NAT any more."
TSR: "Is there anything else I can help you with today?"

> 
>> 	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 cases.

Even if it is, at this point, I doubt it will be a sufficient critical mass of environments to drive ISVs to provide special support for it. As such, those few institutions will probably change fairly quickly.

The customer NAT, CGN, and NAT64 cases are not likely to exist by then. See above.

> 
>> 
>> 			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 widely available.

Yes, but their prefix isn't anonymous and they have a hard time getting outside of the prefix.

> 
>> 				B.	Easier to track down spoofing
> 
> Don't see how. (See below). (Never mind that BCP38 should have prevented this long ago)

1.	You don't have to compare 701 against 9,000,000 prefixes in the routing table looking for
	the one that's getting spoofed.

2.	RIR records will be more accurate because there is no legacy space.

> 
>> 				C.	Simplified log correlation
> 
> Yes, if only you didn't also have to do it for all the CGN and NAT64 cases.

Which won't last long.

> 
>> 				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.

NAT will most likely become a thing of the past. I know you prefer to remain in denial about this, but more and more of the ISVs I have talked to are saying that they have no intention of adding NAT traversal to their IPv6 code.

> 
>> 			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.

Sure… I meant that you don't need to dump the state table to identify that the packet from 192.0.2.123:1234 to 204.81.221.6:80 is the same packet as the one on the inside from 192.168.5.6:9321 to 204.81.221.6:80.

> 
>> 				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.

The firewall shouldn't be adjusting the packet. I'm not sure why you think it would or what adjustments you think it would be making.

> 
>> 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.

If you think this will actually scale and provide a user experience that will be considered at all acceptable, then you are delusional.

> 
>> 
>> 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.

I don't think that's actually true. I think that the economic incentives to drop IPv4 support from the inter domain world as soon as possible will apply strong pressure to expedite this process once IPv6 achieves a certain level of critical mass.

> 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.

Actually, smart engineers realize that in the long run it's a lot less work. That there's a brief period where it's way more work followed by a much better long-term. I'll leave off the obvious question about how smart can engineers be if they built an application in the 90s that was as strongly tied to unistack as Skype is when it was obvious that unistack IPv4 was a very temporary phenomenon.

Owen





More information about the NANOG mailing list