Packet loss / timeout on some IPv6 connections

RouterOS General
1

I'm using a hEX S (2025) with routeros 7.20.6 on a fiber optic modem. The connection is established via PPPoE client. My ISP is providing an IPv4 address and an IPv6 prefix via DHCPv6 client. I'm using VLANs to split up my network.

When using IPv6, the most webpages works as expected, but some webpages/webservices are not reachable (TLS timeout), some are occasionally available after multiple retries. I do not observe this behavior on IPv4. I have the issue on LAN and WLAN. Also when conneting my Laptop directly to the mikrotik router (with VLAN activated on my laptop interface).

When I directly connect my Laptop via PPPoE client on the fiber modem, all IPv6 pages works fine and I can't replicate the behavior. According to my ISP, there is also no problem with the line itself.

I would like to understand and nail down the problem. How can I approach troubleshooting?

My configuration looks like the following. I have removed some configuration details. If something relevant is missing, I can provide it:

/interface pppoe-client
add add-default-route=yes allow=pap,chap,mschap2 disabled=no interface=vlan7-telekom max-mtu=1492 name=pppoe-telekom profile=default-encryption user=xxxxxxxxx@t-online.de

/interface ethernet
set [ find default-name=ether1 ] comment="WAN"
set [ find default-name=ether2 ] comment="VLANs"

/interface vlan
add comment=vlan7-telekom interface=ether1 name=vlan7-telekom vlan-id=7
add comment="office" interface=ether2 name=vlan16-office vlan-id=16

/interface list
add comment=defconf name=WAN
add name=all-vlan

/interface list member
add comment=WAN interface=pppoe-telekom list=WAN
add interface=vlan16-office list=all-vlan

/ipv6 dhcp-client
add add-default-route=yes allow-reconfigure=yes comment=pppoe-telekom-dhcpv6 default-route-tables=main interface=pppoe-telekom pool-name=pppoe-telekom-dhcpv6-pool request=prefix use-interface-duid=yes use-peer-dns=no

/ipv6 address
add comment=pppoe-ipv6-vlan16-office eui-64=yes from-pool=pppoe-telekom-dhcpv6-pool interface=vlan16-office

/ipv6 nd
set [ find default=yes ] advertise-dns=no disabled=yes hop-limit=64 ra-lifetime=none
add advertise-mac-address=no interface=vlan16-office managed-address-configuration=yes

/ipv6 nd prefix default
set preferred-lifetime=1h valid-lifetime=3h
2

Try adding a PMTU clamping rule for v6:

/ipv6 firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu out-interface=pppoe-client protocol=tcp tcp-flags=syn
1 Like
3

Now it works like a charm. Thank you very much @Fasder.

I have a question for understanding:
Why do I have to set the PMTU with a rule manually and why is this not set by the router itself? I try to understand the behavior. Is this something which is ISP specific or why is this not set by default?

4

For PPPoE, if you use the default PPP profile that has the Clamp TCP MSS option turned on then this is done for you but only for IPv4. That's why you usually don't notice the problem if you only use IPv4 with PPPoE.

You should however first try to see whether your ISP supports RFC 4638. Try to modify the pppoe-telekom settings and set max-mtu=1500 and max-mru=1500 to see what happens. If the connection succeeds and display Actual MTU = 1500, then you won't even need the mangle rule that clamp the MSS.

If that does not succeed, then your ISP doesn't support RFC 4368, and you'll have to live with the non-ideal MTU value. The MSS mangle rule will help but only for TCP. In case Actual MTU shows value smaller than 1500, get that value and put it in the IPv6 -> ND entries, in the property MTU. The value will be advertised to the clients, and they will limit their packet size accordingly, and you won't need the mangle rule anymore, and UDP also has proper knowledge of the limit.

1 Like
5

Thank you very much. It seems, that my ISP does not support RFC 4368. I already tried to set max-mtu=1500 and max-mru=1500 but after connecting via PPPoE, I receive MTU=1492 in the client.

Now I changed ND -> MTU to 1492 and disabled the mangle rule for testing, which seems also to solve the problem.