Put the Mikrotik in place, moved the VLAN tagging from the modem to the router aaaand it worked.
That was so simple.
This is how a router should work.
Discussion
Loading...
Even IPv6 just works.
Wow.
I shouldn't be so surprised by a router just working, but I am.
This is great.
I got stuck debugging an issue where I thought IPv6 on the router itself wasn't working, because I couldn't even ping my monitoring host and certainly not establish a Wireguard tunnel.
But upon further analysis it seems like I only can't reach that particular subnet, rejected by a some Telekom router 
I dug a bit deeper on the funky connection issue from a DTAG line to my monitoring server.
@domi had already confirmed to me that the EPIX exchange regularly has some funkies with IPv6, so now I wanted to figure out whether this was a regional thing, or the entirety of the DTAG network just doesn't know how to reach the target.
And after I got a generous donation of RIPE Atlas credits to use, I was able to determine just that! (thanks @arch :3)
I ran a probe with a mix of 25 AS3320 (DTAG) nodes and some random worldwide ones.
None of the AS3320 were able to reach my target.
I ran another test with 50 random nodes from Germany and another 50 worldwide.
Some tests from around the world failed, which all don't seem particularly relevant to me.
In Germany? Successful connections from Telefonica, Vodafone, 1&1, Oracle, Netcup, Hetzner, Deutsche Glasfaser, multiple regional providers and even randomly an OpenFactory node.
Who once again didn't manage a single successful connection? DTAG!
IPv4 on the other hand works fine. Even shows a lot less failures around the world.
So yeah, don't know who to blame here, but I was able to confirm that the entirety of the DTAG network has no idea how to reach my monitoring server via IPv6. Fun 
Remember when in December I had a bit of a debug session why I couldn't reach my monitoring server via #IPv6 from a DTAG internet line?
Well, this later motivated @domi to dig a bit deeper and it ended up with @q3k sending some emails to EPIX, DTAG and Lumen about it, as it was obviously a bigger issue of an entire /32 IPv6 prefix from Lumen not being accepted by DTAG.
The issue ended up being escalated multiple times and it seemed to take them quite a while to figure out what was wrong.
But as of today (or recently, today is when I got note of it), it works!
DTAG now accepts the 2a0d:eb00::/32 prefix, which they previously rejected due to, supposedly, an incorrectly documented Lumen AS-SET in the RIPE DB.
This is certainly not the escalation I expected after I connect to my server back then 
2 media
