Windows IPV6 - Cannot Ping Outside Local Network

Question

I'm setting up and testing IPv6 on our network and have run into a snag with our windows clients..

I've got a Cisco Catalyst 3850 switch setup for ipv6 unicast-routing and have two networks setup on it. The catalyst switch also has a working ipv6 route out to the internet and I've been able to successfully contact public ipv6 server addresses without issue from the switch CLI (from the switch's ipv6 gateway address on either network).

The gateway addresses/networks on the switch are: VLAN 20: 2607:f460:21c0:a020::1/64 VLAN 200: 2607:f460:21c0:a200::1/64

I can ping one of the configured networks from the other with no issue:

ping 2607:f460:21c0:a200::1 source 2607:f460:21c0:a020::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2607:F460:21C0:A200::1, timeout is 2 seconds:
Packet sent with a source address of 2607:F460:21C0:A020::1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/10 ms

There are no ACLs or special routes setup on the switch other than the default ::/0 public route to the internet.

The windows client resides on VLAN 20 and has the static address: 2607:f460:21c0:a020::2/64 with 2607:f460:21c0:a020::1 set as the default gateway..

If I ping the gateway, it works...

C:\Windows\system32>ping 2607:f460:21c0:a020::1

Pinging 2607:f460:21c0:a020::1 with 32 bytes of data:
Reply from 2607:f460:21c0:a020::1: time=2ms
Reply from 2607:f460:21c0:a020::1: time=2ms
Reply from 2607:f460:21c0:a020::1: time=2ms

C:\Windows\system32>tracert -6 2607:f460:21c0:a020::1

Tracing route to 2607:f460:21c0:a020::1 over a maximum of 30 hops

  1     2 ms     2 ms     2 ms  2607:f460:21c0:a020::1

Trace complete.

If I try to ping anything outside the local On-Link network, it fails with an unreachable error:

C:\Windows\system32>ping 2607:f460:21c0:a200::1

Pinging 2607:f460:21c0:a200::1 with 32 bytes of data:
Destination host unreachable.
Destination host unreachable.
Destination host unreachable.
Destination host unreachable.

Ping statistics for 2607:f460:21c0:a200::1:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),


Tracing route to 2607:f460:21c0:a200::1 over a maximum of 30 hops

  1  Destination host unreachable.

Trace complete.

The fact that the trace fails on the first hop with unreachable implies to me that windows does not seem to be trying to contact the default route but rather is searching for the host on-link...

This doesn't make sense to me, because I have a gateway set, and it has a lower metric than the on-link route..

===========================================================================
Interface List
  7...00 50 56 94 e7 38 ......vmxnet3 Ethernet Adapter
  1...........................Software Loopback Interface 1
===========================================================================

IPv6 Route Table
===========================================================================
Active Routes:
 If Metric Network Destination      Gateway
  7    271 ::/0                     On-link
  7    271 ::/0                     fe80::521c:bfff:fe73:1656
  7     16 ::/0                     2607:f460:21c0:a020::1
  1    331 ::1/128                  On-link
  7    271 2607:f460:21c0:a020::/64 On-link
  7    271 2607:f460:21c0:a020:947a:1291:c6e3:b93d/128
                                    On-link
  7    271 fd67:df27:a77::/48       On-link
  7    271 fd67:df27:a77:7777::/96  On-link
  7    271 fe80::/64                On-link
  7    271 fe80::947a:1291:c6e3:b93d/128
                                    On-link
  1    331 ff00::/8                 On-link
  7    271 ff00::/8                 On-link
===========================================================================
Persistent Routes:
  None

Anyone able to help me with this?

Answer 1

Well, here's what I've just discovered...

When I delete the ::/0 On-Link route, it starts to work. I'm not sure why this would be the case other than going with the assumption that windows must prioritize on-link routes even if their metric is higher than a manually configured route.

Then I asked, "Why would that route even be there?"... I did some digging around and windows enables stateless autoconfiguration (SLAAC) on ipv6 interfaces by default.. This can be disabled by issuing the following command for the interface in question...

netsh inter ipv6 set interface "X" routerdiscovery=disabled

When SLAAC gets disabled, the ::/0 On-Link route gets removed and everything starts to work.

Why SLAAC configures that default on-link route, I don't know.. Bonus points if someone can explain that to me... Here's my suspicion which I'm not going to bother testing - In order to get a proper default route, SLAAC would need to be enabled on my routers (my switches) so they advertise the routes to my windows clients.

I'm staying away from SLAAC because I want to use my own addressing scheme, so I will just disable it on my statically assigned windows servers.

I'm hoping for my dhcp clients that I can configure an option to tell them not to use SLAAC...

Answer 2

The ::/0 route was only occurring on a few of my servers.. I could delete the route and it wouldn't come back.. SLAAC would then start working.

I still ended up disabling SLAAC on my managed networks since we don't really use android devices. I like having everything managed by DHCPv6, and I was having trouble getting DDNS registration working with my windows clients using SLAAC addressing.