but i did not think a really noticeable lowering of mtu up to 150 was needed ...
It is not
needed - it will
happen if you don't disable the auto-adjusting mechanisms, which otherwise change it down to 150 due to the positive feedback (or self-locking if you prefer that name) loop. I've tried to explain the mechanism how it happens in more detail in my previous post. If you want to avoid problems with MTU, you have to use L2TP with BCP and MLPPP - large frames carrying IPv6 packets will be split at PPP level.
another doubt would be if i use eoip v4, ipv6 ip are also transported ...?
The difference between EoIP(v4) and EoIPv6 is in the transport protocol, not in the payload protocol. EoIP/EoIPv6 transports payload L2 frames no matter what protocol they carry, so it can be even PPPoE, PPPoE-discovery, 802.2 (STP, LLDP, ...), MPLS... And so does BCP.
I do not know the filters on the bridge if not rules at the Firewall level ... then maybe see to understand how they are configured
The
/interface bridge filter works similar to
/ip firewall filter:
/interface bridge filter
add chain=forward in-interface=ether1 out-interface=eoip1 mac-protocol=ipv6 action=accept
add chain=forward in-interface=ether1 out-interface=eoip action=drop
But there's another problem that may prevent it from working - most virtualisation platforms do not allow MAC address "spoofing", i.e. they drop packets coming from a virtual machine if their source MAC address differs from the one of the interface of that machine. So you may have to use also
/interface bridge nat rules to hide the bridging from the virtualisation platform:
/interface bridge nat
add chain=srcnat in-interface=ether1 mac-protocol=ipv6 src-address6=2000::9 action=src-nat to-src-mac-address=mac:addr:of:ether:1:of:chr
add chain=dstnat out-interface=ether1 mac-protocol=ipv6 dst-address6=2000::9 action=dst-nat to-dst-mac-address=mac:addr:of:bridge:of:rb