Regarding CGNAT/LSN:
port allocation there is plenty of information online but here is a short and concise answer
https://networkengineering.stackexchange.com/questions/73876/cgnat-port-allocation
connections tracking is only performed when the client side initiates a connection (packet flow) ie there is no 1:1 mapping from the outside.
That “short and concise answer” doesn’t apply to current discussion.
My understanding of FullCone NAT is as follows, if there are any errors, I welcome correction:
We first assume the following environment data:
PC1 192.168.88.100
PC2 192.168.88.200
LAN 192.168.88.0/24
WAN IP 34.56.78.90
The destination to be visited is 1.2.3.4:2345
When a device PC1 in the LAN network visits the destination UDP://1.2.3.4:2345, then there will be a record in the NAT table
src-address = 192.168.88.100:2345
dst-address = 1.2.3.4:2345 / reply-dst-address: 34.56.78.90:12345
When a device PC2 in the LAN network visits the destination UDP://1.2.3.4:2345, then there will be a record in the NAT table
src-address = 192.168.88.200:2345
dst-address = 1.2.3.4:2345 / reply-dst-address: 34.56.78.90:23456
At this point, as the visited person 1.2.3.4:2345, you will see two requests respectively from 34.56.78.90:12345 and 34.56.78.90:23456 UDP requests.
If we want 1.2.3.4 to be able to return the data normally to 192.168.88.100:2345 and 192.168.88.200:2345,
then we need to add two dstnat mappings to 88.100 and 88.200, respectively.
The problem now is that 12345 and 23456, the two WAN ports bound to the NAT table, are random, that is, if the NAT table expires.
Then perhaps 10 minutes later, when the two PCs visit 1.2.3.4:2345, the NAT table will allocate two new ports, which can be any unused UDP.
We can solve this problem by recording every request from each device in the network and setting the corresponding port mapping.
Of course, someone says we can read the NAT table and then write the dstnat rule, congratulations on what you said, and I have implemented it.
But there will be a situation, you need to cycle this thing at a certain time, when you write the rules according to the known request,
the relevant data has returned to the port, but it has not reached PC1 / PC2 correctly and then failed on the APP on PC1 / PC2.
Similar problems are like the dns-to-address-list currently supported by RouterOS,
I have also written the script this way, by traversing the dns cache, and then reading the record and writing it to the relevant address-list according to the domain name you need.
That is, dns-to-address-list is implemented by the script, but you will find that many times
when the client visits the destination, the expected record has not been written to the address-list by the script.
It is still not possible to rely on the script alone when more and more devices in the system need fullcone NAT.
You need to make RouterOS internally support this feature.
Regarding security concerns, Fullcone NAT now comes with a device list feature, similar to a DMZ list. This means that only devices on the list will be subjected to Fullcone NAT. Of course, if there is malicious software on your computer, it will increase security risks. However, this is no different from the security risks of UPnP and is considered a disclaimer.
here is NAT types defined in STUN
Full-cone NAT
All requests from the same private IP address and port (for example, IP1:Port1) are mapped to the same public IP address and port (for example, IP:Port). In addition, any host on the Internet can communicate with the host on the intranet by sending packets to the mapped public IP address and port.
This is a relatively loose NAT policy. As long as the mapping between the private IP address and port and the public IP address and port is established, any host on the Internet can access the host on the intranet through the NAT device.
Restricted-cone NAT
All requests from the same private IP address and port (for example, IP1:Port1) are mapped to the same public IP address and port (for example, IP:Port). A host on the Internet can send packets to the host on the intranet only if the host on the intranet has previously sent a packet to the host on the Internet.
Port-restricted cone NAT
Port-restricted cone NAT is similar to restricted-cone NAT, but the restriction includes port numbers. That is, a host on the Internet (for example, IP2:Port2) can send packets to a host on the intranet only if the host on the intranet has previously sent a packet to the host on the Internet.
Symmetric NAT
All requests sent from the same private IP address and port to a specific destination IP address and port are mapped to the same IP address and port. If a host sends a packet with the same source IP address and port number to a different destination, a different NAT mapping is used. In addition, only a host on the Internet that receives a packet from a host on the intranet can send a packet back.
Unlike port-restricted cone NAT that maps all requests from the same private IP address and port to the same public IP address and port, regardless of their destinations, symmetric NAT maps requests with the same source IP address and port number but different destinations to different public IP addresses and ports.
The question I’ve asked above remains, aren’t the services/games that rely on “Full Cone NAT” meant to have some functionality to open random ports via UPnP or similar when needed instead of me butchering the NAT table opening ports that the app might not even need?
Considering that the said software/game is written in the last decade the devs responsible for networking should be aware that nobody has a public IP dedicated for the console or the said app, at home.
I might be wrong but I’m pretty sure “the said” developers didn’t deliberately construct a game that required full cone (or whatever definition you prefer) because this functionality was not available, at least not widespread or standard on consumer devices.
So you still persist that these kind of issues with old and poorly designed games are important for MT to solve and not the actual game developer?
In my opinion regarding Mikrotik there is absolutely no need for a new construction as this can already be solved using normal settings in RoS.
My English might be rusty but I wrote no such thing.
They didn’t probably think of “full cone nat” but some of them figured that all these consoles can talk freely over the internet with each other with no sweat, which is obviously wrong.
I didn’t point fingers to MT as they would be the ones to “fix” this. Point me where I’ve said that.
And IYHO you seem wrong to think that it’s an easy fix like ticking a box in RouterOS, even after all these walls of text written in this topic.
I’ve only asked if there is some UPnP-like protocol that consoles can use to take care of the port opening (and the current UPnP isn’t enough), if there is, a feature request for the said protocol should be made.
So far we only got a mention of “PCP”, RFC6887.
What do you mean? Are you talking about the implementation on some other NAT router here?
(where the manufacturer realized that this is a big hole and probably not a good idea to enable for e.g. a TV or other IoT device)
Assuming the pretty pictures above are accurate…
Q remains…can RoS accomplish same?
To be perfectly clear, yes. You can accomplish the exact same thing using Ros but with even greater precision.
I’ve discussed this “issue” with my son who is a true gamer (maniac) since the age of 5 and is now studying computer science in his 5th year. He has literally had all available game consoles and has set up his own servers for Minecraft, Valheim, Terraria, Space Engineers, etc.
I’ve helped him over the years at home with most network issues and at most we’ve had to open a few ports in/out but never been forced into any kind of fully open 1:1 NAT (full cone) so there’s no indication that this would be a widespread problem.
However instead of hypothetical speculations, I’d suggest that we try to compile a list of examples with games where the game developer or other related source clearly states that “full cone” NAT is required for it to work.
OT:
Nowadays, he has his own Asus (Merlin fw) with a dedicated public ip that he takes care of all by himself so the rest of us in the family avoids any network disturbances. 
I think you can’t:
For the record, I don’t need it personally, but if it wouldn’t be too difficult to add (e.g. if the linked existing netfilter module is in good shape), then why not, it would be another tool that would make someone happy.
Sorry, but I beg to differ.
Regarding your first point it all depends on the implementation but in general you have never been dependent on a DMZ-like (1:1) configuration but sometime for a port range. So yes, this can be accomplished using RoS 1:1 mappings for a port range. The rest of the following points, they might be valid for a dedicated consumer device.
As for the last sentens, I really don’t agree, in any case as long as there are unresolved problems with the core functionality of Ros, this should be cleared up before embarking on similar extensions.
And as I said in my previous post I still believe this is a non-existent problem. Thus again, instead of hypothetical speculations bring me facts this is actually a widespread problem for gaming. However, the only thing I would agree with is implementing this feature for purely marketing purposes targeting the consumer market.
If you mean forwarding port ranges to different devices, it wouldn’t really work, would it? Not without some configuration on those devices that would force them to use these ports as source. If I’m dstnatting e.g. 1000-1999 to device A and 2000-2999 to device B, then if device A uses e.g 1500 as source and router keeps it, it will be fine. But if device A uses some random 36313, then I can still srcnat it into 1000-1999 range, but I won’t have dstnat from 1xxx to internal 36313. With this thing, it would just work for any device without any extra config on it.
And sure, there are more important things, but it doesn’t mean that there can’t be other ideas in queue. Also, what’s wrong with consumer market? MikroTik is clearly interested in it. There might be more customers who would appreciate this than those who need BGP (don’t take it too seriously 
).
Well, you have the same basic problem with “full-cone” nat as requests from the same internal ip/port are mapped to the same external ip/port so there are no automatic overlapping that separates two devices using the same port range. Nowadays many also suffer from CGNAT (ie double nat) which becomes a natural limitation and makes this feature less important.
To be honest I don’t really care what MT decide as I’m not dependent on it all but if they really want to enter the consumer market they’ve a pretty tough challenge ahead of them.
On the other hand, there is a huge pile of money in the gambling industry for those who succeed. Gamers spend ridiculous amounts of money on everything related to gaming, my son is a good example of that (well not really )
However for the existing customer base I really hope for their sake MT makes a serious effort to shape up v7 and make it fit for production.
No, this, as I understand it, solves it. Imagine some udp-based game or another system with p2p communication. If it was ideal NAT-less internet:
But if there’s NAT, it’s not longer possible. But this would make it work again:
It’s as if the NAT disappeared. Neat, isn’t it? Too bad I don’t have any use for it myself, I’m starting to like it.
That looks more like some kind of variation of full-cone and symmetric nat. Check RFC 3489 (5. NAT Variations), the external/public port is always mapped to the same internal port number and is why it’s sometimes called Static or 1-to-1 (1:1) NAT.
I think Cisco and probably many of the other carrier grade cgnat vendors have some pretty good white papers that describe the different variants in great detail.
Well, the definition by itself is not completely clear. For full cone it says that “all requests from the same internal IP address and port are mapped to the same external IP address and port”, but that’s not necessarily same internal and external port number. So i.i.i.i:1234 always mapped to e.e.e.e:4321 should be fine. It’s sort of subset of NAT 1:1 (which allows also incoming connections without previous outgoing one). The key difference from current srcnat/masquerade (except NAT 1:1) is that it allows new incoming connections from anywhere (any unrelated address) and they can reach internal host.
It certainly might be as it all depends on the implementation currently in use or as the wiki states: many NAT implementations combine these types, so it is better to refer to specific individual NAT behavior instead of using the Cone/Symmetric terminology.
Thus in this particular case someone should start looking for a reference implementation that possible might fit the purpose. I had a quick look and there are a bunch of open source modules for nftables/netfilter. However I persists and still claim this is a non-existent problem for the modern gaming industry todays, nor for MT owners using Ros.
As for the other suspects, well show me the real problem! ;- )
On the PS5, there are four types of NAT: NAT1, NAT2, NAT3, and NAT4. If there are other NAT types, I may not have encountered them on the PS5, and I welcome any corrections.
NAT1: Full Cone NAT (One-to-One)
NAT2: Restricted Cone NAT (Address Restricted Cone)
NAT3: Port Restricted Cone NAT
NAT4: Symmetric NAT
Generally, the lower the number, the more open the NAT is, and the higher the number, the more restricted it is.
To illustrate, let me use the game “Monster Hunter,” which I play on a daily basis, as an example. The game has different versions, such as “World,” “Rise,” and “Sunbreak.” In the game, there is a place called the Gathering Hall, where players can voice chat and undertake missions.
If you have NAT1, then you will have no problem with voice chat. However, if you have NAT2/3/4, and you want to speak with others, there must be at least one person in the Gathering Hall who has NAT1. If everyone has NAT2/3/4, you may see an indication that someone is speaking, but everyone will hear white noise or nothing at all.
Another thing to consider is the online gaming experience. If several players have a NAT type other than NAT1, it is best to have the NAT1 player create the room, as other players may have a higher chance of experiencing disconnections. However, if all players have NAT1, the online experience is smoother and more enjoyable.
These games typically use P2P (peer-to-peer) connectivity, where a large amount of game data is transmitted between players instead of going through a game server.
If I have made any mistakes, please feel free to correct me.