In a recent post, I scored Apple a 7 out of 10 for their IPv6 efforts after the IPv6 announcements they made at the Apple Developers Conference.
In light of recent posts from Apple, it’s time to reassess that score.
Prioritizing IPv6 over IPv4 in Dual Stack environment
The first post is a public note on the IETF’s V6ops mailing list from David Schinazi of Apple concerning contemplated changes to the so-called Happy Eyeballs behaviour of iOS and Mac OS X.
Apple’s current behaviour in a Dual Stack environment is that when there is a choice to use either IPv4 or IPv6 the Apple device will try to connect using what it thinks is the “fastest” protocol. The problem with this approach is that it generates some subtle forms of backward pressure in the IPv6 transition process.
If devices have a bias to using IPv6 when possible, the more IPv6 is deployed then the less IPv4 is used. Deploying IPv6 in such an environment will reduce the intensity of pressure of use of address sharing mechanisms such as NATs, as the more IPv6 is used then the lower the level of use of IPv4.
Apple are contemplating changing their behaviour as of the forthcoming iOS 9 and OS X El Capitan releases. The browser’s connection mechanism in an IPv6 equipped Apple device will generate DNS queries for the IPv6 and IPv4 address records, starting with the IPv6 query.
If they get a response from the IPv6 address query first then the data connection will immediately commence with a TCP SYN packet sent over IPv6.
If they get a response for the IPv4 address query first the system will wait for 25ms to see if there is an IPv6 address response to come. If so then it will fire off an IPv6 connection. Otherwise, if the 25ms timer triggers without an IPv6 address response, it will fire off an IPv4 connection.
If the addresses are already in the host’s local cache then it will pick the address and protocol with the lowest TCP rounds trip time recorded from previous TCP sessions.
The essential change here is that it will weight the IPv6 RTT values by 25ms, biasing the host to select IPv6 in those cases where the numbers are within 25ms of each other.
Testing Apple’s Dual Stack preferences
Apple have observed that their tests lift the Dual Stack IPv6 preference to approximately 99 per cent, which is a substantial change to the 50 per cent IPv6 preference they have observed.
At APNIC Labs we have observed a slightly different behaviour (as shown in the following figure), where the observed preference rate for Apple systems in the Internet today is between 70 to 75 per cent, slightly higher than the 50 per cent reported by Apple. If the contemplated changes get to the 95 per cent observed level of Windows then this would be a distinct change for the better.
It also appears that Apple is changing the way its iOS Personal Hotspot operates.
The conventional approach to implementing a personal hotspot in IPv4 is to use a Network Address Translation module in the hotspot domain, with the public NAT interface directed to the external interface. However, this is one of those areas where you shouldn’t simply substitute IPv6 in place of IPv4 and carry on.
One of the underlying motivations in the design of IPv6 with its significantly expanded address space was to avoid the use of NATs in IPv6 altogether. If you can’t NAT to create a personal hotspot in IPv6 then what options are left?
The answer to this question involves taking a piece of pre-NAT IPv4 functionality and using its current IPv6 equivalent.
ARP originally provided IPv4 address to MAC binding on local networks. ARP required the host to send a broadcast message to all other IP hosts on the same network, and the ARP response would contain a response that bound a particular MAC address to a particular IP address. There was a way of binding together two distinct broadcast networks as a single logical IP subnet by using a technique called “Proxy ARP”.
A Proxy ARP relay passes ARP messages between subnets, substituting its own MAC address for MAC addresses that are relayed from one broadcast net to the other.
In IPv6, ARP has been largely replaced by the Neighbour Discovery Protocol, which replaces the broadcast approach of ARP (together with some redirect functions of ICMP) with a richer set of messages that provide for router and neighbour solicitation and advertisements.
The Neighbour Discover protocol is described in RFC4861. Like Proxy ARP, there is an experimental specification of a Neighbour Discovery Proxy function where the proxy agent acts as a bridge between two distinct networks, obviating the need for distinct subnet addresses for the connected subnet. IPv6 Neighbour Discovery Proxies are described in RFC4389.
So if you want to avoid the use of NATs in IPv6, and you want to share an external IPv6 connection to a local subnet, then it appears that the ND Proxy approach is a possible way forward. The clients of the hotspot believe that they are on a conventional IPv6 network, and the ND Proxy relays the ND messages to the external connected network.
What are Apple doing here?
The note from Apple has said that an iPhone with a Dual Stack cellular connection will support a Dual Stack client hotspot, and the approach being used here is the ND Proxy for IPv6. For those who want the implementation details then the next step is to consult the codebase for iOS, where the ND Proxy module can be found.
The Mac OS X systems on the other hand have no such support. To quote from David’s note to the V6ops IETF list, on Mac OS X “regular internet sharing (from your ethernet to Wi-Fi for example) does not support IPv6 because of the limited use cases, and the lack of demand for it.”
And, finally, what about 464XLAT? Well this note from Apple says it simply: “we do not support 464XLAT.”
Where is Apple now with IPv6?
A few weeks ago I gave Apple a score of 7/10 for their v6 story. The Happy Eyeballs change in their v6 selection policy is an important, and in my mind, necessary change.
The ND Proxy support on iOS is also an important step forward, but I’m surprised that it has not been added to the Mac OS X code stream as well. And iPhones still don’t support 464XLAT.
In light of the changes, my score is now at 8.5/10.
Getting closer!
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
Interesting about no support for 464XLAT given that’s T-Mobile’s transition mechanism. And speaking of unsupported things, what’s your view on Google’s refusal to implement DHCPv6 in Android because then USB tethering would break on wifi? Maybe it’s time to score Android and IPv6?
Apple just don’t seem to think that 464XLAT is sufficiently important for them. Which is a shame I think. As for scoring Android – what a good idea!