Hi, does anyone know if there is a plan to implement the "action=mark-routing" and "new-connection-mark=<routing mark> in IPv6, firewall, mangle rules.

Our IP services are served by multiple links so we round robin packets up the links to the ISP who provide us with native IPv6 addresses. It's just a bit of a shame that I cannot implement IPv6 at the moment without foregoing the resilience provided by our multiple links as I cannot get the traffic balanced without using routing marks. I'm not sure if the routing marks are not in there as there is an alternative way of doing this in IPv6 or if it had been missed/is in progress.

If I implement IPv6 for our networks and then users become used to it all working fine but without resilience then if and when a link fails I'll be left with them all moaning at me, I'd prefer just to do it once I can make it resilient and mark the routes.

Any help or advice would be greatly appreciated.

Thanks, Dominic.

any news .... this is a really important feature that gives us increased bandwidth and resilience over our ADSL circuits, was it just missed from the IPv6 implementation, is it removed for good reason or is it planned to be done in the future.

Hi, im looking for the same solution. Any idea how can i do this?

no real way to achieve this without this functionality. I'm going to use an L2TP tunnel over my IPv4 bonded link to tunnel my IPv6 in for the time being until this can be sorted.

It's a shame, was hoping to be live for World IPv6 day today but alas, no joy.

Dominic.

Bad news at IPv6 Launch date.

I had to figure out how can i make IPV6 DUAL WAN Mikrotik router.

I actually per packet round robin my IPv4 traffic up my three ADSL lines to Andrew and Arnold, equally they per packet round robin the data down to me in the same way. To achieve this I have to use mangle to mark each packet per block of 3 with router1, route2 and route3 then the routing table picks up the right packet and sends it up the correct line.

I think if you just wanted to do per connection balancing it will support that by just specifying two gateways in the routing configuration for IPv6 but I've never tested this.

Cheers, Dominic.

Hmm.. i had to figure it out by Mikrotik Metarouter for the second IPV6 connection. Not so clean solution, but it do what i need.

bump.
I'm also having issues with the lack of ipv6 routing mark. any ideas please?

Hi gr0mit,

When I trialled this I setup an L2TP tunnel to A&A over IPv4 so the tunnel IPv4 traffic was marked and thus round robin balanced up multiple lines then I routed my IPv6 traffic through this L2TP tunnel hence by the nature of going through the tunnel operated the same way and was load balanced. Obviously there is some overhead for the tunnel etc.

It's all such a shame given A&A support IPv6 so effectively and we're all scratching around trying to find a way to make RouterOS do something it's always done. Anyone with resilience/bonded lines on IPv4 using this method basically has to accept they cannot move to native IPv6 without a load of hassle.

So when are Mikrotik going to realise that IPv6 is not just an awkward bolt-on, but a wholesale replacement for IPv4? Coz I can't mass deploy IPv6 on Mikrotik routers at the moment....

bump, same problem, bit rubbish!

I asked about route marking for IPv6 over 2 years ago and still no sign of it. http://forum.mikrotik.com/viewtopic.php ... 40#p225402 Fobbed off then and still being fobbed off now.

I can't move any of our clients that are currently using bonded ADSL lines over to IPv6 for this very reason, the lack of routing marks on IPv6 Plus, time is running out.

Yeah, it's such a shame that something this important has been missed from IPv6 with no real acceptance or indication by Mikrotik of this being any sort of problem or issue they plan to address. Ignorance doesn't make problems go away, it just annoys people. They should indicate their plans and why they are not addressing this as an urgent issue.

1. We're not going to do it - we can buy something else or accept IPv6 isn't an option for us.
2. We're going to do it by X we can buy something else or choose to wait for X
3. Keep quiet and hope that this IPv6 thing is simply a fad which before too long will stop being so talked about and the problem might just go away ... is this even an option, it's certainly something that will reduce the customer base if nothing else.

IPv6 policy routing requires rework of the routing so it will be possible to add this feature only after new routing comes out.

Your reply is gratefully received, this topic commenced in March 2012 and I think there are some earlier posts on the topic as well. There are obviously a lot of frustrated users left wondering how/what they were going to do to implement IPv6 but this now gives some clarity.

Are you stating that the IPv6 implementation of the new routing does have routing marks included in it from the outset?

IPv6 policy routing requires rework of the routing so it will be possible to add this feature only after new routing comes out.

Yes but this "new routing" was promised for RouterOS version 6 and yet IPv6 policy routing
is not in the release candidate.

What is the timescale for "new routing" ?

Nick.

This is very needed feature! Is there any time scale on this?

This feature is a must

Yes Please! Not even in the 6RCx

Look what I found in RouterOS v6.1.

ros code

ipv6 firewall mangle add new-routing-mark=

Don't tell to anyone . it seems mikrotik does not like to introduce it's features

Look what I found in RouterOS v6.1.

ros code

ipv6 firewall mangle add new-routing-mark=

I can see there is the ability to add routing mark, however there is no "action" to "mark-routing" so that it is used.

In addition there is no option for "routing-mark" under "ipv6 route add"

I'm using v6.12, am I missing something?

I just ran into this today. I have multiple IPv6 tunnels that provide different networks, so I need to be about to route out the correct tunnel based on the source address. Running 6.18 and this action still doesn't exist under ipv6 firewall mangle. (Mostly posting a "me too" so I get emails in case this ever gets solved). Too bad, I was hoping that my move to RouterOS from dd-wrt would give me this functionality.

I asked about route marking for IPv6 over 2 years ago and still no sign of it. http://forum.mikrotik.com/viewtopic.php ... 40#p225402 Fobbed off then and still being fobbed off now.

4 years on... Would Mikrotik like to make a comment on the time scale now for this implementation?

The silence is deafening!

Yep, me again...
...any sign of this making it into v6.xx or is now on hold till v7 or 8 or 9?

it's already a difficult push for people to move to IPv6, however, it's going to be impossible if the IPv6 facilities are not at the very most basic level equivalent to the IPv4 facilities, you would assume addressing this issue would be one of the most important things facing Mikrotik at the moment?

Just to add a 'me too', we've managed to avoid needing this for a while, but now we do. I'd be grateful if MT could provide the merest hint of a timescale. Please? Pretty please? Pretty please with sugar on?

v6.30.2 - still no routing-marks support

Surely this will move things along:

http://www.internetsociety.org/deploy36 ... os-9-apps/

I doubt it.

It has been said many times by various MT staff. Once they stop using the routing engine embedded in the Linux kernel and rewrite all their own routing code, they can then add the code to support IPV6 Routing marks. Yes, we were first promised it was coming in v6. Now we're being told v7. Like all companies, they have constantly shifting priorities which are led from a number of external and internal factors. So it will be released when they're ready and they believe it's stable (ish!).

Sadly however it's not just the lack of routing mark functionality that is stopping us using IPV6 in our WISP. There is also missing support with the PPPoE Server and Radius which means we can only provide a IPV4 address to the CPE. Until full IPV6 Radius Attribute functionality is working, we are stuck with using just IPV4 at the moment.

Oops.. missed the 5th anniversary of requesting this option/feature.

Still no real indication of when this will happen and yet it was said to be included in the re-written route engine. Maybe developer resources need to be channelled towards this goal instead prolonging the arrival of this fabled version by over pimping old code base?

One year ago I requested:

I'd be grateful if MT could provide the merest hint of a timescale.

and still no sight or sound of what is fast becoming a deal-breaker for MT kit. We're now in the process of quoting for a rollout which must include IPv6 and are going to have to heavily caveat our proposal...

Happy 6th anniversary

Any news about that ???

Any news about that ???

I don't think you'd appreciate a repeat of the standard reply. Something about v7?

Not very much support on this forum indeed...

I just found out I can't do this,

I have had a lot of this recently. It's a shame, I've been a fan of Mikrotik for a while, but I might just have to move back to what I did before: building my own linux-based routers.

7th anniversary is fast approaching (3rd September)!

Well, FWIW, the OP's concern really wouldn't be fixing what he thinks it's fixing by having policy-based routing on IPv6 because it would on;y handle the egress forwarding - i.e. he can load balance the outbound traffic all day long, but his ISP is the one responsible for load-balancing the return traffic. In fact, if the ISP will do that for inbound, and you're like most ISPs where inbound is like 6x the outbound anyway, the chances are that a simple floating static backup route would take care of everything the OP wanted to do.

For those not understanding why - it's because ROS can't do NAT on IPv6 so simply forwarding packets out one connection won't cause the replies to come back in the same interface.

That doesn't mean that PBR isn't a very useful tool that should be implemented anyway despite the lack of NAT. . . .

OP wanted uplink Round Robin packet balancing. I can not see where NAT was ever mentioned. The concept of what the OP was to utiise all available bandwidth by (if need be) a single data stream and not ECMP. OP stated they had native IPv6.
I am aware of the method the OP is reqesting as i constructed the original IPv4 config for said ISP and it was based on PBR.

OP wanted uplink Round Robin packet balancing.

Yes, but my impression was that the goal was to balance the inbound traffic. The only way that would happen based on outbound load balancing is if the src address is natted to the egress interface. The other concern was redundancy, which can be handled in straightforward ways w/o PBR.

The ISP handles the downlink aggregation, again using RR. As for fail over or redundancy, simple, what ever link is left carries the lot. I ran this method of link aggregation combining 4 ADSL circuits for over 4 years until VDSL came along. Again I did 2 aggregated VDSL circuits using this method with a successful 150mbit down link and 38mbits uplink . Both circuits rated at 80/20. No NAT required. I gather the ISP has updated the end user wiki to now include a NAT'd config but alas IPV6 will still not be possible using the PBR method without running through a 6to4

Hi guys, i had same issue - two ISP's, routing marks and ipv6 via 6in4 tunnel, so what i made - IP > Routes > Rules > added rule for dst. address=%hurracane electric 6in4 gateway%, action=lookup, table=%routing mark for corresponding ISP% and tunnel is start to work.
Hope it will be helpful =)

Hope it will be helpful =)

Indeed it is but not for the OT. You are only route marking IPv4 in this instance. IPv6 route marking is still not available.

Still nothing? Same with v6 NAT. transparent proxy and IPS/IDS implementation depend on this.
Iptables has that feature for a long time, i don't understand why exactly ROS7 is necessary.

7th anniversary is fast approaching (3rd September)!

8th anniversary!
Meaning 8 BUMP BUMP BUMP BUMP BUMP BUMP BUMP BUMP - and one for luck - *BUMP*!

Having had IPv6 via a tunnel broker for a long time, I now have another ISP connection with native IPv6.

It would be *sooooo* helpful if I could policy-route packets with the old IPv6 source range down the tunnel, and packets with the new source range down the native connection. It would allow me to deploy the new addresses incrementally onto each server. Indeed, the servers could keep both old and new addresses and I'd have redundancy for inbound connections (with the tunnel bound to the old ISP connection).

The other issue is lack of fasttrack on IPv6. I can happily fill the new link on IPv4, but IPv6 maxes out the CPU

Happy 9th anniversary in 4 days time!

Waiting for this and L7 protocol support before I can roll out v6.

Any news on this? Is it going to be at least at RouterOS v7?

Already supported in v7 beta

oops.. I missed the 10th anniversary :-D

Does anyone know if this feature is coming soon?

Yes

So we have to upgrade to v7 BETA to get PBR working on IPv6?

Is it save to run v7 BETA on a provider network yet?

So we have to upgrade to v7 BETA to get PBR working on IPv6?

Is it save to run v7 BETA on a provider network yet?

ROFL

input does not match any value of new-routing-mark

is this still not working in 7.1rc4, or am I doing something wrong?

Happy 11th anniversary

Looking at the v7 Routing Protocol Status Page, it should already work, but how? or is this only the input matcher? routing-mark=abc action=xyz.
But even this doesn't make sense, because when we can't add routing-marks how should we match on them..
Edit: Answer from support: "Bug will be fixed in one of the next versions."