We've rolled out about 12 million nodes on IPv6, over 300 customer /48 networks, and about 6,000 individual /64 subnetworks. 99% of those have been RFC 4193 Unique Local IPv6 Unicast addresses.

IPv6 is like a breath of fresh air when it comes to setting up address spaces. For the past 10 years as a network engineer, three overriding issues have existed when setting up new networks. (1) Begging ARIN for a /19 or /20 when setting up a major new network, (2) Constantly having to have a CIDR calculator running in my head when trying to figure out where the usable hosts/broadcast/network/gw live for the various /29s, /28s, /27s/ /26s, (3) Dreading having to communicate with a new partner or customer also in RFC 1918 space (because of the odds of an address conflict), and/or adding NATing so that we can do a hand off in public space.

With IPV6 - all of those issues are gone. Every subnetwork is always a /64 - CIDR is basically gone. Also, because RFC 4193 is so large (FC::/7, though, for local assignment, it's always FD::/8) - we for all practical purposes never have to worry about negotiating with partners.

Our "Addressing Strategy" is as follows:

For a new customer, Randomly generate, following the guidance of RFC 4193, a /48. Then, for all of their subnetworks, just increment by one. I.E. A customer might get FDC2:D343:107F::/48, and their first subnetwork in that range would be, FDC2:D343:107F:1::/64

For our own IPv6 space, we occasionally play stupid aggregation games, just to keep our routing tables a little more dense - aggregate on ::/56 boundaries - I.E. If we have a new data center with a bunch of subnetworks in our FD1B:D2C5:6AB3::/48 space, we might assign it to be FD1B:D2C5:6AB3:0100::/56, and then we have 255 subnetworks, FD1B:D2C5:6AB3:0100::/64 - FD1B:D2C5:6AB3:01FF::/64) that we work with.

About the only problem with IPv6, is that they make it difficult for you to get your own provider independent globally routable address space that you can advertise out via BGP. So, for instance, a company can't just (easily) get some address space and advertise it out through the internet - the powers that be want you to get a subnetwork out of your ISPs /32. As a result, we ended up just doing everything in RFC 4193, and, using a relative handful of "globally routable" IPv6 hosts for communicating on the internet from our ISPs /32 space. Our ISP gave us a globally routable /48, and we use about 12 hosts addresses from its possible 2^80 possible addresses. Talk about sparse utilization!

Eventually, as more IPv6 hosts land on the internet, and we want to communicate to them from inside our network, we'll probably just add a IPv6-to-IPv6 Network Prefix Translation (NPTv6), or, more likely, an IPv6 NAT system.

NAT has become so embedded in the Enterprise, and provider independent globally routable addresses assigned to companies so difficult to get, that, the globally routable space will ironically be used for fewer IPv6 hosts in many cases, than it was for IPv4 hosts in many cases.

I realize that this is very controversial, and contrary to what every IPv6 IETF network designer/architect/RFC writer wants to hear, but, in talking with the dozen or so colleagues that I have who are also deploying IPv6, it's seems to be the consensus. NAT has been used for so long, by so many network engineers, that non-routability internal space has become our "goto" strategy for the second layer of defense. (With stateful firewalls, of course, always, always being the first layer)

Indeed, when we tried to move a bunch of our applications to Amazon, they indicated that they were only supporting IPv6 for limited interaction on the internet, and that they weren't supporting IPv6 for their internal networks - really embedding the Proxy/NAT concept for AWS applications. Which is a shame, because we'd love to move a lot of our IPv6 applications into AWS.