Just to add my two cents regarding the use of the OneDrive Personal Vault which I hadn't tested since putting a couple pictures in it that I wanted secured a year or so ago, that had a different specific effect within my Activity logs.
Though the initial check I made by logging into my Microsoft Account had the usual Device/platform of Windows and Browser/app of Microsoft Edge, the access of OneDrive Personal Vault a few minutes later logged a separate Successful sign-in entry from the same location and map, but with the same Device/platform of Windows, with a different Browser/app of Internet Explorer.
The interesting thing here is that this likely explains the occasional appearance of the legacy Internet Explorer app in these logs as relating to items like the Windows Hello Face (camera) verification of my identity that occurred as a result of this access, since that's probably still tied to portions of those same legacy components of Internet Explorer that still remain embedded in at least Windows 10, and would require major revisions if Microsoft attempted to remove these Internet Explorer components completely, so they simply left them there fulfill this legacy purpose.
Even more interesting in my case, these two particular Activity log entries were logged as occurring from Barcelona, Spain, which just happens to be where I'm sitting at the moment on vacation in a hotel, so perfectly accurate, though obviously different from the previous set of Activity logs from a few days before I left home.
So clearly it isn't simply the use of OneDrive or even the Personal Vault that triggers these special IPv6 entries, nor either Windows Hello from Windows 10 or the act of authentication via Microsoft Authenticator Push notifications and number matching from an Android phone, since all of these actions occurred at some point within the testing I just performed and listed above.
So, it's still unexplained why a subset of users happens to receive these IPv6 log entries from internal Microsoft cloud IP addresses during otherwise seemingly normal activities or occasionally outside typical usage hours as well.
It clearly has nothing directly to do with the SharePoint [unpatched] locally managed server vulnerabilities either, per my earlier post mentioned here by others, though we can't say there's no relation to similar issues without knowledge we don't have.
I still don't believe this is a 'bug' as such though, simply a minor logging annoyance that since many of those affected seem to be the same subset of users who were also affected by the earlier bot attack attempts against their Microsoft account passwords, has been anecdotally linked by these same relatively paranoid users to mean there's some potential relationship to that earlier set of attacks.
In truth there's absolutely no evidence of this at all though, it's simply the coincidental effect that just about the only people who ever bother to look at the Microsoft account Activity logs are these same people who were previously under bot attack, so of course if some portion of this same group overlaps with those experiencing the IPv6 entries, that coincidence would tend to look suspicious to those already paranoid for those legacy reasons.
This appears to me to be a form of confirmation bias, while the process of thinking all of this through has led me to wonder if any of those affected by these IPv6 log entries also happened to be among those that chose to try the workaround solution to that earlier bot attack issue of creating a new account alias and switching to the use of that alias for login, since that's just the sort of account modification I could see potentially requiring some additional internal cloud account interactions that might result in the internal authentication traffic likely to cause these IPv6 Activity entries to display.
Rob