Obwohl Linux als freie Software kostenlos verfügbar ist, setzen viele beim Unternehmenseinsatz auf Enterprise-Distributionen mit Support. Wo die Stärken der ... (mehr)

Suche Relay

Sollen native IPv6-Adressen im IPv6-Internet angesprochen werden, sucht der 6to4-Router beziehungsweise 6to4-Host ein nahes 6to4-Relay. Hierfür existiert die IPv4-Anycast-Adresse 192.88.99.1. IPv6-Pakete an native IPv6-Adressen werden also von 6to4-aktivierten Knoten ebenfalls eingekapselt, wobei die Zieladresse des IPv4-Headers 192.88.99.1 ist. Diese Pakete landen beim nächstgelegenen 6to4-Relay und werden gemäß normaler IPv6-Routing-Mechanismen zugestellt.

Die Rückantwort des IPv6-Only-Knotens wird ebenfalls über ein 6to4-Relay geroutet, wobei dies nicht zwangsläufig dasselbe sein muss wie auf dem Hinweg. Dies kann in der Praxis zu den typischen, durch asymmetrisches Routing verursachten Problemen führen, zum Beispiel bei Stateful-Firewalls, die Antwortpakete nicht zuordnen können. In diesem Zusammenhang muss auch sichergestellt sein, dass die Knoten im IPv6-Internet eine Route zu einem 6to4-Relay kennen – dies ist jedoch derzeit nicht immer der Fall. Daneben hat 6to4 den Nachteil, dass NAT nur dann unterstützt wird, wenn der 6to4-Router beziehungsweise das 6to4-Relay gleichzeitig das NAT-Device ist. 6to4 wird von den meisten gängigen Betriebssystem-Plattformen unterstützt.

6rd – die Evolution

Die Tunneltechnologie 6rd [3] basiert auf 6to4 und wurde von Rémi Després entworfen. 6rd und 2007 vom französischen Provider FREE in wenigen Monaten eingeführt. Die Buchstaben "RD" stehen einerseits für Rapid Deployment und andererseits für die Initialen des Entwicklers. Im Gegensatz zu 6to4 arbeitet 6rd mit den Präfixen der Endkunden, statt ein eigenes Präfix zu nutzen. Dies vereinfacht die Einführung deutlich. Nachdem zunächst ein von Després selbst geschriebener Informational-RFC veröffentlicht wurde, bereitet die IETF die Standardisierung nun im Standard-RFC 5969 vor.

Im Gegensatz zu 6to4 wandern die Daten für die Kommunikation zwischen internen IPv6-Only-Knoten und externen IPv6-Only-Knoten, die über das IPv4-Internet verbunden sind, über Provider-eigene 6rd-Relays. Der Provider behält die vollständige Kontrolle über die IPv6-Kommunikation, die über ihn läuft und kann daher auch seine eigenen Präfixe nutzen. Da auch hier die öffentliche IPv4-Adresse des 6rd-Relays kommuniziert werden muss, ist sie ebenfalls in die IPv6-Adresse integriert.

Eine Besonderheit bei 6rd ist allerdings, dass das einem Provider zugewiesene Präfix flexibel ist und somit bei längeren Präfixen nicht mehr genügend Bits in der IPv6-Adresse zur Verfügung stehen. Erhält der Provider ein Standard-Präfix (/32) von der Regional Internet Registry (RIR), so kann er zwar die IPv4-Adresse in den folgenden 32 Bits unterbringen, dem Kunden aber dann nur noch ein einzelnes Subnetz zur Verfügung stellen, da die hinteren 64 Bits der IPv6-Adresse für die Interface-ID reserviert sind.

Im Fall von FREE erhielt der Provider später ein /26-Präfix. Die Adresse wurde so aufgeteilt, dass nach dem Präfix die IPv4-Adresse hexadezimal eingebettet ist, dann zwei reservierte Bits folgen und schließlich die 4 Bit lange Subnet-ID. Eine andere Variante, um bei längeren Provider-Präfixen festgelegte Bits zu sparen, besteht darin, redundante Teile der IPv4-Adresse auszulassen. Nutzt ein Provider für seine Kunden zum Beispiel immer ein bestimmtes /18-Subnetz, kann er die vorderen 18 Bits der IPv4-Adresse weglassen, ohne relevante Informationen zu verlieren. 6rd ist ein interessanter Ansatz mit dem Potenzial, das alte 6to4 mittelfristig weitgehend abzulösen.

Abbildung 6: Bei 6rd wandern die Daten für die Kommunikation zwischen internen IPv6-Only-Knoten über Provider-eigene 6rd-Relays.
comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023