DX3301-T0 fails to learn IPv6 global LAN neighbour address unless they access router's LAN side one

DavidW93

I've spent a lot of time diagnosing this, and whilst any official bug
report has to come through my ISP, who are more likely to just try a
different brand, I think it worth making this public through the forum.
(I see postings for this model, even though the forum might only be
officially intended for direct to consumer models.)

Steps to reproduce:

1. Ensure that device has new global IP address which is not in the
router's neighbour table. On the Linux system for the primary test,
this was achieved by taking the Ethernet interface down and bringing it
up again (ifconfig interface-name down; followed by ifconfig
interface-name up), and verified by the GUI menu's ARP diagnostics on
the router, but was also true of the initial state.

2. From the device IPv6 ping the WAN side global address of the router.

Expected behaviour.

a) The ping succeeds.
b) The router does a Neighbour Solicitation request to solicited node multicast address of the device.
c) The global IPv6 address of the device is added to router's neighbour cache.

Actual behaviour.

a) The ping times out.
b) There is no Neighbour Solicitation.
c) The neighbour cache remains unchanged.

This establishes that there is a problem with the router (although see steps (5) and (6) for confirmation that the expectations are reasonable). The following steps try to characterise it more precisely:

3) Whilst running a packet capture at the ISP end, ping6 an external host known to be able to respond to such pings (actually my ISPs mail server).

Expected behaviour.

a) The ping succeeds.
b) The ICMP6 echo request and response are seen at the ISP end.
c) There is a Neighbour Solicitation request, as above.
d) The global IPv6 address of the device is added to the router's neighbour cache.

Actual behaviour.

Only item (b) succeeds, suggesting that the problem is on the return path.

4) Use the TCP diagnostics on the router to ping6 the global IPv6 address on the device.

Expected behaviour.

a) The ping succeeds.
b) There is a neighbour solicitation to to the solicited node broadcast address on the device .
c) The global IPv6 address of the device is added to the router's neighbour cache.

Actual behaviour.

a) The ping fails.
b) There is no solicitation.
c) The neighbour cache, on the router is unchanged.

The following steps show how it can be taught to work for a specific device, although should only be considered a workaround, and is not easy to do on a mobile device.

5) Ping6 the LAN side global IPv6 address, of the router, from the device.

Expected and actual behaviour.

a) The ping succeeds.
b) The device makes a Neighbour Solicitation from which the router should learn its link address.
c) The global IPv6 address of the device is added to the router's neighbour cache.

6) Repeat steps 2, through 4, which now produce successful pings (the neighbour entry is already present, at this point).

Environment.

Model Name: DX3301-T0
Serial Number: S250Y21064321
Firmware Version: V5.50(ABVY.7.1)C0

Address allocation stateless, although results with stateful were similar.

WAN side: Openreach FTTC (VDSL), /64 IPv6 allocation, and separate allocation for the WAN side global IPv6 address.

Device: Desktop running Debian 12, although the initial indications of a problem were noticed on a Samsung A16 5G over WiFi. Also some of the tests above were repeated on a Debian netbook, over WiFi, a Windows 11 desktop over Ethernet, with less instrumentation, but behaving the same way.

Initial presentation.

The first indication that there was a problem was that the Samsung email client took almost a minute to read the list of new email messages, going through the router, but was fast on mobile data and fast, on the previous ADSL, IPV4 only, setup. Excessive delays were also present when accessing the Samsung store, for updates.

Additional cases.

Although the formal testing is just done with icmpv6, it also fails for outbound IPv6 TCP, until the above step 5. I didn't test waking it up with TCP or UDP to the LAN side global address, but have no reason to believe those wouldn't have worked. tracert did produce similar results in steps 2, 3, 4, and 6, although I didn't try using it to wake up the neighbour cache in step 5 (I suspect it would have worked).

Analysis.

It appears to me that:

1) The router is never issuing neighbour solicitations to the solicited node multicast address, the only ones it ever issues are ones to refresh the cache, to the unicast address, which is what it doesn't know in the problem case. Failure of RFC 4861 7.2.2.

2) It learns when pinging the LAN side global address of the router because the device
sends a Neighbour Discover request, with its global address as source address. RFC 4861 7.2.3 (SHOULD, type requirement).

3) Speculatively, RFC 9131 rules out other methods of gleaning this information, that were in the field, and it is conceivable that earlier firmware used these, and that was masking the failure to do proper initial discovery, but the current firmware removed this method, so as to come in line with the RFC.