I have a network in which the ISP is giving a /64 IPv6 network and single IPv4 address. The ISP keeps first address in the /64 for their router.
So.. I have to transparently do IPv6 firewalling while NATting the IPv6.
Is there a way to control which protocols are sent to be routed in the bridge filter?
In Linux this seems to be done in BROUTING chain, which is missing in the RouterOS.
Simple drop protocol ipv4 in BROUTING chain seems to force it routed instead of bridging.
I first tried to do everything with bridge filter and use-ip-firewall=yes, but that ended in extremely complex rules and strange behavior.
It would be. But with only one /64 network I can’t see how it is possible? The ISP’s router thinks all addresses in /64 are local, not routed through my router.
routers do not need to have ipv6 addresses so your solution is to put /64 prefix in your LAN where your local ipv4 addresses reside and on the routers between you just set up ipv6 routes that will point where your /64 prefix is. just ask that your provider sets up route to your /64 prefix via LL address.
Which your providerprobably allready did.
Just assign a IPv6 from the ::/64 to your internal interface, add the default ipv6 route to your external one, set up forwarding and voila..
And you can use the router to do RA on the interior if you would like automatic configuration.
I think the best way is to use two interfaces towards the internet. One routed with ipv4 and one bridged with ipv6.
Or write/debug complex bridge-firewall rules.
All the workarounds proposed in this thread require ISP to do routing. My ISP does not wish to do too much work for IPv6 connectivity, so there is no link-local routes available.
Hopefully the BROUTING one day returns to RouterOS.
I would vote too for the features like Proxy NDP and BROUTE. There is a huge problem with some ISPs, givinga out /64 prefixes and doesn’t route anything but to the nodes directly attached to their router. My RB100 (v5.19) is behind of one of those.
There are some strange behaviors with my configuration:
From my Mikrotik I can ping the world only if the default route is set as the link-local address of the ISP’s router AND if the WAN interface doesn’t have the global address from my prefix. In that condition the router’s global address (::1/64) pings too. But from the LAN behind MT the Echo Requests get through both routers (verified with Wireshark on the remote server), but Reply gets “not reachable” response from the ISP’s router.
If I set my WAN’s interface manually to the same subnet within my prefix (EUI64 or not), Mikrotik cannot ping the router’s global IP-address anymore (but can ping the world).
If I set the ISP router’s global address as the default route instead of LL, it says it’s reachable. But ping doesn’t get response anymore from anywhere.
So, the only possible way to get the Routerboard connected to the world via IPv6 is setting the ISP’s router’s LL as the default gw and NOT assigning to the WAN’s interface an address from the pool of the prefix. But that doesn’t give my LAN the IPv6 connection.
So I’ve learned that there are only 2 methods to get a /64 prefix to work behind a blackbox + personal router: NDP Proxy and BROUTE. I even count it very urgent matter, because half of the world gets /64 prefixes and many of them need to reroute it. Cannot make an extra bridge to the router neither, because I can’t make an additional port free for it.
I can confirm that this is a problem. One of my provider is delivering a single /64 and does not care about IPv6 routing. So it’s not possible to get that working with RouterOS, even using 6.7 version.
NDP proxying or IPv6 bridging seems the only solutions.
I have another provider delivering a /48 (PPPoE) and in this case there is no problem.
If we could split IPv4 and IPv6 traffic on two different virtual interfaces, this would make possible the routing of IPv4 and bridging of IPv6.
I did try to bridge IPv6 with an external switch using a per protocol VLAN but the solution does not work for an unknown reason (HP PROCURVE 2610 switch firmware 11.98). Per protocol VLANs does not seem to work on this switch. If some users did have success with procurve switches and protocol based vlans let me know.
Mikrotik can you do something for users that have a provider delivering a non routable /64 ? In my country there are a few millions users in this situation (Free Provider).
I’m scared to state, but it looks like we will need a meta router until MT makes this possible within ROS. Unfortunately all my meta routers were unstable so I don’t like them much
Bridging is about expanding layer 2 - Link layer. The fact that other layers (IP layer, Packet layer) start working in same Ethernet network is a direct result of what happened on Link layer.
If you want to just send packets somewhere, you can get CRS and in ACL configure redirect rules. But that is not going to be anything supported by any network structures.
I wonder if a router manufacturer has to implement all kinds of workarounds for stupid decisions by ISPs?
Is it really common to have this double-broken IPv6 architecture?
It could be fixed at least in two different ways:
the ISP could give out more than a /64 to each customer. I get a /48 from my ISP. A /60 would be plenty.
the ISP could ROUTE the /64 to the customer over a link-local address obtained on PPPoE or ethernet.
In my case, my ISP uses DHCPv6 PD to retrieve the /48 prefix, but there is no global address on the link
between the local router and ISP router, so for a single internal network I use only a /64 from that /48.
A provider that wants to give out only a /64 could use the same method and it would just work.
After 12 years this is still more common than you think (in a way i would say it became a norm). OpenWRT adapted by providing odhcpd and ndppd, Ubiquiti can have ndppd installed with little effort, Mikrotik users are still kinda left behind…
