IP6 relay problems

I've switched back to my old ISP (Sky) but now have to use the supplied modem/router (SR204), which cannot be operated in bridge mode, so i'm having to use double NAT. the IP4 side of things seems fine, but i'm having some issues with the IP6 side.

i have to run in relay mode as the SR204 does not support P-D. last time this worked ok, but this time I've noticed that i have random jitter on IP6 pings, where the RTT is usually 1-2ms but can spike to 800-900ms. this shows up even when pinging the LAN port of the SR204 (which is connected to the WAN port on my R7800), so it's not an external issue.

from using wireshark and tcpdump, from what i can tell the spikes happen when the SR204 does a neighbour solicitation asking for the client doing the ping, then has to wait for a neighbour advertisement response. in fact the tcpdump is full of constant NS and NAs for the same addresses (all addresses of devices connected to the R7800). looking at an individual NS and NA response, i'm not entirely sure this is right. The SR204 sends an NS for the address of the client device (the one running ping):

    Type: Neighbor Solicitation (135)
    Code: 0
    Checksum: 0x1e07 [correct]
    [Checksum Status: Good]
    Reserved: 00000000
    Target Address: 2a02:c7f:ac4a:6800:6d37:961a:eb9d:671
    ICMPv6 Option (Source link-layer address : 11:22:33:44:55:66)
        Type: Source link-layer address (1)
        Length: 1 (8 bytes)
        Link-layer address: BSkyB_f4:33:29 (11:22:33:44:55:66)

and the R7800 responds with an NA containing the MAC address of its own WAN port

Internet Control Message Protocol v6
    Type: Neighbor Advertisement (136)
    Code: 0
    Checksum: 0x11f2 [correct]
    [Checksum Status: Good]
    Flags: 0x40000000, Solicited
    Target Address: 2a02:c7f:ac4a:6800:6d37:961a:eb9d:671
    ICMPv6 Option (Target link-layer address : 66:55:44:33:22:11)
        Type: Target link-layer address (2)
        Length: 1 (8 bytes)
        Link-layer address: Netgear_ef:3a:48 (66:55:44:33:22:11)

the R7800 replies to all NS requests from the SR204 for any device attached to the R7800 with the MAC address of its own WAN port. isn't this wrong? i don't really understand IPV6 but isn't this telling the SR204 'this is an individual IP6 address connected on this MAC address'? so there will potentially be collisions?

from what i can tell this is kinda borne out by the web UI of the SR204, i'm sure the last time i had this working (on an SR102, in 2018) it showed all devices connected to the R7800 in its 'attached devices' table, each with their own mac address IIRC. now it only shows one device at a time, always with the R7800s WAN MAC address, and a constantly changing IP6 address.

my vague recollection was that the R7800 used to send ICMPV6 Redirect responses, rather than NA responses, but i could be wrong.

i think all the above might be a bit of a red herring...does anyone know much about how odhcpd works? as far as i can tell the lag happens because periodically the SR204 sends a NS request to the R7800 for the PC's IPV6 address. when it does this odhcpd pings the PC on its IPV6 address, and somehow this triggers the R7800 to send a NA back to the SR204. all of this traffic happens within 1-2ms:

  • PC-SR204 ping request
  • SR204-R7800 NS
  • R7800-PC ping request
  • PC-R7800 ping response

but then there is a delay of several 100ms before these two happen almost simultaneously

  • R7800-SR204 NA
  • SR204-PC ping response

as far as i can tell the kernel is responsible for sending these NA responses, does anyone have any idea what is causing the delay?

for future reference i solved this by disabling odhcpd's NDP proxying and using ndppd instead: IPv6 NDP relay works only on second attempt - #6 by facboy

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.