{"id":24863,"date":"2026-10-05T12:39:48","date_gmt":"2026-10-05T12:39:48","guid":{"rendered":"https:\/\/atalnetworks.com\/?p=24863"},"modified":"2026-10-05T12:45:10","modified_gmt":"2026-10-05T12:45:10","slug":"ipv4-and-ipv6-address-planning-for-multi-site-hosting","status":"publish","type":"post","link":"https:\/\/atalnetworks.com\/de\/ipv4-and-ipv6-address-planning-for-multi-site-hosting\/","title":{"rendered":"IPv4- und IPv6-Adressplanung f\u00fcr Multi-Site-Hosting"},"content":{"rendered":"<p><span style=\"font-weight: 400;\">Das Ausf\u00fchren von Servern aus mehreren Rechenzentren bietet einem Unternehmen eine bessere geografische Reichweite, Redundanz und Netzwerkoptionen. Es entsteht auch ein Problem, das Teams h\u00e4ufig zu sp\u00e4t bemerken: Die Verwaltung der IP-Adresse wird schwieriger, wenn die Websites wachsen.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Ein schwacher Adressplan kann \u00fcberlappende private Netzwerke, verstreute IPv4-Zuordnungen, schwierige BGP-Richtlinien, IPv6-Pr\u00e4fixe ohne klare Struktur und lange Migrationsfenster erzeugen.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Ein guter IP-Adressplan f\u00fcr mehrere Standorte beginnt mit der Netzwerktopologie. Wir teilen dann den Adressraum nach Region, Standort, Netzwerkfunktion und Subnetz, w\u00e4hrend wir gen\u00fcgend Wachstumskapazit\u00e4t lassen.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">IPv4 und IPv6 ben\u00f6tigen unterschiedliche Planungsmethoden. Die IPv4-Planung konzentriert sich stark auf die Erhaltung des begrenzten \u00f6ffentlichen Raums. Die IPv6-Planung konzentriert sich mehr auf Hierarchie, Subnetzstruktur, Delegation und Aggregation.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">F\u00fcr die meisten Hosting-Umgebungen mit mehreren Standorten sollte das Kerndesign Folgendes umfassen:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Regional- und Site-Level-Zuordnung<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">\u00d6ffentliche und private Adressierung<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">IPv4-Erhaltung<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">IPv6-Pr\u00e4fixzuweisung<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Routenaggregation<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">BGP- und ASN-Richtlinie<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">IPAM<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">DNS und Reverse DNS<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Byoip<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Kapazit\u00e4t f\u00fcr neue Websites<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Ein klarer Plan erleichtert zuk\u00fcnftige Bereitstellungen, da jedes neue Subnetz einen logischen Platz im Netzwerk hat.<\/span><\/p>\n<h2><b>IPv4- und IPv6-Adressplanung auf einen Blick<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">IPv4 und IPv6 l\u00f6sen das gleiche Grundproblem, aber der verf\u00fcgbare Adressraum \u00e4ndert die Art und Weise, wie wir jedes Protokoll planen.<\/span><\/p>\n<table>\n<tbody>\n<tr>\n<td><b>Planungsbereich<\/b><\/td>\n<td><b>IPv4<\/b><\/td>\n<td><b>IPv6<\/b><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Adressgr\u00f6\u00dfe<\/span><\/td>\n<td><span style=\"font-weight: 400;\">32-Bit<\/span><\/td>\n<td><span style=\"font-weight: 400;\">128-Bit<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Adressverf\u00fcgbarkeit<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Beschr\u00e4nkt<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Extrem gro\u00df<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Hauptplanungsproblem<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Erhaltung<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Hierarchische Zuordnung<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Private Adressierung<\/span><\/td>\n<td><span style=\"font-weight: 400;\">RFC 1918<\/span><\/td>\n<td><span style=\"font-weight: 400;\">ULA gegebenenfalls<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Nat<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Gemeinsam<\/span><\/td>\n<td><span style=\"font-weight: 400;\">In der Regel nicht f\u00fcr die Adresskonservierung erforderlich<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Standard-LAN-Gr\u00f6\u00dfe<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Basierend auf den erforderlichen Hosts<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Meistens <\/span><span style=\"font-weight: 400;\">\/64<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Multi-Site-Design<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Sorgf\u00e4ltige Blockzuordnung<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Regional- und Site-Pr\u00e4fix-Hierarchie<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Leitung<\/span><\/td>\n<td><span style=\"font-weight: 400;\">CIDR und BGP<\/span><\/td>\n<td><span style=\"font-weight: 400;\">CIDR und BGP<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Management<\/span><\/td>\n<td><span style=\"font-weight: 400;\">IPAM<\/span><\/td>\n<td><span style=\"font-weight: 400;\">IPAM<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">DNS<\/span><\/td>\n<td><span style=\"font-weight: 400;\">A Aufzeichnungen<\/span><\/td>\n<td><span style=\"font-weight: 400;\">AAAA-Aufzeichnungen<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><span style=\"font-weight: 400;\">Die globale Unicast-Adressierung von IPv6 unterst\u00fctzt eine Struktur, die ein globales Routing-Pr\u00e4fix, eine Subnetz-ID und eine Schnittstellen-ID enth\u00e4lt. Diese Struktur macht die hierarchische Adressierung zu einer nat\u00fcrlichen Anpassung f\u00fcr Netzwerke, die \u00fcber mehrere Standorte verteilt sind.\u00a0<\/span><\/p>\n<h2><b>Beginnen Sie mit der Hosting-Topologie<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Starten Sie kein Adressierungsprojekt mit mehreren Standorten, indem Sie einen Subnetzrechner \u00f6ffnen.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Beginnen Sie mit der Infrastruktur.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Eine einfache Topologie k\u00f6nnte so aussehen:<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Globales Hosting-Netzwerk<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u2502<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u251c\u2500\u2500 Europa<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u2502 \u251c\u2500\u2500 Amsterdam<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u2502 \u251c\u2500\u2500 Frankfurt<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u2502 \u2514\u2500\u2500 London<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u2502<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u251c\u2500\u2500 Nordamerika<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u2502 \u251c\u2500\u2500 New York<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u2502 \u2514\u2500\u2500 Los Angeles<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u2502<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u2514\u2500\u2500 Asien-Pazifik<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u251c\u2500\u2500 Singapur<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u2514\u2500\u2500 Tokio<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Jeder Standort kann mehrere separate Netzwerkfunktionen enthalten:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">\u00d6ffentliche Servernetzwerke<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Verwaltungsnetzwerke<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Lagerung<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Sicherungskopie<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Virtualisierung<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Datenbanknetzwerke<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Load Balancer<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Kundennetzwerke<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">VPN-Infrastruktur<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">\u00dcberwachung<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Transitverbindungen<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Die Planung dieser Grenzen erleichtert die Subnetzzuweisung erheblich.<\/span><\/p>\n<p><img fetchpriority=\"high\" decoding=\"async\" class=\"alignnone size-full wp-image-24857\" src=\"https:\/\/atalnetworks.com\/wp-content\/uploads\/2025\/04\/Build-a-Regional-and-Site-Level-Address-Hierarchy.webp\" alt=\"Erstellen Sie eine regionale und auf Standortebene Adresshierarchie\" width=\"1672\" height=\"941\" srcset=\"https:\/\/atalnetworks.com\/wp-content\/uploads\/2025\/04\/Build-a-Regional-and-Site-Level-Address-Hierarchy.webp 1672w, https:\/\/atalnetworks.com\/wp-content\/uploads\/2025\/04\/Build-a-Regional-and-Site-Level-Address-Hierarchy-300x169.webp 300w, https:\/\/atalnetworks.com\/wp-content\/uploads\/2025\/04\/Build-a-Regional-and-Site-Level-Address-Hierarchy-1024x576.webp 1024w, https:\/\/atalnetworks.com\/wp-content\/uploads\/2025\/04\/Build-a-Regional-and-Site-Level-Address-Hierarchy-768x432.webp 768w, https:\/\/atalnetworks.com\/wp-content\/uploads\/2025\/04\/Build-a-Regional-and-Site-Level-Address-Hierarchy-1536x864.webp 1536w, https:\/\/atalnetworks.com\/wp-content\/uploads\/2025\/04\/Build-a-Regional-and-Site-Level-Address-Hierarchy-18x10.webp 18w\" sizes=\"(max-width: 1672px) 100vw, 1672px\" \/><\/p>\n<h2><b>Erstellen Sie eine regionale und auf Standortebene Adresshierarchie<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Ein Multi-Site-Netzwerk wird einfacher zu bedienen, wenn die Adressstruktur die physikalische oder logische Netzwerkstruktur widerspiegelt.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Ein praktisches Modell ist:<\/span><\/p>\n<p><b>Organisation \u2192 Region \u2192 Standort \u2192 Netzwerkfunktion \u2192 Subnetz \u2192 Host<\/b><\/p>\n<p><span style=\"font-weight: 400;\">Zum Beispiel:<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Europa<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u251c\u2500\u2500 Amsterdam<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u2502 \u251c\u2500\u2500 Management<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u2502 \u251c\u2500\u2500 \u00d6ffentliche Server<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u2502 \u251c\u2500\u2500 Private Dienste<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u2502 \u2514\u2500\u2500 Backup<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u2502<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u2514\u2500\u2500 Frankfurt<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u251c\u2500\u2500 Management<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u251c\u2500\u2500 \u00d6ffentliche Server<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u251c\u2500\u2500 Private Dienste<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u2514\u2500\u2500 Backup<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Diese Struktur gibt Netzwerkteams einen sofortigen Hinweis, wohin eine Adresse geh\u00f6rt.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Es unterst\u00fctzt auch sauberere Routing-Richtlinien. Verwandte Netzwerke k\u00f6nnen in zusammenh\u00e4ngenden Adressbl\u00f6cken bleiben, anstatt \u00fcber nicht verwandte Pr\u00e4fixe verteilt zu sein.<\/span><\/p>\n<h2><b>Planen Sie den IPv4-Adressraum um das begrenzte Angebot<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Der \u00f6ffentliche IPv4-Raum ist begrenzt, daher sollte das erste Ziel darin bestehen, zu bestimmen, welche Systeme weltweit routingf\u00e4hige Adressen ben\u00f6tigen.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Ein Datenbankserver hinter einer Anwendungsschicht ben\u00f6tigt m\u00f6glicherweise keine eigene \u00f6ffentliche IPv4-Adresse. Eine Verwaltungsschnittstelle sollte in der Regel nicht direkt dem \u00f6ffentlichen Internet ausgesetzt werden. Ein \u00f6ffentlicher Webserver, ein VPN-Gateway, ein Proxy-Endpunkt oder ein Kunden-Workload k\u00f6nnen unterschiedliche Anforderungen haben.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Durch die Trennung dieser Workloads wird die unn\u00f6tige \u00f6ffentliche IPv4-Nutzung verringert.<\/span><\/p>\n<h3><b>Trennen Sie \u00f6ffentliche und private IPv4-Netzwerke<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">RFC 1918 reserviert drei Adressbereiche f\u00fcr private Netzwerke:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">10.0.0.0\/8<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">172.16.0.0\/12<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">192.168.0.0\/16<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Diese Adressen bieten kein direktes globales Internet-Routing und werden h\u00e4ufig f\u00fcr interne Netzwerke verwendet.<\/span><a href=\"https:\/\/www.rfc-editor.org\/info\/rfc1918\/?utm_source=chatgpt.com\" target=\"_blank\" rel=\"noopener\">\u00a0<\/a><\/p>\n<p><span style=\"font-weight: 400;\">F\u00fcr eine gro\u00dfe Bereitstellung mehrerer Standorte k\u00f6nnten wir einen privaten Block nach Regionen teilen.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Beispiel:<\/span><\/p>\n<p><span style=\"font-weight: 400;\">10.0.0.0\/8 Globale private Zuteilung<\/span><\/p>\n<p>&nbsp;<\/p>\n<p><span style=\"font-weight: 400;\">10.16.0.0 \/ 12 Europa<\/span><\/p>\n<p><span style=\"font-weight: 400;\">10.32.0.0\/12 Nordamerika<\/span><\/p>\n<p><span style=\"font-weight: 400;\">10.48.0.0\/12 Asien-Pazifik<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Jeder regionale Bereich kann dann auf einzelne Rechenzentren aufgeteilt werden.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Die genauen Pr\u00e4fixl\u00e4ngen h\u00e4ngen von der Netzwerkgr\u00f6\u00dfe ab. Das Kernprinzip ist die Konsistenz.<\/span><\/p>\n<h3><b>\u00dcberlappende private Netzwerke verhindern<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">\u00dcberlappende RFC 1918-Bereiche verursachen schwerwiegende Probleme, sobald Standorte eine direkte Verbindung ben\u00f6tigen.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Angenommen, Amsterdam und Singapur verwenden beide:<\/span><\/p>\n<p><span style=\"font-weight: 400;\">10.10.0.0\/16<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Verbinden der Standorte \u00fcber VPN, privates Backbone, SD-WAN oder Routentunnel wird schwierig, da Router nicht bestimmen k\u00f6nnen, welche <\/span><span style=\"font-weight: 400;\">10.10.0.0\/16<\/span><span style=\"font-weight: 400;\"> Netzwerk sollte Datenverkehr empfangen.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Weisen Sie von Anfang an eindeutige Bereiche zu.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Dies wird noch n\u00fctzlicher, wenn das Unternehmen sp\u00e4ter eine Verbindung herstellt:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Ein weiterer Cloud-Anbieter<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ein erworbenes Gesch\u00e4ft<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Kundennetzwerke<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">disaster recovery infrastructure<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">B\u00fcronetzwerke<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Colocation-Einrichtungen<\/span><\/li>\n<\/ul>\n<h2><b>Gr\u00f6\u00dfe IPv4-Subnetze basierend auf realer Nachfrage<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Vermeiden Sie es, eine zuzuweisen <\/span><span style=\"font-weight: 400;\">\/24<\/span><span style=\"font-weight: 400;\"> Einfach, weil es vertraut ist.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Sch\u00e4tzen Sie die Anzahl der erforderlichen Adressen f\u00fcr jedes Netzwerk und enthalten Sie die Kapazit\u00e4t f\u00fcr:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Server<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Gateways<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Load Balancer<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Firewalls<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Virtualisierungs-Hosts<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Failover-Adressen<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Zuk\u00fcnftige Knoten<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Ein kleines Netzwerk ben\u00f6tigt m\u00f6glicherweise eine <\/span><span style=\"font-weight: 400;\">\/28<\/span><span style=\"font-weight: 400;\">, w\u00e4hrend ein gr\u00f6\u00dferer Kunden- oder Serverpool m\u00f6glicherweise a <\/span><span style=\"font-weight: 400;\">\/26<\/span><span style=\"font-weight: 400;\">, <\/span><span style=\"font-weight: 400;\">\/24<\/span><span style=\"font-weight: 400;\">oder gr\u00f6\u00dferer Block.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00d6ffentliche Adresspools verdienen strengere Kontrollen als der private Raum, da jede nicht verwendete \u00f6ffentliche IPv4-Adresse Opportunit\u00e4tskosten tr\u00e4gt.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">IPAM sollte nicht verwendete Kapazit\u00e4t aufzeichnen, anstatt Adressen ohne dokumentierten Zweck zu hinterlassen.<\/span><\/p>\n<h2><b>Entwerfen Sie IPv6 als Hierarchie<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">IPv6-Planung sollte die IPv4-Erhaltungsgewohnheiten nicht kopieren.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">IPv6 bietet uns gen\u00fcgend Adressraum, um lesbare Hierarchie, Delegation, sauberes Routing und langfristiges Wachstum zu priorisieren.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">RFC 6177 macht auch das deutlich <\/span><span style=\"font-weight: 400;\">\/48<\/span><span style=\"font-weight: 400;\"> sollte nicht als obligatorische Pr\u00e4fixgr\u00f6\u00dfe f\u00fcr jeden Standort behandelt werden. Adresszuweisungen sollten den tats\u00e4chlichen und geplanten Netzwerkanforderungen entsprechen.\u00a0<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Ein Hosting-Provider oder ein Unternehmen kann ein gr\u00f6\u00dferes IPv6-Pr\u00e4fix erhalten und es nach Standort dividieren.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Betrachten Sie dieses Dokumentationsbeispiel:<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Organisation: 2001: DB8: 1200 :: \/ 40<\/span><\/p>\n<p>&nbsp;<\/p>\n<p><span style=\"font-weight: 400;\">2001: DB8: 1201 :: \/ 48 Amsterdam<\/span><\/p>\n<p><span style=\"font-weight: 400;\">2001: DB8: 1202 :: \/ 48 Frankfurt<\/span><\/p>\n<p><span style=\"font-weight: 400;\">2001: DB8: 1203 :: \/ 48 London<\/span><\/p>\n<p><span style=\"font-weight: 400;\">2001: DB8: 1204 :: \/ 48 Singapur<\/span><\/p>\n<p><span style=\"font-weight: 400;\">2001: db8 :: \/ 32<\/span><span style=\"font-weight: 400;\"> ist f\u00fcr die Dokumentation reserviert, daher sollten diese Beispiele nicht als reale Produktionsadresse verwendet werden.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The purpose of the structure matters more than the exact sample prefix.<\/span><\/p>\n<h3><img decoding=\"async\" class=\"alignnone size-full wp-image-24858\" src=\"https:\/\/atalnetworks.com\/wp-content\/uploads\/2025\/04\/IPv6-prefix-hierarchy-diagram.webp\" alt=\"IPv6 prefix hierarchy diagram\" width=\"1672\" height=\"941\" srcset=\"https:\/\/atalnetworks.com\/wp-content\/uploads\/2025\/04\/IPv6-prefix-hierarchy-diagram.webp 1672w, https:\/\/atalnetworks.com\/wp-content\/uploads\/2025\/04\/IPv6-prefix-hierarchy-diagram-300x169.webp 300w, https:\/\/atalnetworks.com\/wp-content\/uploads\/2025\/04\/IPv6-prefix-hierarchy-diagram-1024x576.webp 1024w, https:\/\/atalnetworks.com\/wp-content\/uploads\/2025\/04\/IPv6-prefix-hierarchy-diagram-768x432.webp 768w, https:\/\/atalnetworks.com\/wp-content\/uploads\/2025\/04\/IPv6-prefix-hierarchy-diagram-1536x864.webp 1536w, https:\/\/atalnetworks.com\/wp-content\/uploads\/2025\/04\/IPv6-prefix-hierarchy-diagram-18x10.webp 18w\" sizes=\"(max-width: 1672px) 100vw, 1672px\" \/><\/h3>\n<h2><b>Understand \/48, \/56, \/60, and \/64 Prefixes<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Prefix size controls how much IPv6 address space belongs to a network.<\/span><\/p>\n<table>\n<tbody>\n<tr>\n<td><b>Prefix<\/b><\/td>\n<td><b>Number of \/64 Networks<\/b><\/td>\n<td><b>Typical Planning Use<\/b><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">\/48<\/span><\/td>\n<td><span style=\"font-weight: 400;\">65,536<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Large site or organizational assignment<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">\/52<\/span><\/td>\n<td><span style=\"font-weight: 400;\">4,096<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Site or regional subdivision<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">\/56<\/span><\/td>\n<td><span style=\"font-weight: 400;\">256<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Smaller site or delegated network<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">\/60<\/span><\/td>\n<td><span style=\"font-weight: 400;\">16<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Small delegated environment<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">\/64<\/span><\/td>\n<td><span style=\"font-weight: 400;\">1<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Normal IPv6 subnet<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><span style=\"font-weight: 400;\">IPv6 global unicast architecture uses a 64-bit interface identifier for the standard address format described by RFC 4291. That is one reason <\/span><span style=\"font-weight: 400;\">\/64<\/span><span style=\"font-weight: 400;\"> remains the normal subnet size for common IPv6 LAN deployments.<\/span><a href=\"https:\/\/www.rfc-editor.org\/info\/rfc4291\/?utm_source=chatgpt.com\" target=\"_blank\" rel=\"noopener\">\u00a0<\/a><\/p>\n<p><span style=\"font-weight: 400;\">Do not assume every customer, site, or server requires a <\/span><span style=\"font-weight: 400;\">\/48<\/span><span style=\"font-weight: 400;\">. 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.<\/span><a href=\"https:\/\/www.rfc-editor.org\/info\/rfc6177\/?utm_source=chatgpt.com\" target=\"_blank\" rel=\"noopener\">\u00a0<\/a><\/p>\n<h2><b>Divide Each Site by Network Function<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Once a site receives an IPv6 block, divide it in a repeatable way.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Beispiel:<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Amsterdam: 2001:db8:1201::\/48<\/span><\/p>\n<p>&nbsp;<\/p>\n<p><span style=\"font-weight: 400;\">2001:db8:1201:0000::\/64\u00a0 \u00a0 Management<\/span><\/p>\n<p><span style=\"font-weight: 400;\">2001:db8:1201:0100::\/64\u00a0 \u00a0 Public servers<\/span><\/p>\n<p><span style=\"font-weight: 400;\">2001:db8:1201:0200::\/64\u00a0 \u00a0 Private services<\/span><\/p>\n<p><span style=\"font-weight: 400;\">2001:db8:1201:0300::\/64\u00a0 \u00a0 Storage<\/span><\/p>\n<p><span style=\"font-weight: 400;\">2001:db8:1201:0400::\/64\u00a0 \u00a0 Load balancers<\/span><\/p>\n<p><span style=\"font-weight: 400;\">2001:db8:1201:0500::\/64\u00a0 \u00a0 Customer network<\/span><\/p>\n<p><span style=\"font-weight: 400;\">2001:db8:1201:0600::\/64\u00a0 \u00a0 Monitoring<\/span><\/p>\n<p><span style=\"font-weight: 400;\">2001:db8:1201:0700::\/64\u00a0 \u00a0 Backup<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The numbers are examples, not protocol requirements.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The value comes from having the same pattern at every location.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Frankfurt, Amsterdam, Singapore, and Los Angeles can all use the same subnet ID for the same service class.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">That makes troubleshooting easier because network engineers can recognize a subnet&#8217;s function without searching through several systems.<\/span><\/p>\n<h2><b>Align IPv4 and IPv6 Boundaries Where It Helps Operations<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Dual-stack networks are often easier to manage when IPv4 and IPv6 networks represent the same logical segment.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Beispiel:<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Web VLAN 120<\/span><\/p>\n<p>&nbsp;<\/p>\n<p><span style=\"font-weight: 400;\">IPv4: 10.20.120.0\/24<\/span><\/p>\n<p><span style=\"font-weight: 400;\">IPv6: 2001:db8:1201:120::\/64<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Both prefixes represent the same VLAN and workload group.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">This approach can simplify:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">firewall policies<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ACL management<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">\u00dcberwachung<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">incident investigation<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">network diagrams<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">server provisioning<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<h2><b>Plan Route Aggregation Before Address Assignment<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">IP addressing and routing should be planned together.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">If related networks sit inside contiguous prefixes, routers can advertise summarized routes instead of many smaller routes.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Random address assignment removes this option.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Before allocating a new subnet, ask:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Which region owns this address space?<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Which site owns it?<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Can related routes be summarized?<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Does another site already use part of this range?<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Will this prefix need public BGP advertisement?<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Does the failover design require the prefix somewhere else?<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">This process reduces routing cleanup later.<\/span><\/p>\n<h2><b>Include BGP, ASN, RPKI, and ROA Planning<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Public IP planning does not end with subnet allocation.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">A multi-site hosting environment may use BGP to announce IPv4 and IPv6 prefixes through one or more upstream networks.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The IP plan should record:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">prefix<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">origin ASN<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">upstream provider<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">announcement location<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">backup location<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">RPKI status<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ROA authorization<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">IRR route object<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">routing policy<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">This becomes especially useful during migrations.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Treat the prefix as an infrastructure asset rather than a number assigned to a server.<\/span><\/p>\n<h2><b>Plan BYOIP Before Moving Between Data Centers<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Bring Your Own IP, or BYOIP, allows an organization to use eligible IP space with infrastructure outside its original environment.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Before a BYOIP migration, verify:<\/span><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Prefix ownership or authorization<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Provider prefix-length requirements<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Origin ASN<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">ROA configuration<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">IRR records where required<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Existing BGP advertisements<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Target data center support<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Cutover sequence<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">DNS dependencies<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Rollback procedure<\/span><\/li>\n<\/ol>\n<p><span style=\"font-weight: 400;\">One common failure is advertising the same prefix from locations that were never designed to operate as anycast or multi-origin networks.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Routing behavior must be planned before the second announcement goes live.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">For global hosting companies, BYOIP also helps separate IP identity from individual server hardware or one specific facility.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">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<\/span><\/p>\n<h2><b>Use IPAM as the Source of Truth<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">A spreadsheet can work for a small network. It becomes risky once several sites, teams, customers, VLANs, and prefixes are involved.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">An IP Address Management system should record more than whether an IP is available.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Track fields such as:<\/span><\/p>\n<table>\n<tbody>\n<tr>\n<td><b>Field<\/b><\/td>\n<td><b>Example<\/b><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Prefix<\/span><\/td>\n<td><span style=\"font-weight: 400;\">2001:db8:1201:100::\/64<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Protocol<\/span><\/td>\n<td><span style=\"font-weight: 400;\">IPv6<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Region<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Europa<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Site<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Amsterdam<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">VLAN<\/span><\/td>\n<td><span style=\"font-weight: 400;\">120<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Purpose<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Public web servers<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Gateway<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Documented in IPAM<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">ASN<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Origin ASN<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">DNS<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Assigned<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">PTR<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Assigned<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Status<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Active<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Owner<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Network Operations<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><span style=\"font-weight: 400;\">The same database should track IPv4.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">IPAM should answer three questions quickly:<\/span><\/p>\n<p><b>Who owns this address? Where is it used? Why was it allocated?<\/b><\/p>\n<p><span style=\"font-weight: 400;\">If the system cannot answer those questions, address records need work.<\/span><\/p>\n<h3><img decoding=\"async\" class=\"alignnone size-full wp-image-24859\" src=\"https:\/\/atalnetworks.com\/wp-content\/uploads\/2025\/04\/IPAM-workflow-diagram.webp\" alt=\"IPAM workflow diagram\" width=\"1672\" height=\"941\" srcset=\"https:\/\/atalnetworks.com\/wp-content\/uploads\/2025\/04\/IPAM-workflow-diagram.webp 1672w, https:\/\/atalnetworks.com\/wp-content\/uploads\/2025\/04\/IPAM-workflow-diagram-300x169.webp 300w, https:\/\/atalnetworks.com\/wp-content\/uploads\/2025\/04\/IPAM-workflow-diagram-1024x576.webp 1024w, https:\/\/atalnetworks.com\/wp-content\/uploads\/2025\/04\/IPAM-workflow-diagram-768x432.webp 768w, https:\/\/atalnetworks.com\/wp-content\/uploads\/2025\/04\/IPAM-workflow-diagram-1536x864.webp 1536w, https:\/\/atalnetworks.com\/wp-content\/uploads\/2025\/04\/IPAM-workflow-diagram-18x10.webp 18w\" sizes=\"(max-width: 1672px) 100vw, 1672px\" \/><\/h3>\n<h2><b>Plan DNS With IPv4 and IPv6<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">DNS should be part of the migration plan rather than an afterthought.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">IPv4 services normally use <\/span><b>A Aufzeichnungen<\/b><span style=\"font-weight: 400;\">.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">IPv6 services use <\/span><b>AAAA-Aufzeichnungen<\/b><span style=\"font-weight: 400;\">.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Public hosting environments may also need PTR records for reverse DNS.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">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.\u00a0<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Test:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">application response<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">firewall policy<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">load balancer<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">TLS<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">\u00dcberwachung<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">upstream routing<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">DNS<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">IPv6 path<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">failover<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">For migrations, lower DNS TTLs before the planned change where appropriate, then restore normal values after the network has stabilized.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Reverse DNS delegation should also be planned around clean prefix boundaries. RFC 7381 notes that nibble-aligned IPv6 prefixes can simplify reverse DNS delegation.<\/span><a href=\"https:\/\/www.rfc-editor.org\/info\/rfc7381\/?utm_source=chatgpt.com\" target=\"_blank\" rel=\"noopener\">\u00a0<\/a><\/p>\n<h2><b>Separate Customer, Infrastructure, and Management Address Pools<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">A hosting network should not treat every server address as part of one large pool.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Keep logical separation between:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">customer services<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">hypervisors<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">router interfaces<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">management<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Lagerung<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">\u00dcberwachung<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Backups<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">public services<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Address structure can then support routing and security policy.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">A management subnet, for example, can have stricter firewall rules than a public web server network.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">A customer subnet can have its own routing policy without affecting storage traffic.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">This structure also makes incident response cleaner because the address itself provides useful context.<\/span><\/p>\n<h2><b>Dual Stack or IPv6-Only?<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Many multi-site hosting networks still use dual stack because customers and applications may require both protocols.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">RFC 7381 describes the common progression from IPv4-only networks to dual stack and eventually toward IPv6-only operation.<\/span><a href=\"https:\/\/www.rfc-editor.org\/info\/rfc7381\/?utm_source=chatgpt.com\" target=\"_blank\" rel=\"noopener\">\u00a0<\/a><\/p>\n<table>\n<tbody>\n<tr>\n<td><b>Model<\/b><\/td>\n<td><b>IPv4<\/b><\/td>\n<td><b>IPv6<\/b><\/td>\n<td><b>Suitable For<\/b><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">IPv4-only<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Ja<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Nein<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Legacy workloads<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Dual stack<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Ja<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Ja<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Broad application compatibility<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">IPv6-only<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Nein<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Ja<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Modern controlled environments<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">IPv6 with NAT64\/DNS64<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Translation<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Ja<\/span><\/td>\n<td><span style=\"font-weight: 400;\">IPv6-first environments accessing IPv4 resources<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><span style=\"font-weight: 400;\">Dual stack increases operational work because both protocols need routing, firewall rules, monitoring, and troubleshooting.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">IPv6-only can reduce dependence on private IPv4 space, but application, provider, customer, and third-party compatibility should be tested first.<\/span><\/p>\n<h2><b>Reserve Space for Future Sites<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Do not consume an address block simply because unused capacity exists today.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Reserve logical ranges for:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">new data centers<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">new regions<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">customer growth<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">disaster recovery<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">acquisitions<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">additional VLANs<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">cloud connections<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">private backbone expansion<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">RFC 7381 recommends planning IPv6 address space with growth in mind rather than building a plan that soon requires renumbering.<\/span><a href=\"https:\/\/www.rfc-editor.org\/rfc\/rfc7381.html?utm_source=chatgpt.com\" target=\"_blank\" rel=\"noopener\">\u00a0<\/a><\/p>\n<p><span style=\"font-weight: 400;\">The same operating principle helps IPv4, although public IPv4 must be allocated more conservatively.<\/span><\/p>\n<h2><b>Multi-Site Address Planning Example<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Consider a company operating four sites:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Amsterdam<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Frankfurt<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Los Angeles<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Singapur<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">A logical plan might look like this:<\/span><\/p>\n<table>\n<tbody>\n<tr>\n<td><b>Site<\/b><\/td>\n<td><b>Private IPv4<\/b><\/td>\n<td><b>IPv6 Site Block<\/b><\/td>\n<td><b>Main Function<\/b><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Amsterdam<\/span><\/td>\n<td><span style=\"font-weight: 400;\">10.16.0.0\/16<\/span><\/td>\n<td><span style=\"font-weight: 400;\">2001:db8:1201::\/48<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Europe primary<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Frankfurt<\/span><\/td>\n<td><span style=\"font-weight: 400;\">10.17.0.0\/16<\/span><\/td>\n<td><span style=\"font-weight: 400;\">2001:db8:1202::\/48<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Europe secondary<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Los Angeles<\/span><\/td>\n<td><span style=\"font-weight: 400;\">10.32.0.0\/16<\/span><\/td>\n<td><span style=\"font-weight: 400;\">2001:db8:1203::\/48<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Nord-Amerika<\/span><\/td>\n<\/tr>\n<tr>\n<td><span style=\"font-weight: 400;\">Singapur<\/span><\/td>\n<td><span style=\"font-weight: 400;\">10.48.0.0\/16<\/span><\/td>\n<td><span style=\"font-weight: 400;\">2001:db8:1204::\/48<\/span><\/td>\n<td><span style=\"font-weight: 400;\">Asia Pacific<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><span style=\"font-weight: 400;\">Each site could then follow a common internal model:<\/span><\/p>\n<p><span style=\"font-weight: 400;\">VLAN 100\u00a0 \u00a0 Management<\/span><\/p>\n<p><span style=\"font-weight: 400;\">VLAN 120\u00a0 \u00a0 Public servers<\/span><\/p>\n<p><span style=\"font-weight: 400;\">VLAN 140\u00a0 \u00a0 Private services<\/span><\/p>\n<p><span style=\"font-weight: 400;\">VLAN 160\u00a0 \u00a0 Storage<\/span><\/p>\n<p><span style=\"font-weight: 400;\">VLAN 180\u00a0 \u00a0 Backup<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The exact prefix sizes should reflect actual requirements. The value of the model is that every site follows the same addressing logic.<\/span><\/p>\n<h3><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-24861\" src=\"https:\/\/atalnetworks.com\/wp-content\/uploads\/2025\/04\/Complete-Four-Site-Dual-Stack-Architecture.webp\" alt=\"\" width=\"1672\" height=\"941\" srcset=\"https:\/\/atalnetworks.com\/wp-content\/uploads\/2025\/04\/Complete-Four-Site-Dual-Stack-Architecture.webp 1672w, https:\/\/atalnetworks.com\/wp-content\/uploads\/2025\/04\/Complete-Four-Site-Dual-Stack-Architecture-300x169.webp 300w, https:\/\/atalnetworks.com\/wp-content\/uploads\/2025\/04\/Complete-Four-Site-Dual-Stack-Architecture-1024x576.webp 1024w, https:\/\/atalnetworks.com\/wp-content\/uploads\/2025\/04\/Complete-Four-Site-Dual-Stack-Architecture-768x432.webp 768w, https:\/\/atalnetworks.com\/wp-content\/uploads\/2025\/04\/Complete-Four-Site-Dual-Stack-Architecture-1536x864.webp 1536w, https:\/\/atalnetworks.com\/wp-content\/uploads\/2025\/04\/Complete-Four-Site-Dual-Stack-Architecture-18x10.webp 18w\" sizes=\"(max-width: 1672px) 100vw, 1672px\" \/><\/h3>\n<h2><b>Common IP Address Planning Mistakes<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Multi-site networks often become difficult to manage because of small design choices made during early deployment.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Avoid these problems:<\/span><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Reusing private IPv4 ranges at multiple connected sites<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Assigning IP blocks without a regional hierarchy<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Using public IPv4 for systems that only need internal connectivity<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Treating IPv6 address space like scarce IPv4 space<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Giving every IPv6 site the same prefix size without assessing need<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Allocating networks without considering route aggregation<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Publishing AAAA records before testing IPv6<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Ignoring reverse DNS<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Mixing management and customer networks<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Keeping no capacity for new locations<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Allowing undocumented BYOIP advertisements<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Failing to update ROA or routing records during migration<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Managing a large network from disconnected spreadsheets<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Assigning addresses without clear ownership<\/span><\/li>\n<\/ol>\n<p><span style=\"font-weight: 400;\">Good address planning reduces renumbering, routing changes, and migration risk.<\/span><\/p>\n<h2><b>Multi-Site IP Address Planning Checklist<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">Before deploying a new site:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Inventory existing IPv4 and IPv6 prefixes.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Map every current and planned location.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Create regional allocations.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Create site allocations.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Separate public and private IPv4 space.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Assign unique private ranges.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Build an IPv6 hierarchy.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Reserve growth capacity.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Standardize network-function IDs.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Check route aggregation.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Document origin ASNs.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Review ROAs and IRR records.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Add prefixes to IPAM.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Plan A and AAAA records.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Configure reverse DNS.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Test IPv4 and IPv6 routing.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Test firewall policy.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Test failover.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><span style=\"font-weight: 400;\">Document ownership.<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">A well-structured addressing plan should make the next data center easier to add than the first one.<\/span><\/p>\n<h2><b>Plan Multi-Site Hosting With Atal Networks<\/b><\/h2>\n<p><span style=\"font-weight: 400;\">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<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Our infrastructure also supports private networking, BYOIP, multihomed networking, high-bandwidth ports, and custom server configurations. About Atal Networks<\/span><\/p>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">A clear IP plan reduces future network changes and gives every new server, subnet, and site a defined place in the infrastructure.<\/span><\/p>\n<h1><b>H\u00e4ufig gestellte Fragen<\/b><\/h1>\n<h3><b>What is IP address planning?<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<h3><b>What IPv6 prefix should a hosting site receive?<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">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 <\/span><span style=\"font-weight: 400;\">\/48<\/span><span style=\"font-weight: 400;\"> as the required default for every end site.<\/span><a href=\"https:\/\/www.rfc-editor.org\/info\/rfc6177\/?utm_source=chatgpt.com\" target=\"_blank\" rel=\"noopener\">\u00a0<\/a><\/p>\n<h3><b>Why are IPv6 LAN networks normally \/64?<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">Standard IPv6 global unicast addressing uses a 64-bit interface ID in the normal address architecture. This makes <\/span><span style=\"font-weight: 400;\">\/64<\/span><span style=\"font-weight: 400;\"> the standard subnet size for many IPv6 LAN deployments.<\/span><a href=\"https:\/\/www.rfc-editor.org\/info\/rfc4291\/?utm_source=chatgpt.com\" target=\"_blank\" rel=\"noopener\">\u00a0<\/a><\/p>\n<h3><b>Should IPv4 and IPv6 follow the same network layout?<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<h3><b>Does every dedicated server need public IPv4?<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<h3><b>What role does IPAM play in multi-site hosting?<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<h3><b>How does BGP affect IP address planning?<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>\n<h3><b>Can BYOIP be used across several data centers?<\/b><\/h3>\n<p><span style=\"font-weight: 400;\">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.<\/span><\/p>","protected":false},"excerpt":{"rendered":"<p>Running servers from several data centers gives a business better geographic reach, redundancy, and network options. It also creates a [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":24860,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"default","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"set","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[1],"tags":[],"class_list":["post-24863","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-enterprise-grade-server"],"acf":[],"_links":{"self":[{"href":"https:\/\/atalnetworks.com\/de\/wp-json\/wp\/v2\/posts\/24863","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/atalnetworks.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/atalnetworks.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/atalnetworks.com\/de\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/atalnetworks.com\/de\/wp-json\/wp\/v2\/comments?post=24863"}],"version-history":[{"count":1,"href":"https:\/\/atalnetworks.com\/de\/wp-json\/wp\/v2\/posts\/24863\/revisions"}],"predecessor-version":[{"id":24864,"href":"https:\/\/atalnetworks.com\/de\/wp-json\/wp\/v2\/posts\/24863\/revisions\/24864"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/atalnetworks.com\/de\/wp-json\/wp\/v2\/media\/24860"}],"wp:attachment":[{"href":"https:\/\/atalnetworks.com\/de\/wp-json\/wp\/v2\/media?parent=24863"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/atalnetworks.com\/de\/wp-json\/wp\/v2\/categories?post=24863"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/atalnetworks.com\/de\/wp-json\/wp\/v2\/tags?post=24863"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}