Experience after upgrading to 10G ぷらら (plala)

[fakemanhk]

First I need to thanks for an Reddit user reported to me regarding the experience on his/her 10G NTT with OpenWrt so I open up this discussion to drop down some notes about 10G ぷらら service, it might also be applicable to other similar 10G plan.

I noticed that ぷらら has add-on service named "GGGG" claiming faster route, lower latency and good for gaming, this add-on service will change the connectivity from MAP-E to DS-LITE (mentioned on their website), which can't use this guideline for connectivity.

Before I upgrade to 10G, the 1G plan without Hikari phone service will result into no-RA & a /64 prefix, I thought it was also true after upgrading to 10G plan so I really never look into the details when things were working as usual until the Reddit user told me that WAN6 side is getting /56 with PD but not /64 prefix! So now interesting thing comes....

You can play with the prefix length and subnet ID on LAN side (if you have multiple VLAN then you can play with more subnets), and by default WAN6 interface gets NO IP address, only a /56 prefix, since it comes with PD so you don't have to manually put option ip6prefix xxxxxxx/64 under WAN6 interface.

[missing233]

I found that even without configuring ip6prefix, it's still possible to automatically obtain PD. However, every once in a while, wan6 loses connection (10G only). Have you encountered a similar issue?

[fakemanhk]

I forgot to ask, will your connection come back automatically (after a few seconds/minutes?) or needs manually reset to bring it back?

[missing233]

Yes, it comes back automatically in about 10s.

[fakemanhk]

I found that even without configuring ip6prefix, it's still possible to automatically obtain PD

That's normal, because in old days with /64 there was NO RA on WAN side (I did a tcpdump and verified), and now with /56 there is RA + PD available and you can see that WAN6 has only prefix but no address now (it's actually not that important)

However, every once in a while, wan6 loses connection (10G only). Have you encountered a similar issue?

Yes I do notice this, haven't investigate into detail yet, but this also happens on Buffalo WXR-5950AX12 with stock firmware, I am thinking whether this is NTT's problem or not.

[fakemanhk]

Do you capture logs? Most of the time things happening while I'm not at home or in middle of night that I can't really see what's going on there.

[fakemanhk]

BTW I remembered one thing, when I used the Buffalo WXR-5950AX12 with stock firmware, and then I went to some extremely slow/free online storage platform to download a file, since it has speed limit so my files took 36-48hrs to download, and I almost never seen interruption, so that means the interruption on stock firmware is less frequent.

[missing233]

It loses connection regularly, just like the issue:
openwrt/openwrt#13454

[fakemanhk]

BTW not sure if we can change the client?
Like the "isc-dhcp-client-ipv6", and I saw there is another non-embedded "dhcpcd" (however not sure if they are still available on 23.05)
Because like my WXR-5950AX12 doesn't have this issue with stock, and I think the stock is using older firmware (at that time there is no 23.05.0 yet), there might be a chance that those routers using something other than odhcpc6.

Also is the "fakeroute" option for odhcpc6 works?

[missing233]

OpenWrt used Dibbler as the DHCPv6 client 10 years ago, now it uses odhcp6c.
Perhaps compiling a version prior to 2018 could verify your speculation.
I found this information on the OpenWrt forum:

The "fakeroute" is a workaround in case of a network's main and only router sending improper RA packets which don't announce that the router is the default route. You can use option fakeroute 0 to disable this behavior (the default is 1).
If your network is designed around DHCPv6 and you don't want to act upon RA packets at all, you could also try options noslaaconly 1 and reqaddress force though I'm not sure if that is sufficient to completely disable RA.

[missing233]

@fakemanhk Have you tried directly connecting CentOS or Debian to the 10G-ONU? I attempted to create a NAT0 environment for testing on CentOS7 and Debian12, but I couldn't access the IPv6 internet no matter what. I tried wide-dhcpv6-client, dhcpcd5, and dhclient. Even though they completed the DHCPv6 Solicit, they couldn't add the address and route to the wan interface. Only OpenWrt worked properly.

I tried the methods mentioned in these blogs written by Japanese people, as well as switching the system back and forth between CentOS7, Debian 12, and Ubuntu Server, but all attempts failed.
https://zenn.dev/koyashiro/scraps/d05ff8a0ddeeef#comment-8f1f7638d131b9
https://quintrokk.subness.net/?p=1979#toc2
https://benedicam-te.blogspot.com/2020/05/map-e-router-by-debian-box-iptables.html

[fakemanhk]

Haven't tried using a normal client PC to connect, but from what I observed, even OpenWrt WAN6 interface is only requesting a prefix, if I try to force getting IP address it will fail.

Did you try to follow this to perform prefix delegation with radvd for SLAAC?