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

[Matthew Kaufman <matthew () matthew at>]

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:
>
> > On Wed, Mar 6, 2013 at 12:34 AM, Mike. <the.lists () 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

See above.

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

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

Doubt it.

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

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

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

Matthew Kaufman