You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Many ASN do not tag there ipv6 ranges correctly.
The use there HQ as the location for ipv6 range
ipv4 is most of the time geo tagged correctly
and only some times record in the GeoIP DB is stale.
My idea for a feature would be, when a dual stack host with different resolved locations is detected,
then the probe operator could define the preferred link (ipv4 or ipv6)
Triangulation could be used to resolve this conflict or validate the location automatically,
but it is most likely not necessary.
In my case the probae has
an ipv6 resolved as DE-Berlin
and an ipv4 resolved as AT-Vienna
The text was updated successfully, but these errors were encountered:
Hey, thanks for the feedback. Coincidentally we've been working on almost this exact issue during the past week.
v6 low data quality came up and we're looking for solutions for dual-stack probes and potentially v6-only probes as well.
Many ASN do not tag there ipv6 ranges correctly.
The use there HQ as the location for ipv6 range
ipv4 is most of the time geo tagged correctly
and only some times record in the GeoIP DB is stale.
My idea for a feature would be, when a dual stack host with different resolved locations is detected,
then the probe operator could define the preferred link (ipv4 or ipv6)
Triangulation could be used to resolve this conflict or validate the location automatically,
but it is most likely not necessary.
In my case the probae has
an ipv6 resolved as DE-Berlin
and an ipv4 resolved as AT-Vienna
The text was updated successfully, but these errors were encountered: