Why would you use IPv6 internally?
Solution 1:
There is no NAT for IPv6 (as you think of NAT anyway). NAT was an $EXPLETIVE temporary solution to IPv4 running out of addresses (a problem which didn't actually exist, and was solved before NAT was ever necessary, but history is 20/20). It adds nothing but complexity and would do little except cause headaches in IPv6 (we have so many IPv6 Address we unabashedly waste them). NAT66 does exist, and is meant to reduce the number of IPv6 addresses used by each host (it's normal for IPv6 hosts to have multiple addresses, IPv6 is somewhat different than IPv4 in many ways, this is one).
The Internet was supposed to be end-to-end routable, that is part of the reason IPv4 in invented and why it gained acceptance. That is not to say that all address on the Internet were supposed to be reachable. NAT breaks both. Firewalls add layers of security by breaking reachability, but normally that it's at the expense of routability.
You will want IPv6 in your networks as there is no way to specify an IPv6 endpoint with a IPv4 address. The other way around does work, which enables IPv6-only networks using DNS64 and NAT64 to access the IPv4 Internet still. It's actually possible today to ditch IPv4 all together, though it's a bit of hassle setting it up. It would be possible to proxy from IPv4 internal addresses to IPv6 servers. Adding and configuring a proxy server adds configuration, hardware, and maintenance costs to the network; usually much more than simply enabling IPv6.
NAT causes it's own problems too. The Router has to be capable of coordinating every connection running through it, keeping track of endpoints, ports, timeouts, and more. All that traffic is being funneled through that single point usually. Though it's possible to build redundant NAT routers, the technology is massively complex and generally expensive. Redundant simple routers are easy and cheap (comparatively). Also, to re-establish some of the routability, forwarding and translating rules have to be established on the NAT system. This still breaks protocols which embed IP addresses, such as SIP. UPNP, STUN, and other protocols were invented to help with this problem too - more complexity, more maintenance, more that could go wrong.
Solution 2:
Running out of internal (rfc1918) ipv4 addresses can also be a very valid reason to go ipv6.
Comcast explained at Nanog37 why they were going ipv6 for their management addresses.
20 Million video customer
x 2.5 STB/customer
x 2 ip addresses/STB
--------------------
= 100 Millions IP addresses
And this is only for video, not data/modems.
They exhausted the RFC1918 pools in 2005. Then they used public addresses pools (as nat isn't an option for management), and went ipv6 to solve their needs.
Solution 3:
Couple of reasons:
IPv6 doesn't support broadcasting. It is replaced with multicasting. Broadcasting enables one node to send traffic to all nodes on a subnet. Management of broadcast domains is a major issue with keeping large IPv4 networks running fast and smoothly. Multicasting requires that nodes that want to receive "broadcast"-style actually "sign-up" for it, so the network isn't flooded with traffic that hits all hosts.
IPv6 supports IPsec style encryption natively.
IPv6 supports autoconfiguration. It's possible for hosts behind a router to configure themselves without the need for DHCP, although you still need a DHCP server to hand out DHCP options such as DNS server, TFTP server, etc.
Solution 4:
My old job, at a large University, would use an IPv6 allocation internally. They were assigned an IPv4 /16 back in the day and even today is passing out IPv4 addresses to nearly every internal client. The RFC1918 networks were restricted to the telecom-only network and certain specialized usages (the PCI standards required RFC1918 usage until October 2010).
Because of this, they were actively planning to use IPv6 internally as well. There were some hardware issues still to work out, the edge switches weren't supporting v6 well enough, but the core was ready. The idea was that getting v6 support at the publicly visible end (okay, the publicly responsive end) of the network would involve 70% of the work to deploy it to everyone, may as well do the extra 30% and go end-to-end with it.
Having lived with a public IP allocation for so long, our people were very aware of the adage: "just because it is public, does not mean it is reachable." As Chris S said, routeable does not imply reachable.
That is why at least one class of organization would deploy IPv6 internally: because they're already using non-RFC1918 IPv4 internally.
Solution 5:
Working for a small company I can only think of reasons NOT to use IPv6.
- We don't even have an IPv6 public address, so why on Earth would we run it internally?
- We would have to replace our firewall, which I love dearly, as it doesn't (yet) support IPv6
- We don't have a way to assign, let alone control, IPv6 addresses
- Only half of our PCs supports IPv6
- None of our manufacturing plant supports IPv6
- Our switches don't support IPv6
- I've never even seen a printer that supports IPv6
- IPv6 is much harder to use from the command line - pretty important point for me
- I would need to get fully up to speed on IPv6 - hard to do when I'm uninterested
- ... and a whole lot of other reasons I can't think of just now
It just doesn't make sense for a company like ours to make the change, as it would take considerable expense and effort with absolutely nothing to gain from it.
Quite frankly, I like NAT and the benefits we get from dealing with local addresses. If it ever becomes necessary (as opposed to being a geek want-to-do) for us to interact with IPv6 on the Internet we'll do so at the gateway.
I'm not expecting this current IPv6 fad to become a necessity for the very vast majority of the world, internally at least, for a decade or more. As I expect to be retired by then there's not a whole lot of incentive for me personally to waste time and effort on it.
Edit:
I'm getting downvotes but not a single logical and sensible opposing view. Makes me think it's just a bunch of bandwagon jumping geeks who want to follow the trend without thinking about it. There has to be a REASON to make such a drastic change to a network and I don't have one. Further, I strongly suspect only a very few SF users do have one.