I've very recently discovered RFC7422 that deals with deterministic NAT.

I'm thinking of using RFC7422 to reduce logging requirements when serving 500 devices through a single (or double) Internet connection (FTTH).
The way I see this is:
"Whenever IP 192.168.0.17 from 192.168.0.0/23 network is NAPTed, it should be given a port within 11700-11799 range so that, if ten weeks
later I need to trace whoever did communicate through public IP and port 11749, I'm certain it cames from 192.168.0.17."


1. Is the above understanding correct or did I miss something ?

2. How many ports should you allocate to an "end user" to let him comfortably access to "usual Internet services" (emailing, web surfing, ...) ?
Is allocating 100 ports, starting from port 10000, a good practise for 500 users, max ?
And what if you have 5000 users ?

3. Is it correct than implementing RFC7422 on Linux and derivates, means adding many lines such as see [1]:
/ip firewall nat add chain="xxx-$($i / $x)" action=src-nat protocol=tcp src-address=($srcStart + $i) \
to-address=$toAddr to-ports=$prange

4. How does it scale with Mikrotik hardware if you need Gigabit throughput ?

[1] viewtopic.php?f=2&t=126232&p=723081&hilit=7422#p723081

Best regards

1. Is the above understanding correct or did I miss something ?

Correct.

2. How many ports should you allocate to an "end user" to let him comfortably access to "usual Internet services" (emailing, web surfing, ...) ?
Is allocating 100 ports, starting from port 10000, a good practise for 500 users, max ?

It depends on the type of users and their typical activity and the applications they use. After a TCP session is terminated peacefully, the client-side port must not be reused for another TCP connection to the same server side IP and port for 2m30s. Many application programmers do not have a clue about such kind of traps in networking, so some applications close TCP sessions after every request-response exchange, some do it properly and reuse TCP sessions, i.e. close them only after a certain timeout (of minutes) after the last request has been sent. So for just web browsing, it may be fine, for some specialized client-server applications, it may create hard to find issues.

And what if you have 5000 users ?

Deterministic NAT is a poor man's workaround for small networks where you cannot log connection initiation events on an external storage. So for 5000 users sharing a single public IP it is unusable. It is also unusable (at least alone) if you have dynamic access (like a complimentary WiFi for random customers in a store).

3. Is it correct than implementing RFC7422 on Linux and derivates, means adding many lines such as see [1]:
/ip firewall nat add chain="xxx-$($i / $x)" action=src-nat protocol=tcp src-address=($srcStart + $i) \
to-address=$toAddr to-ports=$prange

Correct. There is no embedded functionality where you would set the number ports allocated to each internal address and let the magic of RouterOS do the rest for you. You can use scripting as in the example to generate those individual rules, like in the example, but you cannot have a single rule evaluating an arithmetic formula to calculate the new source port from the original source IP address on the fly.

4. How does it scale with Mikrotik hardware if you need Gigabit throughput ?

When NAT is used, what causes the load is that every single packet needs to be matched to the list of existing connections, and modified before getting forwarded if NAT handling is required for that particular connection. The first packet of each (potential) connection is typically seen by much more firewall rules than the mid-connection packets, but the difference between having a single NAT rule and 500 NAT rules will be negligible unless all the clients' connections consist of just a few packets. 5000 rules may be a different thing, so you'd need to build some kind of a binary tree to reduce a number of packets traversed by any given packet. Say, you have a 192.168.0.0/19 (8190 addresses) for clients. Whilst with 8190 individual rules, an average initial packet of a connection will traverse 4095 of them until it gets matched; using the tree approach illustrated below, you can reduce that figure to about 1024 rules per average packet. It is just an example, for smaller source subnets networks the reduction ratio may not be worth the effort spent to create the configuration.

Thank you very much for you very informative answer

And what if you have 5000 users ?

Deterministic NAT is a poor man's workaround for small networks where you cannot log connection initiation events on an external storage.

1. Alternatively, how can you log connection initiation events on an external storage with a Mikrotik router for a 5000 users setup ?

I've just found IPFIX section within 6.47's IP/Traffic Flow config page.
It contains a very long list of parameters, some of them being "NAT Src Port", "NAT Dst Port" so this looks promising.
Using this, can you restrict collected data to connection initiation events ?

2. From experience, would you then follow the "logging route" (no detailed NAT settings) or the RFC7422 one (per user NAT settings) for large networks ?

[2] viewtopic.php?t=53483

1. Alternatively, how can you log connection initiation events on an external storage with a Mikrotik router for a 5000 users setup ?

I'd set log=yes on the action=masquerade (or action=src-nat, depending on which one you's use) rule, and set a dedicated external syslog server in /system logging as a target for topics=firewall,info.

I've just found IPFIX section within 6.47's IP/Traffic Flow config page.
...
Using this, can you restrict collected data to connection initiation events ?

I've never tried, but it doesn't seem to be the case - after all, the original purpose of IPFIX is different.

2. From experience, would you then follow the "logging route" (no detailed NAT settings) or the RFC7422 one (per user NAT settings) for large networks ?

5000 users NATed to a single public IP are a nightmare even without deterministic NAT, for the reasons outlined above - you'll just run out of TCP ports on WAN side just a few minutes later.