Ok, you’re right:
/ipv6/firewall/nat/add chain=srcnat src-address=fd01::/64 action=netmap to-address=2001:db8::/64
failure: dstnat/redirect/netmap action must be in dstnat/output chains
But it means that from the two netmaps possible for IPv4 (source/destination), they added only the destination type for IPv6. It looks like mistake or bug.
Actually, this restriction is correct. As the NETMAP changes SRC addresses - the placement chain is correct. it should be placed in DSTNAT chain because these changes should be done in PREROUTING chain-set. The problem is that the IPv6 netmap doesn’t perform prefix translation at all. Functionally it works similarly to DSTNAT. It is the problem and it is what requires an explanation from DEVs. Obliously, the IPv6 implementation of NETMAP works in different way than IPv4 NETMAP and there is nothing about that at all in the ROS7 documentation. It isn’t clear why and it isn’t clear what the IPv6 NETMAP does at all. There are two other actions (as I mentioned earlier): SNPT/DNPT - they works (conditionally) well. There is another oddity with these two actions but it is out off-topic here. But they work. But the IPv6 NETMAP does something senseless at all.
It’s possible that I may have missed something, because I didn’t play much with IPv6 NAT yet. But I don’t see any reason why IPv6 netmap should be fundamentally different from IPv4 netmap. And since Linux is happy to accept these:
ip6tables -t nat -A POSTROUTING -s fd01::/64 -j NETMAP --to 2001:db8::/64
ip6tables -t nat -A PREROUTING -d 2001:db8::/64 -j NETMAP --to fd01::/64
Which is the same way as I’d do it with IPv4, then for now I’m going to stick with my theory that MikroTik simply added only half of netmap by mistake.
Yes, I noticed this before and came to the same conclusion. Also, the action src-nat is not available in the srcnat chain for some reason, only masquerade. I haven’t checked on a Linux box but I assume this option is available in ip6tables.
The problem with the IPv6 NETMAP isn’t a big problem. The problem is that the DEVs keep silent. It isn’t a big deal to post an update like “Folks, don’t rush with the IPv6 NETMAP - it is implemented buggy”. Just 1 minute to post such update which could explain the things and avoid all these theories… But there is just that what is there.
Nevermind. I implemented this functionality in another way.
Do you really think that “DEVs” should be held accountable for all possible problems and can be summoned by you to explain their behavior here?
I believe DEVs are responsible for buggy features in “stable” releases. In alphas, betas, dev- and test- releases they can do everything they wish - no any complaints about that. But the “stable” means the stable. It is a well-documented and well-tested release. Frankly speaking, they are obvious things. As the question is related to ROS7.1.1 which is declared as the STABLE release - yes, they should explain all unclear and odd things they released as “stable”.
Also, I believe DEVs are responsible for useful documentation that can be used to find all product-related details including implemented IPv6 NETMAP. Also, I believe it must be done with no summon from users.
I advise you to buy equipment from a manufacturer that charges 5 times as much and then forces you to have a “support contract” to report any issues and download new firmware.
You will get a very warm feeling scolding them when problems occur, and you can tell others that you have chosen the brand that treats you as a king.
Awful… What are you telling??? Is it actually possible at all?
It’s just a joke. I’m not an amateur and not a newbie neither in software nor in networks. Even “enterprise-grade” contracts don’t scare me. Thank you for the advice. I appreciate it a lot. But it has nothing to do with this topic and the issue under consideration. Fortunately, I’m able to decide on my own what to do and what to buy without your advices 
Does anyone have a working example of nptv6 netmap? or even nat66? I am trying to translate a ::/56 ULA to ::/56 public prefix.
ipv6 netmap through prefix translation isn’t implemented until kernel 5.8 so curious how Mikrotik has it working; I believe ROS is still 5.6
Quick test with latest 7.3beta37 says that netmap in srcnat chain still isn’t accepted (see few posts back). As for snpt/dnpt, it’s either broken too, or I’m doing something wrong (no idea what). If I have this:
/ipv6 firewall mangle
add chain=postrouting action=snpt src-address=fd00:1234:5678:9a00::/56 src-prefix=fd00:1234:5678:9a00::/56 dst-prefix=publ:icpr:efix:b700::/56
add chain=prerouting action=dnpt dst-address=publ:icpr:efix:b700::/56 src-prefix=publ:icpr:efix:b700::/56 dst-prefix=fd00:1234:5678:9a00::/56
Then ping from fd00:1234:5678:9a01::183 to internet works, but translation seems weird, because the source gets changed to publ:icpr:efix:b701:1905::183 (I’d expect publ:icpr:efix:b701::183). Response going back to that is correctly translated to fd00:1234:5678:9a01::183. But other incoming traffic is broken, because publ:icpr:efix:b701::183 gets changed to fd00:1234:5678:9a01:e6fa::183.
Update, it looks like snpt/dnpt probably works correctly. But as user expectations go, it’s a mess. Problem is that it’s supposed to be as simple as possible, which doesn’t sound bad, but it brings some limitations. If it’s stateless and only rewrites addresses, it at the same time breaks checksums. So it needs to correct them, and that can be done by changing also some other bits in addresses:
https://datatracker.ietf.org/doc/html/rfc6296#section-2.6
It’s not too bad if you get /48, because then it changes only 16 bits between 48 and 64, which means that you don’t have complete control over them (e.g. mapping internal i:i:i:0001:: to external e:e:e:0001:: is not possible, external will be computed automatically based on internal and will be different), but at least it doesn’t touch rightmost 64 bits, so this part of address stays the same (i:i:i:0001::1234 will be e:e:e:xxxx::1234).
But if you get longer prefix (/56, /60, …) it has to use also rightmost 64 bits. Which works, but doesn’t seem user friendly at all, because internal and external address won’t be just different, but completely different. You can’t just swap prefix and know what the new address will be (that’s the same with /48 too, but here it’s even worse).
Well I would prefer changing a part of the local address (e.g. the middle 16 bits that are FFFE when a static address is used) over changing the network address.
I have /48 at work but I would want to use that function to map external addresses to a constant local network address so load-balancing and failover can be done with 2 ISPs similar to IPv4, but of course we have several internal networks so we cannot burn all 65536 network prefixes on a single local network.
I probably like netmap more (in case I’d need any kind of translation). It’s not stateless, so it’s in a way worse. But if I’m going to use stateful firewall anyway (so the heavy part with connection tracking will still need to happen), I don’t see it as problem.