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.
- 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:
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:
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:
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:
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:
Notice the prefix information is now published.
And now ipconfig too shows the automatically generated addresses:
- "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:
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:
And ipconfig will show a default gateway is automatically set:
Ain’t that cool!
- 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.
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.