Das Ausführen von Servern aus mehreren Rechenzentren bietet einem Unternehmen eine bessere geografische Reichweite, Redundanz und Netzwerkoptionen. Es entsteht auch ein Problem, das Teams häufig zu spät bemerken: Die Verwaltung der IP-Adresse wird schwieriger, wenn die Websites wachsen.

Ein schwacher Adressplan kann überlappende private Netzwerke, verstreute IPv4-Zuordnungen, schwierige BGP-Richtlinien, IPv6-Präfixe ohne klare Struktur und lange Migrationsfenster erzeugen.

Ein guter IP-Adressplan für mehrere Standorte beginnt mit der Netzwerktopologie. Wir teilen dann den Adressraum nach Region, Standort, Netzwerkfunktion und Subnetz, während wir genügend Wachstumskapazität lassen.

IPv4 und IPv6 benötigen unterschiedliche Planungsmethoden. Die IPv4-Planung konzentriert sich stark auf die Erhaltung des begrenzten öffentlichen Raums. Die IPv6-Planung konzentriert sich mehr auf Hierarchie, Subnetzstruktur, Delegation und Aggregation.

Für die meisten Hosting-Umgebungen mit mehreren Standorten sollte das Kerndesign Folgendes umfassen:

• Regional- und Site-Level-Zuordnung
• Öffentliche und private Adressierung
• IPv4-Erhaltung
• IPv6-Präfixzuweisung
• Routenaggregation
• BGP- und ASN-Richtlinie
• IPAM
• DNS und Reverse DNS
• Byoip
• Kapazität für neue Websites

Ein klarer Plan erleichtert zukünftige Bereitstellungen, da jedes neue Subnetz einen logischen Platz im Netzwerk hat.

IPv4- und IPv6-Adressplanung auf einen Blick

IPv4 und IPv6 lösen das gleiche Grundproblem, aber der verfügbare Adressraum ändert die Art und Weise, wie wir jedes Protokoll planen.

Planungsbereich	IPv4	IPv6
Adressgröße	32-Bit	128-Bit
Adressverfügbarkeit	Beschränkt	Extrem groß
Hauptplanungsproblem	Erhaltung	Hierarchische Zuordnung
Private Adressierung	RFC 1918	ULA gegebenenfalls
Nat	Gemeinsam	In der Regel nicht für die Adresskonservierung erforderlich
Standard-LAN-Größe	Basierend auf den erforderlichen Hosts	Meistens /64
Multi-Site-Design	Sorgfältige Blockzuordnung	Regional- und Site-Präfix-Hierarchie
Leitung	CIDR und BGP	CIDR und BGP
Management	IPAM	IPAM
DNS	A Aufzeichnungen	AAAA-Aufzeichnungen

Die globale Unicast-Adressierung von IPv6 unterstützt eine Struktur, die ein globales Routing-Präfix, eine Subnetz-ID und eine Schnittstellen-ID enthält. Diese Struktur macht die hierarchische Adressierung zu einer natürlichen Anpassung für Netzwerke, die über mehrere Standorte verteilt sind. 

Beginnen Sie mit der Hosting-Topologie

Starten Sie kein Adressierungsprojekt mit mehreren Standorten, indem Sie einen Subnetzrechner öffnen.

Beginnen Sie mit der Infrastruktur.

Erstellen Sie ein Inventar aller aktiven und geplanten Hosting-Standorte. Zeichnen Sie das Land, die Stadt, das Rechenzentrum, das Upstream-Netzwerk, die Serveranzahl, die erwartete Kundenzahl, die aktuellen IP-Blocks, die Routing-Methode und das erwartete Wachstum auf.

Eine einfache Topologie könnte so aussehen:

Globales Hosting-Netzwerk

│

├── Europa

│ ├── Amsterdam

│ ├── Frankfurt

│ └── London

│

├── Nordamerika

│ ├── New York

│ └── Los Angeles

│

└── Asien-Pazifik

    ├── Singapur

    └── Tokio

Jeder Standort kann mehrere separate Netzwerkfunktionen enthalten:

• Öffentliche Servernetzwerke
• Verwaltungsnetzwerke
• Lagerung
• Sicherungskopie
• Virtualisierung
• Datenbanknetzwerke
• Load Balancer
• Kundennetzwerke
• VPN-Infrastruktur
• Überwachung
• Transitverbindungen

Die Planung dieser Grenzen erleichtert die Subnetzzuweisung erheblich.

Erstellen Sie eine regionale und auf Standortebene Adresshierarchie

Ein Multi-Site-Netzwerk wird einfacher zu bedienen, wenn die Adressstruktur die physikalische oder logische Netzwerkstruktur widerspiegelt.

Ein praktisches Modell ist:

Organisation → Region → Standort → Netzwerkfunktion → Subnetz → Host

Zum Beispiel:

Europa

├── Amsterdam

│ ├── Management

│ ├── Öffentliche Server

│ ├── Private Dienste

│ └── Backup

│

└── Frankfurt

    ├── Management

    ├── Öffentliche Server

    ├── Private Dienste

    └── Backup

Diese Struktur gibt Netzwerkteams einen sofortigen Hinweis, wohin eine Adresse gehört.

Es unterstützt auch sauberere Routing-Richtlinien. Verwandte Netzwerke können in zusammenhängenden Adressblöcken bleiben, anstatt über nicht verwandte Präfixe verteilt zu sein.

Planen Sie den IPv4-Adressraum um das begrenzte Angebot

Der öffentliche IPv4-Raum ist begrenzt, daher sollte das erste Ziel darin bestehen, zu bestimmen, welche Systeme weltweit routingfähige Adressen benötigen.

Ein Datenbankserver hinter einer Anwendungsschicht benötigt möglicherweise keine eigene öffentliche IPv4-Adresse. Eine Verwaltungsschnittstelle sollte in der Regel nicht direkt dem öffentlichen Internet ausgesetzt werden. Ein öffentlicher Webserver, ein VPN-Gateway, ein Proxy-Endpunkt oder ein Kunden-Workload können unterschiedliche Anforderungen haben.

Durch die Trennung dieser Workloads wird die unnötige öffentliche IPv4-Nutzung verringert.

Trennen Sie öffentliche und private IPv4-Netzwerke

RFC 1918 reserviert drei Adressbereiche für private Netzwerke:

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

Diese Adressen bieten kein direktes globales Internet-Routing und werden häufig für interne Netzwerke verwendet. 

Für eine große Bereitstellung mehrerer Standorte könnten wir einen privaten Block nach Regionen teilen.

Beispiel:

10.0.0.0/8 Globale private Zuteilung

 

10.16.0.0 / 12 Europa

10.32.0.0/12 Nordamerika

10.48.0.0/12 Asien-Pazifik

Jeder regionale Bereich kann dann auf einzelne Rechenzentren aufgeteilt werden.

Die genauen Präfixlängen hängen von der Netzwerkgröße ab. Das Kernprinzip ist die Konsistenz.

Überlappende private Netzwerke verhindern

Überlappende RFC 1918-Bereiche verursachen schwerwiegende Probleme, sobald Standorte eine direkte Verbindung benötigen.

Angenommen, Amsterdam und Singapur verwenden beide:

10.10.0.0/16

Verbinden der Standorte über VPN, privates Backbone, SD-WAN oder Routentunnel wird schwierig, da Router nicht bestimmen können, welche 10.10.0.0/16 Netzwerk sollte Datenverkehr empfangen.

Weisen Sie von Anfang an eindeutige Bereiche zu.

Dies wird noch nützlicher, wenn das Unternehmen später eine Verbindung herstellt:

• Ein weiterer Cloud-Anbieter
• ein erworbenes Geschäft
• Kundennetzwerke
• disaster recovery infrastructure
• Büronetzwerke
• Colocation-Einrichtungen

Größe IPv4-Subnetze basierend auf realer Nachfrage

Vermeiden Sie es, eine zuzuweisen /24 Einfach, weil es vertraut ist.

Schätzen Sie die Anzahl der erforderlichen Adressen für jedes Netzwerk und enthalten Sie die Kapazität für:

• Server
• Gateways
• Load Balancer
• Firewalls
• Virtualisierungs-Hosts
• Failover-Adressen
• Zukünftige Knoten

Ein kleines Netzwerk benötigt möglicherweise eine /28, während ein größerer Kunden- oder Serverpool möglicherweise a /26, /24oder größerer Block.

Öffentliche Adresspools verdienen strengere Kontrollen als der private Raum, da jede nicht verwendete öffentliche IPv4-Adresse Opportunitätskosten trägt.

IPAM sollte nicht verwendete Kapazität aufzeichnen, anstatt Adressen ohne dokumentierten Zweck zu hinterlassen.

Entwerfen Sie IPv6 als Hierarchie

IPv6-Planung sollte die IPv4-Erhaltungsgewohnheiten nicht kopieren.

IPv6 bietet uns genügend Adressraum, um lesbare Hierarchie, Delegation, sauberes Routing und langfristiges Wachstum zu priorisieren.

RFC 6177 macht auch das deutlich /48 sollte nicht als obligatorische Präfixgröße für jeden Standort behandelt werden. Adresszuweisungen sollten den tatsächlichen und geplanten Netzwerkanforderungen entsprechen. 

Ein Hosting-Provider oder ein Unternehmen kann ein größeres IPv6-Präfix erhalten und es nach Standort dividieren.

Betrachten Sie dieses Dokumentationsbeispiel:

Organisation: 2001: DB8: 1200 :: / 40

 

2001: DB8: 1201 :: / 48 Amsterdam

2001: DB8: 1202 :: / 48 Frankfurt

2001: DB8: 1203 :: / 48 London

2001: DB8: 1204 :: / 48 Singapur

2001: db8 :: / 32 ist für die Dokumentation reserviert, daher sollten diese Beispiele nicht als reale Produktionsadresse verwendet werden.

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.

Beispiel:

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.

Beispiel:

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
• Überwachung
• 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 Aufzeichnungen.

IPv6 services use AAAA-Aufzeichnungen.

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
• Überwachung
• 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
• Lagerung
• Überwachung
• 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.