The definition in question:
|
% https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses |
|
-define(IPV4_IPV6_PREFIX, <<0:80, 16#FFFF:16>>). |
Following tentative PR #39 a few months ago and, more recently, evidence of this in #43 .
As per the spec, the root node seems to be ::/96 rather than ::ffff:0:0/96 (which is for IPv4-mapped IPv6 addresses) and I had read it wrong all this time:
https://maxmind.github.io/MaxMind-DB/#ipv4-addresses-in-an-ipv6-tree
Official Python implementation mentioned by @nickjacob in #39, which further suggests this in the way it walks over the IPv6 tree to get the IPv4 root node:
https://github.com/maxmind/MaxMind-DB-Reader-python/blob/b59335627a27b96c6e5a3178632ed0ab77d53cfb/maxminddb/reader.py#L118-L127
This being true, the existing behavior worked purely out of chance: all the databases I had tested so far happened to account for IPv4-mapped IPv6 addresses, and therefore I didn't run into the bug for 6+ years.
The definition in question:
locus/src/locus_mmdb_tree.erl
Lines 48 to 49 in 8d0019d
Following tentative PR #39 a few months ago and, more recently, evidence of this in #43 .
As per the spec, the root node seems to be
::/96rather than::ffff:0:0/96(which is for IPv4-mapped IPv6 addresses) and I had read it wrong all this time:https://maxmind.github.io/MaxMind-DB/#ipv4-addresses-in-an-ipv6-tree
Official Python implementation mentioned by @nickjacob in #39, which further suggests this in the way it walks over the IPv6 tree to get the IPv4 root node:
https://github.com/maxmind/MaxMind-DB-Reader-python/blob/b59335627a27b96c6e5a3178632ed0ab77d53cfb/maxminddb/reader.py#L118-L127
This being true, the existing behavior worked purely out of chance: all the databases I had tested so far happened to account for IPv4-mapped IPv6 addresses, and therefore I didn't run into the bug for 6+ years.