Welche IPv6-Adressierungsarten gibt es – und was bedeuten Präfix, Scope und Format fürs Routing?

IPv6-Adresstypen nach Prefix und Scope: Global Unicast, ULA, Link-Local, Multicast und Anycast

IPv6 kodiert Adresstyp und Reichweite (Scope) weitgehend über Präfixe und teils über reservierte Bitmuster. Für Routing und Filterregeln zählt weniger die Schreibweise, sondern die präzise Einordnung: Welche Präfixbereiche sind global routbar, welche bleiben strikt lokal, welche existieren nur auf einem Link und welche adressieren Gruppen oder „nächstgelegene“ Instanzen. Gleichzeitig bestimmt der Adresstyp, ob und wie Autokonfiguration (SLAAC) greift, welche Interface-Identifier (IID) typisch sind und wo Sicherheitsrisiken durch Adressstabilität oder falsche Annahmen entstehen.

Global Unicast (GUA): Aggregation, Subnetting und stabile vs. temporäre IIDs

Global-Unicast-Adressen liegen im Bereich 2000::/3 und bilden die reguläre End-to-End-Adressierung. Operativ wichtig ist die Trennung von Routing-Präfix (Netzanteil) und IID. In nahezu allen Enterprise- und Provider-Designs gilt das /64 als Standard pro Layer‑2‑Segment, weil SLAAC und Neighbor Discovery darauf ausgelegt sind; längere Präfixe auf einem Link brechen zwar nicht grundsätzlich jede Implementierung, führen aber regelmäßig zu Interoperabilitätsproblemen und unerwartetem Verhalten in Autokonfiguration und Adresserkennung.

Bei IIDs dominieren heute zwei Muster: semistabile „stable privacy“-IIDs (RFC 7217) und temporäre IIDs („temporary addresses“, RFC 8981) für ausgehende Verbindungen. EUI‑64 aus MAC-Adressen ist technisch möglich, wird aber aus Datenschutz- und Tracking-Gründen vielerorts vermieden oder deaktiviert. Für Firewalling und Logging bedeutet das: Filter sollten primär auf Präfixe und Rollen (z. B. Subnetze, VLANs) zielen, nicht auf einzelne Hostadressen; Zugriffssteuerung über einzelne /128 kann bei temporären IIDs schnell ins Leere laufen.

Unique Local Addresses (ULA): interne Stabilität ohne Internet-Routbarkeit

ULA verwenden fc00::/7; in der Praxis wird fd00::/8 genutzt, da der andere Teilbereich historisch nicht für ein zentrales Vergabeschema definiert wurde. Das Format sieht eine 40‑bit Global-ID vor, die zufallsbasiert erzeugt wird, um Kollisionen beim Zusammenschalten von Netzen (Merger, VPN, Lab‑Umgebungen) selten zu machen. ULA lassen sich hierarchisch wie GUA subnetten, typischerweise ebenfalls mit /64 pro Link.

Sicherheitsseitig entstehen zwei gegensätzliche Effekte: Einerseits reduziert Nicht‑Routbarkeit aus dem Internet die Angriffsfläche an Perimetern. Andererseits verleitet „intern = sicher“ zu zu offenen Ost-West-Freigaben. Zusätzlich bleiben ULA in Logs und Telemetrie stabil, was für forensische Korrelation hilfreich ist, aber bei Endgeräten ebenfalls Identifizierbarkeit erhöhen kann, wenn stabile IIDs verwendet werden.

Link-Local (fe80::/10): Scope-Grenzen und Zonen-IDs in Betrieb und Tools

Link-Local-Adressen aus fe80::/10 existieren automatisch auf praktisch jedem IPv6-fähigen Interface und gelten ausschließlich auf dem lokalen Link. Router verwenden Link-Local häufig als Next-Hop, und viele Control-Plane-Funktionen (Router Advertisements, Neighbor Discovery) setzen sie voraus. Daraus folgt eine zentrale Betriebskonsequenz: Link-Local ist nicht eindeutig ohne Interface-Kontext, weshalb Werkzeuge eine Zonen-ID erwarten.

• Linux (iproute2): Link-Local-Ziel mit Interface angeben, z. B. ping -6 fe80::1%eth0 oder Route prüfen mit ip -6 route.
• Windows: Interface-Index verwenden, z. B. ping -6 fe80::1%12; Indizes anzeigen mit netsh interface ipv6 show interfaces oder Get-NetIPInterface -AddressFamily IPv6.
• Router/Firewall-Betrieb: IGP- oder BGP-Sessions nutzen häufig Link-Local als Transport; Filterregeln sollten den Link-Local-Scope berücksichtigen und nicht mit „nicht geroutet = irrelevant“ verwechseln.

Multicast (ff00::/8): Flags, Scope-Nibble und typische Gruppen

Multicast beginnt mit ff und kodiert im Header der Adresse Flags sowie den Scope in einem 4‑bit Feld (Scope-Nibble). Häufig relevant sind Link-Local- und Site/Organisation-Scopes, da Neighbor Discovery und viele Service-Mechanismen darüber arbeiten. Beispiele sind ff02::1 (All Nodes, Link-Local) und ff02::2 (All Routers, Link-Local). Multicast ersetzt Broadcast; falsch konfigurierte Filter, die ff02::/16 pauschal blockieren, führen oft zu schwer diagnostizierbaren Ausfällen bei SLAAC, ND und Router-Erkennung.

Anycast: Unicast-Format, Anycast-Semantik und typische Stolperfallen

Anycast besitzt keinen eigenen Präfixbereich. Technisch handelt es sich um eine Unicast-Adresse, die gleichzeitig auf mehreren Knoten oder Interfaces konfiguriert ist; das Routing sorgt dafür, dass Verkehr beim topologisch „nächsten“ Ankündiger landet. Typische Einsatzfälle sind DNS-Resolver, Edge-Services oder verteilte Gateways. Die Semantik ist damit rein netzseitig: Ein /128 kann Anycast sein, muss es aber nicht.

Stolperfallen entstehen bei Zustandsbehaftung und Sichtbarkeit. Persistente Sessions (z. B. TLS ohne Wiederaufnahme, stateful NAT64, Protokolle mit Quellbindung) reagieren empfindlich, wenn sich der „nächste“ Anycast-Knoten durch Routing-Änderungen verschiebt. Monitoring und Log-Auswertung müssen Anycast berücksichtigen, weil dieselbe Zieladresse auf mehreren Hosts auftaucht. Bei Neighbor Discovery ist sorgfältig sicherzustellen, dass Anycast nicht unbeabsichtigt auf einem einzelnen L2-Link dupliziert wird, sofern das Design das nicht vorsieht.

Typische Fehlinterpretationen: Prefix-Delegation, /64-Grenzen und Scope-Verwechslungen

• /64 als „optional“ pro Link: Viele Stacks erwarten /64 für SLAAC und ND; längere Präfixe auf einem gemeinsamen L2-Link führen häufig zu Host-Problemen, auch wenn Routing rechnerisch möglich wäre.
• Prefix-Delegation (PD) mit Subnetting verwechseln: DHCPv6-PD delegiert einen aggregierten Präfixblock (z. B. /56) an einen nachgelagerten Router; das ist nicht identisch mit der Zuweisung eines einzelnen On-Link-/64 an Hosts.
• ULA als Ersatz für Segmentierung: fd00::/8 reduziert keine lateralen Bewegungen ohne passende L3-/L4-Policy; interne Router routen ULA regulär, und Ost-West-Firewalling bleibt erforderlich.
• Link-Local als „unwichtig“ behandeln: Blockaden oder Fehlkonfigurationen rund um fe80::/10 stören Routing-Nachbarschaften, RA und Fehlersuche, weil viele Control-Plane-Pfade darauf beruhen.
• Multicast pauschal sperren: Sperren von ff02::/16 oder ICMPv6-Funktionalität führt zu ND-/SLAAC-Ausfällen; gezielte Regeln sollten Protokolle und Scopes differenzieren statt Multicast generell zu verwerfen.

Präfixlängen und Bitfelder: Formatstruktur, Interface-Identifier, IPv4-Mapping und typische Interface-Kennungen

IPv6 trennt die 128 Bit einer Adresse logisch in Präfix und Interface-Identifier (IID). Die Präfixlänge (CIDR) bestimmt, welcher Anteil für Routing-Entscheidungen und Aggregation relevant ist, während der IID typischerweise die Host- bzw. Interface-Zuordnung innerhalb des Subnetzes abbildet. In der Praxis prägt diese Trennung nicht nur die Routenhierarchie, sondern auch Autokonfiguration, Filterregeln, Nachvollziehbarkeit von Endgeräten und typische Fehlerbilder bei Subnetting und Prefix-Delegation.

Präfixlängen: Standardmuster und ihre Bedeutung für Routing

Für Global-Unicast im Enterprise- und Provider-Umfeld gilt /64 als Norm für „klassische“ LAN-Subnets, weil SLAAC und viele ND-Optimierungen einen 64‑Bit-IID voraussetzen. Abweichungen sind möglich, aber mit Nebenwirkungen verbunden (z. B. eingeschränkte Autokonfiguration oder unerwartetes Verhalten von Implementierungen). Oberhalb des Subnetzes dienen längere Aggregationen (z. B. /48, /56) der Adressplanung und Routenaggregation; diese Präfixe sind typischerweise als Zuteilungen (Allocation) oder Delegationen (PD) zu verstehen, nicht als einzelne Link-Netze.

Link-Local (fe80::/10) nutzt ebenfalls üblicherweise /64 pro Link, ist jedoch nicht routbar und bleibt auf den jeweiligen L2‑Broadcast-Domain/Link beschränkt. Unique Local Addresses (ULA, fc00::/7, praktisch fd00::/8) werden häufig als /48 geplant und ebenfalls in /64-Subnets unterteilt, um interne Segmentierung konsistent zu halten und Regeln wiederverwendbar zu machen.

• Subnetzgröße im LAN: /64 bleibt die interoperabelste Wahl für Netze mit SLAAC; längere Präfixe wie /80 reduzieren zwar den Hostraum, brechen aber häufig Erwartungen an den IID und erschweren Standardmechanismen.
• Aggregation vs. Link: /48 und /56 sind meist Organisations- oder Standortpräfixe; erst die Aufteilung in /64 definiert einzelne Links/VLANs, die als direkt verbunden geroutet werden.
• ULA-Planung: Für fdxx:xxxx:xxxx::/48 bietet sich die Hierarchie /48 (Organisation) → /64 (Subnetz) an, um parallele Strukturen zu Global-Unicast zu erhalten und Policy-Routing/Firewalling zu vereinfachen.
• Link-Local-Realität: Trotz Präfix fe80::/10 behandeln viele Stacks Link-Local effektiv als fe80::/64 pro Interface; Router Advertisements spielen hier keine Rolle, die Adresse entsteht lokal pro Interface.

Bitfelder und Formatstruktur: wo Präfixe „herkommen“

Mehrere IPv6-Adressarten tragen ihre Semantik direkt in festen Bitfeldern. Multicast beginnt immer mit ff00::/8; danach folgen Flags und Scope, die die Reichweite (z. B. Link, Site/Organisation, Global) definieren. Bei Link-Local ist der Präfixbereich fe80::/10 fest, die restlichen Bits sind für Subnet-ID (in der Praxis meist 0) und IID verfügbar. Bei ULA ist der Bereich fc00::/7 reserviert, wobei heute nahezu ausschließlich fd00::/8 (L-Bit „locally assigned“) verwendet wird; der darauffolgende 40‑Bit Global-ID-Anteil soll zufällig gewählt werden, um Kollisionsrisiken bei Zusammenschaltungen zu minimieren.

Interface-Identifier (IID): EUI-64, Stable, Temporary und „auffällige“ Kennungen

Der IID-Anteil ist nicht „beliebig“, sondern Ergebnis eines Mechanismus: manuell gesetzt, aus einer MAC-Adresse abgeleitet (EUI‑64), stabil aber zufallsbasiert (Stable Privacy) oder bewusst kurzlebig (Temporary/Privacy Extensions). Moderne Betriebssysteme nutzen für ausgehende Verbindungen häufig temporäre Adressen, während für Erreichbarkeit im LAN (DNS, Serverrollen) stabile Adressen erforderlich bleiben. EUI‑64 ist leicht erkennbar (Einfügen von ff:fe in die MAC und Flip des U/L‑Bits) und erleichtert Korrelationsangriffe sowie Geräte-Fingerprinting, weshalb viele Umgebungen EUI‑64 für Global-Unicast vermeiden.

• EUI‑64 erkennbar: IIDs mit dem Muster xxxx:xxff:fexx:xxxx deuten auf MAC-Ableitung; dies erhöht Wiedererkennbarkeit über Netze hinweg, wenn dieselbe NIC in mehreren Segmenten adressiert wird.
• Stable Privacy (RFC-konform): Stabile IIDs entstehen pro Präfix und Interface aus einem geheimen Seed; dadurch bleibt die Adresse innerhalb eines Netzes konstant, ohne die MAC preiszugeben.
• Temporary/Privacy: Zusätzliche, zeitlich rotierende IIDs reduzieren Tracking bei Client-Systemen; für eingehende Dienste sind sie ungeeignet, weil sie sich ändern und oft nicht im DNS geführt werden.
• „Typische“ Server-IIDs: Administrativ vergebene Endungen wie ::1, ::10 oder ::100 sind gut lesbar, aber leicht zu scannen; Schutz entsteht durch Segmentierung, Filterregeln und Diensthärtung, nicht durch „Unerratbarkeit“.

IPv4-Mapping und Übergangsformate: Präfixe mit Spezialsemantik

Neben „klassischen“ Unicast-Präfixen existieren IPv6-Formate, die IPv4-Adressen einbetten oder auf sie verweisen. Diese Adressen dienen nicht der globalen IPv6-Routenaggregation, sondern der API- und Übergangslogik in Stacks, Proxies oder Dual-Stack-Anwendungen. Wichtig ist die saubere Abgrenzung: Nicht jedes Präfix mit IPv4-Anteil ist im Routing sichtbar, und einige Formen sind ausdrücklich nur für interne Darstellung gedacht.

Typische Fehlinterpretationen bei Präfixstrukturen und IIDs

Fehler entstehen oft durch IPv4-geprägtes Denken: Ein „kleineres Subnetz“ wird mit weniger Hosts gleichgesetzt, obwohl bei IPv6 der Hostraum selten der Engpass ist. Kritisch wird es, wenn Prefix Delegation und Link-Präfixe vermischt werden: Ein delegiertes /56 oder /60 ist ein Pool für mehrere /64-Links, nicht das eine LAN-Präfix. Ebenso führt die Annahme, der IID sei immer „zufällig“, zu Sicherheitslücken, wenn tatsächlich EUI‑64 oder einfache Muster verwendet werden.

• „/64 ist Verschwendung“: Die Größe des IID-Raums ist Designvoraussetzung für SLAAC und ND; die Knappheit liegt in der Präfixvergabe und im Routing-Design, nicht in der Zahl der Hostadressen pro Link.
• Prefix-Delegation falsch interpretiert: Ein vom Provider delegiertes /56 gehört in der Regel an den Edge-Router; dahinter entstehen mehrere /64-Netze (z. B. pro VLAN). Ein einzelnes /56 als „LAN“ erschwert Policies, RA/DHCPv6-Design und Adressdokumentation.
• „Anycast = eigener Adresstyp“: Anycast ist in IPv6 funktional ein Unicast-Präfix, das auf mehreren Interfaces identisch konfiguriert wird; die Präfixstruktur unterscheidet sich nicht, aber Routing und Monitoring müssen Anycast-Realitäten abbilden.
• IID-Sicherheit überschätzt: Temporäre IIDs schützen nicht vor Erreichbarkeitsscans auf Dienste, die auf stabilen Adressen lauschen; umgekehrt sind stabile, gut dokumentierte IIDs betrieblich sinnvoll, solange Filter, Segmentierung und Hardening stimmen.

Routing- und Betriebsfolgen: SLAAC vs. DHCPv6, Prefix Delegation, Filterregeln und häufige Fehlinterpretationen

SLAAC und DHCPv6: Kontrollumfang, Stabilität der Interface-Identifier und Log-Korrelation

SLAAC (Router Advertisements, RA) und DHCPv6 lösen unterschiedliche Teilprobleme und beeinflussen Routing und Betrieb deutlich. SLAAC verteilt primär den Präfix (PIO) und Default-Gateway-Informationen, während DHCPv6 zustandsbehaftet Adressen und zusätzliche Parameter liefern kann. In der Praxis entsteht Komplexität weniger durch das „entweder/oder“, sondern durch Mischbetriebe: RA bleibt für den Default Route zwingend relevant, auch wenn Adressen per DHCPv6 bezogen werden. Ohne konsistente RA-Policy (z. B. RA Guard an Access-Ports) entstehen schwer zu diagnostizierende „Ghost“-Default-Routen.

Operativ kritisch ist die Frage, wie stabil und wie identifizierbar Interface-Identifier (IID) sind. EUI-64-basierte IIDs sind heute in Enterprise-Clientnetzen selten wünschenswert, weil sie Hardwarebezug herstellen und damit Tracking erleichtern. Moderne Betriebssysteme nutzen standardmäßig temporäre Adressen nach RFC 8981 (Privacy Extensions) oder „stable, opaque“ IIDs nach RFC 7217. Das verbessert Privatsphäre, erschwert aber Korrelation in Logs, insbesondere wenn Security-Analysen auf IP-basierten Identitäten beruhen. DHCPv6 kann hier durch feste Leases und DUID/IAID-Korrelation helfen, löst aber nicht automatisch das Problem, dass Geräte parallel temporäre SLAAC-Adressen verwenden dürfen, sofern RA dies zulässt.

• Typische Mischbetriebs-Falle: DHCPv6 liefert Adresse, aber RA setzt Managed-Flag (M) nicht konsistent oder RA fehlt zeitweise; Clients behalten dann eine gültige Adresse, verlieren jedoch den Default Route und wirken „teilweise erreichbar“ (L2 ok, L3 bricht intermittierend).
• Stabilität vs. Privatsphäre: Privacy-Adressen rotieren (je nach OS/Policy), wodurch IP-basierte Allow-Lists und forensische Korrelation an Aussagekraft verlieren; stabile IIDs nach RFC 7217 bleiben pro Präfix stabil, sind aber nicht aus MAC ableitbar.
• Adressauswahl/Quelladresspräferenz: Mehrere globale Adressen (z. B. temporär + stabil) beeinflussen ausgehende Sessions; Fehlannahmen entstehen, wenn Firewall-Regeln nur eine der Adressen berücksichtigen und Rückverkehr dadurch verworfen wird.
• Operatives Minimum an Telemetrie: Auf L2 sollten RA-Ereignisse sichtbar sein (Switch-Logs/Telemetry für RA Guard), auf L3 die ND/Neighbor-Cache-Flaps; ohne diese Signale werden SLAAC-Probleme häufig fälschlich als „Routing instabil“ klassifiziert.

Prefix Delegation (PD): Routing-Dynamik am WAN-Rand und interne Präfix-Disziplin

DHCPv6 Prefix Delegation verschiebt die zentrale Ressource „gerouteter Präfix“ auf CPE/Edge-Router und erzeugt damit eine Kopplung zwischen WAN-Status und interner Adressierung. Wechselt der delegierte Präfix (Renumbering), müssen interne Router Advertisements, Route-Announces (z. B. via IGP) und Filterregeln zeitnah folgen. Wird PD ohne klare interne Präfix-Planung eingesetzt, entstehen inkonsistente Präfixlängen je Segment, überschneidende Zuteilungen oder „verwaiste“ Routen, wenn der Edge alte Präfixe nicht sauber zurückzieht.

Eine häufige Fehlinterpretation betrifft die Rolle der Präfixlänge: PD liefert oft ein /56 oder /60, während Endnetze in der Regel /64 benötigen (SLAAC und zahlreiche ND/IPv6-Mechanismen setzen /64 als Standard-L2-Subnetz voraus). Das Vergeben von /80- oder /96-Endnetzen „wie bei IPv4“ führt zu unerwartetem Verhalten (fehlende SLAAC-Funktion, unklare Neighbor-Discovery-Reichweite, abweichende Implementationen). Ebenso problematisch ist es, ein gesamtes delegiertes /56 direkt auf ein einzelnes LAN zu announcen und anschließend intern „per Hand“ zu subnetten, ohne Routing und RA-Policies konsistent nachzuführen.

Filterregeln und Schutzmechanismen: RA Guard, DHCPv6 Guard, ND-Inspektion und ICMPv6

IPv6-Betrieb scheitert in der Praxis häufiger an falsch geschnittenen Filterregeln als an Routing-Protokollen. Besonders gefährlich ist das pauschale Blocken von ICMPv6: Path MTU Discovery, Neighbor Discovery (NS/NA), Router Solicitations/Advertisements sowie Multicast Listener Discovery benötigen ICMPv6-Funktionalität. Wer ICMPv6 „wie ICMPv4“ behandelt, produziert fragmentierte Sessions, sporadische Timeouts und schwer reproduzierbare Fehlerbilder. Sinnvoll sind stattdessen granular erlaubende Regeln (Typ/Code-basiert) und klare Zonenmodelle.

Am Access-Layer gehören unerwünschte Router Advertisements und rogue DHCPv6-Server zu den häufigsten Ursachen für falsch gesetzte Default-Routen oder DNS-Server. Switch-seitige Schutzfunktionen (RA Guard, DHCPv6 Guard/Shield, ND Inspection) müssen jedoch an das jeweilige Netzdesign angepasst werden, insbesondere wenn legitime RAs von mehreren Routern (Redundanz) oder legitimer DHCPv6 aus bestimmten VLANs kommen. Fehlkonfigurationen wirken schnell wie „Routing flapped“, sind aber in Wahrheit L2-basierte Kontrollverlust-Effekte.

• ICMPv6 nicht pauschal sperren: Erforderlich sind mindestens Neighbor Discovery (z. B. Typen 133–136), PTB (Packet Too Big) und Time Exceeded; Regeln sollten auf relevante Zonen/Interfaces begrenzt und nicht global verworfen werden.
• RA Guard gezielt einsetzen: Trusted-Uplinks zu Routern als „trusted“ markieren, Client-Ports als „untrusted“; dadurch werden unerlaubte RAs unterbunden, ohne Redundanzrouter zu stören.
• DHCPv6 Guard/Shield: DHCPv6-Server- und Relay-Ports fest definieren; rogue Replies (Advertise/Reply) auf Client-Ports blockieren, um DNS- und Lease-Manipulation zu verhindern.
• ND/Neighbor-Cache-Schutz: Je nach Plattform Funktionen gegen ND-Flooding und Spoofing aktivieren; andernfalls kippt Erreichbarkeit unter Last, obwohl das Routing korrekt bleibt.

Häufige Fehlinterpretationen: Subnetting-Denkmuster, „IPv4-Mapping“ und PD-Renumbering

Ein verbreitetes Missverständnis ist die Annahme, ein LAN könne „effizienter“ mit Präfixen kleiner als /64 betrieben werden, analog zu IPv4-/27- oder /28-Planungen. Für klassische Ethernet-Segmente unterminiert das zentrale Mechanismen: SLAAC erwartet /64; auch wenn statische Adressierung in kleineren Präfixen technisch möglich ist, entstehen Abweichungen bei Implementierungen, Tools und Sicherheitsannahmen. Praktisch betrachtet führt das zu mehr Sonderfällen, nicht zu mehr Kontrolle.

Ebenfalls häufig ist die falsche Gleichsetzung von IPv4-NAT-Modellen mit IPv6: Der Wegfall von NAT als Standardmittel verschiebt die Sicherheitsgrenze auf zustandsbehaftete Firewalls und saubere Segmentierung. Gleichzeitig erzeugen temporäre SLAAC-Adressen und mehrere Adressen pro Interface den Bedarf, Filterregeln nicht an einzelnen IPs festzumachen, sondern an Präfixen, Rollen und Zuständen. Bei PD wird zudem übersehen, dass ein Präfixwechsel nicht nur „neue Adressen“ bedeutet, sondern auch DNS, Zertifikatsbindungen, Logging-Pipelines, Monitoring-Targets und statische Whitelists betrifft.

• „/64 ist Verschwendung“: In L2-Endnetzen ist /64 ein Interoperabilitätsstandard; Abweichungen erhöhen Betriebsrisiko, insbesondere bei SLAAC, ND und Tooling.
• „DHCPv6 ersetzt RA“: DHCPv6 liefert keinen Default Gateway; ohne RA fehlt die Standardroute, selbst wenn Adressen korrekt bezogen wurden.
• „PD ist statisch wie ein Provider-IPv4“: Delegierte Präfixe können wechseln; ohne Renumbering-Design (kurze RA-Lifetimes, saubere Route-Withdrawals, DNS-Aktualisierung) entstehen lange Übergangsphasen mit Parallelpräfixen und unklaren Policy-Grenzen.
• „IPv4-mapped IPv6 ist ein Übergang für Clients“: IPv4-mapped Adressen (::ffff:0:0/96) sind primär eine API/Socket-Repräsentation innerhalb von Hosts; sie sind nicht als on-the-wire-Adressierung und nicht als Routing-Präfix im Netzdesign zu behandeln.