Windows IPv6 hosts lose default gateway after couple of minutes

Hi,

I have just purchased an USG20W-VPN a couple of days ago, and noticed some issues with IPv6 connectivity after configuring the device.

The problem is that Windows 10 IPv6 hosts lose their default gateway a couple of minutes after they have connected to the network. Right after connecting to the network I am able verify that the host passes test-ipv6.com connectivity check, but already after 4-5 minutes the host might lose default gateway and routing to IPv6 internet is not possible anymore.
Other configuration such as all configured IPv6 host addresses and DNS servers do persist even when the gateway is lost.

My interface configuration is as follows:

The WAN interface is connected to a cable modem which is configured to bridged mode.
My ISP provides a dual stack connection with native IPv4 and IPv6, and the ISP's DHCPv6 server provides a ::/56 network prefix and IPv6 DNS servers for USG20W-VPN.

"lan2" interface is a VLAN trunk port which is connected to a managed switch, "vlan1" is only a management interface, and "vlan2" is the network where IPv6 hosts are connected either via the managed switch or the internal WiFi.

I have enabled DHCPv6 server in vlan2 interface configuration to provide DNS server information, and enabled ICMPv6 Router Advertisements with the Other configuration bit set and added a delegated prefix ::1/64.

The RA packets seem to look good to me in Wireshark:
Frame 34: 118 bytes on wire (944 bits), 118 bytes captured (944 bits) on interface 0
Ethernet II, Src: ZyxelCom_xx:yy:zz (bc:99:11:xx:yy:zz), Dst: IPv6mcast_01 (33:33:00:00:00:01)
Internet Protocol Version 6, Src: fe80::be99:11ff:fexx:yyzz, Dst: ff02::1
Internet Control Message Protocol v6
    Type: Router Advertisement (134)
    Code: 0
    Checksum: 0x4363 [correct]
    [Checksum Status: Good]
    Cur hop limit: 64
    Flags: 0x40, Other configuration, Prf (Default Router Preference): Medium
        0... .... = Managed address configuration: Not set
        .1.. .... = Other configuration: Set
        ..0. .... = Home Agent: Not set
        ...0 0... = Prf (Default Router Preference): Medium (0)
        .... .0.. = Proxy: Not set
        .... ..0. = Reserved: 0
    Router lifetime (s): 1800
    Reachable time (ms): 0
    Retrans timer (ms): 0
    ICMPv6 Option (Prefix information : 2001:14ba:1122:3301::/64)
        Type: Prefix information (3)
        Length: 4 (32 bytes)
        Prefix Length: 64
        Flag: 0xc0, On-link flag(L), Autonomous address-configuration flag(A)
            1... .... = On-link flag(L): Set
            .1.. .... = Autonomous address-configuration flag(A): Set
            ..0. .... = Router address flag(R): Not set
            ...0 0000 = Reserved: 0
        Valid Lifetime: Infinity (4294967295)
        Preferred Lifetime: Infinity (4294967295)
        Reserved
        Prefix: 2001:14ba:1122:3301::
    ICMPv6 Option (MTU : 1480)
    ICMPv6 Option (Source link-layer address : bc:99:11:xx:yy:zz)

However, the (solicited) Neighbor Advertisement packets sent by the router do look suspicious to me, the Router bit is not set in flags:
Frame 81: 78 bytes on wire (624 bits), 78 bytes captured (624 bits) on interface 0
Ethernet II, Src: ZyxelCom_xx:yy:zz (bc:99:11:xx:yy:zz), Dst: 0a:12:65:a0:f1:95 (0a:12:65:a0:f1:95)
Internet Protocol Version 6, Src: fe80::be99:11ff:fexx:yyzz, Dst: fe80::f0f5:85df:f6bf:d44b
Internet Control Message Protocol v6
Type: Neighbor Advertisement (136)
Code: 0
Checksum: 0xab2c [correct]
[Checksum Status: Good]
Flags: 0x40000000, Solicited
0... .... .... .... .... .... .... .... = Router: Not set
.1.. .... .... .... .... .... .... .... = Solicited: Set
..0. .... .... .... .... .... .... .... = Override: Not set
...0 0000 0000 0000 0000 0000 0000 0000 = Reserved: 0
Target Address: fe80::be99:11ff:fexx:yyzz

I assume that the Router bit being zero might be the culprit of my problem here?
At least according to RFC4861 section 7.2.5 the default router information must be dropped by a host, if that bit is not set.

USG20W-VPN is running the latest firmware V4.32(ABAR.0).

---
PS. Before purchasing the device I had the same cable modem in router mode, and IPv6 connectivity was working properly.
It did set the Router bit in NA packets, and also supported draft RFC options in RA packets instead of stateless DHCPv6 to advertise DNS servers and routes.





Best Answer

Answers

  • tpetpe Member Posts: 3
    Thanks @Ian31, that seems to have solved my problem!

    I disabled SLAAC on vlan2 interface and configured it to use DHCPv6 prefix delegation instead, and now the Router bit is set in ICMPv6 NA packets.
    After one hour of testing I haven't observed anything weird with the gateway configuration anymore.
  • retret Member Posts: 5

    Hello,

    I have the exact same problem, but I have not understood how you fixed it. Could you please post some screenshots or tell me what you have changed?





  • tpetpe Member Posts: 3
    Hi @ret,

    The only thing I changed was the IPv6 address assignment of the internal downlink interface "vlan2" where the windows computers are connected. Here is a picture of the modified settings:

    SLAAC needs to be disabled, and I also assigned a global address to the interface using DHCPv6 prefix delegation and a static suffix from the same ::1/64 range that I had configured earlier in the router advertisement settings for the same interface:


    The relevant interface configuration has now changed to this:


  • retret Member Posts: 5

    Thank you for your answer @tpe

    I deactivated SLAAC. The problem is that I am now not getting an ipv6 connection. Not even for a short time.



    WAN:

    LAN:


    Thank you in advance.
  • Zyxel_CharlieZyxel_Charlie Zyxel Official Agent Posts: 686  mod
    @ret
    Regarding to your configuration, it seems there is overlap between wan and lan.
    Modify Lan's suffix address to ::16dd:a3ff:0:0:11/64

    Also, since you already enabled the DHCPv6, please leave empty on Advertised Prefix Table.

    After modified, please try it again.
    Charlie
Sign In to comment.