Stellt euch vor, ihr habt eine Menge von Servern, welche ausschließlich über IPv6-Adressen verfügen und deshalb keine Dienste nutzen können, welche nur über IPv4 bereitgestellt werden. Wer sich dies nicht vorstellen mag, findet in „IPv6… Kein Anschluss unter dieser Nummer“ ein paar Beispiele dafür.

Was kann man nun tun, damit diese IPv6-only-Hosts dennoch mit der IPv4-only-Welt kommunizieren können?

Eine mögliche Lösung ist die Nutzung eines Dualstack-Proxy-Servers. Das ist ein Server, welcher über Adressen beider Internet-Protokoll-Versionen verfügt und so stellvertretend für einen IPv6-Host mit einem IPv4-Host kommunizieren kann. Das folgende Bild veranschaulicht den Kommunikationsablauf:

Im Bild ist zu sehen:

1. Wie IPv6-Host A eine Verbindung über IPv6 zum Proxy-Server B aufbaut und diesem bspw. die gewünschte URL mitteilt
2. Der Proxy-Server B baut nun seinerseits eine IPv4-Verbindung zu IPv4-Host C auf, welcher die gewünschten Inhalte bereitstellt
3. IPv4-Host C sendet seine Antwort über IPv4 an den Proxy-Server
4. Der Proxy-Server sendet die gewünschten Inhalte anschließend via IPv6 an den IPv6-Host A zurück

Das obige Video demonstriert die Nutzung eines Proxy-Servers durch den Abruf einer Demo-Seite mit curl:

1. Mit dem host-Kommando wird gezeigt, dass für die Demo-Seite kein AAAA-Record existiert; die Seite ist also nicht via IPv6 erreichbar
2. Mit dem ip-Kommando wird geprüft, dass der Host auf dem Interface ens18 ausschließlich über IPv6-Adressen verfügt
3. Ohne Proxy ist die Demo-Seite nicht abrufbar
4. Erst durch Nutzung des Proxys kann die Seite abgerufen werden

Funktioniert das auch von IPv4 nach IPv6?

Ja. Entscheidend ist, dass der verwendete Proxy beide IP-Versionen unterstützt.

Welcher Proxy ist empfehlenswert?

Der Proxy-Server muss beide IP-Versionen beherrschen. Ich persönlich bevorzuge Squid. Dieser ist in so gut wie allen Linux-Distributionen verfügbar, weit verbreitet, robust und selbstverständlich Freie Software.

Sind damit alle Herausforderungen bewältigt?

Für eine Virtualisierungs-Umgebung mit einer IPv4-Adresse und einem /64-IPv6-Netzsegment funktioniert diese Lösung gut. Sie funktioniert auch in jeder anderen Umgebung, wie gezeigt. Man beachte jedoch, dass man mit nur einem Proxy einen Single-Point-of-Failure hat. Um diesem zu begegnen, kann man Squid mit keepalived hochverfügbar gestalten.

Keepalived ist ebenfalls Freie Software. Sie kostet kein Geld, erhöht jedoch die Komplexität der Umgebung. Verfügbarkeit vs. Komplexität möge jeder Sysadmin selbst gegeneinander abwägen.

Wie mache ich meine IPv6-Dienste für IPv4-User erreichbar, die keinen Proxy haben?

Das Stichwort lautet Reverse-Proxy. Ein Artikel dazu erscheint in Kürze in diesem Blog. ;-)

Weiterführende Quellen und Links

• http://www.squid-cache.org/
• https://keepalived.org/
• RHEL 9 Docs: Configuring the Squid caching proxy server
• https://wiki.ubuntuusers.de/Squid/
• https://de.wikipedia.org/wiki/Squid
• Enable Sysadmin: Setting up a Linux cluster with Keepalived: Basic configuration
• Enable Sysadmin: Keepalived and high availability: Advanced topics
• https://keepalived.readthedocs.io/en/latest/introduction.html

Das ist eine gute Frage. Hat man „IPv6… Kein Anschluss unter dieser Nummer“ gelesen, kann man mich sicher fragen, warum ich mir das antue, wo doch überall Stolpersteine und Probleme lauern. Und ich kenne einige Personen, die sich lieber eine Axt ins Bein schlagen, eine Nadel unter die Fingernägel schieben oder Broccoli essen würden, statt sich mit IPv6 zu beschäftigen.

Die Antwort ist ganz einfach. Ich tue dies, weil ich es kann, Spaß daran habe und IPv4-Adressen knapper und teurer werden.

Möchte man Dienste im Internet anbieten, benötigt man IP-Adressen. Üblicherweise bekommt man zu den gängigen Angeboten von Virtual Private Server, Dedicated Server, etc. eine IPv4-Adresse und ein /64-IPv6-Netzsegment kostenlos. Zusätzliche IPv4-Adressen kosten Stand heute zwischen 2,00 € und 5,00 € pro Monat, wobei häufig noch eine saftige Einrichtungsgebühr hinzukommt. Im Abschnitt Preisübersicht findet ihr das Ergebnis einer kurzen Internetrecherche.

Da ich einen Proxmox-Host und ein /64-IPv6-Netzsegment für Spiel-, Spaß- und Laborumgebungen besitze, möchte ich mich gern damit auseinandersetzen. Und sei es nur, um zu lernen, wo es noch überall klemmt und mit welchen Workarounds man die existierenden Klippen umschiffen kann. Wundert euch also nicht, wenn es in Zukunft noch den ein oder anderen Artikel zu diesem Thema gibt.

Preisübersicht

• Hetzner IP-Preise
• Contabo VPS-Konfigurator
• AWS Germany Neues Kostenmodell und neues Insights-Feature für öffentliche IPv4-Adressen
• Azure IP-Adressen Preise
• IONOS IP-Adressen
• Open Telekom Cloud Leistungsbeschreibung inkl. Preisliste

Das Jahr 2023 neigt sich langsam dem Ende zu. In diesem Monat for 25 Jahren wurde das IPv6-Protokoll in RFC 2460 beschrieben, bevor es 2017 in RFC 8200 als Internet-Standard von der Internet Engineering Task Force (IETF) veröffentlicht wurde.

Seit immerhin sechs Jahren ist dieses IP-Protokoll also schon standardisiert. Da sollte man doch meinen, dass man im Jahr 2023 problemlos ein vernetztes System betreiben kann, welches nur mit einer IPv6-Adresse mit dem Internet verbunden ist. Leider ist dem nicht so.

In den folgenden kurzen Abschnitten schreibe ich mir meinen Frust von der Seele und dokumentiere, was heute alles mit IPv6 noch nicht geht. Falls ihr weitere Fälle ergänzen möchtet, nutzt gerne die Kommentare, um eurem IPv6-Frust Luft zu machen.

Red Hat Satellite 6.14

Bei der Planung einer Red Hat Satellite 6.14 Installation bin ich über folgenden Satz in der Dokumentation gestolpert:

You can install Satellite and Capsules in IPv6-only systems, dual-stack installation is not supported.

URL: https://access.redhat.com/documentation/en-us/red_hat_satellite/6.14/html/installing_satellite_server_in_a_connected_network_environment/preparing-environment-for-installation-in-ipv6-network_satellite

Das ist schade. Betreibt man Server in IPv4- und IPv6-Netzwerken und möchte eine vollständig unterstützte Lösung, muss man aktuell zwei Satellite installieren.

Ich wollte jedoch einen Satellite in einer reinen IPv6-Umgebung installieren, daher sollte mich diese Anmerkung nicht weiter stören. Da störten mich folgende Stellen im gleichen Kapitel der Dokumentation schon mehr:

You must deploy an external IPv4 HTTP proxy server. This is required because Red Hat Content Delivery Network distributes content only over IPv4 networks, therefore you must use this proxy to pull content into the Satellite on your IPv6 network.

You must configure Satellite to use this IPv4 HTTP proxy server as the default proxy. For more information, see Adding a Default HTTP Proxy to Satellite.

URL: https://access.redhat.com/documentation/en-us/red_hat_satellite/6.14/html/installing_satellite_server_in_a_connected_network_environment/preparing-environment-for-installation-in-ipv6-network_satellite#requirements-for-installation-in-an-ipv6-network_satellite

Zuerst wollte ich dies nicht glauben, habe einen Fehler in der Dokumentation vermutet. Es ist 2023 und Content Delivery Network (CDN) von Red Hat unterstützt kein IPv6? Das kann doch nicht sein! Kann es doch:

• Unable to register system using subscription-manager over IPv6 interface
• Public CIDR Lists for Red Hat (IP Addresses for cdn.redhat.com)

Der zweite Link in obiger Liste führt ausschließlich IPv4-Adressen auf. Einzelne Kommentare lassen darauf schließen, dass es jedoch durchaus Interesse an IPv6-Konnektivität gibt. Also installiere ich erstmal einen Proxy-Server mit Dual-Stack, damit ich Hosts aus einem reinen IPv6-Netzwerk via subscription-manager register beim Red Hat Subscription Management (RHSM) registrieren kann.

subscription-manager cli command does not support IPv6 proxy

Nachzulesen in:

• RHEL-7209
• BZ 2225403
• candlepin/subscription-manager #3302

Die gute Nachricht, es sind gefixte Versionen für RHEL 9 und RHEL 8 in Aussicht. Auf einen Fix für RHEL 7 würde ich nicht warten und diese Systeme lieber migrieren oder aktualisieren, ist das Support-Ende doch bereits nah.

Also lege ich mein Vorhaben erstmal beiseite und wende mich anderen Wochenendprojekten zu, die vielleicht mehr Erfolg versprechen.

ansible-galaxy does not work on IPv6 only hosts

Nun guck an, da ist mein Kollege Andreas also schon im Jahr 2022 in den Ansible-Issue #77308 gelaufen. Ihr interessiert euch für den aktuellen Stand dieser Geschichte? Siehe:

• Ansible-galaxy (galaxy.ansible.com) is not usable for ipv6-only hosts #3002
• Missing IPv6 DNS/IP for S3 bucket used for ansible-galaxy

So langsam komme ich mir vor wie ein bekannter spanischer Junker, welcher gegen Windmühlen pardon Riesen anritt. Aber es ist ja nicht so, dass mir die Themen ausgehen. Klone ich mir halt ein Repo von Github und trage ein bisschen zu Open Source bei…

IPv6 support for cloning Git repositories #10539

Ich spare mir viele Worte und präsentiere nur folgenden Code-Block:

$ host -t AAAA github.com
github.com has no AAAA record

URL zur Diskussion: https://github.com/orgs/community/discussions/10539

Auch hier kein Anschluss unter dieser Nummer.

Fazit

Ich möchte meine jüngsten Erfahrungen umschreiben mit: „An manchen Tagen hat man kein Glück und an anderen kommt auch noch Pech dazu.“

Für Red Hat möchte ich sagen, ist es ein Priorisierungs-Thema. Wenn der Wunsch nach IPv6 auf Kundenseite hinreichend groß wird, wird man hier handeln. Bei Github wird es ähnlich sein. Ich muss vielleicht nur nochmal 25 Jahre warten.

• Welche Erfahrungen habt ihr mit IPv6 gemacht?
• Habt ihr es schon an den Nagel gehängt; oder bleibt ihr hartnäckig und gebt nicht auf?
• Ich freue mich auf eure schönsten Fehlschläge und Erfolgsmomente.