Plusnet Gateway dropping IPv6 tunnel data

[#1]

---

@dave wrote:

... As such need to get a bit of confirmation on @RPMozley's setup.

---

@dave   can you spell out exactly what you need  @RPMozley  to tell you, that hasn't already been stated in this thread ?

I used to run an H.E. IPv6 tunnel over Plusnet static IPv4 for about 13 years, and if I was trying to answer you, I wouldn't know what 'confirmation of setup' you are trying to find out ?

.

[#2]

Good point.

On a Mac/Linux the output of ifconfig showing the relevant tunnel interface (IPv6 address can be redacted)

ifconfig

gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
tunnel inet 192.168.1.116 --> 209.51.161.14
inet6 fe80::60b1:5232:61c4:17ee%gif0 prefixlen 64 scopeid 0x2
inet6 2001:470:<snip>::2 --> 2001:470:<snip>::1 prefixlen 128
nd6 options=201<PERFORMNUD,DAD>

I think ipconfig /all is the equivalent on Windows (again IPv6 address can be redacted) and only need the tunnel interface.

I'd check to see if they are the same on both a working gateway and none-working one.

Also would be useful get the result of the following on working and none-working gateways:

ping6 ipv6.google.com

traceroute6 ipv6.google.com

[#3]

Thanks @dave , I guess we'll have to wait for @RPMozley to reappear.

.

[#4]

Hi all, I’m here now, been a bit preoccupied with other things (mostly concerning my older brother’s cancer op) and I’ve not had a PPP drop that put us on a “problem” gateway.

I did some short testing earlier and I saw some strange results. Currently I’m setup with a Ubuntu based Linux machine connected with ethernet, acting as IPv6 server (along with DHCP and DNS proxy services).
Connectivity was a little off with some IPv6 locations accessible while others just timing out. I tried to find any correlation with the problem sites but it’s not anything clear (not IP address). One possibility is the TLD “.io” (DNS is being provided by NextDNS which uses .io). It’s not entirely clear though as there could be cached responses in play. Ping tests were carried out using “mtr” and were working but slow output possibly due to reverse dns lookups (only Google domain tested).
Testing done while connected to GW .255 and tunnel server 216.66.80.26
Once back on GW .251 connectivity is back to normal.

I think some further longer testing sessions are required to find the diagnosis of the problem.

[#5]

Managed to get in one longer time period testing session during the week (at late night).
TLD turned out to be just a red herring. I first started on test-ipv6.com with a working gateway, all ok. Switched to an “odd” gateway and immediately reloaded test-ipv6, some timeouts seen on two of the tests. Then tried ping -6 -c 10 google.com no problems.
Back to test-ipv6.com even more timeouts on the tests! Another reload and IPv6 connectivity completely broken.
Tested ping google.com again, still no issues.

Completed testing and have to go through the lottery of dropping PPP in the hope of getting back on the only working gateway. Back on gateway .251 and IPv6 is perfectly fine.

Results!
ICMPv6 traffic - unaffected.
All other traffic - timeouts with zero responses.

Possible fixes? (just educated guesswork)
MTU problem? ICMPv6 packets are much smaller than data packets.