Help me design my IPv6 Subnets

[dfcs]

Here is my scenario:

1 Data Center, 3 Servers, 2 Switches, Hyper-V Cluster.
-----------------------------
Current Internal Networks:
         Management
              NAS – iSCSI
         CSV/HeartBeat
         Live Migration
         Private
              Vault

Current External Networks
                   DMZ
------------------------------

This is for my customer who does Managed Software Services.

He is expanding rapidly, so network design with expansion/organization in mind is very important. The plan is to expand to a data center in New York, Europe, Africa, etc.

I just want the prefix designed so that every network is a /64. What do you think is a good organization design  like the example below?

First the assigned /48 prefix (2001:6dc2:abcd::/48) then Region(0:North America),Site(DA:Data Center A/01:Office B),Network(0:Management/1:Vault/2:Public/etc), /64 subnet

(2001:6dc2:abcd:0DA2:/48) = North America Data Center A Public Network

Would it make sense to have separate Regions for private vs public traffic routing? Something like (A:North America Private) vs (0:North America Public) or to just have the private as the network?

By Region:   (2001:6dc2:abcd:ADA0:/48) = North America Private Data Center A Management Network
By Network: (2001:6dc2:abcd:0DA0:/48) = North America Data Center A Management Network (Private)

These are probably bizarre questions because I'm not sure if having IPv6 would change the way we secure certain networks.

Would it be realistic to have a Storage network designed to be opened up for internet routing in the future? A Hyper-V cluster with a shared NAS will eventually run through a switch when we add a third node to the cluster, instead of direct. The plan is to keep it on its own switch that is separate from the internet for security and performance. It seems stupid to allow access to the storage network over the internet for security concerns. However, does IPv6 change how this type of network is designed?

For example if the New York NAS and the Oregon NAS needed to sync for off site backup wouldn't it be ideal to design a privately routed IPv6 network for this traffic?

How will I design my IPv6 networks for syncing active directory over different sites? Wasn't the best practice for IPv4 networks to use site-to-site VPN for a secure link over the WAN? Is this different or the same for IPv6?

I think I'm over-complicating this as I continue to think about a NAT free internet with all devices connected  directly. Perhaps someone can help me clarify my concerns so that I don't go insane  :).

[kasperd]

Who are you getting address space from? Given the size of the assignments I am guessing the address space is provided by the hosting provider. In that case you'll have a separate prefix assigned in each location where you are hosting equipment. So make a plan for that prefix matching your growth plans for that location.

If you have your own address space directly from a RIR and you are announcing that through your hosting provider or if you are letting the hosting provider address it for you, then not much will change. You just have to make sure that the sizes of the prefixes that you announce are short enough that they will be accepted upstream. I don't know what the threshold is. With IPv4 anything longer than a /24 is frowned upon. With IPv6 a /32 or shorter is definitely ok to announce. I don't know if announcing prefixes longer than a /32 is accepted by upstreams. Announcing /48s into the global routing table sounds like a bad idea, and will probably get filtered.

If you have a /32 and split it into for example a /40 for each location where you are hosting equipment, but still announce the entire /32 in each location, then it becomes your responsibility to get the packets between those locations. That means you can only do that if you have your own links between those locations.

If you don't plan to run a global network yourself each location will need a prefix to be announced from that location. And that means there won't be any benefit in allocating those prefixes out of a common shorter prefix. So the idea of getting a short prefix and subdividing it into longer prefixes for each location is a no-go, if you don't intend on building a network between them. Instead get a prefix in an appropriate way for each location. There is nothing wrong with getting a prefix from each RIR, if you are hosting equipment in different regions.

As for VPN between the sites, the security reasoning is the same as it was with IPv4. With IPv4 it was sometimes used with private addresses inside VPN connections, simply because you didn't have enough IPv4 addresses. With IPv6 you won't have that problem, so you can very well use globally routable addresses inside your VPN connections. However if you are worried about accidentally routing between the sites without using the VPN or breaking the network by introducing cyclic dependencies with encapsulated packets being routed back into the VPN, then use private addresses for the VPN on IPv6 as well.

Private addresses in IPv6 comes in blocks of /48, so if your allocation from a hosting provider is a /48 or longer, you can assign the exact same structure to internal and external addresses.

For example one hosting provider assign you 2001:db8:1::/48 and another assign you 2001:db8:2::/48, then you generate local prefixes fd67:bbb5:0c0f::/48 and fde6:0205:b8c5::/48. That means an interface assigned address 2001:db8:1:xxxx::yyyy is also assigned fd67:bbb5:0c0f:xxxx::yyyy and an interface assigned address 2001:db8:2:zzzz::wwww is also assigned fde6:0205:b8c5:zzzz::wwww. Then you just need to setup a VPN connection to route between fd67:bbb5:0c0f::/48 and fde6:0205:b8c5::/48. So You'll have global IPv6 addresses in the outer IPv6 header and RFC 4193 addresses in the inner IPv6 header.