Sponsored By

Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs.

Short tips for resolving Apple's IPv6 enforcement

Apple announced that they will check submitted apps whether they work for IPv6 network environment. This article introduces the resolution in concise explanation.

Hyunjik Bae, Blogger

January 27, 2016

4 Min Read

Happy New Year!

Ok, now we have to prepare for Apple’s AppStore reject policy to apps which does does not support IPv6 networking to be started early this year. 

In short, Apple deigns these Commandments:

  • Use the networking frameworks

  • Avoid use IPv4-specific APIs

  • Avoid hard-coded addresses

Image source link

Let’s get into each one.

1. Use the networking frameworks

Apple recommends using the network framework provided by iOS SDK. iOS Network Framework provides more convenient utilities than Socket API. It is okay to use 3rd party network framework too. If you are using a network framework other than Socket API directly, you usually don’t have to consider the Commandment 2. Instead, you should ask this a question to developers of your 3rd party network framework: 

“Does your framework supports IPv6?”

2. Avoid use IPv4-specific APIs

You must not use IPv4-specific APIs below if you write your code with Socket API directly.

  • inet_addr()

  • inet_aton()

  • inet_lnaof()

  • inet_makeaddr()

  • inet_netof()

  • inet_network()

  • inet_ntoa()

  • inet_ntoa_r()

  • bindresvport()

  • getipv4sourcefilter()

  • setipv4sourcefilter()

“Calling any of these function in any case will be rejected by Apple” is not confirmed yet. Anyway, we rewrote a little of our code not to call these functions.

To test whether your code works on IPv6 network environment, you have to prepare your own IPv6-only network environment. There are several ways, and Apple proposes a way doing it. See Test for IPv6 DNS64/NAT64 Compatibility Regularly section for details. You’ll need a Mac desktop or laptop.

3. Avoid hard-coded addresses

Apple mentioned hard-coded addresses. I think they intended for giving audiences easy understanding. The precise representation is IP literal. For example, “11.22.33.44”.

We frequently mention host name such as “server1.mygame.com” is called FQDN or Fully Qualified Domain Name.

What will occur if your client program tries to connect the server using hard-coded address aka. IP literal? Some of your client processes in IPv6-only network will be unable to connect to your server in IPv4-only network. Apple say that iOS 9.2 may be able to connect.

The vice versa is also the same: your client in IPv4 and your server in IPv6 network.

The reason why this happens can be explained with NAT64/DNS64 mechanism. I will skip this because it takes a long article.

So what do we do for now? Just follow Apple’s Commandment 3. Your server have to be reached via FQDN address rather than IP literal. In short, connect with FQDN.

Here’s the example.

  • 11.22.33.44 ⇒ Apple rejects your app.

  • server.mygame.com ⇒ OK.

  • 11:22:33:44:55:66:77:88 ⇒ Apple rejects your app. 

Your server administrators should configure a DNS server to give each FQDN name for each server. Of course, your client program should connect to your server with that FQDN names. 

If you have no time to give your servers FQDN names, ProudNet gives a workaround. Of course, I also explain making your own workaround implementation here below.

  • Enter your IP literal as you previously did.

  • Enter two FQDN names. They have to have different domain name. Don’t worry for the performance of two servers. Only DNS lookup is done. No connection will be attempted. These two FQDN names must have no IPv6 address.

It is not guaranteed yet whether this works for every network environment [1], but anyway you can win days to configure your DNS server. 


CNetClient* nc = CNetClient::Create();
p.m_serverIP = "11.22.33.44";
p.m_publicDomainName1 = "www.nettention.com";;
p.m_publicDomainName2 = "www.nts.go.kr";; 
nc->Connect(p);

Here’s how we implemented this workaround. You can make your own implementation following this method:

We implemented manual IPv6 address synthesize. Let’s talk about this with the picture above.

Given that your server has IPv4 address “11.22.33.44”, DNS lookup will retrieve it from “server.mygame.com”.

As your IPv6 client cannot identifiy “11.22.33.44” diectly, the NAT64 device between your server and client will give the address XX:XX...XX:0B:16:21:2C to your client. If you convert each number in 0B:16:21:2C to decimal one, you will notice that the result is 11.22.33.44. Please note that IPv4 mapped address such as ::ffff:0B:16:21:2C is usuable only for IPv4 network with dual stack Sockets. You cannot use IPv4 mapped address for your app in IPv6 network.

If you do DNS lookup with two more different FQDN names to IPv4 hosts, you get the similar IPv6 addresses. Head part of the addresses are the same, and the last 32 bits are the exact IPv4 address. The head part is called pref64. There are more pref64 patterns, but let’s skip them for now. You can find articles about them by looking for them among RFC documents with the keyword pref64 IPv6.

Please notice that this is just a workaround way. For complete resolution, follow Apple’s Commandment “Avoid using hard-coded addresses.”  

Have a happy coding!

[1]: This way works for our experiments with NAT64 router made with Mac machines. 

Read more about:

Featured Blogs

About the Author(s)

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like