• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

Windows Server 2016 IPv6

CEW4

Member
Hallo,

ich bin gerade dabei, für ein kleines Netzwerk einen Internetzugang über IPv6 herzustellen. Im Netzwerk läuft ein Windows Server 2016, der bisher schon IPv6-Addressen (ULA) vergeben hat (stateful, also über DHCPv6). Das funktioniert soweit fehlerfrei.

Nun kam eine FritzBox mit DualStack-DSL hinzu. Und damit fangen die Probleme an:

1.) Kann es wirklich sein, daß Windows Server 2016 nicht mit Prefix Delegation vom Router (d.h. von der FritzBox) umgehen kann?

2.) Es ergibt sich die drollige Situation, daß die Client-Rechner das Internet per IPv6 erreichen können, aber der Server nicht: Die Clients (Windows 10) bekommen eine öffentliche IPv6-Adresse, auch wenn sie auf "verwaltete Adresskonfiguration" (M-bit) konfiguriert sind. Beim Server funktioniert das allerdings nicht. Der scheint sein M-bit ernstzunehmen und erstellt sich keine IPv6-IP. Damit hat ausgerechnet der Server als einziger im Netz keinen IPv6-Zugang ins Internet.

Nummer 1 scheint einfach so zu sein - bravo, tolle Leistung im Jahr 2019. Aber fällt irgendjemandem eine Abhilfe für Nummer 2 ein? Windows 10 scheint mit dem "Anniversary Update" die Option bekommen zu haben, auf ein und demselben Interface sowohl statisch als auch DHCP zu konfigurieren (Option "dhcpstaticipcoexistence" über netsh), aber Server 2016 scheint das nicht zu kennen.

MfG
 
Ich hatte zwischenzeitlich ein paar Sachen mit einem Windows Server 2016 hinter einer Fritzbox getestet (Dual-Stack Telekom-Anschluss) und da war es kein Problem, dass der Server seine IPv6 per RA vergeben hat. Allerdings lief auf dem Server kein DHCP-Server, was evtl. zu Einschränkungen in der Netzwerk-Konfiguration beim Server führen kann.
 
Ich würde ja verstehen, wenn die Clients keine RAs von der FritzBox auswerten, solange der Server M=1 sendet. Das tun sie aber sehr wohl - nur der Server selbst nicht.

Ich habe zwischenzeitlich auch einmal versucht, auf dem Interface des Servers M=0 und O=0 zu setzen - keine Änderung, der Server bekommt keine IPv6-Adresse von der Fritzbox.
 
Das die Clients trotz M-Bit eine IPv6-Konfig auf Basis der RAs generieren, ist in Ordnung (es zeigt nicht verpflichtend an, dass die Konfig per DHCP kommen muss). Aber das meine ich auch gar nicht. Auf deinem Server läuft der DHCP-Dienst und es kann sein, dass dadurch die automatische Konfiguration des Servers eingeschränkt ist (der Server sich also "selbst im Weg steht").
 
Das müsste ich ausprobieren können, indem ich den DHCP auf dem Server temporär stoppe, oder? Wäre dann keine Lösung, weil der Dienst in meinem LAN notwendig ist (mindestens für IPv4), aber wir könnten die Theorie damit testen.

Oder meinst Du, daß der DHCP-Server komplett deinstalliert werden müsste? Das lässt sich ja nicht so einfach ausprobieren.
 
Last edited:
Evtl. kann es sein, dass du den DHCP-Server IPv4-only konfigurieren musst und nur ein Stoppen des Dienstes nicht ausreicht. Wenn ich das richtig im Kopf habe, benötigt der Windows-DHCP-Dienst eine statische IPv6-Konfig für die Netzwerkkarte, um überhaupt Adressen zu vergeben - das wird bei dir der Fall sein und statische Konfig <> Konfig per RA.
 
Hmja, daran hatte ich auch schon gedacht. Windows 10 kann offenbar seit dem Anniversary-Update statisch und DHCP auf einem einzigen Interface, aber Server 2016 noch nicht. Vielleicht ist das der Unterschied.

Ok, andere Idee: Ein zusätzliches (virtuelles) Interface auf dem Server, das ausschließlich IPv6 unterstützt (kein IPv4) und auf DHCP konfiguriert ist. Funktioniert das, könnte man den externen IPv6-Kram darüber routen, den internen (per DHCP6 verwalteten) dagegen weiterhin über das alte Interface.

Das könnte man noch probieren, wenn sonst gar nichts mehr hilft.
 
Da der Windows Server 2016 und WIndows 10 Anniversary Update beide auf der gleichen Code-Basis laufen, wird der Server das prinzipiell schon können. Es kann aber natürlich sein, dass Microsoft diese Konfiguration beim Server aus (ggfl. nur MS bekannten) Gründen grundsätzlich verhindert oder evtl. auch nur in Verbindung mit dem DHCP-Dienst nicht erlaubt.
 
Unter Windows 10 (hier 1903) gibt es folgende zusätzliche Optionen:

Code:
netsh interface ipv6 show interface 14
[...]
RA-basierte DNS-Konfiguration (RFC 6106)     : enabled
Koexistenz von DHCP/statischer IP         : enabled

Unter Server 2016 fehlen diese. Da ich auf dem Server aber auch noch nie ein "Feature Upgrade" wie zwischen Windows 10-Versionen gemacht habe, würde ich schon vermuten, daß der Server das entsprechende Update einfach nie bekommen hat.
 
Ok, andere Idee: Ein zusätzliches (virtuelles) Interface auf dem Server [...]
Mist, geht auch nicht so einfach: Jedem VLAN kann nur eine einzige "Teamschnittstelle" zugewiesen werden, nicht mehrere. Ich müsste also eine zusätzliche Hardware-NIC verwenden - falls das überhaupt einen Unterschied bzgl. dieser Einschränkung macht.

Ganz klar ist mir das ja nicht - warum kann ich denn nicht beliebig viele NICs mit einem VLAN verbinden? Ist das eine Treibereinschränkung oder gibt es dafür einen logischen Grund?
 
Da ich auf dem Server aber auch noch nie ein "Feature Upgrade" wie zwischen Windows 10-Versionen gemacht habe, würde ich schon vermuten, daß der Server das entsprechende Update einfach nie bekommen hat.

Windows Server hat das Rollingrelease Prinzip von Win10 nie eingeführt. Entsprechend gibts solche Updates da auch gar nicht wirklich.
Irgendwie muss man Windows Server 2019 ja auch verkaufen. ;)

Bin mir grad nicht sicher, welches Win10 Release tatsächlich noch am ehesten Win2016 entspricht, die 1903 ist es aber definitiv nicht. Entsprechend wirst du dein Feature vermutlich auch eher im Win2019 finden.
 
Windows Server 2016 und das Windows 10 Anniversary Update haben die gleiche Code-Basis (die 1607 mit der Build 14393), und von der Windows 10 1607 gibt es auch eine LTS-Variante mit 5+5 Jahren Support. Bei Windows Server 2019 wäre Windows 10 1809 das entsprechende Gegenstück (Build 17763), von dem es ebenfalls eine LTS-Variante gibt.
Inwieweit der IPv6-Stack seit der Build 14393 geändert wurde und ob es Auswirkungen auf gemischten Betrieb (statisch + DHCP + RA gleichzeitig) hat, kann ich aber nicht sagen. Microsoft verhindert ja auch bestimmte Kombinationen von Konfigurationen, daher halte ich es sogar für durchaus möglich, dass die Kombi prinzipiell möglich ist, aber durch die installiert DHCP-Rolle verhindert wird. Läßt sich ja testen, indem ein System mit Windows Server 2016 ins Netz gehangen wird, der eine fest IPv6 eingestellt hat, aber nicht die DHCP-Rolle instaliert hat (z.B. als virtuelle Maschine auf einem Client-PC).
 
Ich habe gerade ein paar Versuche mit Server 2016 in einer virtuellen Maschine ausgeführt:

- IPv4 und IPv6 DHCP: erhält IPv4 und IPv6 GUA
- IPv4 statisch, IPv6 DHCP: erhält IPv6 GUA
- IPv4 und IPv6 ULA statisch: erhält IPv6 GUA

In allen Fällen, in denen die VM eine IPv6 GUA erhalten hat, erhielt sie auch eine (tatsächlich sogar zwei, das muß ich nochmal getrennt erforschen) ULA.

Privacy Extensions waren per default deaktiviert.

Jetzt gibt es noch eine potentielle Fehlerquelle: Ich habe die Tests in der angegebenen Reihenfolge ausgeführt. Das heißt, daß bereits beim ersten Versuch alle IPs vorhanden waren. Es wäre nun möglich, daß in den späteren Testfällen die IP nicht neu jeweils neu erhalten wurde, sondern noch vom letztenmal "gemerkt" worden war.

Um dem entgegenzuwirken, habe ich zwischen den einzelnen Konfigs die VM immer wieder auf ein internes Netz umgeschaltet und nachgesehen, ob die IPs dann verschwunden waren. Sie waren. Ich habe also Grund zur Annahme, daß die Tests aussagekräftig sind. (Gegenmeinungen hierzu?)


Fazit:
Ein out-of-the-box Windows Server 2016 wertet sehr wohl fremde RAs aus, um eine IPv6 GUA zu erstellen. Es spielt dazu keine Rolle, ob das Interface auf statisch oder DHCP konfiguriert ist.

Jetzt könnte ich noch probieren, ob sich das Verhalten ändert, wenn ich einen DHCP-Server installiere.

MfG
 
Das würde ja soweit meine Theorie bestätigen, dass es keine Einschränkung vom Windows Server 2016 gegenüber Windows 10 ist. Ich tippe darauf, dass sich das Verhalten ändert, sobald du die DHCP-Rolle installierst und für IPv6 aktivierst.
 
Daneben. :)

Gerade habe ich in der VM einen DHCPv6 installiert und gestartet. Die IPv6 GUA auf dem Interface ist immer noch da.

Um sicherzugehen habe ich die GUA mit "netsh" gelöscht. "ipconfig" bestätigte, daß sie weg war. Nach einem "ipconfig /renew6" war sie wieder da.

Ok: Dann ist also auf meinem produktiven Server irgendetwas verbastelt. Die VM kann alles - sie ist nur nicht in der Domäne. Aber das kann doch eigentlich nicht das ausschlaggebende sein...
 
Ha, ich hab's gefunden:

Sobald ich in der VM die "Ankündigung" setze (in netsh: "advertise=enabled"), ist die GUA verschwunden. Das lässt sich reproduzieren - während "enabled" bringt ein "ipconfig /renew6" keine GUA zustande, während "disabled" dagegen sofort.

Ist das logisch? Das "advertise" steuert doch 'rausgehende RAs auf diesem Interface. Ist es dann so, daß auf einem Interface nur entweder RAs gesendet oder RAs empfangen werden können, aber nicht beides gleichzeitig? Vielleicht eine Sicherheitsmaßnahme gegen loopbacks oder replays?

Edit: Tippfehler korrigiert - "RA" meinte ich natürlich, nicht "GA.
 
Last edited:
Ist es dann so, daß auf einem Interface nur entweder RAs gesendet oder RAs empfangen werden können, aber nicht beides gleichzeitig? Vielleicht eine Sicherheitsmaßnahme gegen loopbacks oder replays?

Ja. Wenn du RAs raussendest, bist du ein Router und ein Router sollte immer eine feste Adresse haben (entweder statisch konfiguriert oder per DHCPv6 statisch zugewiesen). Persönlich habe ich damit bisher nur auf Linux-Systemen zu tun gehabt, aber der Linux-Kernel ignoriert RAs, wenn im Linux-Kernel IP-forwarding für IPv6 aktiviert ist (wobei es sich über einen Kernel-Parameter aktivieren lässt). Die Windows-Programmierer werden da ähnliche Gedankengänge gehabt haben.
Ich weiss ja nicht, was dein Server alles macht, aber dass er RAs sendet, sollte eigentlich nur der Fall sein, wenn er Router für ein zweites Netz ist (kann z.B. auch VPN oder Virtualisierung sein).
 
Ja. Wenn du RAs raussendest, bist du ein Router und ein Router sollte immer eine feste Adresse haben (entweder statisch konfiguriert oder per DHCPv6 statisch zugewiesen).
Genau das widerspricht sich doch:

- Um das dynamische IPv6-Prefix vom Gateway (FritzBox) zu akzeptieren, müssen eingehende RAs verarbeitet werden.
- Um die eigene, statische IPv6-IP (bzw. deren Netz) anzukündigen, müssen ausgehende RAs gesendet werden.

Will (bzw. kann) ich das nicht, sehe ich nur folgende Möglichkeiten:

- Zwei getrennte Interfaces, eines zum Gateway, eines zum LAN. Dann muß aber geroutet werden, und die Maschinen im LAN müssen eine IPv6-IP aus einem global-routable internen Netz bekommen. Damit ist gleichzeitig die Privacy im Eimer, weil sich das Prefix für die Maschinen im LAN niemals ändert.

- Gar keine lokale IPv6-Verwaltung, alles über SLAAC. Dann aber klappt das nur in dem einen Subnetz, in dem sich auch das Gateway befindet, weil dieses als einziges RAs verteilt und diese selbst nicht routeable sind.

der Linux-Kernel ignoriert RAs, wenn im Linux-Kernel IP-forwarding für IPv6 aktiviert ist (wobei es sich über einen Kernel-Parameter aktivieren lässt). Die Windows-Programmierer werden da ähnliche Gedankengänge gehabt haben.
Ich verstehe die Motivation dahinter nicht. Wenn ich schon mehrere IPs auf einem Interface haben kann, dann sollte ich diese doch auch aus beliebigen, unabhängigen Quellen ableiten können?

Ich weiss ja nicht, was dein Server alles macht, aber dass er RAs sendet, sollte eigentlich nur der Fall sein, wenn er Router für ein zweites Netz ist (kann z.B. auch VPN oder Virtualisierung sein).
Ist er ja. Ursprünglich wollte ich mehrere Subnetze mit IPv6 versorgen. Mit internen Adressen funktioniert das auch, aber eben nicht mit einem externen, dynamischen Prefix.
 
Back
Top