Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
September 24, 2016
arrowPress Releases
September 24, 2016
PR Newswire
View All






If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Short tips for resolving Apple's IPv6 enforcement
by Hyunjik Bae on 01/27/16 12:55:00 pm   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

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. 


Related Jobs

Age of Learning, Inc.
Age of Learning, Inc. — Glendale, California, United States
[09.23.16]

Software Engineer - Unity
Dark Rift Entertainment
Dark Rift Entertainment — Irvine, California, United States
[09.23.16]

Gameplay Programmer (C++)
CCP
CCP — London, England, United Kingdom
[09.23.16]

Senior Engineer
3BLACKDOT
3BLACKDOT — Los Angeles , California, United States
[09.22.16]

Gameplay Engineer





Loading Comments

loader image