Test 2
Category: Testing
Jun 10
Apple Will Require IPv6 Support For All iOS 9 Apps
“Because IPv6 support is so critical to ensuring your applications work across the world for every customer, we are making it an AppStore submission requirement, starting with iOS 9.” With those words, Sebastien Marineau, Apple’s VP of Core OS, gave a huge boost to IPv6 developer support in Apple’s WWDC Platform State Of The Union (SOTU) address yesterday.
You can watch the Platform SOTU presentation yourself (although you may need the Safari browser to do so). The IPv6 segment begins at 34:16 and Marineau’s statement about the AppStore requirement can be heard at 37:16.
Here, though, is the quick summary.
Why IPv6?
Sebastien Marineau began by talking about IPv6 and why it is important:
In particular he noted that carriers in several regions of the world are now deploying IPv6-only networks and emphasized the importance of making your application work well for everyone, everywhere. He reinforced how critical it is to support IPv6:
“If your application doesn’t work properly with IPv6, it will simply not function on those networks, those carriers and for those customers.”
He also explained how Apple has supported IPv6 for over ten years now since early versions of Mac OS X and from iOS 4 onward.
3 Steps For Developers
He went on to explain three steps all developers can take to make sure their applications work over IPv6 networks:
Those steps are:
- Use the networking frameworks (for example, “NSURLSession”)
- Avoid use of IPv4-specific APIs
- Avoid hard-coded IP addresses
Essentially, if app developers are using the higher level APIs and frameworks and aren’t hacking around at the IP layer, their apps should probably “just work” on top of either IPv4 or IPv6.
Testing Your App Over IPv6
However, Martineau addressed the question of “how do you test your app over IPv6?“, particularly when many app developers may not have access to a native IPv6 Internet connection. He indicated that in an upcoming release of Mac OS X there will be a new feature to help with this:
What I understood Martineau to say was that you will be able to set up a “personal WiFi hotspot” on your Mac and check an “IPv6-only” box. Your iPhone/iPad with your app could then connect to that specific WiFi network to work in an IPv6-only mode. The Mac would then provide the gateway to the legacy IPv4 Internet so that the app on the IPv6-only network could connect out to services on IPv4 servers.
THIS IS HUGE! One of the struggles many application developers have had is to easily create an “IPv6-only” network in which to test systems. Even those of us who are IPv6 advocates/enthusiasts have struggled with making this work well. It typically involves bringing up a second access point (which you are effectively doing with this new configuration) and then turning off all IPv4 services on that access point, which some access points make difficult to do.
Whenever this feature rolls out in Mac OS X, it will greatly help all of us who are working on apps and systems and want to test them in an IPv6-only environment.
An Important Step
Now, to be clear, most iOS app developers probably won’t have to do all that much to support IPv6. If they are already using the higher level APIs and networking frameworks they should be all set. The exact mechanisms of IP address handling are not a concern of theirs. However, some app developers will have to make some changes, particularly if they are directly using IPv4 addresses as any kind of identifier or in logging.
More importantly, the requirement for AppStore submission will require app developers to test their applications with IPv6 networks, and that alone will suddenly cause the millions of iOS app developers out there to have to learn at least something about IPv6 (if nothing else, the fact that it exists).
Most significantly, though, this step by Apple means that all the iOS apps that run on iOS 9 will work well over the IPv6-only networks that are starting to be deployed. Even in dual-stack (IPv6/IPv4) networks, this should mean that iOS 9 apps will work better in those environments when, for instance, IPv6 may be faster. (More needs to be understood here about the specifics of the IPv6 support.)
And… this also will help take away the argument used by some network operators who are still not moving ahead with IPv6 that “why should we deploy IPv6 when apps don’t support it?”
Apple’s answer is that, as of iOS 9, all iPhone/iPad apps will support IPv6!
Kudos to Apple for taking these steps, creating this new AppStore submission requirement, and also providing what sounds like a new and easy way to create IPv6-only networks!
We’re looking forward to iOS users being able to use ALL their favorite applications on an IPv6-only network!
P.S. If you want to get started with IPv6, please visit our Start Here page to find resources tailored for your role or type of organization. The time to make the move to IPv6 is TODAY!
Also, hat tip to Adam Iredale on Twitter, who first brought this new requirement to my attention, and to Borja Reinares who provided some more information.
Feb 21
NIST Offers New Tool To Verify TLSA Records For DANE / DNSSEC
Are you experimenting with using the DANE protocol to provide an additional layer of security to your TLS/SSL certificates via DNSSEC? Would you like to easily test that your TLSA record needed for DANE works correctly?
If so, the folks at the US National Institute of Standards and Technology (NIST) now have a new tool for testing TLSA records and DANE support. All you do is go to:
and in the simplest form just enter in the URL of the site you want to test. Here is an example of what happened when I entered https://www.freebsd.org/ (click image to see larger version):
The site basically tests that you have your TLSA record correctly configured and that it matches the TLS/SSL certificate you are using with your web server.
Now, if you don’t have a site with a TLSA record but want to see how the tool works, the NIST tool helpfully lets you choose from one of the DANE test sites we list here on Deploy360. You can also connect to the NIST “DANE Reference site” to explore different usage types.
In an email message to several public mailing lists, tool author Stephen Nightingale at NIST indicated that his latest version of this tool was now offering the choice of testing from clients based either on TLSlite or GnuTLS. He goes on to note:
Mine was one of the ‘DANE-in-the-App’ sites that Viktor Dukhovni reviewed, and he kindly gave an extensive critique. Many of his points have been addressed. A few things still to clear up:
- I’m not checking for certificate revocation. That is on the list to fix.
- For 0xx and 1xx uses, it is hard to identify a single canonical CA list. I have overlapping, but different Root Cert sets from Mozilla, Fedora and Linux Mint. So when searching for an authority to build a verification chain I cycle through all of these until succeeding or exhaustion of the possibilities. Some of the DANE 360 listed sets (including some from members of this group) fail to authenticate because the root certs are not in my authorities. A golden, canonical CA list would be nice to find. But I guess that its non-universal availability is one of the problems of the CA system that DANE is aiming squarely at.
The differences between TLSlite and GnuTLS clients highlight the fact that there are unresolved interoperability issues among TLS implementations. It seems reasonable that TLS interoperability testing be instituted as pre-requisite to DANE testing. The development of a TLS Interoperability test suite is therefore on our ‘to-do’ list. I look forward to seeing the newly upgraded OpenSSL client with added DANE. It is quite possible that as an interim step before its appearance I will add this DANE-in-the-App implementation to pyOpenSSL and/or Twisted.
Thanks to Stephen and the team at NIST for making this tool public and we hope that it will help those of you working with DANE to test out your implementations.
