IPv6 impossible travel wrong geo-ip data

[Peter Holland]

we are seeing a lot of alerts and reports of impossible travel coming up since the IPv6 support added to 365. In all instances it seems that whatever Defender for Cloud Apps is using to geo-tag the source IPv6 address is wildly innacurate. 

IPv6 addresses for domestic broadband connections in Dorset UK are being reported as coming from Germany.

we used to see this occasionally with IPv4 addresses, or that whatever is being used seems to be way less accurate than any of the publicly available geo-ip lookup sites. e.g. again Dorset UK IP addresses being marked as northern UK or scotland. IPv4 seems to have improved and rarely reports as innacurate as before but IPv6 seems to be a freshly opened can of worms and the detections are failing to instill confidence in the alerts.

is there any insight into whats being used or any way to provide this feedback to the team responsible?

[#2]

@Peter Holland This is not just with Defender for Cloud Apps. I'm seeing it in Sign-In logs in Azure AD. IPv4 is indicating they are in Arlington, VA (where they live), and IPv6 logs says they are in Levittown, New York, US. The only difference is that the Microsoft VPN seems to force IPv6, and I have dozens of folks being reported as accessing our network from Levittown, New York (incorrectly).

It seems the IPv6 is wildly inaccurate across Microsoft's platform. What good are logs if you can't trust them? 

[#3]

I was locked out of M365 today due to a conditional access policy. My IPv6 was being reported as Los Angeles, CA when it should have been Sydney, AUS

Checking the IPv6 address on https://www.iplocation.net/ seems to be correct, so maybe Microsoft's IP DB is messed up.

[#4]

@Peter Holland, I have noted the same thing.  The IP6 GeoLocation services do not have consistent and accurate data. I plugged in the IPv6 address being reported from Microsoft as located in Levittown,, NY but in fact we are in MA.  When I went to IP Address Lookup | Geolocation (iplocation.net) to check out what they reported as the Geolocation, they list 7 different service results and 5 of the 7 where incorrect. Not very good odds and defeats the validity of using IP ranges in Conditional Access policies.

[#5]

@Peter Holland Here is what I suggest we do - methodically log each instance of inaccurate IPv6 geo-tagging and report it to Microsoft through official support channels. The more precise, actionable data we provide, the better chance engineering teams have of identifying gaps and improving their datasets. This problem won't be resolved overnight.

However, by contributing concrete examples rather than just venting frustration, we stand a better chance of getting Microsoft's attention focused on tightening up IPv6 accuracy. I'm happy to help compile feedback examples if others want to contribute. Though it will take time, hopefully Microsoft will refine their IP geolocation capabilities to reduce these false alerts.

[#6]

@BarryGoblon, @Peter Holland ,

I agree with reporting the inaccurate instances of IPv6 geolocation to Microsoft, in theory. In practice, however, I don't have anyone on my team who has time to do this. This is something Microsoft needs to get right. If there are other databases that are more accurate, then MS needs to get access to that data. They are using bad IPv6 data for geofencing and, as has already been reported in this thread, this can lead to admins being locked out of their management and admin portals, not to mention reporting being wrong for logging, etc.