Verdy_p added a comment.
The decimal form cannot be correct of it's not qualified with the address type (IPv4 or IPv6). And the numeric type cannot hold 128 bits of precision for IPv6 (note: we really need 128 bit for supporting users that can only use IPv6 via internet relays, many of them not delivering a full /48 or /64 range to each user, but granting them very small ranges (e.g. a /124 only). For some ISPs (notably some mpbile ISPs) there's no other choice, because they can't safely maintain enough IPv4 sessions for long, as they don't have enough IPv4 to share or use NAT routing (various mobile ISPs only give a local address like 192.168.0.1 or 10.0.0.1, all traffic passing through a proxy then routed from the same publicly routable /48 IPv6 block, where each of their user sessions are mapped to very small ranges). It would be preferable to use a storage form based on hexadecimal. Note that IPv4 addresses also have an equivalent canonical IPv6 mapping, so everything could be mapped to IPv6. So just use a format using fixed-length hexadecimal strings (32-bit or 128-bit) and another byte to specify the CIDR prefix length, possibly with an additional suffix byte for protocol filters. And some addresses may also be stored as being the result of a DNS query, in which case it should contain the domain name and a timestamp, to see when we need to reassert the IP address. We could also filter not just IP addresses but some AS numbers if we need them against malicious third party networks whose IP addresses are changing often, or if some AS is out of control or attacked. AS numbers are now over the old limit of 16 bits and can already be 32 bit too (so no way to distinguish a 32 bit IPv4 and a 32 bit AS number). For some filters, we may need to identify not just the source IPv4 or IPv6 but also the peered IPv4 or IPV6 or tracking identifier when they are reported by the proxy (e.g. for students in a university, or workers in a company or public organisation using strong firewalls and strict protocol filters): if we want to report abuses to the remote proxy admin, they'll want us to specify this identifier, which can be any string (possibly with a date or some additional fields required by them). So a single "number" cannot fit. The new type should still be based on strings, but with special formatting rules. TASK DETAIL https://phabricator.wikimedia.org/T235389 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Verdy_p Cc: Verdy_p, Lucas_Werkmeister_WMDE, Krenair, Reedy, Niharika, Aklapper, dbarratt, Hook696, Daryl-TTMG, RomaAmorRoma, 0010318400, E.S.A-Sheild, darthmon_wmde, Meekrab2012, joker88john, DannyS712, CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo, Majesticalreaper22, Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Af420, Darkminds3113, Bsandipan, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, LawExplorer, WSH1906, Lewizho99, Maathavan, _jensen, rosalieper, Wikidata-bugs, aude, Mbch331
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
