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