[161246] in North American Network Operators' Group
Re: What Should an Engineer Address when 'Selling' IPv6 to Executives?
daemon@ATHENA.MIT.EDU (Owen DeLong)
Tue Mar 5 23:28:38 2013
From: Owen DeLong <owen@delong.com>
In-Reply-To: <5136BE2C.3060804@matthew.at>
Date: Tue, 5 Mar 2013 20:20:52 -0800
To: Matthew Kaufman <matthew@matthew.at>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Mar 5, 2013, at 7:55 PM, Matthew Kaufman <matthew@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@gmail.com> =
wrote:
>>=20
>>> On Wed, Mar 6, 2013 at 12:34 AM, Mike. <the.lists@mgm51.com> wrote:
>>>=20
>>>> I would lean towards
>>>>=20
>>>> f) Cost/benefit of deploying IPv6.
>>>>=20
>>> 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.
>>>=20
>>> 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=85
>>=20
>> Admittedly, most of these are too technical to be suitable for =
management consumption, but:
>>=20
>> 1. Decreased application complexity:
>=20
> Yeah. After IPv4 goes entirely away. Which is a long, long, LONG time =
from now. Until then=85
>=20
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:
>=20
> No, we keep the NAT traversal code.
>=20
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.
>>=20
>> I. Improved security
>> A. Fewer code paths to test
>=20
> 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.
>=20
>> B. Lower complexity =3D less =
opportunity to introduce flaws
>=20
> See above.
See above debunking of the flawed assumptions.
>=20
>> II. Lower cost
>> A. Less developer man hours =
maintaining (or developing) NAT traversal code
>=20
> 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=85 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.
>=20
>> B. Less QA time spent testing NAT =
traversal code
>=20
> See above about all the interworking cases.
See above about why nobody is actually going to be that dumb.
>=20
>> C. No longer need to keep the lab =
stocked with every NAT implementation ever invented
>=20
> 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=85 See above.
>=20
>> D. Fewer calls to support for =
failures in product's NAT traversal code
>=20
> 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=85 Get IPv6, we don't support NAT any more."
TSR: "Is there anything else I can help you with today?"
>=20
>> 2. Increased transparency:
>> Because addressing is now end-to-end =
transparent, we gain a
>> number of benefits:
>=20
> 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.
>=20
>>=20
>> I. Improved Security
>> A. Harder for attackers to hide in =
anonymous address space.
>=20
> 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.
>=20
>> B. Easier to track down spoofing
>=20
> 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.
>=20
>> C. Simplified log correlation
>=20
> Yes, if only you didn't also have to do it for all the CGN and NAT64 =
cases.
Which won't last long.
>=20
>> D. Easier to identify source/target =
of attacks
>=20
> 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.
>=20
>> II. Simplified troubleshooting
>> A. No more need to include state =
table dumps in troubleshooting
>=20
> 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=85 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.
>=20
>> B. tcpdump inside and tcpdump =
outside contain the same packets.
>=20
> 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.
>=20
>> Finally=85 There are 7 billion people on the planet. There are 2 =
billion currently on the internet.
>>=20
>> The other 5 billion won't fit in IPv4. If you want to talk to them, =
you'll need IPv6.
>=20
> 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.
>=20
>>=20
>> 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.
>=20
> 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
