IPv6/Windows/Router Advertisements

IPv6 Router Advertisements on Windows

From my previous post you know that IPv6 hosts can autoconfigure themselves if they get the network prefix from a router (or server running this service). Windows Server (and Clients) can send Router Advertisement messages without any additional software. This functionality is in-built and can be configure via the netsh command.

Here’s what I did on the Server Core 2012 which functions as the “router” for my test lab.# Visit https://www.sixxs.net/tools/grh/ula/ and get a ULA prefix for myself. This is a /48 block – meaning I have to fill in the remaining 16 bits of subnet ID to make this a /64 block. I can have 2^16 subnets. I got the fdcc:7c4e:3651::/48 prefix, I’ll just use subnet 1 for now, so my network prefix will be fdcc:7c4e:3651:1::/64.

1. I assigned an IPv6 address “fdcc:7c4e:3651:1::254”, netmask 64, to the server.
2. Next, I issued the following command on the server to enable router advertisements:
   netsh interface ipv6 set interface "Local Area Connection" advertise=enabled

netsh interface ipv6 set interface "Local Area Connection" advertise=enabledThis enables Router Advertisements. But this doesn’t advertise any prefixes.

Below is a Wireshark capture on that interface from a client:

"RA1"

Notice that Router Advertisement messages are being sent. The messages specify two options – MTU and the link-layer address of the router.

Here is the result of ipconfig for that interface on the client:

"ipconfig1"

The only IPv6 address is the link local address. No gateway is set either.

1. To specify prefixes the publish, I issued the following command on the server:
   netsh interface ipv6 set route fdcc:7c4e:3651:1:::/64 "Local Area Connection" publish=yes

netsh interface ipv6 set route fdcc:7c4e:3651:1:::/64 "Local Area Connection" publish=yesIn case that command gives an error – maybe you don’t have that route entry already – replace it with the following:

netsh interface ipv6 add route fdcc:7c4e:3651:1:::/64 "Local Area Connection" publish=yesnetsh interface ipv6 add route fdcc:7c4e:3651:1:::/64 "Local Area Connection" publish=yesThis tells the server to publish this prefix on the Router Advertisement messages on that interface. Without publish=yes the command tells the server that the fdcc:7c4e:3651:1:::/64 network is on the “Local Area Connection” interface for routing purposes – that the prefix for devices on this interface is (or will be) fdcc:7c4e:3651:1:::/64. The publish=yes bit tells the server to publish this prefix information in Router Advertisement messages.

Below is a Wireshark capture once prefix publishing is enabled:

"RA2"

Notice the prefix information is now published.

And now ipconfig too shows the automatically generated addresses:

1. "ipconfig2"
2. So far the server isn’t functioning as a router (i.e. it is not forwarding packets). If we want the server to function as a router that can be enabled:
   netsh interface ipv6 set interface "Local Area Connection" forwarding=enabled

netsh interface ipv6 set interface "Local Area Connection" forwarding=enabled# Once the server functions as a router we can also tell it to include this information in the Routing Advertisement messages. This way clients can automatically pick up the router as a default gateway!
netsh interface ipv6 set interface "Local Area Connection" advertisedefaultroute=enabled

netsh interface ipv6 set interface "Local Area Connection" advertisedefaultroute=enabledChecking the Wireshark capture will now show a new option in the Router Advertisement messages:

"RA3"

And ipconfig will show a default gateway is automatically set:

"ipconfig3"

Ain’t that cool!

1. To view the current configuration of that interface on the server, the following command can be used:
   netsh interface ipv6 show interface "Local Area Connection"

netsh interface ipv6 show interface "Local Area Connection"# The neat thing with Router Advertisement messages is that they can work in conjunction with DHCPv6. The Router Advertisement messages can tell clients to also contact DHCP for an IPv6 address and additional options, or contact DHCP not for an IPv6 address but only for additional options.
For the former do this:
netsh interface ipv6 set interface "Local Area Connection" managedaddress=enabled

netsh interface ipv6 set interface "Local Area Connection" managedaddress=enabledFor the latter do this:

netsh interface ipv6 set interface "Local Area Connection" otherstateful=enablednetsh interface ipv6 set interface "Local Area Connection" otherstateful=enabledHere’s the Wireshark output after I enabled managed address. The output is similar to the previous ones except for the flags (it’s 0x80 now in contrast to 0x0 before). So I have expanded it.

"RA4"

The way clients will behave now is thus:## If the client’s interface is set to Managed Address as disabled (i.e it is not looking for DHCPv6 address configuration), since the Router Advertisement now sets it to enabled it will start looking for DHCPv6 address configuration.

1. 1. If the client’s interface is set to Managed Address as enabled, since the Router Advertisement too sets it as enabled it will behave as before.

In the opposite scenario – suppose Router Advertisement messages were setting Managed Address as disabled (which is the default) clients ignore this and continue working based on what their own Managed Address configuration is.If you don’t want Windows clients to listen for Router Advertisements, do the following on the client:

netsh interface ipv6 set interface "Local Area Connection" routerdiscovery=disabled

netsh interface ipv6 set interface "Local Area Connection" routerdiscovery=disabled

As with the server, to view the interface configuration on the client the following works:

netsh interface ipv6 show interface "Local Area Connection"

netsh interface ipv6 show interface "Local Area Connection"

Lastly, suppose you have enabled prefix publishing on the server, and Wireshark shows the information is being sent but clients aren’t picking it up, the following might be helpful. By default the site prefix is set to /64 but if your network prefix is (say) /48 either by mistake or intentionally, clients will ignore this network prefix.

Correct the prefix setting then, or the network prefix mask if it’s a typo. The first time I played with this I had forgotten to change the mask from /48 to /64 once I added the subnet ID bits, so the server was advertising it with /48 and clients were ignoring it.

TMP

IPv6-Router-Ankündigungen unter Windows

Aus meinem vorherigen Beitrag wissen Sie, dass IPv6-Hosts sich selbst konfigurieren können, wenn sie das Netzwerkpräfix von einem Router (oder einem Server, der diesen Dienst betreibt) erhalten. Windows Server (und Clients) können Router Advertisement Nachrichten ohne zusätzliche Software senden. Diese Funktionalität ist eingebaut und kann mit dem netsh Befehl konfiguriert werden.

So habe ich es auf dem Server Core 2012 gemacht, der als "Router" für mein Testlabor fungiert.# Rufen Sie https://www.sixxs.net/tools/grh/ula/ auf und holen Sie sich ein ULA-Präfix für mich. Dies ist ein /48-Block - das heißt, ich muss die verbleibenden 16 Bits der Subnetz-ID ausfüllen, um daraus einen /64-Block zu machen. Ich kann 2^16 Subnetze haben. Ich habe das Präfix fdcc:7c4e:3651::/48, ich werde vorerst nur Subnetz 1 verwenden, also wird mein Netzwerkpräfix fdcc:7c4e:3651:1:/64 sein.

1. Ich habe dem Server eine IPv6-Adresse "fdcc:7c4e:3651:1::254", Netzmaske 64, zugewiesen.
2. Als nächstes gab ich auf dem Server den folgenden Befehl ein, um Router Advertisements zu aktivieren:
   netsh interface ipv6 set interface "Local Area Connection" advertise=enabled

netsh interface ipv6 set interface "Local Area Connection" advertise=enabledDamit werden Router Advertisements aktiviert. Allerdings werden dadurch keine Präfixe bekannt gegeben.

Nachfolgend sehen Sie eine Wireshark-Aufnahme dieser Schnittstelle von einem Client:

"RA1"

Beachten Sie, dass Router Advertisement-Nachrichten gesendet werden. Die Nachrichten geben zwei Optionen an - MTU und die Link-Layer-Adresse des Routers.

Hier ist das Ergebnis von ipconfig für diese Schnittstelle auf dem Client:

"ipconfig1"

Die einzige IPv6-Adresse ist die lokale Adresse des Links. Es ist auch kein Gateway eingestellt.

1. Um Präfixe für die Veröffentlichung festzulegen, habe ich folgenden Befehl auf dem Server eingegeben:
   netsh interface ipv6 set route fdcc:7c4e:3651:1:::/64 "Local Area Connection" publish=yes

netsh interface ipv6 set route fdcc:7c4e:3651:1:::/64 "Local Area Connection" publish=yesFalls dieser Befehl einen Fehler auslöst - vielleicht haben Sie diesen Routeneintrag noch nicht - ersetzen Sie ihn durch den folgenden:

netsh interface ipv6 add route fdcc:7c4e:3651:1:::/64 "Local Area Connection" publish=yesnetsh interface ipv6 add route fdcc:7c4e:3651:1:::/64 "Local Area Connection" publish=yesDies weist den Server an, dieses Präfix in den Router Advertisement Nachrichten auf dieser Schnittstelle zu veröffentlichen. Ohne publish=yes teilt der Befehl dem Server mit, dass das Netzwerk fdcc:7c4e:3651:1:::/64 zu Routingzwecken auf der Schnittstelle "Local Area Connection" liegt - dass das Präfix für Geräte auf dieser Schnittstelle fdcc:7c4e:3651:1:::/64 ist (oder sein wird). Das publish=yes Bit weist den Server an, diese Präfix-Information in Router Advertisement Nachrichten zu veröffentlichen.

Nachfolgend sehen Sie eine Wireshark-Aufnahme, wenn die Veröffentlichung von Präfixen aktiviert ist:

"RA2"

Beachten Sie, dass die Präfixinformationen jetzt veröffentlicht werden.

Und nun zeigt auch ipconfig die automatisch generierten Adressen an:

1. "ipconfig2"
2. Bis jetzt funktioniert der Server nicht als Router (d.h. er leitet keine Pakete weiter). Wenn wir wollen, dass der Server als Router funktioniert, kann das aktiviert werden:
   netsh interface ipv6 set interface "Local Area Connection" forwarding=enabled

netsh interface ipv6 set interface "Local Area Connection" forwarding=enabled# Sobald der Server als Router fungiert, können wir ihm auch sagen, dass er diese Information in die Routing Advertisement Nachrichten aufnehmen soll. Auf diese Weise können die Clients den Router automatisch als Standard-Gateway auswählen!
netsh interface ipv6 set interface "Local Area Connection" advertisedefaultroute=enabled

netsh interface ipv6 set interface "Local Area Connection" advertisedefaultroute=enabledBei der Überprüfung der Wireshark-Aufzeichnung wird nun eine neue Option in den Router Advertisement-Nachrichten angezeigt:

"RA3"

Und ipconfig zeigt an, dass ein Standard-Gateway automatisch gesetzt ist:

"ipconfig3"

Ist das nicht cool!

1. Um die aktuelle Konfiguration dieser Schnittstelle auf dem Server anzuzeigen, kann der folgende Befehl verwendet werden:
   netsh interface ipv6 show interface "Local Area Connection"

netsh interface ipv6 show interface "Local Area Connection "# Das Schöne an Router Advertisement-Nachrichten ist, dass sie in Verbindung mit DHCPv6 funktionieren können. Die Router Advertisement-Nachrichten können den Clients mitteilen, dass sie DHCP auch für eine IPv6-Adresse und zusätzliche Optionen kontaktieren sollen, oder dass sie DHCP nicht für eine IPv6-Adresse, sondern nur für zusätzliche Optionen kontaktieren sollen.
Für Ersteres tun Sie Folgendes:
netsh interface ipv6 set interface "Local Area Connection" managedaddress=enabled

netsh interface ipv6 set interface "Local Area Connection" managedaddress=enabledFür letzteres gehen Sie wie folgt vor:

netsh interface ipv6 set interface "Local Area Connection" otherstateful=enablednetsh interface ipv6 set interface "Local Area Connection" otherstateful=enabledHier ist die Wireshark-Ausgabe, nachdem ich managed address aktiviert habe. Die Ausgabe ist ähnlich wie die vorherige, außer den Flags (jetzt 0x80 im Gegensatz zu 0x0 vorher). Also habe ich es erweitert.

"RA4"

Das Verhalten der Clients ist nun wie folgt:## Wenn die Schnittstelle des Clients auf Managed Address als disabled gesetzt ist (d.h. sie sucht nicht nach DHCPv6-Adresskonfiguration), wird sie, da das Router Advertisement sie nun auf enabled setzt, nach DHCPv6-Adresskonfiguration suchen.

1. 1. Wenn die Schnittstelle des Clients auf Managed Address als enabled gesetzt ist, wird sie sich wie zuvor verhalten, da das Router Advertisement sie ebenfalls als enabled setzt.

Im umgekehrten Fall - angenommen, die Router Advertisement-Nachrichten setzen die Managed Address als deaktiviert (was der Standard ist) - ignorieren die Clients dies und arbeiten auf der Grundlage ihrer eigenen Managed Address-Konfiguration weiter.Wenn Sie nicht möchten, dass Windows-Clients auf Router Advertisements hören, führen Sie auf dem Client folgende Schritte aus

netsh interface ipv6 set interface "Local Area Connection" routerdiscovery=disabled

netsh interface ipv6 set interface "Local Area Connection" routerdiscovery=disabled

Wie beim Server kann die Schnittstellenkonfiguration auf dem Client wie folgt angezeigt werden:

netsh interface ipv6 show interface "Local Area Connection"

netsh interface ipv6 show interface "Local Area Connection" (Lokale Verbindung)

Angenommen, Sie haben die Veröffentlichung von Präfixen auf dem Server aktiviert und Wireshark zeigt, dass die Informationen gesendet werden, aber die Clients sie nicht empfangen, dann könnte Folgendes hilfreich sein. Standardmäßig ist das Site-Präfix auf /64 eingestellt, aber wenn Ihr Netzwerk-Präfix (sagen wir) /48 ist, entweder aus Versehen oder absichtlich, ignorieren die Clients dieses Netzwerk-Präfix.

Korrigieren Sie dann die Präfix-Einstellung oder die Netzwerk-Präfix-Maske, wenn es sich um einen Tippfehler handelt. Als ich das erste Mal damit spielte, hatte ich vergessen, die Maske von /48 auf /64 zu ändern, nachdem ich die Subnetz-ID-Bits hinzugefügt hatte, so dass der Server mit /48 warb und die Clients es ignorierten.