willst Du nicht besser den ursachen auf den grund gehen als die symptome zu unterdrücken?
Generell kannst du das so machen. Aber welche Probleme gab es mit IPv6 ? Normalerweise läuft das absolut problemlos.
Mit ipv6-only Servern wirst du dann aber nicht mehr kommunizieren können.
Langsam schwant mir was, zumindest falls diese Aussage stimmt:
Docker unterstützt auch IPv6, jedoch ist es nicht standardmäßig aktiviert. Wenn du IPv6 mit Docker nutzen möchtest, musst du dies manuell aktivieren
Jap.
Natürlich muss man sich mit IPv6 beschäftigen, da einige Dinge anders geregelt sind, als bei IPv4. Aber wenn man es einmal verstanden hat, ist es nicht kompliziert, und die Möglichkeiten sind erheblich größer und vielfältiger, gerade wenn man mit Containern arbeitet. Bei mir laufen einige Container IPv6-only, weil so viele IPv4 Adressen könnte ich gar nicht kaufen, um den Portkonflikten aus dem Weg zu gehen.
Zusätzlich zu den Ecken und Kanten eines ungeliebten design-by-committee Protokolls hat IPv6 bei Netcup noch einige Besonderheiten, die besonders dann unangenehm werden, wenn man nicht nur eine Adresse für den Host benutzt sondern Container mit eigenen Adressen ausstattet. Wenn es IPv6 sein muss (meiner Meinung nach muss es das nicht), dann sollte man hier die selbe Konstruktion wie mit IPv4 nutzen: Reverse Proxy auf dem Host oder in einem Container, der die IPv6-Adresse trägt. In den Containern braucht man dann keine öffentlichen IPv6-Adressen und damit eigentlich gar kein IPv6.
Wenn man mit IPv6 beginnt, ist es sicherlich klug, wenn man den Containern nicht direkt eine IPv6 aus dem Public Netzwerk gibt, sondern mit einem Reverse Proxy bzw. Loadbalancer arbeitet. Dieser kann dann im Dualstsack arbeiten, IPv4 und IPv6 terminieren und dann ins Backend z.B. nur noch IPv4 sprechen. Dann braucht man sich bei Docker & Co. gar nicht mit der Problematik beschäftigen und kann den Clients dennoch Dualstack anbieten.
Ich halte das für kompletten Unsinn, da man damit die größten Vorteile von IPv6 verschenkt und die gleichen Fehler wieder macht, die man auch schon unter IPv4 gemacht hat. Aber wie heißt es so schön: Wer keine Arbeit hat, macht sich welche, und des Menschen Wille ist sein Himmelreich.
Neben der von dir genannten Möglichkeit über sysctl gibt es auch noch die Möglichkeit IPv6 über den Kernel zu deaktivieren.
Dazu einfach "ipv6.disable=1" an die Kernel Cmdline anhängen. Über den Bootloader grub würdest du das in /etc/default/grub unter dem Konfigurationsparameter GRUB_CMDLINE_LINUX="ipv6.disable=1" eintragen und mit update-grub scharfschalten.
Dadurch wird IPv6 komplett deaktiviert.
Dass das ganze keine gute Idee ist, haben dir meine Vorredner ja bereits mitgeteilt. Ich gebe hier außerdem noch zu Beachten, dass einige Software sich anfängt merkwürdig, bis hin zu instabil zu verhalten, oder schlicht komplett den Dienst verweigert wenn du den IPv6 Stack deaktivierst.
Gerade in Verbindung mit Docker führt dies sehr häufig zu Mehrarbeit, wenn der Dienst innerhalb des Containers konfiguriert wurde sich auf IPv4 und IPv6 zu binden.
EDIT: kleiner Nachtrag, nach update-grub ist natürlich noch ein reboot notwendig.
Wenn man mit IPv6 beginnt, ist es sicherlich klug, wenn man den Containern nicht direkt eine IPv6 aus dem Public Netzwerk gibt, sondern mit einem Reverse Proxy bzw. Loadbalancer arbeitet. Dieser kann dann im Dualstsack arbeiten, IPv4 und IPv6 terminieren und dann ins Backend z.B. nur noch IPv4 sprechen. Dann braucht man sich bei Docker & Co. gar nicht mit der Problematik beschäftigen und kann den Clients dennoch Dualstack anbieten.
Unbewusst habe ich ja wohl genau das gemacht, bzw. ist das Verhalten von Docker Containern im Bridge-mode, allerdings per Default erstmal nur IPv4.
Docker bearbeitet ja dann die iptables Regeln, ebenso wie meine UFW. Auch das birgt Konfliktpotential. Klassisches SNAT und DNAT kenne ich vor allem auch über iptables masq, möglicherweise macht Docker das aber auch intern anders...
Ich halte das für kompletten Unsinn, da man damit die größten Vorteile von IPv6 verschenkt und die gleichen Fehler wieder macht, die man auch schon unter IPv4 gemacht hat.
in der nächsten virtuellen umgebung verwende ich ULAs und NPTv6. IPv6 re-numbering ist ja aus der hölle.
und im LAN zuhause eine kombination aus ULA und GUA. ULA fürn DNS und GUA für alles andere. wenn ich dann mal endlich natives IPv6 zuhause habe ...
Um mal deine Frage zu beantworten und nicht nur (mehr oder weniger) durch die Blume gesagt zu bekommen, dass du blöd bist wenn du v6 deaktivierst:
oder gibt es noch eine andere Möglichkeit IPv6 von meinem VPS zu deaktivieren?
echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6 ohne reboot
und dann in eine datei namens
/etc/sysctl.d/01-disable-ipv6.conf
net.ipv6.conf.all.disable_ipv6 = 1
reinschreiben um es permanent zu machen.
Dann bist du alle Sorgen los 
Nachtrag: Macht Natting in einer IPv6-Welt überhaupt Sinn? War es nicht auch ein Ansatz dieser Protokollversion mit dieser "Adressspartechnik" endlich aufhören zu können?
Völlig richtig. Leider ist Docker was IPv6-Support als auch nftables-Support angeht sehr durchwachsen. iptables wird nach wie vor vom Docker Daemon eingesetzt obwohl es bereits längst den Legacy-Status besitzt und nftables der Nachfolger ist.
IPv6-NAT würde ich persönlich immer vermeiden - ausser wenn es halt wirklich nicht anders geht. Mailcow bedient sich beispielsweise per Standard an IPv6-NAT, könntest du aber auch mittels mailcow.conf auf ein Public-Prefix anpassen (sollte dann aber auch entsprechend gefirewalled sein)
Es bleibt für also nach wie die Fage offen, was grund genug ist sich damit intensiver auseinanderzusetzen. Weg geht IPv6 ja sicher nicht mehr.
Ich kann und möchte dir nicht IPv6 aufzwingen aber kann dir durchaus die Empfehlung geben, es künftig zu verwenden.
Generelle Annahme ist oft leider:
1. IPv6 trackt mich! Ich bekomm ja ein Prefix und meine Endgeräte eine öffentliche Adresse!!
2. IPv6 hat kein NAT, ist also unsicher!
3. Ein Router sollte keine Firewall darstellen und das Endgerät muss sich nicht darum kümmern "Secure by design" zu sein, weil es ja "nur in einem lokalen Netzwerk" ist.
4. IPv6 arbeitet mit öffentlichen Adressen und keinen lokalen Adressen? Wieso sollte ich öffentliche Adresse lokal nutzen?
Antworten aus meiner Sicht dazu:
1. Nein tut es nicht. EUI-64, dynamische Prefixvergabe des Providers sowie SLAAC allgemein werden immer eine temporäre Adresse und eine MAC-abgeleitete IPv6 Adresse anhand des Prefixes zuweisen. Jegliches Betriebssystem mit IPv6 Support wird jedoch für die Kommunikation per Standard die temporäre, also ständig wechselnde Adresse verwenden. Das sind insgesamt 4x 16Bit Hexadezimale Blöcke aka. Theoretisch 2⁶⁴ verschiedene Adressmöglichkeiten. Wenn das jemand herausfindet, liegt eher ein ganz anderes Problem in der Infrastruktursicherheit vor.
2. NAT war nie ein Sicherheitskonzept, sondern ein Konzept zur Einsparung vom bereits seit Jahren ausgeschöpften Pool an öffentlich verfügbaren IPv4 Adressen. Universitäten / Hochschulen haben beispielsweise meist mindestens ein /16-IPv4 Subnet zugewiesen bekommen und vergeben auch aus diesen jeweilige Adressen an Endgeräte. Das gleiche Konzept wie es bei IPv6 existiert war ursprünglich auch bei IPv4 der Fall. Eine Firewall (z.B. auf dem ISP-Router) sollte IMMER diese Funktion erfüllen und nicht NAT. Ebenfalls gibt es verschiedene, sogenannte NAT-Traversal Methoden die den "Sicherheitsaspekt" umgehen können.
3. Falsch! Die Antwort zu Punkt 2 erklärt das bereits ganz gut. Ebenfalls sollte man sich folgende Frage stellen: Kann ich davon ausgehen dass z.B. IoT Geräte im Internen Netzwerk nicht auch neugierig sein können? Lässt sich denn auch davon ausgehen dass z.B. Windows-Clients im lokalen Netzwerk 100% Viren/RAT-Frei sind und im Internen Netzwerk keine Kommunikation suchen? Nein! Endgeräte sollten immer bereits selbst ein gewisses Grundlevel an Absicherung besitzen. Sei es nur dass Debug-Ports o.ä. einfach generell nicht per LAN/WLAN-Schnittstelle des Endgerätes lauschen.
4. Firewall ist das Schlüsselwort. Und sofern der Router bzw. die Endgeräte bei der Adresslokalisierung feststellen dass sie sich jeweils über lokalen Weg erreichen können, tun sie das auch. Ja, immer - ausser man will es explizit nicht. Und selbst wenn man sich mit lokaler Adressierung wohler fühlt, kann man das ebenfalls mit einer zusätzlichen IPv6 im sogenannten ULA (Unique Local Address) Prefix-Bereich tun.
Abschließend kann ich nur sagen:
Freut mich sehr zu lesen, dass du grundsätzlich dich mit dem Thema IPv6 auseinandersetzt und dich nicht vollständig verschließt. Leider gibt es oft die schnelle Annahme: brauch ich nicht, bleibt einfach aus.
Dabei ist IPv4 einfach seit Jahren schon ein veraltetes Auslaufprodukt dass sich mit NAT über Wasser hält, aber längst an den Kapazitätsgrenzen angekommen ist. Auch die Adressvergabe bei IPv6 im Heimnetz ist mittels IPv6-RA wesentlich angenehmer.
da bin ich nun etwas verunsichert.
Welche Befürchtungen hast du denn?
Ich habe auf allen Servern außer SMTP und neuerdings den Nameservern ip6 abgeschaltet.
Und auch beim Einrichten einer Fritzbox ist ip6 das Erste, was ich abschalte (sofern es kein kastriertes Internet ist).
jemand mit IPv6-Only Internetanschluß nicht erreichen kann
Das wird nicht vorkommen, da es dazu Proxys gibt.
das jeder ernstzunehmende Mail-Node über eine IPv4 Adresse verfügen dürfte?
Das kannst du. Und falls irgendein arroganter Admin es abschaltet, gibt es noch immer die Proxys.
Die Gefahr eines wildgewordenen Spamfilter(admin)s ist da weitaus größer.
Weg geht IPv6 ja sicher nicht mehr.
Nein, aber es ist sehr wahrscheinlich, dass ich es für den Rest meines Beruflebens weiter abschalten kann, ohne Nachteile befürchten zu müssen.
irgendein arroganter Admin es abschaltet
ohne worte
