@Mis1eader-dev thanks so much for this PR, would you please add some unit tests for this?

It's done, can we merge it?

There is one potential optimization that could be done for ipv6.
Currently ipv6 addresses are encoded into a string in its full form, meaning "::1" will get encoded as 16 bytes with toIpNetEndian(), compared to toIp()'s 3 bytes. Meaning the net endian version of toIp() is at a disadvantage in encoding ipv6 addresses that have too many zero bytes.
One way to improve this is to add an additional byte to both ipv4 and ipv6 that indicates the ip version, and for ipv6 to avoid conflicts with ipv4 addresses that have only 4 bytes.

Here is why this additional byte is necessary:
The ipv6 address "::0101:0101" must be encoded as std::string({ 1, 1, 1, 1 }), this would conflict with the ipv4 address "1.1.1.1", that also gets encoded as std::string({ 1, 1, 1, 1 }).
These conflicts can be avoided by appending one additional byte that indicates the ip version, std::string({ 6, 1, 1, 1, 1 }) and std::string({ 4, 1, 1, 1, 1 }), this still is more compact than toIp for a non-printable version of that function, but is not adhering to any standard as far as I am aware.

In my opinion it is worth making this change, this function must only be used in non-printable contexts only, such as rate limiting, and user identification.

I will start working on this improvement and add it as a default parameter for both toIpNetEndian and toIpPortNetEndian.

Edit: Actually never mind, it is not worth adding more overhead to the generating function for these addresses, the likelihood of user ipv6 addresses having too many zeros is too little for this to be considered.