cocoachina上的讨论链接：
http://www.cocoachina.com/bbs/read.php?tid=458416
原文如下：
苹果应用商店拒绝不支援 IPv6 的应用的解决方法
written by: imays
translated by: coolspeed (weibo.com/coolspeed)
大家新年快乐！
话说这苹果是从新年第一天起就开始了恐怖活动啊……虽然是去年已经预告了的恐怖活动……—那就是“你们的应用必须支援 IPv6，不然的话就拒绝通过审核，嘿嘿”
直奔主题。如果不想被拒，你应该这样做才行：
- 使用网络通讯框架；
- 避免使用 IPv4 专用的 API；
- 避免使用硬编码地址。
来源：点击链接跳转
现在让我们来逐条展开：
- 使用网络通讯框架；
也就是是说推荐你使用 iOS SDK 自带的，构建于 socket 上层的网络通讯框架，或是第三方的网络通讯框架。这样，使用网络通讯框架的话，上面的第 2 条大体上是不用操心的。如果你使用的是第三方的网络通讯框架的话，一定记得询问该框架的开发商：“你们支援 IPv6 吗？”
作为网络通讯框架其中之一的 ProudNet™ 是支持 IPv6 的哟。自 2015 年 12 月的更新版本开始支持。ProudNet 的使用者如果要想支援 IPv6 的话，应该使用 2015 年 12 月版本，或更高的版本。
- 避免使用 IPv4 专用的 API；
如果你亲自编程 socket 层的话，记得不能使用 IPv4 专用 API。比如说，你不能使用如下这些 API (光是使用这些函数本身，是否会成为苹果方面拒绝通过应用审核的事由，目前还不清楚。反正 ProudNet 目前是全然不使用这些函数的)。
inet_addr()
inet_aton()
inet_lnaof()
inet_makeaddr()
inet_netof()
inet_network()
inet_ntoa()
inet_ntoa_r()
bindresvport()
getipv4sourcefilter()
setipv4sourcefilter()
如果要测试在 IPv6 的环境下是否运转正常，你需要构建 IPv6 only 的网络环境。方法有很多种。我们使用的是通过 Mac 机器的方法。
- 避免使用硬编码地址。
苹果使用的是“硬编码地址”这样的术语。不过这大体上只是对大众友好的简化说法。正确的学名其实应该叫 IP literal。比方说形如 “11.22.33.44” 这种啦。
另一方面，我们通常所说的 “hostname”，比方说“server1.mygame.com”这种，学名叫 FQDN (fully qualified domain name)。
你问，通过“硬编码地址”，也就是我们所说的 IP literal 连入服务器的话会有什么样的后果呢？一些 IPv6 网络下的客户端会连不上 IPv4 网络下的服务器（虽说 iOS 9.2 以后这个问题会部分解决，但是没法保证在所有 IPv6 网络下都没问题）。
反之亦然—客户端在 IPv4 下，服务器 IPv6。
至于连不上的原因吗，要从 NAT64 / DNS64 的联动关系说起。因为内容有点长，这里就不赘述了。
那么应该肿么办呢？乖乖地听从苹果大人所“指示”（？）的。通过 FQDN 而不是 IPv4 literal 的连入的情况下，服务器要能够接收。客户端连接服务器时则要使用 FQDN。
举例说明上面的内容：
- 11.22.33.44 ==> 苹果会屏蔽你
- server.mygame.com ==> Ok
- 11:22:33:44:55:66:77:88 ==> 苹果会屏蔽你
运维人员则要对每台服务器设置 DNS 使每台机器均有 FQDN 是吧？客户端方面则要在连入服务器时使用 FQDN 而不是 IP literal 是吧。
如果现阶段对每台机器赋予 FQDN 比较困难的话，ProudNet 提供如下的的应急方案。
连入基于 ProudNet 的服务器时使用 IP literal，并额外输入另一台 IPv4 下的服务器 X 的FQDN，就行啦。服务器 X 并不会真的连入，只是作为 DNS 检索对象，所以请放心。有了这个，就可以光用 IPv4 literal 也能连入服务器啦，虽然不能保证 100% 管用 [1]。
CNetClient* nc = CNetClient::Create();
p.m_serverIP = "11.22.33.44";
p.m_publicDomainName1 = "www.nettention.com";
p.m_publicDomainName2 = "www.baidu.com";
nc->Connect(p);
(C#也是可以的，这里不再赘述)
为什么光用 IPv4 literal 也能连上呢？因为实现了 NAT64 的“地址组合算法”。这个说来也比较长，这里也是略过 ^^
不管怎么说，使用上述 API 始终只是缓兵之计，应急措施。要彻底解决的话还是要听从苹果大人“指示”（？）的那样子，“”。
番外：等到 IPv6 大量普及了以后，路由器是不是就可以消失了？
如果 IPv6 大量普及了的话，路由器“在理论上”确实可以扔进历史的回收站了。路由器本身就是用来解决互联网地址总数不够用这个问题的其中一种方法而已。
但是。作为对每个 IP 地址明码标价，作为商品出售的网络提供商来说，即使是 IPv6，奸商们也不大可能会轻轻松松送你 IP 地址的。那么设置路由器的这种事儿也就不可避免啦。对路由器这块比较强大的 ProudNet 也会继续有存在的必要性的。
那祝编程愉快～
2016.7.19
转载上面的文章时，IPV6的新规还没有正式执行，并且到目前为止，已经提交了多次审核，并且都没有发生过问题；
不过最近一次提审被苹果拒了，提示在登录时网络故障；重复提交一次，结果还是相同的问题被打回；
（这个问题很多人应该都遇见过，在本地进行IPV6环境测试，都OK的，但是送到苹果审核就连不上网络）
我的解决方法是：在被拒绝的通知下直接回回复自己测试ok的，并附上视频片段；
结果第二天还真的通过了。这说明，苹果那边还是会尽量协助开发者的。
另外，在网上收集了一些相关的讨论：
阿里云技术论坛：
https://bbs.aliyun.com/read/284699.html?spm=5176.bbsr284699.0.0.yehNue
来自cocoachina上的讨论：
http://www.cocoachina.com/bbs/read.php?tid-1684570-page-1.html
[1]: 在包括 Mac 机器在内的部分客户端 IPv6 路由器下正常工作。
