While forgoing the simplicity which service provider managed addresses afford the provider, allowing the customer to bring their own addressing can greatly simplify the customer’s network configuration. The addresses assigned to workload VMs or load balancing virtual IPs (VIPs) are used directly by remote clients on the customer’s WAN to connect to services within the Org VDC, removing the need for NAT. Some customers consider a third-party data center to be a less trusted environment and might insist on a layer of NAT between the workloads within the data center and their WAN environment. When this is the case, even if the customer provides both the Org VDC network addresses and the NAT range, their configuration is effectively identical to that described in Section 5.1.1, Service Provider Managed Addressing with the exception that they might overlap with addresses used by another tenant or the provider’s management environment.

Workflows which, either at tenant onboarding, or as a “Day 2” action, create new Org VDC networks must assign new address subnets to those networks. To do so, the customer requires an IP addressing schema from which to allocate addresses for use within vCloud Director managed networks. vCloud Director provides an error message if a network is requested with an overlapping address range as shown in the following figure, but the customer or provider creating the network must have access to an appropriate subnet allocation to overcome the error message.

A number of techniques exist for allocating addresses from a larger schema. In some cases, each network subnet must be requested from the schema owner at the point of provisioning. In others, a larger “supernet” range of addresses are allocated by the customer schema owner for use within the provider environment. This allows delegation of management to either the service provider if they are providing a management service, or to the customer solution owner responsible for the workloads in the vCloud Director Org VDCs.