PPPoE server, dual stack IPv4+IPv6, buggy SOHO routers that refuse IPv6

I’ve been running a small local ISP, running VyOS on 4 boxes (2 as BGP routers, 2 as PPPoE servers, OSPF between them). IPv4 setup has been running for a long time, mostly without issues. Now, time to break something and implement IPv6…
It works when set up properly with a MikroTik as PPPoE client, but I have trouble with some cheap routers (mainly Phicomm KE2M - manufacturer no longer exists, too cheap to be upgradable to OpenWRT). IPv4-only setup works with “set service pppoe-server ppp-options ipv6 deny”, but when I change it to “allow”, these broken routers keep disconnecting a few seconds after successful authentication, and RADIUS logs shows these disconnects as User-Request.
Because of this, I may need to run separate PPPoE servers on separate VLANs for broken and non-broken clients. Is there a better way? Since the disconnect happens after authentication, perhaps it is possible to aply “ppp-options ipv6 deny/allow” selectively depending on the user (so it can only be enabled for those with known good routers)?

Hello @marekm72
Try using delegation-prefix and ipv6 address (for example):

set service pppoe-server client-ipv6-pool delegate '2001:db8:8003::/48' delegation-prefix '56'   (ipv6 prefix)
set service pppoe-server client-ipv6-pool prefix '2001:db8:8002::/48' mask '64'                  (ipv6 address)


Actually I use RADIUS attributes for that (Framed- and Delegated-IPv6-Prefix) and with a properly set up good client router it works (with MikroTik I was able to get 10/10 on test-ipv6.com). The problem is, the customers have their own routers not under my control, a mix of different routers with different bugs. All they have in common is that they support PPPoE for IPv4, as that is the service I currently provide (each customer gets a single static IPv4 address, assigned by RADIUS based on PPPoE username). Now, I want to add IPv6 (static framed /64 and delegated /56 prefixes for each customer) for those with routers that support it. But, there are some problematic ones that don’t really support IPv6, but break when ppp-options “ipv6 deny” is changed to “ipv6 allow”. I will try to capture some traffic between such a problematic router and the PPPoE server, perhaps it will help to understand better the issue.

More details to follow - I have set up a problematic router (Phicomm KE 2M - manfacturer no longer exists) as PPPoE client on a dedicated VLAN, and VyOS 1.3.1 as PPPoE server with IPv6 enabled (ppp-options ipv4 require, ipv6 allow), and captured the traffic. I see normal PPPoE discovery, LCP negotiation, PAP authentication, IPCP negotiation- until now, as expected. Then, the router (which in its web GUI has no traces of any IPv6 support!) starts with IPV6CP (client sends random interface identifier to server). Then IPCP and IPV6CP proceed in parallel, IPv4 is negotiated, and soon after, the client sends IPV6CP termination request (the packet contains the string “Interface configuration failedace”), then the server sends LCP termination request and finally PADT. RADIUS logs show Start with all the IP addresses, and then Stop with “Acct-Terminate-Cause = User-Request” in the same second. All of this repeats every 33 seconds, traffic capture is available here - . Other routers either support IPv6 and work dual stack, or don’t support IPv6 and work as IPv4 only, with the same PPPoE server configuration. Unfortunately, these routers were cheap and a significant number of customers has them. My conspiracy theory is that they could no longer be sold in China as the ISPs there already support IPv6, so they sold them to Poland where IPv6 support was not universal yet so the breakage was not apparent (IPv4 only works fine). But, it is the PPPoE server that terminates LCP in response to IPV6CP termination by the client, perhaps the server could just accept IPv6 termination but instead continue to work as IPv4 only?