Overhaul stats: Increase IPv4 stats for IPv6 IPs with the prefix `::ffff:`

[josecelano]

Relates to: #1368

When you bind the server socket address to IPv6 IP addresses ([::]:6969 in the bind_address config option), the tracker can handle requests from IPv4 and IPv6 clients. IPv4 clients' addresses are converted to IPv6 IPs.

However, the metrics are increased for IPv6. I think we can add a config option to change the behaviour and increase IPv4-related metrics when the IPv6 address has the ::ffff: prefix.

I would make it the default behaviour, but that's a breaking change. So the new config option should be disabled.

IPv4-mapped notation

cc @da2ce7 @devnakx

[josecelano]

Hi @devnakx, I've been discussing this feature today with @da2ce7 and he had a better proposal. Instead of using a config option to move the metrics from IPv6 to IPv4 we could add new sub-metrics for IPv6.

Pros

• We explicitly put this information in the exposed metrics. So consumers know where they metrics came from even if they don't know the tracker configuration.

Cons

• We have to duplicate all metrics for addresses with this prefix. In practice it will be like having a new "IP version".

On the other hand, I do not know if we should give more metrics than the basic raw metrics. This seems to be a sub-product of the current metrics. Without changing anything you can process all the evens, parse the clients' IPs and get the metrics for the IPv-4mapped IPv6 IPs (this will be possible once I finish the refactor to allow third-party packages to subscribe to events).

Where should be put the limit? Other people could potentially ask for metrics for a a subnet or something like that. I think the difference here is that if we don't do it metrics would be like "fake"· This prefix is a standard way to do it and I guess we will not have many more cases like this. So I will implement it and I will update the related issue accordingly.

[josecelano]

I've used an AI model to get a list of the different ways to represent an IPv4 address in IPv6 (not confirmed):

Representation Type	IPv6 Format	Purpose / Use Case	Example for IPv4 192.0.2.33
IPv4-Mapped IPv6	::ffff:<IPv4>	IPv6 apps communicating with IPv4-only hosts (dual-stack)	::ffff:192.0.2.33 or ::ffff:c000:221
IPv4-Compatible IPv6	::<IPv4>	Deprecated; legacy IPv6-over-IPv4 systems	::192.0.2.33 or ::c000:221
6to4 Address	2002:<IPv4 in hex>::/48	Automatic tunneling over IPv4 using public IPv4 address	2002:c000:0221::/48
Teredo Address	2001::/32 prefix + embedded obfuscated IPv4	NAT traversal for IPv6 over IPv4 networks (Teredo tunneling)	2001:0000:<server>:<flags>:<obfuscated>
ISATAP Address	<prefix>:0:5efe:<IPv4>	Internal IPv6 tunneling over IPv4 (common in enterprise setups)	fe80::5efe:192.0.2.33 or fe80::5efe:c000:221

For now, we will implement only the IPv4-Mapped IPv6 format.

With the new extendable labeled metrics this can be implemented just by adding a new label to existing metrics. For example:

http_tracker_core_requests_received_total{request_kind="announce",server_binding_ip="0.0.0.0",server_binding_port="7070",server_binding_protocol="HTTP",ip_version="v4_mapped_v6"} 176

udp_tracker_server_requests_accepted_total{kind="announce",server_binding_ip="0.0.0.0",server_binding_port="6969",server_binding_protocol="udp",ip_version="v4_mapped_v6"} 1443931189

Where values for the new label are: v4, v6, v4_mapped_v6.

cc @da2ce7

[josecelano]

I think I'm going to use the label.

• Name: server_binding_address_type
• Values: plain, v4_mapped_v6

To avoid mixing IP version (4 or 6) with mapping or what the address represents.

We can add more options in the future.

cc @da2ce7