Bulk Port Allocation - LSN - Reduce Log

[fischerdouglas]

Feature suggestion
Bulk Allocation Port

I quickly looked in the Jool documentation and also in the Issues of that repository, and I didn't find any reference to the words "bulk" or "lsn", which made me think that this functionality I'm going to suggest has not yet been considered by the project maintainers.

The purpose of this suggestion is to increase the feasibility of implementing Jool as a tool used as P-LAT in 464XLAT scenarios.

I've been interacting with Jool recently, and I've been positively surprised.

However, I currently don't feel comfortable suggesting a set of "CPEs with C-LAT + Jool as PLAT" to replace the "Dual-Stack + CGNAT" scenario precisely because of the volume of logs that Jool generates.

Basically it generates a log entry for each connection that opens or closes, right?
This, in a ISP scenario of 10K, 20K, 50K customers ends up becoming unfeasible both to maintain the necessary disk volume and also to do any search for events up to 2 years ago.

Therefore, I decided to suggest the idea of ​​BulkPortAllocation, which is used by vendors and also by OpenSource projects.

If we were talking about CGNAT 44, if we compared the Predefined(AKA.: Fixed) method with the Bulk Port Allocation(AKA.: LSN) method, the great advantage of the BPA method over Fixed is that after doing the proper tuning the size of the steps of ports and the maximum number of allocation, it is possible to have a very small volume of logs, optimizing the use of public IPv4.
Furthermore, it avoids the problem that the fixed method imposes of "spending" public ports with IPs that are often not being used.

In a simple example, if instead of generating a LOG for each of the 256 new connections established by the same client, I generated only a log saying "these 256 ports are for this client" I would save 255 LOG entries.
(I ask for tolerance here, I know the example is very shallow).

I AM NOT A PROGRAMMER!
But I will try to make a very concise explanation of what the idea is in an environment where Jool would play the role of P-LAT with Bulk Port Allocation support:

A new connection request arrived from the IPv6 side->
Does this IPv6 already have a block of ports allocated to it?
_If yes: Is there a port available to do the translation?
_ _If yes: Do NAT 64
_ _If not: Go to TryAllocateNewBlock
_If not: Go to AllocateNewBlock

TryAllocateNewBlock
Has this IPv6 already exceeded the maximum amount of blocks that was configured?
_If yes: Is there a port available to do the translation?
_ _If yes: Reply with NAK, and generate log.
_ _If not: Go to AllocateNewBlock

AllocateNewBlock
Choose a block of available public IPv4 ports, whether random or sequential.
Allocate this block to this IPv6.
Generate Log of this allocation

There are also snippets of logic for:

• Generate block deallocation log.
• Generate log of "still allocated to the same client", almost like an interim-update.

There are also many other criteria in the configuration of this scenario, such as whether or not to synchronize the UDP and TCP port ranges to avoid making a log for each protocol...

Well... I make myself available, if it is in your interest, to try to collaborate as much as possible.

[hagodoy]

I believe it is an exciting feature to be discussed and implement.

We have seen that over time the concepts currently applied in CGNAT are migrating to translation tools.
This has already happened with MAP-T, with a predetermined allocation of a pool of ports.

The 464XLAT generates a slightly more significant amount of logs, and I believe that the discussion here is how to reduce these logs by studying the possibility of using the Bulk Allocation Port.

[ydahhrk]

This was started here, but was never finished. At this point, the branch is too old to merge.

I don't know. From what I can tell, this is not too hard to implement, but it's rather impractical at no budget. I guess I could try to code it in a few weekends, maybe around late November. Would you be able to pull off some relatively exhaustive testing?

[hagodoy]

At the University, I have installed Jool/464XLAT on the wireless network. With your guidance and help, I can use the scenario to do the tests. As soon as you can, contact me to test. Thanks

[ydahhrk]

WIP at the issue390 branch.

[hagodoy]

Hi, it's already an excellent start. I'm going to prepare for some tests.

I think randomizing ports is unnecessary and would increase the need for logs for identification.

With the addition of the blocks, it would be interesting if they were added automatically in the future defined by administrator, 512, 1024, or 2048, .... port range.

This would follow the deterministic model used today by CGNAT. The automatic allocation or deallocation (measurements of port usage) according to the demand of each client would follow another model called bulk port allocation (BPA) and is interesting to improve dynamics and save public IPs delivered. In this case, the allocation log is essential.

[ydahhrk]

With the addition of the blocks, it would be interesting if they were added automatically in the future defined by administrator, 512, 1024, or 2048, .... port range.

Just to clarify: You mean something like this?

jool p4block add 192.0.2.0/31:10000-10999 --block-size 250

Generates blocks

192.0.2.0:10000-10249
192.0.2.0:10250-10499
192.0.2.0:10500-10749
192.0.2.0:10750-10999
192.0.2.1:10000-10249
192.0.2.1:10250-10499
192.0.2.1:10500-10749
192.0.2.1:10750-10999

Or do you have something else in mind?

This would follow the deterministic model used today by CGNAT.

This is what confuses me. You seem to be thinking something different than what this thread is asking.

If you want to predefine each user's blocks, and not have them assigned automatically, you can already do it through mark. (And if you're willing to use the old iptables, you might be able to speed it up quite a bit.)

[hagodoy]

Yes, that's right, it follows the deterministic CGNAT model, your example is correct and well illustrated.

I may have expressed myself confusingly, sorry. Each user's IP blocks should be automatically distributed.

I believe we can run the tests now, thanks ;-)