I am trying to setup IPv6 with only a /64 assigned to me from ISP and 4 segregated bridges on my network. Quite new to IPv6 so not sure what is the correct solution. What is the proper way to do so?

If I set each of the router address for each of the bridge to be /64, the computers wont router traffic for the other bridges through the gateway since /64 is considered local through the RA (?) and is just sent through the ethernet interface as local traffic. However, the bridges are like individual networks and need to pass through the router to check for firewall rules.

If I set each of the router addresses for each of the bridge to be /72, I can't set advertise=yes.

Currently ROS (and some other OSes as well) doesn't support well IPv6 addresses with prefix lengths other than /64. Meaning you should always use /64 addressing. So if ISP only gives you a single /64 prefix, you can only have single LAN.

BTW, in modern times, using multiple bridges on single ROS device most probably means wrong setup, one should be able to get away with using single bridge ... if several subnets need to be separated, then one can use VLANs ... even if sole purpose is to "segment" bridge into several isolated parts.

It is perfectly normal that advertise=yes is not possible for smaller networks than /64. This is not going to change either, it is part of the standard.
The "advertise" method simply means that the router tells to the local clients what the network range is and what the router address is, not an address for the client.
The client then picks a random address from the /64, checks if it is in use, and then starts using it. The router does not keep a list of assigned addresses.
So this is quite different from DHCP.

In DHCPv6 it would be possible to assign an address from a smaller subnet, but RouterOS does not support it and hardly any clients do either.
Your only recourse is to talk to your ISP and explain to them how unreasonable it is to give a client only one /64.
At the very least you should get a /60 for a home connection. Many providers give a /56 or more, here I get a /48 (which is a bit on the other end of the scale).

BTW, in modern times, using multiple bridges on single ROS device most probably means wrong setup, one should be able to get away with using single bridge ... if several subnets need to be separated, then one can use VLANs ... even if sole purpose is to "segment" bridge into several isolated parts.

That does not matter, the problem would be exactly the same. As soon as you have more than one internal network, be it on separate ports, separate VLANs, or separate bridges, you need more IPv6 address space than a /64.

That does not matter, the problem would be exactly the same.

Indeed. That's why the paragraph started with BTW hinting that it's not really related to paragraph before it.

But quite probably it matters when it comes to performance of intra-LAN communications. Both IPv4 and IPv6 ... because I assume OP needs bridges to bridge multiple physical ports belonging to same LAN and only single bridge can be HW offloaded ... even if it's a trivial one. If my assumption about why OP needs bridges is not correct, then there's additional disclaimer about it - I wrote "most probably means wrong setup".

Well, I often use multiple bridges with only a single port each - I configure a bridge with some "application" e.g. internet connection, then put a single port in that where the internet is connected.
I do that because it makes it easy to configure all higher-level config on that bridge and then attach one port to it which can later be changed, e.g. from ether to sfp.
It is also convenient when you get another router that has different optimal port usage.

I never experienced performance issues. But of course a bridge with a single port already is more efficient ("fast forward").

1. You are supposed to use only a single bridge for all your non-upstream ports and interfaces – You then separate them using VLAN filtering as you need
Source: https://help.mikrotik.com/docs/display/ ... plebridges

I do not know why people think they know MikroTik software/hardware better than the official MikroTik docs. Even in vanilla Linux networking, DSA was created to make the job easier by using a single bridge and then apply VLAN filtering as needed. Never understood the strange love for multiple bridges:
https://www.kernel.org/doc/Documentatio ... sa/dsa.txt

2. SLAAC is a standard by definition that requires a minimum /64 per VLAN. This is the same on all operating systems including Cisco and Juniper.

3. This is why we have BCOP 690. Your ISP for home users, is supposed to give you a /56 (a persistent one at that to avoid breaking SLAAC- https://www.6connect.com/blog/is-your-i ... pe-router/).

The only hack you can do here is to use the 200::/7 block (because ULAs don't work well with end-hosts in dual stack). Take 200::/7, slice it into a /56, then use a /64 per VLAN.

Now, configure NAT66 on MikroTik using netmap. Where on src nat chain, you have your /56 that netmaps to the ISP /64, and on dst nat chain, you have your ISP /64 that netmaps to your /56. This will more or less, give you 1:1 mapping, but it won't be perfect as the /56 is larger than the /64. If you have two VLANs, and you're using two /64s, you can replace the /56 with a /63 to help improve the mapping.

The real solution here is to demand your ISP to deploy BCOP 690 compliant IPv6:
https://www.ripe.net/publications/docs/ ... -customers

Thanks all. I managed to get /56 from ISP and now all is good.
I'll look into a single bridge with VLAN some day.

1. You are supposed to use only a single bridge for all your non-upstream ports and interfaces – You then separate them using VLAN filtering as you need
Source: https://help.mikrotik.com/docs/display/ ... plebridges

That would make things more complicated. Over here we normally get internet connections as "PPPoE over VLAN6" on the fiber or VDSL demarcation.
So when you have two internet connections you want to balance/failover, you will have to separate VLAN6 connections each running PPPoE.
That is why I make two bridges, each containing a VLAN6 subinterface of e.g. ether1 and ether2, and then name them "internet1" and "internet2" and run PPPoE on them.

It may be possible to do that in a single bridge but it would require VLAN-in-VLAN or VLAN renumbering in bridge filter rules. Too complicated for me.

1. You are supposed to use only a single bridge for all your non-upstream ports and interfaces – You then separate them using VLAN filtering as you need
Source: https://help.mikrotik.com/docs/display/ ... plebridges

That would make things more complicated. Over here we normally get internet connections as "PPPoE over VLAN6" on the fiber or VDSL demarcation.
So when you have two internet connections you want to balance/failover, you will have to separate VLAN6 connections each running PPPoE.
That is why I make two bridges, each containing a VLAN6 subinterface of e.g. ether1 and ether2, and then name them "internet1" and "internet2" and run PPPoE on them.

It may be possible to do that in a single bridge but it would require VLAN-in-VLAN or VLAN renumbering in bridge filter rules. Too complicated for me.

“WAN” interfaces are *not* supposed to be in the bridge. You continue using them standalone as usual and can send tagged VLAN using L3 sub-interface VLAN if you want, or via the switch chip depending on the hardware model.

By default, a standalone port is isolated on layer 2, unless bridged, and once bridged, you use VLAN filtering.

So if ether 1 is ISP 1 and ether 2 is ISP 2, both are standalone L2 interfaces, not in any bridge. Only downstream or intra-as ports are members of the bridge, including LACP bonding slave interfaces if any.

Ideally you should let WAN VLAN tagging job to the ONT device or modem. Make it simple on the Tik box.

@pe1chl, I've had exactly this type of use for more than single bridge when I used "probably" when talking about multiple bridge as error. Even though your particular use case warrants use of multiple bridges, it's a niche use case. In most cases people use multiple bridges when they really should use only one, we've had such case when an user complained about low throughput/high CPU load on a CRS used as (fairly simple) switch. After some fuss (user did not provide full configuration export quite a while) it turned out there was another bridge (with single port) which got HW offloaded (instead of main bridge which could actually benefit of HW offload).

So I really do think that defending mostly non-optimal setup just because you have a legitimate use for it (and you properly master it because you have both knowledge and experience to do it right) is not benefitial to most (not so advanced) users. Actually some users may (wrongly) take your input as confirmation that their config is optimal. I'd be more than happy to stand back if OP explained his use case for multiple bridges as intentional (and sensible) ... but he didn't.
Note that I'm not as arrogant as @DarkNate defending single bridge concept (and I believe that WAN interfaces can be members of single bridge in certain use cases) ... but I believe that this concept is right concept in 99.9% of cases.

“WAN” interfaces are *not* supposed to be in the bridge. You continue using them standalone as usual and can send tagged VLAN using L3 sub-interface VLAN if you want, or via the switch chip depending on the hardware model.

By default, a standalone port is isolated on layer 2, unless bridged, and once bridged, you use VLAN filtering.

So if ether 1 is ISP 1 and ether 2 is ISP 2, both are standalone L2 interfaces, not in any bridge. Only downstream or intra-as ports are members of the bridge, including LACP bonding slave interfaces if any.

I explained the reason for putting the WAN interface in a bridge. It makes it easy to move it to another physical port, while keeping all the configuration.
While lots of configuration (e.g. firewall) can now be handled via an interface list, so there is no more need to put "ether1" in each firewall rule that refers to the WAN interface, it still is convenient to do it this way.

And as I write, having a separate bridge interface with only a single port has not noticably hurt the performance on CCR, RB4011 etc. Maybe I would be more careful when trying to extract the utmost from a RB2011 or similar age router.
Of course I make sure that the bridge that is used for local devices (which includes VLAN filtering and different VLANs e.g. for guest and IoT networks) is the one that is HW accelerated, and the bridge with the single port is not, but it has "fast forward".

I explained the reason for putting the WAN interface in a bridge. It makes it easy to move it to another physical port, while keeping all the configuration.
While lots of configuration (e.g. firewall) can now be handled via an interface list, so there is no more need to put "ether1" in each firewall rule that refers to the WAN interface, it still is convenient to do it this way.

And as I write, having a separate bridge interface with only a single port has not noticably hurt the performance on CCR, RB4011 etc. Maybe I would be more careful when trying to extract the utmost from a RB2011 or similar age router.
Of course I make sure that the bridge that is used for local devices (which includes VLAN filtering and different VLANs e.g. for guest and IoT networks) is the one that is HW accelerated, and the bridge with the single port is not, but it has "fast forward".

It appears you're just a home end user, where of course you're not going to see the performance issues. Try your genius multiple bridge idea on a production network pushing 100G or similar rates with the CCR2216 along with full tables.

Test my idea which is also officially explained on MikroTik (single bridge) and your genius idea to see which one has more performance with minimal CPU usage.

Try your genius multiple bridge idea on a production network pushing 100G or similar rates with the CCR2216 along with full tables.

One should either stick to default concept (which will work always, but might not use resources most efficiently) or one can go with other concepts (which are mostly applicable only to one class of hardware). What you're saying about CCR2216 is true for CC2216 because it features switch chip that can do L3 in hardware. Many other routers don't (whole CCR1xxx family, early CCR20xx as well), and those don't suffer much just because of inclusion of bridge code in already wholly SW/CPU ridden path. And for L3HW to work, all interfaces (including WAN) need to be on same bridge (because, again, only single bridge can offload things to HW, including L3).

I explained the reason for putting the WAN interface in a bridge. It makes it easy to move it to another physical port, while keeping all the configuration.
While lots of configuration (e.g. firewall) can now be handled via an interface list, so there is no more need to put "ether1" in each firewall rule that refers to the WAN interface, it still is convenient to do it this way.

And as I write, having a separate bridge interface with only a single port has not noticably hurt the performance on CCR, RB4011 etc. Maybe I would be more careful when trying to extract the utmost from a RB2011 or similar age router.
Of course I make sure that the bridge that is used for local devices (which includes VLAN filtering and different VLANs e.g. for guest and IoT networks) is the one that is HW accelerated, and the bridge with the single port is not, but it has "fast forward".

It appears you're just a home end user, where of course you're not going to see the performance issues. Try your genius multiple bridge idea on a production network pushing 100G or similar rates with the CCR2216 along with full tables.

Test my idea which is also officially explained on MikroTik (single bridge) and your genius idea to see which one has more performance with minimal CPU usage.

I am not a home user but I use only 1Gbit lines. And note that I am not trying to emulate a switch, I use a single port on a bridge. That already is an optimized situation that you probably are not familiar with.
I have tested the CPU usage before and after I migrated a CCR1009 to this config and there was no change. And because this device does not have a switch chip, there is nothing to be HW accelerated at all.

I know this is marked solved, but may I make an unpopular suggestion that would work.

NATv6 using the fc00::/7 network reserved for private networks. It's not quite the same as RFC1918, but it does give us some ipv6 space that is not going to be centrally registered, so possibility of collisions if low especially using a random generator. Adding a /64 to each local BRIDGE from this space, and NATing out would work.

The RFC
https://www.rfc-editor.org/rfc/pdfrfc/rfc4193.txt.pdf

A Generator
https://cd34.com/rfc4193/

By FAR not the best option, but should work. Am I being dumb or irresponsible with this space? For the record I am not doing this in production, but it works in labs.

I know this is marked solved, but may I make an unpopular suggestion that would work.

NATv6 using the fc00::/7 network reserved for private networks. It's not quite the same as RFC1918, but it does give us some ipv6 space that is not going to be centrally registered, so possibility of collisions if low especially using a random generator. Adding a /64 to each local BRIDGE from this space, and NATing out would work.

The RFC
https://www.rfc-editor.org/rfc/pdfrfc/rfc4193.txt.pdf

A Generator
https://cd34.com/rfc4193/

By FAR not the best option, but should work. Am I being dumb or irresponsible with this space? For the record I am not doing this in production, but it works in labs.

Code: Select all

/ipv6 firewall nat
add action=masquerade chain=srcnat comment=NatV6Rule out-interface-list=WAN src-address=fc00::/7

Why the hell would you use ULAs when it is useless in dual-stacked home networks?
https://www.ietf.org/archive/id/draft-i ... la-00.html

I am not a home user but I use only 1Gbit lines. And note that I am not trying to emulate a switch, I use a single port on a bridge. That already is an optimized situation that you probably are not familiar with.
I have tested the CPU usage before and after I migrated a CCR1009 to this config and there was no change. And because this device does not have a switch chip, there is nothing to be HW accelerated at all.

MikroTik made it clear years ago. Single bridge + VLAN segregation and disabling STP on per port basis is the best approach:
https://help.mikrotik.com/docs/display/ ... switchchip
"Sometimes it is possible to restructure a network topology to use VLANs, which is the proper way to isolate Layer2 networks."

Even if the underlying hardware doesn't have a switch chip like CCR1k series – The more bridges you add, the more work for the CPU for overhead. Multiple bridges with FastForward/FastPath will always be slower than single bridge with FastForward/FastPath.

Why the hell would you use ULAs when it is useless in dual-stacked home networks?
https://www.ietf.org/archive/id/draft-i ... la-00.html

Guess I won't! Thanks for the read. Good stuff. I really appreciate it.

• ULA per [RFC6724] is less preferred (the Precedence value is lower) than all legacy IPv4 (represented by ::ffff:0:0/96 in the aforementioned table).

• Because of the lower Precedence value of fc00::/7, if a host has legacy IPv4 enabled, it will use legacy IPv4 before using ULA.

• A dual-stacked client will source the traffic from the legacy IPv4 address, meaning it will require a corresponding legacy IPv4 destination address.

Time to look elsewhere for a solution then.

NATv6 using the fc00::/7 network reserved for private networks. It's not quite the same as RFC1918, but it does give us some ipv6 space that is not going to be centrally registered, so possibility of collisions if low especially using a random generator. Adding a /64 to each local BRIDGE from this space, and NATing out would work.

ULA is definitely not what you want to use. It has a number of issues. I was involved with the testing and writing of this draft and we found that ULA in dual stack just ends up being more problematic than it is worth.

https://datatracker.ietf.org/doc/html/d ... ops-ula-02

I'm not opposed to the use of NAT in IPv6 in specific circumstances (like routing an LTE/5G hotspot that only hands off a /64) but it should be the exception. Dual stack works well in home networks

I gratefully accept my flogging for the ULA suggestion. I was unaware of the issues.

i think the "single bridge" thing is very relevant mostly on new equipment which includes an integrated Switch like ccr2116/2216

i have the same habit of using a bridge for wan interface even when using only a single port as a useful tool to do some L2 trouble-shooting, if you dont enable vlan filtering on that bridge the CPU overhead is very hard to notice

i think that habit will have to disapear when using ccr2116/2216 in favor of single bridge because of integrated switch which affect all interfaces except mangement eth

I gratefully accept my flogging for the ULA suggestion. I was unaware of the issues.

No flogging needed. The creators of ULA weren't aware of it either until last year when we spent the better part of 6 months convincing them of the issues outlined in the draft on the IETF v6ops mailing list.

I gratefully accept my flogging for the ULA suggestion. I was unaware of the issues.

No flogging needed. The creators of ULA weren't aware of it either until last year when we spent the better part of 6 months convincing them of the issues outlined in the draft on the IETF v6ops mailing list.

Joining that mailing list. Thanks again!

No problem.

Another way to solve this is to just ask for an IPv6 block from the RIR. You can use it as common IPv6 space for internal use. A /40 is free from ARIN until 2026.

https://www.arin.net/resources/fees/fee_schedule/

It's a shame that LACNIC's prices are not so pleasant.

i think the "single bridge" thing is very relevant mostly on new equipment which includes an integrated Switch like ccr2116/2216

i have the same habit of using a bridge for wan interface even when using only a single port as a useful tool to do some L2 trouble-shooting, if you dont enable vlan filtering on that bridge the CPU overhead is very hard to notice

i think that habit will have to disapear when using ccr2116/2216 in favor of single bridge because of integrated switch which affect all interfaces except mangement eth

There's no other way to put this. Even if it's purely software/CPU. Multiple bridges will perform worse than a single bridge. Just how it is. I never understood who or where did the idea come from, that "Yay, let's use multiple bridges, sure this is the best and only way to do it right".

You can still add the mgmt port into the bridge, but segregate it with VLAN filtering. Or do not at all and leave it as a standalone interface. That's okay too.

When the difference in performance is not noticable (and in my case I did not notice it), it does not matter. Even when in a purist view it does.
For quite some time (when RouterOS still supported it) I have used configurations without any bridge at all, with VLAN configuration in the switch menu, and VLAN subinterfaces on the master-port. That was even more efficient than a VLAN filtering bridge, especially on older hardware like the 2011 and old 750s.
When this possibility went away, and we all had to use a bridge even when it wasn't really required, "nobody" complained about the loss in performance.
HW accel of VLAN filtered bridges is still only available on selected models, even though all models supported it through switch config.
But now, this loss in performance is suddenly a dealbreaker? I think not.

Multiple bridges will perform worse than a single bridge. Just how it is.

Conceptually you're probably right, but did you observe big difference? Personally I don't see how performance could differ much between setups where bridges are purely SW ... and where one setup has single VLAN-enabled bridge where the other setup has multiple "plain" bridges. After all, VLAN operations of bridge (tagging/untagging, VLAN filtering, etc.) do cost s few CPU cycles as well, possibly more than code selecting the right bridge.
@pe1chl OTOH ensured us that performance hit is negligible.

If, OTOH, you had HW offload in mind, then one has to consider what is offloaded to hardware ... for example, quite a few people are forgetting that L2HW offload doesn't help at all when router needs to perform L3 functions (e.g. routing between different VLANs on low-end devices), if such bridge can not really do L2 functions (e.g. because it's only got one port), it's only important to configure it such that ROS won't attempt to HW offload it. If done properly, things won't really work less optimally in the big picture.

I'll say again: there are use cases and device models, where common principles don't work out optimally. A good administrstor will recognise these occasions and by doing "out of the box" configuration use available resources much more optimally. Not every other administrator may appreciate the solution but that doesn't give them right to trash talk about those solutions.

When the difference in performance is not noticable (and in my case I did not notice it), it does not matter. Even when in a purist view it does.
For quite some time (when RouterOS still supported it) I have used configurations without any bridge at all, with VLAN configuration in the switch menu, and VLAN subinterfaces on the master-port. That was even more efficient than a VLAN filtering bridge, especially on older hardware like the 2011 and old 750s.
When this possibility went away, and we all had to use a bridge even when it wasn't really required, "nobody" complained about the loss in performance.
HW accel of VLAN filtered bridges is still only available on selected models, even though all models supported it through switch config.
But now, this loss in performance is suddenly a dealbreaker? I think not.

I'll say again: there are use cases and device models, where common principles don't work out optimally. A good administrstor will recognise these occasions and by doing "out of the box" configuration use available resources much more optimally. Not every other administrator may appreciate the solution but that doesn't give them right to trash talk about those solutions.

If you both bothered to read the official MikroTik docs here: https://help.mikrotik.com/docs/display/ ... +switching

For older hardware with a switch chip, specifically here:
https://help.mikrotik.com/docs/display/ ... switchchip

You'd see, there are different ways to do the “single bridge” configuration for different device models including the older hardware like 2011 etc without losing performance.

In short, there's no reason to avoid “single bridge” concept like COVID-19.

In short, there's no reason to avoid “single bridge” concept ...

I don't see where linked documents contradict what I (or @pe1chl) actually wrote.

If I could be sure google will never direct some unsuspecting user to this thread I'd stop arguing with you long ago. It's useless to write arguments to you because you're stubbornly sticking to some concepts in your head and don't accept MT reality which is "maximum flexibility" and admin is free to configure whatever fits. And only reason why others should speak against it is if person asking has some problem or if it's very obvious that concept used is a wrong one.

There's no other way to put this. Even if it's purely software/CPU. Multiple bridges will perform worse than a single bridge.

This assumes that maximum data plane performance is the only consideration when building a network. I think this is a case where "it depends" is very relevant.

The ability to abstract physical interface dependencies in config is something that shouldn't be overlooked. When throughput performance is not the key driver, there is value in making the config easier and more modular.

This assumes that maximum data plane performance is the only consideration when building a network. I think this is a case where "it depends" is very relevant.

The ability to abstract physical interface dependencies in config is something that shouldn't be overlooked. When throughput performance is not the key driver, there is value in making the config easier and more modular.

The ability to abstract would be ideal if it was not an additional CPU overhead (multiple bridges). Something like how JunOS does interface configuration seem better than “multiple bridges” – where the latter (based on official MikroTik docs) either disables hardware offloading at the most or is just additional CPU overhead to begin with and is generally advised against by MikroTik themselves:
https://help.mikrotik.com/docs/display/ ... plebridges

"Instead of creating multiple bridges, create one and segregate L2 networks with VLAN filtering."

Unless, someone here who defends “multiple bridges” can elaborate on why it is harmless with some actual in-depth Linux kernel stack discussion – Bridges are after all a virtual Linux interface. Perhaps, my understanding of the Linux kernel network stack with regard to this discussion is incorrect i.e. more virtual interfaces on top of the physical interfaces = more CPU overhead. Unless of course, the hardware supports multiple bridges hardware offloading, then my opinion no longer matters.

In short, abstraction that adds CPU overhead in my opinion should be avoided.

At this point, I'd be happy to hear some opinions from MikroTik staff themselves, where if they agree multiple bridges = harmless practice, this should be reflected in their official docs.

The ability to abstract would be ideal if it was not an additional CPU overhead (multiple bridges).

Come on, STOP IT! It doesn't matter when it is not noticable. When you do not want additional CPU overhead, you should not use a router that runs Linux.
All this is not even related to the topic "IPv6 - Multiple bridges with only /64 from ISP", you have been babbling OFFTOPIC all of the time!

you should not use a router that runs Linux.

Lol what? What do you think Cisco IOS, JunOS Evolved, and Nokia SR runs on? Windows? What matters is support for hardware offloading of whatever you need that for, in this case single/multiple bridge. Of which only one is supported.

You keep playing your broken record...

Unless, someone here who defends “multiple bridges” can elaborate on why it is harmless ...

Nobody in whole thread claimed that using multiple bridges is completely harmless. We're only arguing that sometimes the harm is much less than gain.

One question: how can you use custom MAC address per port if you use single bridge? (Yes, I know one can change MAC address on interface directly and skip using bridge, but let's say one needs some bridge functionality as well, e.g. bridge filters).

For the last time: sometimes one must use unorthodox setups (which might involve multiple bridges) that can not be mapped to glorified single-bridge layout. And none of your crusade will change that. I sincerely hope you can stop playing broken record ...

One question: how can you use custom MAC address per port if you use single bridge? (Yes, I know one can change MAC address on interface directly and skip using bridge, but let's say one needs some bridge functionality as well, e.g. bridge filters).

I did check this out before answering, and it is interesting, but since you're both experts. I recommend you go with your “more gain, less harm” solution called “multiple bridges”. Easy, peasy, right?

The creators of ULA weren't aware of it either until last year when we spent the better part of 6 months convincing them of the issues outlined in the draft on the IETF v6ops mailing list.

I think Google might need an IPArchitech talking to about ULA. I didn't see them mention dual stack, but looks like they treating it as an rfc1918 clone like I was.

https://cloud.google.com/blog/products/ ... ogle-cloud