Since MT won’t confirm or deny if they are working on it, I presume this won’t see the light and day I for one also hoping this will become reality because we have a lot of CPE (hapac2) will surely benefit from this but I’m slowly starting to accept that this won’t happen and started to lose hope 
I saw someone from Mikrotik, in another thread, saying that it was planned/in the works. Didn’t give a date or anything else, but…
It has been said to be in planning since mid to late 2021. But only “on the TODO list”.
It is not MikroTik related, other vendors treat IPv6 too as a gentleman’s fad. As I try to understand whats going on here, I digging deeper and deeper. It seems to me RouterOS using Linux kernel’s fastpath and flowtable functions with some specialized code to RouterOS. IIRC RouterOS7 is based on Linux kernel v5.6.3, with a lot of modification. The kernel itself is supporting fastpath and flowtable for IPv6 so I think the question is how hard to implement it in RouterOS and in current HW diversity and how much resources has MTik for this. Interesting thing is L3HW offload is already implemented for IPv6 unicast traffic however it is not enabled by default.
+1 for fasttrack on IPv6
Many ISP offers ipv6 with 1gb or more simetric speeds.
+1 for this. I got a Hex refresh and the lack of IPv6 fasttrack is apparent. This router should be able to handle a gigabit residential connection (without QoS).
+1 …
+1…
+1 what?
The time wasted adding “+1” posts on the user forum is completely useless and foolish.
Instead, write directly to support@mikrotik.com and complain there…
IMO forum should have separate section for feature request topics, topic created by @normis http://forum.mikrotik.com/t/feature-requests/41609/1 growed and it is hard to track what is requested or not, it is mix of feature requests and per request discution, better to have requests segmented into separate topics so that discussion can be per request like this topic. To avoid “+1”, “yes”, “I want this”… posts, poll must be mandatory for topics in feature request section and from poll result, depending how much is needed by community, MT can decide if feature will be considered for implementation and in which priority. When feature is implemented such topic can be marked as solved. I think this would be much clearer and easier to track.
Deeply wrong way of thinking:
Those who don’t need it… don’t waste time registering on the forum for vote no…
Of course the yes will always win because they will be the only ones who register to vote…
Be careful with these OBVIOUS things, think about them first…
Maybe it was not obvious, I proposed like that not to decide on ratio between yes/no, ofc. yes will win in most cases, but there is a count of votes which can replace these +1 posts, no will be is in most cases useless, not seeing much -1 vote posts on feature request topics, still MT can see number of yes votes and see how much is request is wanted by forum users…
I would like to clarify, however, to avoid misunderstandings,
that I am interested.
Regardless of the logical considerations that I make above.
+1 I would be interested too!
+1 please
New year new +1.
