Contact

Subscribe via Email

Subscribe via RSS

Categories

Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan

Enabling 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.

  1. 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.
  2. I assigned an IPv6 address “fdcc:7c4e:3651:1::254”, netmask 64, to the server.
  3. Next, I issued the following command on the server to enable router advertisements:

    This 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.

  4. To specify prefixes the publish, I issued the following command on the server:

    In case that command gives an error – maybe you don’t have that route entry already – replace it with the following:

    This 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:
    ipconfig2

  5. 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:

  6. 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!

    Checking 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!

  7. To view the current configuration of that interface on the server, the following command can be used:

  8. 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:

    For the latter do this:

    Here’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:

    1. 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.
    2. 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:

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

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.

Using netsh to set Static/ DHCP addresses

Place where I work, our desktops are locked down so regular users have no access to the network settings. And since I am always logged in as a regular user and only use my admin account via RunAs (because it’s best practice not to be logged in with your admin account) I don’t have access to the network settings window either. Of course I could logout-login, but who does that!?

Enter netsh (or PowerShell if you are on Windows 8, but I am on Windows 7 at work).

To show your currently assigned IPv4 addresses and interfaces:

To set a Static IPv4 address for the “Local Area Connection” interface:

And to set a DHCP IPv4 address for the “Local Area Connection” interface:

Easy peasy! (sort of)

A cool thing about netsh is that it’s an interactive shell so you can type netsh at the command prompt to enter the shell and then navigate around to get a list of commands and slowly figure your way out.