An MTU problem is definitely possible, if your router's IPv6 implementation doesn't clamp MSS to MTU.

The easiest way to figure this out is to use a client *nix OS which lets you fiddle with MTU easily

Typically one would clamp it to PMTU and let the kernel do the math. Do you have the option for that?

Mine seems to have it. I can add the mangle rule, although I can't confirm whether it actually works. Version 6.4 FWIW.

Having said that, technically it's not pure in the sense that there's something in the middle meddling with the IP payload. Lemme see whether there's any IPv6 spec that addresses the PMTU problem.

Oh I didn't know they would add those rules automatically. Mine doesn't add them for IPv4. In Linux, the MTU mangling is normally done in rp-pppoe userspace client, so it isn't necessary to create iptables rules. I don't know if Mikrotik uses the same pppoe client implementation.

So now I understand what you mean by "manually". What I meant wasn't automatic as in remove the need to manually add clamping rules. Just to remove the manual MSS calculation, by using a rule like:

When I'm free (after I catch up to all the work I missed from being sick) I'll set up an experiment to figure out this MTU problem. In theory... PMTU discovery should address this. But why isn't it?

I'm fairly sure that it is Linux, not rp-pppoe, which does that. If you disable the autoconf sysctl, you will not see any ICMPv6 route solicitations sent.

Well in the case of PPPoE, the MTU of the host's link layer is bigger than the router's.

AFAIK there's two ways to handle this - 1) through RA announcements about the smaller MTU (not sure whether this is honored by popular OSes), or 2) MSS clamping (which breaks end-to-end principle). The fallback is PMTU discovery.

Coincidentally, after some downtime on my FTTH link today, at reconnection my BRAS now assigns me an allocation through DHCPv6

Our hosting provider's IPv6 is down, so you guys won't be able to surf the forum over IPv6 until it is rectified.

I've been investigating the MTU issue more closely now that I have IPv6 working at home.

I think it's a problem specific to Mikrotik. MTU for the PPPoE interface is set to 1480 by default. So if you use clamp values that you found through googling, they might not work if calculated to assume an MTU of 1492.

Further compounding the problem, it appears that a ICMPv6 Packet Too Big isn't sent back to the host in this case.

In my opinion, the best solution on the Mikrotik is to set your IPv6 -> ND -> MTU advertisment to match your PPPoE interface MTU. Doing it this way is less hackish than writing mangle rules for the router to change the TCP MSS. Furthermore the MTU hint will be usable by protocols other than TCP.

I have set lowered it from 30d/1w to 2h/1h for Valid/Preferred. Confirmed on Linux that the new lifetimes have taken effect.

In RFC 4862 section 5.5.3, it is recommended that hosts ignore AdvValidLifetime < 2 hours, to avoid a denial of service attack from bogus advertisements. So I think you should raise that to 2 hours.

Ahh yeah Windows has that problem. I did some reading and found one way to address it: the routers sends a 0-second ValidLifetime RA to "clear" the prefix. This probably isn't supported by Mikrotik though.

Hmm you might be on to something!

Mikrotik wiki has a code snippet that can be used together with that: http://wiki.mikrotik.com/wiki/Manual:Scrip...ce_have_changed

The first record of our implementation was in December 2010: https://forum.lowyat.net/topic/1420285?author=wKkaY

Checked out a looking glass and saw that they also use NTT, C&W, Sprint.

And for what it's worth, lowyat.net's hosting provider isn't peered with TMNet at MyIX. Not sure when it will be complete

It's in AIMS @ Jalan Raja Chulan.

I have split off the Youtube discussion to https://forum.lowyat.net/topic/3010305

Please center this discussion around TMnet and IPv6.

Ja!