| « José 3.0 ist fertig! | Office 97 deinstallieren - ohne CD » |
Wie man IPv6 richtig deaktiviert
Ich liebe Windows 7 und Server 2008 R2, ein richtig großer Wurf aus Redmond. Allerdings kann ich mit IPv6 innerhalb meiner LANs nix anfangen, ergo liegt es nahe, dieses Protokoll vollständig zu deinstallieren. Aber wie? Im Internet geistern die abenteuerlichsten Anleitungen dazu herum, dabei sind es bloss ein paar Mausklicks und ein wenig Tipparbeit.
regedit starten und zu HKLM\System\CurrentControlSet\System\Services\TCPIP6\Parameters navigieren und im rechten Fenster einen Eintrag anlegen: Typ "DWORD-Wert (32Bit)" - das gilt auch für 64Bit-Systeme!
Der Eintrag bekommt den Namen "DisabledComponents" (ohne die Hochkommas) und erhält den (Hex-)Wert 0x000000ff (dezimal: 255).
Follow up:
regedit schliessen, Netzwerk- und Freigabecenter öffnen, in der linken Spalte auf "Adaptereinstellungen ändern" klicken und folgende Schritte nacheinander für alle Netzwerkadapter durchführen:
- Adapter rechts anklicken
- Eigenschaften auswählen
- die Bindung des Adapters an "Internetprotokoll Version 6 (TCP/IPv6)" entfernen
- mit OK bestätigen
Wenn das mit allen Adaptern gemacht ist, System neu starten und den Gerätemanager öffnen. Unter Netzwerkadapter taucht nun ein Teredo Pseudo Interface mit einem gelben Ausrufezeichen auf. Den Eintrag rechtsklicken und Deinstallieren wählen. Einen weiteren Reboot später ist IPv6 auf dem Rechner vollständig deaktiviert (und ipconfig /all sieht wieder ordentlich aus *g*).
Gar nicht so schwer, oder?
15 Kommentare
Wir haben umfangreiche Probleme gehabt, wenn es darum geht, Ipv6 abzuschalten.
Viele der netzwerkseitigen Kommunikation läuft ohne weitere Konfiguration über IPv6, auch wenn Services an IPv4-IPs gebunden werden.
Die Deinstallation von IPv6 führte reproduzierbar zur Bootschleife des Servers. Ist mMn auch nicht supported von Microsoft, im Gegenteil, es wird davor gewarnt.
Kannst du mal etwas ins Detail gehen?
Ich kenne solche Auswirkungen nur, wenn man den "abenteuerlichen" Anleitungen im Netz folgt. Wir haben hier mittlerweile etliche 2008(R2)-Server am Start, bei allen wurde das IPv6-Protokoll auf diesem Weg deaktiviert, keine Probleme.
Und nur, um es nochmal deutlich zu machen: Auf diesem Weg wird IPv6 _NICHT_ deinstalliert - es wird (nur) deaktiviert.
Nutzt doch einfach ipv6, auch im LAN. Dateifreigaben und andere Dienste funktionieren doch auch damit.
Ein "ordentliches ipconfig /all" sollte kein ipv4 mehr haben. Aber das rauszuschmeißen traut sich wohl keiner.
Wenn das mal so einfach wäre...
Bei der Erst-|Neuausrüstung _eines_ Standorts kann man das sicherlich so machen, wenn auch die restliche Hardware wie Router, Gateways, Switche, Printserver etc. _alle_ IPv6 sprechen. Du kannst jetzt gerne mal anfangen zu suchen, wieviele Geräte das derzeit sind...
Davon abgesehen halte ich IPv6 für _lokale_ Netze für oversized. Schön, ich könnte theoretisch irgendwann mal allen Maschinen richtige, öffentliche IP-Adressen verpassen. Der Paranoiker in mir sagt dann: Spinnst du?
Und da muss ich ihm Recht geben: Auch wenn ich es mit IPv6 nicht müsste, wird mein NAT-ting erhalten bleiben.
Seit wann ist Arbeit einfach? ;-)
Nein ich habe dies bei meinem Standort Schritt für Schritt getan - nicht bei Erst-|Neuausrüstung. Im Grunde nutze ich ipv4 nur noch wegen nfs und der Außenwelt(ohne Proxies).
Wegen ein, zwei kleiner Inseln (irmc, ilom, einige Drucker) müsste nicht mehr das gesamte Netz mit ipv4 laufen, da reicht ein Printserver davor bzw. ein kleineres Managementnetz.
Alles wichtige läuft bevorzugt mit ipv6. Da muss man auch nicht mehr lange suchen, jedenfalls nicht, wenn man von aktuellen OS(von MS, Linux und Apple) spricht.
IPv6 ist nicht oversized, außerdem steht es jedem frei Unique Local Unicast Adressen zu nehmen.
Für Paranoide gibt es auch nach wie vor die Möglichkeit Firewalls(auch für Nicht-Paranoide) und Proxies zu nutzen.
Was mich allerdings ärgert - im Einzelfall mögen solche Tipps wie der o.g. hilfreich sein - aber es sind meistens die gleichen Leute, die dann sagen "ipv6 kommt ja sowieso nie".
Statt die Probleme, die man ggf. mit ipv6 hat, sauber zu lösen und damit die Entwicklung voranzutreiben, wird mit Tipps geworben, die ich nicht mal als konservativ sondern reaktionär bezeichnen würde.
Mit freundlichen Grüßen
Thomas Schäfer
Markige Worte.
Dann nimm den Arbeitsaufwand und die Zeit mal 30 Standorte, die europaweit verteilt sind. Und dann versuche, den nicht messbaren (und für mich auch nicht sichtbaren) Mehrwert von IPv6 im LAN gegenüber denjenigen zu rechtfertigen, die das bezahlen sollen.
Wenn ich dann noch die Kosten für die benötigte Hardware dazurechne, um wirklich alles, was geht, auf IPv6 umzustellen, bin ich ganz schnell im dicken, sechsstelligen Euro-Bereich. Und das nur, um sagen zu können: Hey, wir haben IPv6 im Einsatz?
Sorry, ich sehe da keinen Sinn drin, ausser damit die technische Machbarkeit zu beweisen. Von daher halte ich das keinesfalls für reaktionär, sondern für ökonomisch. Wenn, ja wenn, die Provider mal _durchgängig_ im öffentlichen Netz IPv6 einsetzen, bin ich einer der ersten, der seine Gateways auf IPv6 umrüstet. Meine LANs bleiben davon aber völlig unberührt.
Die Anzahl/Größe der Standorte hat nichts damit zu tun. Kein Netzwerker sollte so am Limit sein, dass er sich nur auf Katastrophenmanagement konzentriert.
Alle wieviel Jahre tauscht Du Deine Hardware aus? IPv6 kostet in vielen Fällen beim Einkauf keinen Cent mehr - die Arbeit für Konfiguration bleibt natürlich und im Falle von Dualstack zugegebenermaßen doppelt.
Die Machbarkeit ist schon längst bewiesen. Die ökonomische Frage - wie Du sie gestellt hast - halte ich für unbegründet. Darauf zu warten, dass andere (Provider) etwas "durchgängig" tun ist jedenfalls eine billige Ausrede.
Mit freundlichen Grüßen
Thomas Schäfer
PS: Trotzdem vielen Dank, dass Meinungsverschiedenheiten in Deinem Forum erlaubt sind.
Benenne doch mal einen wirklichen Vorteil von IPv6, also etwas, das IPv4 in einem beruflichen Umfeld nicht leistet.
"Auf lange Sicht" sehe ich keinen Mehrwert darin; deaktiviere ich IPv6 und belasse meine lokalen Infrastrukturen in dem funktionierenden Zustand, in dem sie mit IPv4 sind, muss ich mich auch nicht um zwei Protokolle kümmern.
Aktiviere ich IPv6 und hoffe darauf, das "auf lange Sicht" alle Netzwerkkomponenten auch wirklich (korrekt!) mit IPv6 umgehen können, treibe ich den Administrationsaufwand ins Unendliche. Wie überall haben auch wir hier mehr als genug zu tun und die Personaldecke ist dünn.
Meine Hardware tausche ich dann, wenn sie defekt ist oder wg. anderer Anforderungen erweitert|getauscht werden muss. IPv6 gehört für mich nicht zu den kritischen Dingen, die ich ad hoc umsetzen muss, das stellt also keine solche Anforderung dar.
Das einzige Argument, das aus meiner Sicht für IPv6 spricht, ist der gigantisch große IP-Adressraum, der sich daraus ergibt. Keines meiner LANs wird allerdings jemals so groß werden, das es auch nur einen Promille-Wert der verfügbaren IP-Adressen belegen wird. Ergo kein Handlungsbedarf, schon gar nicht akut.
Was die "billige Ausrede" betrifft: Ich sehe keinen Zusammenhang mit dem Ausbau lokaler LANs auf IPv6-Basis und dem Auf- und Ausbau von IPv6 in öffentlichen Netzen - selbst wenn ich IPv6 lokal nutzen würde, wäre das letzte, was ich zulassen würde, die direkte Erreichbarkeit von lokalen Rechnern aus dem Internet - nur, weil es jetzt technisch und von der Verfügbarkeit von IP-Adressen her dann ja kein Problem mehr darstellen würde.
Ich sehe die "billige Ausrede" eher in der Aussage der Provider, das aufgrund mangelnder lokaler IPv6-Implementationen kein großes Interesse an der Umsetzung im öffentlichen Netz bestünde. Das ist nun wirklich an den Haaren herbeigezogen, denn reeller und akuter Handlungsbedarf besteht nur dort, in den öffentlichen Netzen.
Was die "Meinungsverschiedenheiten" angeht:
Erstens ist dies kein "Forum" im eigentlichen Sinne und solange solche Diskussionen sachlich bleiben, wie diese hier, sind sie in meinen Augen immer willkommen.
OS-Updates scheinen hier selbstverständlich.
Es ist immerhin die Rede von Windows 7, bei Protokollupdates gehen die Ansichten offenbar auseinander.
Schade.
Ich kann deinen Kommentaren leider noch immer kein zwingendes Argument dafür entnehmen, warum IPv6 in einem lokalen LAN so unverzichtbar ist. Die Brücke zu den OS-Updates kann ich beim besten Willen auch nicht schlagen....
Mit freundlichen Grüßen
Thomas Schäfer
Ich bin mit Sicherheit kein Update-Muffel, da sei dir sicher. Alle OS sind immer aktuell -WSUS sei Dank- und "kritische" Software wird samt Updates per GPO verteilt. Aber das schweift alles vom Thema ab, ich warte eigentlich immer noch auf das schlagende Argument "pro IPv6"...
*weltweiter Adressmangel.
*Zur Gewohnheit gewordene Workarounds (NAT im großen Stil).
*Die Unmöglichkeit nur einen Teil des Internets (wenn es das noch bleiben soll) umstellen zu wollen - frei nach dem Motto wir haben ja genug Adressen (von der alten Sorte)
* das "sich wehren" gegenüber einer vernünftigen Lösung, die vom Hersteller (hier Microsoft)bevorzugt wird (über manch eigenwillige Tunnelstrategie mag ich hier nicht urteilen)
Thomas Schäfer
- weltweiter Adressmangel
Interessiert mich innerhalb meines LANs nicht die Bohne
- Workarounds:
NAT halte ich keinesfalls für einen Workaround, es ist vielmehr einer der Sicherheits-Eckpfeiler jedes Netzes
- Umstellung des Internets:
Genau da sehe ich ja Handlungsbedarf, in den öffentlichen Netzen, in denen sich der Adressmangel tatsächlich bemerkbar macht
- vernünftige Lösung:
s. oben, für öffentliche Netze absolut d'accord, für lokale LANs nicht notwendig.
Von Vernunft kann beim "Umstellen um des Umstellens willen" in meinen Augen absolut nicht gesprochen werden. Ich gewinne nicht ein einziges Feature hinzu, wenn ich lokal IPv6 einsetze. Genauso wenig schränke ich die Funktionalität eines LANs ein, wenn ich bei IPv4 bleibe. Klassische Patt-Situation. ;-)
NAT ist mit Sicherheit kein "Sicherheits-Eckpfeiler"
NAT ist bestenfalls ein Mischpräparat. Es macht etwas Proxy, es macht ein bisschen Firewall. Aber nichts richtig.
Wir werden sehen.
Mit freundlichen Grüßen
Thomas Schäfer
Kommentare sind für diesen Beitrag deaktiviert.