Running servers from several data centers gives a business better geographic reach, redundancy, and network options. It also creates a problem that teams often notice too late: IP address management becomes harder as sites grow.

A weak address plan can create overlapping private networks, scattered IPv4 allocations, difficult BGP policies, IPv6 prefixes with no clear structure, and long migration windows.

A good multi-site IP address plan starts with the network topology. We then divide address space by region, site, network function, and subnet while leaving enough capacity for growth.

IPv4 and IPv6 need different planning methods. IPv4 planning focuses heavily on conserving limited public space. IPv6 planning focuses more on hierarchy, subnet structure, delegation, and aggregation.

For most multi-site hosting environments, the core design should cover:

• regional and site-level allocation
• public and private addressing
• IPv4 conservation
• IPv6 prefix allocation
• route aggregation
• BGP and ASN policy
• IPAM
• DNS and reverse DNS
• BYOIP
• capacity for new sites

A clear plan makes future deployments easier because each new subnet has a logical place in the network.

IPv4 and IPv6 Address Planning at a Glance

IPv4 and IPv6 solve the same basic problem, but the available address space changes the way we plan each protocol.

Planning Area	IPv4	IPv6
Address size	32-bit	128-bit
Address availability	Beschränkt	Extremely large
Main planning concern	Conservation	Hierarchical allocation
Private addressing	RFC 1918	ULA where appropriate
NAT	Common	Usually not required for address conservation
Standard LAN sizing	Based on required hosts	Usually /64
Multi-site design	Careful block allocation	Regional and site prefix hierarchy
Routing	CIDR and BGP	CIDR and BGP
Management	IPAM	IPAM
DNS	A records	AAAA records

IPv6 global unicast addressing supports a structure containing a global routing prefix, subnet ID, and interface ID. This structure makes hierarchical addressing a natural fit for networks spread across several sites. 

Start With the Hosting Topology

Do not start a multi-site addressing project by opening a subnet calculator.

Start with the infrastructure.

Create an inventory of every active and planned hosting location. Record the country, city, data center, upstream network, server count, expected customer count, current IP blocks, routing method, and expected growth.

A simple topology could look like this:

Global Hosting Network

│

├── Europe

│   ├── Amsterdam

│   ├── Frankfurt

│   └── London

│

├── North America

│   ├── New York

│   └── Los Angeles

│

└── Asia Pacific

    ├── Singapore

    └── Tokyo

Each site may contain several separate network functions:

• public server networks
• management networks
• storage
• backup
• virtualization
• database networks
• load balancers
• customer networks
• VPN infrastructure
• monitoring
• transit links

Planning these boundaries first makes subnet allocation much easier.

Build a Regional and Site-Level Address Hierarchy

A multi-site network becomes easier to operate when the address structure reflects the physical or logical network structure.

A practical model is:

Organization → Region → Site → Network Function → Subnet → Host

For example:

Europa

├── Amsterdam

│   ├── Management

│   ├── Public Servers

│   ├── Private Services

│   └── Backup

│

└── Frankfurt

    ├── Management

    ├── Public Servers

    ├── Private Services

    └── Backup

This structure gives network teams an immediate clue about where an address belongs.

It also supports cleaner routing policies. Related networks can stay inside contiguous address blocks instead of being scattered across unrelated prefixes.

Plan IPv4 Address Space Around Limited Supply

Public IPv4 space is limited, so the first goal should be to determine which systems truly need globally routable addresses.

A database server behind an application layer may not need its own public IPv4 address. A management interface usually should not be exposed directly to the public Internet. A public web server, VPN gateway, proxy endpoint, or customer workload may have different requirements.

Separating these workloads reduces unnecessary public IPv4 use.

Separate Public and Private IPv4 Networks

RFC 1918 reserves three address ranges for private networks:

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16

These addresses do not provide direct global Internet routing and are widely used for internal networks. 

For a large multi-site deployment, we could divide a private block by region.

Example:

10.0.0.0/8      Global private allocation

 

10.16.0.0/12    Europe

10.32.0.0/12    North America

10.48.0.0/12    Asia Pacific

Each regional range can then be divided among individual data centers.

The exact prefix lengths depend on network size. The core principle is consistency.

Prevent Overlapping Private Networks

Overlapping RFC 1918 ranges create serious problems once sites need direct connectivity.

Suppose Amsterdam and Singapore both use:

10.10.0.0/16

Connecting the sites through a VPN, private backbone, SD-WAN, or routed tunnel becomes difficult because routers cannot determine which 10.10.0.0/16 network should receive traffic.

Assign unique ranges from the beginning.

This becomes even more useful if the company later connects:

• another cloud provider
• an acquired business
• customer networks
• disaster recovery infrastructure
• office networks
• colocation facilities

Size IPv4 Subnets Based on Real Demand

Avoid allocating a /24 simply because it is familiar.

Estimate the number of required addresses for each network and include capacity for:

• servers
• gateways
• load balancers
• Firewalls
• virtualization hosts
• failover addresses
• future nodes

A small network might need a /28, while a larger customer or server pool may require a /26, /24, or larger block.

Public address pools deserve tighter controls than private space because every unused public IPv4 address carries an opportunity cost.

IPAM should record unused capacity rather than leaving addresses assigned without a documented purpose.

Design IPv6 as a Hierarchy

IPv6 planning should not copy IPv4 conservation habits.

IPv6 gives us enough address space to prioritize readable hierarchy, delegation, clean routing, and long-term growth.

RFC 6177 also makes clear that /48 should not be treated as a mandatory prefix size for every site. Address assignments should match actual and planned network requirements. 

A hosting provider or enterprise may receive a larger IPv6 prefix and divide it by location.

Consider this documentation example:

Organization: 2001:db8:1200::/40

 

2001:db8:1201::/48    Amsterdam

2001:db8:1202::/48    Frankfurt

2001:db8:1203::/48    London

2001:db8:1204::/48    Singapore

2001:db8::/32 is reserved for documentation, so these examples should not be used as real production addresses.

The purpose of the structure matters more than the exact sample prefix.

Understand /48, /56, /60, and /64 Prefixes

Prefix size controls how much IPv6 address space belongs to a network.

Prefix	Number of /64 Networks	Typical Planning Use
/48	65,536	Large site or organizational assignment
/52	4,096	Site or regional subdivision
/56	256	Smaller site or delegated network
/60	16	Small delegated environment
/64	1	Normal IPv6 subnet

IPv6 global unicast architecture uses a 64-bit interface identifier for the standard address format described by RFC 4291. That is one reason /64 remains the normal subnet size for common IPv6 LAN deployments. 

Do not assume every customer, site, or server requires a /48. Prefix assignment should reflect the number of networks needed now and over the next several years. RFC 6177 specifically moved away from a single default size for every end site. 

Divide Each Site by Network Function

Once a site receives an IPv6 block, divide it in a repeatable way.

Example:

Amsterdam: 2001:db8:1201::/48

 

2001:db8:1201:0000::/64    Management

2001:db8:1201:0100::/64    Public servers

2001:db8:1201:0200::/64    Private services

2001:db8:1201:0300::/64    Storage

2001:db8:1201:0400::/64    Load balancers

2001:db8:1201:0500::/64    Customer network

2001:db8:1201:0600::/64    Monitoring

2001:db8:1201:0700::/64    Backup

The numbers are examples, not protocol requirements.

The value comes from having the same pattern at every location.

Frankfurt, Amsterdam, Singapore, and Los Angeles can all use the same subnet ID for the same service class.

That makes troubleshooting easier because network engineers can recognize a subnet’s function without searching through several systems.

Align IPv4 and IPv6 Boundaries Where It Helps Operations

Dual-stack networks are often easier to manage when IPv4 and IPv6 networks represent the same logical segment.

Example:

Web VLAN 120

 

IPv4: 10.20.120.0/24

IPv6: 2001:db8:1201:120::/64

Both prefixes represent the same VLAN and workload group.

This approach can simplify:

• firewall policies
• ACL management
• monitoring
• incident investigation
• network diagrams
• server provisioning

Do not force identical structures if routing or operational requirements make them inefficient. Logical consistency is useful, but address design still needs to match the network.

Plan Route Aggregation Before Address Assignment

IP addressing and routing should be planned together.

If related networks sit inside contiguous prefixes, routers can advertise summarized routes instead of many smaller routes.

Suppose all European sites come from one larger allocation. The network may be able to advertise a regional aggregate internally while still keeping individual site routes inside the region.

Random address assignment removes this option.

Before allocating a new subnet, ask:

• Which region owns this address space?
• Which site owns it?
• Can related routes be summarized?
• Does another site already use part of this range?
• Will this prefix need public BGP advertisement?
• Does the failover design require the prefix somewhere else?

This process reduces routing cleanup later.

Include BGP, ASN, RPKI, and ROA Planning

Public IP planning does not end with subnet allocation.

A multi-site hosting environment may use BGP to announce IPv4 and IPv6 prefixes through one or more upstream networks.

The IP plan should record:

• prefix
• origin ASN
• upstream provider
• announcement location
• backup location
• RPKI status
• ROA authorization
• IRR route object
• routing policy

This becomes especially useful during migrations.

Moving a workload may involve more than changing server addresses. The team may also need to change advertisements, routing authorization, firewall rules, DNS records, and monitoring.

Treat the prefix as an infrastructure asset rather than a number assigned to a server.

Plan BYOIP Before Moving Between Data Centers

Bring Your Own IP, or BYOIP, allows an organization to use eligible IP space with infrastructure outside its original environment.

Before a BYOIP migration, verify:

1. Prefix ownership or authorization
2. Provider prefix-length requirements
3. Origin ASN
4. ROA configuration
5. IRR records where required
6. Existing BGP advertisements
7. Target data center support
8. Cutover sequence
9. DNS dependencies
10. Rollback procedure

One common failure is advertising the same prefix from locations that were never designed to operate as anycast or multi-origin networks.

Routing behavior must be planned before the second announcement goes live.

For global hosting companies, BYOIP also helps separate IP identity from individual server hardware or one specific facility.

Atal Networks supports IPv4/IPv6 services, ASN-related services, dedicated infrastructure, colocation, and BYOIP-focused network configurations across its hosting footprint. About Atal Networks About Atal Networks

Use IPAM as the Source of Truth

A spreadsheet can work for a small network. It becomes risky once several sites, teams, customers, VLANs, and prefixes are involved.

An IP Address Management system should record more than whether an IP is available.

Track fields such as:

Field	Example
Prefix	2001:db8:1201:100::/64
Protocol	IPv6
Region	Europa
Site	Amsterdam
VLAN	120
Purpose	Public web servers
Gateway	Documented in IPAM
ASN	Origin ASN
DNS	Assigned
PTR	Assigned
Status	Active
Owner	Network Operations

The same database should track IPv4.

IPAM should answer three questions quickly:

Who owns this address? Where is it used? Why was it allocated?

If the system cannot answer those questions, address records need work.

Plan DNS With IPv4 and IPv6

DNS should be part of the migration plan rather than an afterthought.

IPv4 services normally use A records.

IPv6 services use AAAA records.

Public hosting environments may also need PTR records for reverse DNS.

Before publishing an AAAA record, confirm that the full service path works over IPv6. RFC 7381 recommends enabling AAAA records as services become IPv6-ready rather than publishing them before the related service works correctly over IPv6. 

Test:

• application response
• firewall policy
• load balancer
• TLS
• monitoring
• upstream routing
• DNS
• IPv6 path
• failover

For migrations, lower DNS TTLs before the planned change where appropriate, then restore normal values after the network has stabilized.

Reverse DNS delegation should also be planned around clean prefix boundaries. RFC 7381 notes that nibble-aligned IPv6 prefixes can simplify reverse DNS delegation. 

Separate Customer, Infrastructure, and Management Address Pools

A hosting network should not treat every server address as part of one large pool.

Keep logical separation between:

• customer services
• hypervisors
• router interfaces
• management
• storage
• monitoring
• Backups
• public services

Address structure can then support routing and security policy.

A management subnet, for example, can have stricter firewall rules than a public web server network.

A customer subnet can have its own routing policy without affecting storage traffic.

This structure also makes incident response cleaner because the address itself provides useful context.

Dual Stack or IPv6-Only?

Many multi-site hosting networks still use dual stack because customers and applications may require both protocols.

RFC 7381 describes the common progression from IPv4-only networks to dual stack and eventually toward IPv6-only operation. 

Model	IPv4	IPv6	Suitable For
IPv4-only	Ja	Nein	Legacy workloads
Dual stack	Ja	Ja	Broad application compatibility
IPv6-only	Nein	Ja	Modern controlled environments
IPv6 with NAT64/DNS64	Translation	Ja	IPv6-first environments accessing IPv4 resources

Dual stack increases operational work because both protocols need routing, firewall rules, monitoring, and troubleshooting.

IPv6-only can reduce dependence on private IPv4 space, but application, provider, customer, and third-party compatibility should be tested first.

Reserve Space for Future Sites

Do not consume an address block simply because unused capacity exists today.

Reserve logical ranges for:

• new data centers
• new regions
• customer growth
• disaster recovery
• acquisitions
• additional VLANs
• cloud connections
• private backbone expansion

RFC 7381 recommends planning IPv6 address space with growth in mind rather than building a plan that soon requires renumbering. 

The same operating principle helps IPv4, although public IPv4 must be allocated more conservatively.

Multi-Site Address Planning Example

Consider a company operating four sites:

• Amsterdam
• Frankfurt
• Los Angeles
• Singapur

A logical plan might look like this:

Site	Private IPv4	IPv6 Site Block	Main Function
Amsterdam	10.16.0.0/16	2001:db8:1201::/48	Europe primary
Frankfurt	10.17.0.0/16	2001:db8:1202::/48	Europe secondary
Los Angeles	10.32.0.0/16	2001:db8:1203::/48	Nord-Amerika
Singapur	10.48.0.0/16	2001:db8:1204::/48	Asia Pacific

Each site could then follow a common internal model:

VLAN 100    Management

VLAN 120    Public servers

VLAN 140    Private services

VLAN 160    Storage

VLAN 180    Backup

The exact prefix sizes should reflect actual requirements. The value of the model is that every site follows the same addressing logic.

Common IP Address Planning Mistakes

Multi-site networks often become difficult to manage because of small design choices made during early deployment.

Avoid these problems:

1. Reusing private IPv4 ranges at multiple connected sites
2. Assigning IP blocks without a regional hierarchy
3. Using public IPv4 for systems that only need internal connectivity
4. Treating IPv6 address space like scarce IPv4 space
5. Giving every IPv6 site the same prefix size without assessing need
6. Allocating networks without considering route aggregation
7. Publishing AAAA records before testing IPv6
8. Ignoring reverse DNS
9. Mixing management and customer networks
10. Keeping no capacity for new locations
11. Allowing undocumented BYOIP advertisements
12. Failing to update ROA or routing records during migration
13. Managing a large network from disconnected spreadsheets
14. Assigning addresses without clear ownership

Good address planning reduces renumbering, routing changes, and migration risk.

Multi-Site IP Address Planning Checklist

Before deploying a new site:

• Inventory existing IPv4 and IPv6 prefixes.
• Map every current and planned location.
• Create regional allocations.
• Create site allocations.
• Separate public and private IPv4 space.
• Assign unique private ranges.
• Build an IPv6 hierarchy.
• Reserve growth capacity.
• Standardize network-function IDs.
• Check route aggregation.
• Document origin ASNs.
• Review ROAs and IRR records.
• Add prefixes to IPAM.
• Plan A and AAAA records.
• Configure reverse DNS.
• Test IPv4 and IPv6 routing.
• Test firewall policy.
• Test failover.
• Document ownership.

A well-structured addressing plan should make the next data center easier to add than the first one.

Plan Multi-Site Hosting With Atal Networks

Atal Networks provides Dedicated Servers, Bare Metal Servers, VPS Hosting, IPv4/IPv6 leasing, colocation, and network infrastructure for businesses operating across global locations. About Atal Networks

Our infrastructure also supports private networking, BYOIP, multihomed networking, high-bandwidth ports, and custom server configurations. About Atal Networks

For businesses expanding across several data centers, we can help align server deployment with IPv4, IPv6, ASN, BGP, and network requirements before the migration begins.

A clear IP plan reduces future network changes and gives every new server, subnet, and site a defined place in the infrastructure.

Häufig gestellte Fragen

What is IP address planning?

IP address planning is the process of defining how IPv4 and IPv6 prefixes, subnets, and individual addresses will be allocated across a network. A good plan accounts for sites, network functions, routing, security, growth, DNS, and operational ownership.

What IPv6 prefix should a hosting site receive?

There is no universal prefix size for every site. The allocation should reflect the number of required subnets, expected growth, routing policy, and available parent prefix. RFC 6177 specifically advises against treating /48 as the required default for every end site. 

Why are IPv6 LAN networks normally /64?

Standard IPv6 global unicast addressing uses a 64-bit interface ID in the normal address architecture. This makes /64 the standard subnet size for many IPv6 LAN deployments. 

Should IPv4 and IPv6 follow the same network layout?

They can use the same logical VLAN and service structure even though prefix lengths differ. Keeping equivalent IPv4 and IPv6 networks aligned can simplify firewall rules, monitoring, documentation, and troubleshooting.

Does every dedicated server need public IPv4?

No. Public-facing services may require dedicated public IPv4 addresses, but storage, database, backup, monitoring, and management traffic can often use private networks or IPv6, depending on the application and connectivity requirements.

What role does IPAM play in multi-site hosting?

IPAM provides a central record of prefixes, subnets, IP assignments, sites, VLANs, gateways, DNS records, status, and ownership. It reduces duplicate allocations and gives network teams a reliable view of available and assigned address space.

How does BGP affect IP address planning?

BGP determines how public prefixes are advertised between networks. Keeping related address blocks contiguous can support cleaner route aggregation. Address planning should therefore consider origin ASN, announcement location, multihoming, RPKI, and failover requirements.

Can BYOIP be used across several data centers?

It can, subject to prefix ownership, provider policy, routing configuration, RPKI, and BGP design. Organizations should determine where each prefix will be announced and avoid conflicting advertisements unless the routing architecture was built for that behavior.