v7.7 [stable] is released! - MikroTik (2025)

I don't agree. Stateful-ness has nothing to do with NAT, it's the other way around (it's not possible to perform sensible NAT without being aware of connection state). When it comes to NPTv6, it can indeed work as stateless ... but that doesn't prevent firewallv6 from work in stateful manner. And stateful firewall has quite a few advantages over stateless firewall (speed is obviously not one of them).

Stateful-ness doesn't need NAT. But NAT requires stateful-ness to work. NPTv6 isn't NAT, it is stateless, it doesn't need the conn_track module.

You should stop pretending to be a know-it-all expert and do some reading.

This document describes a stateless, transport-agnostic IPv6-to-IPv6 Network Prefix Translation (NPTv6) function that provides the address-independence benefit associated with IPv4-to-IPv4 NAT (NAPT44) and provides a 1:1 relationship between addresses in the "inside" and "outside" prefixes, preserving end-to-end reachability at the network layer.

See Also

Restaurant Jobs Jobs in New Zealand, Job Vacancies - Jan 2025 | SEEK

https://www.rfc-editor.org/rfc/rfc6296
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

The packet flow explanation doesn't differentiate between IPv4 and IPv6 (in some places it explicitly mixes them ... "IPv4 or IPv6"), doesn't explicitly mention netmap - it uses generic "DST NAT" and "SRC NAT" boxes and I assume netmap is covered (as a special case) with that functionality. And I assume NPTv6 is covered there as well.
If my assumptions are correct, then using NPTv6 (or netmap) doesn't change functioning of firewallv6, one only has to be carefull about which addresses are being used when packets are passing firewall (according to packet flow diagrams the "internal" addresses are seen by firewall).

But then my assumptions can be wrong. And I don't need NPTv6 (or netmap) so I'm not going to test it myself.

You are not entirely wrong about the stateful firewall, it has its place, and is useful for non-advanced users or engineers who lack the expertise to configure a stateless firewall that covers A to Z. I can filter out unsolicited traffic or in other words traffic that could for example try to SSH into the router or my hosts or whatever, using purely the stateless firewall by exploiting the various parameters supported in legacy iptables. But as I stated this is advanced and not everyone can do this, or should, because chances are, they may leave loopholes or break stuff on layer 3/4 (been there, done that).

But if an organisation or business or even a home user, wants true native IPv6 end-to-end principle restored, then they should make the efforts to learn advanced iptables and exploit everything there is in the prerouting chain to filter all the crap they want without harming the end-to-end principle and advantage of IPv6 therefore nearly zero performance loss compared to stateful firewall with severe performance loss when trying to route line-rate.

The packet flow diagram hasn't been updated in decades since the NetFilter project became “public” (mass adoption), which is unfortunately a problem for experts such as yourself that assume it is flawless. It does not differentiate between NAT66 and NPTv6 because both didn't even exist back then, when the original diagram went public. Unfortunately for non-experts like myself and other folks, this has been problematic in the field when we deal with experts that believe blindly the packet flow diagram is flawless, it is not. I recommend, you actually look at the Linux kernel source code, focus on the NPTv6 code and compare it to NAT66, they aren't remotely similar short of “translation”, but the mechanism varies between Earth and Mars. I could be wrong, the diagram could be wrong, but the source code does not lie. It is C programming, so easier to parse for non-programming folks like myself, C being procedural and all.

Now, hopefully someone in the Linux NetFilter project will eventually update both the docs and the diagram to reflect the new changes. Especially since everyone (except MikroTik and other vendors) is moving away from NetFilter for filtering (leaving packet assembly and dis-assembly/sk_buff etc still to NetFilter) to either XDP or entire kernel bypass using DPDK. A proper packet-flow diagram including these technologies to properly represent their flow in the process along with NPTv6 is more important now than ever to prevent misinformation from plaguing the networking industry.

The Wikipedia version of the diagram, is slightly more accurate as it does represent XDP, but does not cover the NPTv6 which is in “mangle” (after conn_track), but is supposed to stateless (can be proven by no_tracking in the raw table that it works). You need to realise it's all just hooks, the different “chains” can be hooked stateless_ly without conn_track under the hood. Performance wise, no_tracking doesn't guarantee performance-loss=zero if you use anything short of prerouting/raw table:

iptables has multiple pre-defined tables and base chains, all of which are registered even if you only need one of them. There have been reports of even unused base chains harming performance.

Source: https://wiki.nftables.org/wiki-nftables ... h_iptables

And hopefully, MikroTik migrates to nftables at the least and perhaps give us XDP support (ASIC offloaded or native mode) or DPDK, and we can all dump the stateful-ness bullshit (mostly but not entirely) and filter at the NIC level. ROSv7 took decades, we can expect this in Tik in about 60 years lol.