It frees you from expensive complexities arising from tunneling and private address space. You don't need the network engineering and service costs to bring your private 10.x overlay network to your various datacenters[1] behind different ISPs, you don't have to fight with addressing conflicts when talking to other people using rfc1918 space or debug situations where 1918 addresses are ambiguous, etc. It's cheaper, safer and simpler to integrate with other organizations because you only have to configure your firewall rule instead of trying to mash together incompatible rfc1918 internal networks and overlay technologies in addition to the fw. Your security posture is better and cheaper to maintain because your simpler network is easier to reason about.

[1] meaning your network locations, not your private datacenter (necessarily)

> Could you explain? How does it help to use IPv6 internally if you're using IPv4 publicly?

See this presentation about IPv6 at Facebook: https://www.facebook.com/groups/2234775539/10152303014725540...

> IPv4 offers more than enough address space within its private ranges for your private network

While theoretically true from a raw numbers standpoint, it breaks down at Facebook's scale when you have many gigantic data centers all over the world and start thinking about how you assign the addresses and manage the network that uses them.

As the presentation says, there was lots of wastage due to racks being /24 and clusters being /n (where n < 24).

Assuming you want to provide IPv4 and IPv6 to the outside:

You can relatively easily map IPv4 addresses into IPv6 range: just pick a /96 prefix and append the 32 bit IPv6 address. This is a relatively easy translation, that does not require the machine doing the translation to keep state !!! (so you can send traffic to a random one and it can do the right thing, no need to have connections stick to one). It is thus quite easy to make an IPv6-only network deal with IPv4 clients. With decreasing IPv4 usage, your network naturally adapts since it only becomes easier.

The reverse is not easily possible for serving IPv6 clients from an IPv4 network: you can't map IPv6 1:1 to IPv4, so your gateways have to be more like traditional NAT and keep state tables around, which makes operation in general and load-balancing/fail-over in particular harder. The more and more IPv6 clients you have, the more resources you need for the translation. And at some point in the future, you are going to want to switch.

You could alternatively run your entire DC on IPv4 and IPv6 double-stack, but that adds a lot of unnecessary complexity. Your routers now have to keep routing tables for both around, behavior could differ for both, your applications (logging, fraud prevention, ...) have to understand both, ...

If you are in a position where you control everything you run (so you can make sure there aren't any stragglers that require IPv4 because their vendor doesn't care or something like that), the IPv6 model can be attractive. Do the switch and be done with it for the future, limit your dealings with two protocols to the very edge.

At my company, we used to use IPv6 internally and IPv4 publicly for future proofing and easier migration to a all IPv6 environment. Instead of changing the entire infrastructure we just had to change the gateway.

  > The 10.0.0.0/8 block provides 16 million addresses
  > and there's also 172.16.0.0/12 and 192.168.0.0/16.
  > There are certainly enough addresses in these ranges
  > that running out is not a concern

With the constraints of subnetting, it is a concern. I know a very large telco that ran out of private IPv4 addresses - and that specific issue was the reason for finally launching a proper IPv6 project.

Don't plan on inter-region peering ever shipping. Easy to do in network fabric at a region, not so easy to do across regions (constrained by fiber connectivity).