|
|
| (9 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| '''IPv6 unter Windows''' - Grundlagen | | '''IPv6 unter Windows''' |
| | | {| class="wikitable options" |
| == IPv6-Grundkonfiguration für Windows ==
| | |- |
| [[IPv6/Windows/Grundkonfiguration]] | | ! Option !! Beschreibung |
| | | |- |
| == IPv6 im Windows-Netz ==
| | | [[IPv6/Windows/Grundkonfiguration|Grundkonfiguration]] || IPv6-Grundkonfiguration für Windows |
| [[IPv6/WindowsIPv6ImWindowsNetz]] | | |- |
| | | | [[IPv6/WindowsIPv6ImWindowsNetz|IPv6 im Windows-Netz]] || IPv6 im Windows-Netz |
| == IPv6 unter Windows ==
| | |- |
| [[IPv6/Windows/IPv6 unter Windows]] | | | [[IPv6/Windows/IPv6 unter Windows|IPv6 unter Windows]] || IPv6 unter Windows |
| | | |- |
| == DHCP mit IPv6 ==
| | | [[IPv6/Windows/DHCP mit IPv6|DHCP mit IPv6]] || DHCP mit IPv6 |
| [[IPv6/Windows/DHCP mit IPv6]] | | |- |
| | | | [[IPv6/Windows/IPv6Support|IPv6-Support]] || IPv6-Support |
| [[IPv6/Windows/IPv6Support]] | | |- |
| | | | [[IPv6/Windows/IPv6 Subnetz|IPv6 Subnetz]] || IPv6 Subnetz – Was ist das Richtige für mich? |
| == IPv6 Subnetz – Was ist das Richtige für mich? ==
| | |- |
| Nachdem die ganze öffentliche Vergabe von IPv6 Adressen noch sehr schleppend ist, lohnt der Aufbau vorher eigentlich nicht. Die Telekom will bis Ende 2011 auch Endanwendern IPv6 anbieten. Wer aber schon gewappnet sein will, wenn's dann doch soweit ist, kann sich schon mal mit dem Thema vertraut machen.
| | | [[IPv6/Windows/Allgemein|Allgemein]] || IPv6 Allgemein |
| | | |- |
| Es gibt einen Standard-IPv6-Bereich, der vergleichbar mit dem private Class A / B / C Netzen von IPv4 ist, eine sog. ''Site local address''. Übrigens, die ''Link local address'' (fe80::/64) ist mit der 169.254.0.0/16 bei IPv4 vergleichbar. Wenn man also noch keine offizielle, von der IETF oder dem ISP zugewiesene IPv6 hat, sollte auch nicht auf die Idee kommen irgendeine zu verwenden. Das macht früher oder später nur Probleme und man muss erneut umstellen. Folgende Site local Adresse ist frei verfügbar:
| | | [[IPv6/Windows/IPv6-Labor|IPv6-Labor]] || IPv6-Labor |
| | | |- |
| '''Site local: fec0:: '''
| | | [[IPv6/Windows/Teredo|Teredo]] || Microsofts Tunnelmechanismus Teredo |
| | | |- |
| '''Subnetz prefix length: 64 '''
| | | [[IPv6/Windows/Router Advertisements|Router Advertisements]] || IPv6 Router Advertisements on Windows |
| | | |- |
| Gleiches Netz, andere Schreibweise:
| | | [[IPv6/Windows/Netsh-Befehle|Netsh-Befehle]] || Netsh-Befehle für IPv6 |
| | | |} |
| '''Address prefix:''' '''fec0::/64 '''
| |
| | |
| Man könnte auch ein anderes Subnetz innerhalb von fec0 verwenden, allerdings bevorzuge ich kurze Schreibweisen. Beispiel für ein Subnetz wäre: fec0:0:0:1::
| |
| | |
| Die Übersicht über alle Adressen gibt's hier: [http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml]
| |
| | |
| === Testumgebung ===
| |
| * Server A:
| |
| ** Windows 2008 R2
| |
| ** AD, DNS
| |
| ** IPv6: fec0::3
| |
| * Server B:
| |
| ** Windows 2008 R2
| |
| ** DHCP
| |
| ** IPv6: fec0::2
| |
| * Client:
| |
| ** Windows 7
| |
| ** IPv6: DHCP (z.B. fec0::aaaa)
| |
| | |
| In dieser Umgebung gibt es keinen IPv6 fähigen Router und damit auch kein Gerät was per Router Discovery gefunden wird.
| |
| | |
| === Statische IPv6 vergeben ===
| |
| Nachdem IPv6 mittlerweile standardmäßig aktiv ist, muss man in den Protokolleigenschaften lediglich eine statische IP-Adresse eintragen, hier am Server B:
| |
| | |
| [[Image:Bild8.png|top|alt="image"]]
| |
| | |
| Server A erhält die IP fec0::3.
| |
| | |
| Über '''ping -6 fec0::3''' kann man die IPv6 Konnektivität von A nach B überprüfen (wenn ich den Parameter '''-6''' nicht angebe, versucht Windows es zuerst über IPv6. Mit dem Parameter erzwingt man das Ganze):
| |
| | |
| [[Image:Bild9.png|top|alt="image"]]
| |
| | |
| === Konfiguration DHCP-Server ===
| |
| Während der Installation der DHCP-Server Rolle, wird man gefragt, ob man den DHCP im Stateless oder Stateful Modus betreiben möchte, für diesen Verwendungszweck ist Stateful die richtige Wahl.
| |
| | |
| DHCP-Bereich: fec0:: /64
| |
| | |
| Ausnahmen: * fec0::ffff bis fec0::ffff:ffff:ffff:ffff (ich möchte dass meine Clients möglichst kurze Adressen bekommen, und 65.000 IP's reichen mir)
| |
| * fec0::1 bis fec0::20 (meine statischen IPv6 Adressen sind im Bereich 1-20, deshalb soll dieser nicht per DHCP vergeben werden)
| |
| | |
| Server Options: * 00023 DNS Recursive Name Server IPv6 Addresss: fec0::3
| |
| | |
| Wenn ich jetzt am Client meine IPv6 Adresse per '''ipconfig /renew6 '''erneuere, bekomme ich z.B. fec0::aaaa
| |
| | |
| Starte ich einen ping vom Client zum Server ('''ping -6 fec0::3''') kann es passieren, dass ich nur '''PING: transmit failed. General failure.''' Bekomme. Als nächstes sollte man den ping über link local Adresse (fe80::/64) versuchen, das sollte klappen. In diesem Fall hilft der nächste Schritt.
| |
| | |
| === Zusätzliche Konfiguration am DHCP-Server ===
| |
| An dieser Stelle scheitert man ganz gerne. IPv6 ist auf das sog. Router Advertisement angewiesen, damit ein Routing im Netzwerk möglich ist. Nun steht uns aber kein IPv6 fähiger Router zur Verfügung, d.h. der DHCP-Server soll diese Aufgabe übernehmen. Dazu sind ein paar Kniffe über netsh notwendig. Ohne das Router Advertisement bekommt der Client auch keine Route ins eigene Netz zugewiesen. Über den folgenden Befehl kann man sich die Routen anzeigen lassen:
| |
| | |
| '''netsh int ipv6 show route '''
| |
| | |
| Hier fehlt fec0:: - unser neues Netz.
| |
| | |
| Damit es als Route hinzugefügt wird, muss man am DHCP-Server folgendes konfigurieren: # Auf der Netzwerkkarte Advertise=enabled setzen
| |
| # Für die entsprechende Route, also fec0::, die Eigenschaft publish=enabled setzen
| |
| | |
| Schritt 1:
| |
| | |
| Man muss die ID der betroffenen Netzwerkkarte herausfinden: '''netsh int ipv6 show int'''
| |
| | |
| Anschließend muss Advertise=enabled gesetzt werden: '''netsh int ipv6 set int <ID> advertise=enabled''' // optional noch: rou=en (das sollte schon enabled sein)
| |
| | |
| Schritt 2:
| |
| | |
| Anschließend die Route hinzufügen: '''netsh int ipv6 add route fec0::/64 publish=enabled '''
| |
| | |
| Falls es die schon gibt, kann man die Eigenschaft publish wie folgt ändern: '''netsh int ipv6 set route fec0::/64 publish=enabled '''
| |
| | |
| Update, mit einem Service Pack hat sich scheinbar der Syntax geändert, z.B.: '''netsh int ipv6 set route fec0::/64 "LAN" publish=yes'''
| |
| | |
| [[Image:Bild10.png|top|alt="image"]]
| |
| | |
| Anschließend sollte ein ping vom Client zu Server A & B möglich sein. Alle weiteren IPv6 fähigen Clients können dann ohne zusätzliche Konfiguration über IPv6 kommunizieren.
| |
| | |
| === Troubleshooting Tools ===
| |
| Wertvolle Helfer auf der Kommandozeile, die speziell auf IPv6 losgehen: * ping –6 <hostname>
| |
| * tracert –6 <hostname>
| |
| * ipconfig /release6
| |
| * ipconfig /renew6
| |
| * netsh int ipv6 show int
| |
| * netsh int ipv6 show int <ID>
| |
| * netsh int ipv6 show route
| |
| | |
| === Quelle ===
| |
| http://www.hobmaier.net/2012/12/stateful-ipv6-autoconfiguration-mit.html
| |
| | |
| == IPv6 Allgemein ==
| |
| [[IPv6/Windows/Allgemein]] | |
| | |
| == IPv6-Labor / Pilot ==
| |
| [[IPv6/Windows/IPv6-Labor]] | |
| | |
| == Microsofts Tunnelmechanismus Teredo ==
| |
| [[IPv6/Windows/Teredo]] | |
| | |
| == IPv6 Router Advertisements on Windows ==
| |
| From my [http://rakhesh.com/windows/notes-on-ipv6/ 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 <tt>netsh</tt> 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/ 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'''.
| |
| # I assigned an IPv6 address “fdcc:7c4e:3651:1::254”, netmask 64, to the server.
| |
| # Next, I issued the following command on the server to enable router advertisements:<br/>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:
| |
| | |
| [[Image:Bild52.png|top|alt="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 <tt>ipconfig</tt> for that interface on the client:
| |
| | |
| [[Image:Bild53.png|top|alt="ipconfig1"]] | |
| | |
| The only IPv6 address is the link local address. No gateway is set either.
| |
| # To specify prefixes the publish, I issued the following command on the server:<br/>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 <tt>publish=yes</tt> 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 <tt>publish=yes</tt> bit tells the server to publish this prefix information in Router Advertisement messages.
| |
| | |
| Below is a Wireshark capture once prefix publishing is enabled:
| |
| | |
| [[Image:Bild54.png|top|alt="RA2"]]
| |
| | |
| Notice the prefix information is now published.
| |
| | |
| And now <tt>ipconfig</tt> too shows the automatically generated addresses:
| |
| # [[Image:Bild55.png|top|alt="ipconfig2"]]
| |
| # 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:<br/>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!<br/>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:
| |
| | |
| [[Image:Bild56.png|top|alt="RA3"]]
| |
| | |
| And <tt>ipconfig</tt> will show a default gateway is automatically set:
| |
| | |
| [[Image:Bild57.png|top|alt="ipconfig3"]]
| |
| | |
| Ain’t that cool!
| |
| # To view the current configuration of that interface on the server, the following command can be used:<br/>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.<br/>For the former do this:<br/>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 <tt>0x80</tt> now in contrast to <tt>0x0</tt> before). So I have expanded it.
| |
| | |
| [[Image:Bild58.png|top|alt="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.
| |
| ## 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.
| |
| | |
| == Netsh-Befehle für IPv6 ==
| |
| [[IPv6/Windows/Netsh-Befehle]] | |
|
| |
|
| | <noinclude> |
| == Anhang == | | == Anhang == |
| === Siehe auch === | | === Siehe auch === |
| Zeile 205: |
Zeile 33: |
| ==== Links ==== | | ==== Links ==== |
| ===== Weblinks ===== | | ===== Weblinks ===== |
| | [[Kategorie:IPv6/Windows]] |
| | |
| </noinclude> | | </noinclude> |
| [[Kategorie:Tmp]]
| |
| [[Kategorie:IPv6/Windows]]
| |