Apple’s Worldwide Developers Conference starts with a keynote, but the rest of the week is about sessions that go into much more depth with Apple’s software. During a session named Networking for the Modern Internet (video requires Safari, or you can look it up in the iOS WWDC app), Apple Distinguished Engineer, Scientist, and Technologist Stuart Cheshire took the stage to explain new networking features in iOS 10 and macOS Sierra. Soon the engineer revealed what developers can do to take full advantage of ECN, IPv6, international text in networking, cellular versus Wi-Fi, and network quality of service.
Last year, Apple told iOS developers that IPv6-only cell service is coming soon, get your apps ready. As of June 2015, iOS applications were required to support IPv6. Apparently iOS developers are taking Apple’s advice to heart: use higher level APIs, because those automatically use either IPv4 or IPv6 depending on what’s appropriate.
Apple says that as many as 70 percent of connections to www.apple.com from certain ISPs (like Verizon Wireless) come in over IPv6. About 40 percent of connections from Belgium, the world leader in IPv6 deployment, come in over IPv6. More and more big websites are finding that page load times over IPv6 are faster than over IPv4. For instance, Facebook is seeing 45 percent IPv6 HTTP requests, which complete 15 to 30 percent faster than IPv4 requests.
When an iOS device finds itself connected to an IPv6-only network but needs to talk to an IPv4-only server, there’s almost certainly a NAT64 device available. The NAT64, assisted by a DNS64 DNS server, will translate from IPv6 to IPv4 as long as network connections are set up toward a DNS name. This allows the DNS64 to create a synthetic IPv6 address from the destination’s real IPv4 address. The NAT64 then inserts itself into the conversation and translates between the two versions of the Internet Protocol. However, this doesn’t work if an application attempts to set up a network connection directly to an IPv4 address without involving the DNS.
This year, Apple comes to the rescue by supporting literal IPv4 addresses through NAT64 in “select APIs.” By using the appropriate API calls, applications can work through NAT64 even if they work with IP(v4) addresses directly rather than use the DNS. This is common in peer-to-peer applications such as Voice over IP (VoIP) and video chat.
Apple received feedback from developers that interact with the Internet of Things (IoT). A good number of these things don’t support IPv6, so apps need to talk to them over IPv4. The proper way to do this is using IPv4 to link local addresses (addresses in the 169.254.x.x range), but if that’s not possible, that’s not grounds for App Store rejection. Instead, devs just inform App Review when submitting an app, and they must make sure all other communication is still IPv6/NAT64-compatible.
Explicit Congestion Notification (ECN) is a mechanism that lets routers in the core of the Internet tell servers in datacenters as well as our personal devices that they’re sending data faster than the network can handle. With ECN in effect, networked devices can slow down before they start losing packets, avoiding more severe slowdowns. At last year’s WWDC, Cheshire told us that Apple would enable ECN in iOS 9 and OS X 10.11, but that never came to pass. See the networking section of our review of OS X 10.11 El Capitan for more information.
However, Apple did continue work on ECN and did enable it for VPNs. It then turned out that a German ISP marked all packets as “congestion experienced,” which doesn’t exactly lead to the best user experience. However, that snafu was cleared up within a few weeks. In September 2014, 56 percent of the Alexa top one million websites responded to ECN. In June 2016, that’s 70 percent, and no less than 83 percent over IPv6.
“The Internet is now safe for ECN,” according to Cheshire, who continued with a call to action “to ISPs and carriers and their vendors to support ECN, it’s time to start marking packets rather than dropping them.”
To add some action of their own in iOS 9.3 and OS X 10.11.5, Apple has enabled ECN for one randomly selected network session out of every 20. So far, that has seemed to work without major issues, although some release notes to let us know we’re part of ongoing networking research would have been nice. In the iOS and macOS betas, ECN is enabled 100 percent of the time over Wi-Fi and several cellular providers’ networks.
Listing image by Apple