Hi, We have an app that make HTTP requests to a device on the local network using connect-by-name semantics and for which the name is resolved using mDNS aka mydevice.local. The HTTP request is made using a URLSession (internally using the React-native v0.68.1 fetch implementation) We have a latency problem in the case where the local network router IPv6 is not enabled, under certain conditions. Even though IPv6 is not enabled, our device mDNS resolver advertises the IPv6 AAAA address record of its link-local address (aka fe80::...). From our understanding this seems to be normal, it is the client responsibility to figure out how to contact the host. On iOS 16.0.2 and 16.1.1, we observe in Instruments that the app will first make an attempt on the IPv6 address record alone, timeout after 2 seconds and 3 retries, and then only try the IPv4 address record immediatly after the 3rd IPv6 attempt. For some reason the same name resolution attempts are made for every dataTaskWithRequest calls (even though the same session is reused and not invalidated). This is running on a real iPhone, but the same behavior is observed using the simulator 16.2 instead. The more or less same observation is made if we use Safari rather than our app. We have this latency of 2 seconds, but we can't confirm the same behavior with Instruments. We don't observe this problem on iOS 16.6 and 16.6.1, as well as the simulator running 15.2 (on the same computer running the simulator 16.2). Reading this excellent post and TN3151, we understand that our non-enabled IPv6 is mitigated using the "Happy Eyeballs" algorithm, for which 2 engineers at Apple refined the original algorithm in RFC8305 which is dated end of 2017. From this, we assume that the behavior we see on iOS 16.0.2 and 16.1.1 is incorrect. So for now we assume that this algorithm has been implemented since quite some time in iOS, and we are wondering if something is broken in iOS 16.0 and 16.1? As far as we understand, iOS 16 seems to conform to RFC6724 with an IPv6 preference in its default policy. We understand that all this is a lot of assumptions, but tracking this problem between platforms and accross implementations has been quite intense, so we want to know if we are looking in the right direction. From our observation, it seems that there is something really wrong with iOS 16.0.2 but we also can't believe that would have slip through during Apple beta-test phase either. So if there is something wrong on our side, what could it be? Thanks!