I am choosing to respond in this particular thread to this issue relating to apparent successful IPv6 authentications occurring for some users in data centers in seemingly unrelated locations around the world, specifically due to the additional comments added here by the poster identified as Thomas, with the first containing the following text.
"It seems to be happening to a lot of people. I had this about 3 times, all of those IPv6 belongs to Microsoft it seems. All of them resolve to MICROSOFT-CORP-MSN-AS-BLOCK.
I've realized that it usually happens when I open the mobile app of outlook or OneDrive."
Another poster with this same issue has apparently dredged up this much older thread related to a similar issue with an Azure account back in 2023, with that original poster's follow-up comment from Oct. 9, 2023, containing the following excerpt (with minor spelling/grammar corrections by me).
"However, all the logs indicate a data center logged in. For some reason with the two-factor authentication in place, it seems that when you authenticate with your phone the data center handles all the queries and that is why the system logs the data center logging in."
Why Datacenter IPs are shown when a user logs in - Microsoft Q&A
Now to understand why we might be starting to see IPv6 addresses rather than the legacy IPv4, you need to understand that Microsoft began seriously supporting IPv6 for their Azure business customers a few years back, with various articles by both them and many others in the industry a few years ago around the same time as that earlier thread I referenced.
IPv6 coming to Azure AD - M365 Admin
Around the same time, we began seeing posts in the then Microsoft Answers Community forums relating to the display of IPv6 addresses and map information on the Activity page, which based on my own then Sprint Wireless network phone, were apparently beginning to be recognized as IPv6 connections as well, though mine changed back to IPv4 soon after as the T-Mobile acquisition of Sprint and integration of their towers and network caused them to revert back to IPv4 addresses, even though my actual tower and in fact the wireless frequencies in use hadn't changed.
Referring to this other comment by Thomas in this current thread, I'll try to explain possible reasons we're beginning to see many of these IPv6 changes now rather than a few years ago as happened for most Azure customers.
"Yeah, I thought it was related to the mobile apps but I had another successful sign-in when I wasn't using anything, at 2am, from Canada again, with some Microsoft IP.
I'm having those access at least once a week now."
Up until recently, I'd seen many explanations in the forums about the fact that cellular phone connections didn't show up in in the Microsoft Personal account Activity map displays though the log entries themselves often did, with only the device type like Android and other basic logging info, though I never saw any of this myself due to the way T-Mobile displays all of their customer's locations as related to a single large city in the same region which the customer tower resides, so both my phone and home gateway IP were the same, as well as when I was walking or driving in the same region.
However, another anomaly I'd noticed myself was that on occasion I might receive a login attempt that in rare cases even triggered a notification from Microsoft asking if it was actually me, which I of course logged into the Microsoft Account portal to check, finding that though I'd done nothing recently that should have caused an authentication to be triggered, the logged IP address was obviously my same IPv4 address that had logged an added Successful sign-in related to the phone just minutes before the manual login to check via the Edge browser with Windows.
The point here is, that spurious triggers of reconnect attempts by devices or apps aren't unheard of, and in fact some such as reconnect attempts, for example, to Azure accounts are actually required each hour when those are configured to require confirmation of current location (e.g. country), so it really shouldn't surprise us when our typically always on, or automatic wake-on-update or maintenance devices happen to communicate outside our normal waking hours.
What I'm saying here is that networks aren't static things and in fact are constantly changing, being upgraded, or reconfigured to support these or other new technologies as support devices like routers and firewalls change, leading to the ability for IPv6 to transition new boundaries, which since support for every single device between a client and server trying to communicate via IPv6 is a requirement, might mean a single change by either an ISP, major network provider or peer point could make thousands or even millions of IPv6 connections seem to appear instantly to another network like Microsoft's.
Since nothing has changed for my own IPv4 connection to Microsoft and only a relatively small number have complained, it's relatively obvious that the number of IPv6 connections appearing are limited, though since only those bothering to look in their Microsoft account Activity logs are likely to notice, it's not possible to truly understand how large that number is either.
But based in all of the above, I think it's probable that Thomas is correct and as with that Azure customer in the past, these are simply direct IPv6 connections to Microsoft data centers for background authentication (or possibly other service) traffic from phones, with the potential for various connectivity or location related 'pings' or other unexpected traffic resulting in occasional unexpected connections and possibly even transient alerts as well, just as I received one time sitting here apparently doing nothing.
Rob