参考：
http://blog.csdn.net/zhangweiacm/article/details/51822473
Supporting IPv6 DNS64/NAT64 Networks
对IPv6 DNS64/NAT64网络的支持
With IPv4 address pool exhaustion imminent, enterprise and cellular providers are increasingly deploying IPv6 DNS64 and NAT64 networks. A DNS64/NAT64 network is an IPv6-only network that continues to provide access to IPv4 content through translation. Depending on the nature of your app, the transition has different implications:
随着IPv4地址池的枯竭迫在眉睫，企业和手机运营商们正在增加对IPv6 DNS64 和 NAT64网络的部署。DNS64/NAT64网络是一个通过转化的方式持续提供IPv4内容访问的IPv6-only网络。对于不同的应用程序，这种转化具有不同的含义：
1.If you’re writing a client-side app using high-level networking APIs such asNSURLSessionand the CFNetwork frameworks and you connect by name, you should not need to change anything for your app to work with IPv6 addresses. If you aren’t connecting by name, you probably should be. See Avoid Resolving DNS Names Before Connecting to a Host to learn how. For information on CFNetwork, see CFNetwork Framework Reference.
1.如果你正在使用高级网络API，如NSURLSession和CFNetwork来编写一个app，并且通过域名来进行连接，那么你不需要因为IPv6地址而对你的应用程序作出任何改变。但如果你没有通过域名连接，你可能就需要做IPv6的相关处理了。可以参阅文章在连接到主机之前避免解析DNS名称来学习如何处理。关于CFNetwork的信息，请参考CFNetwork框架指南。
2.If you’re writing a server-side app or other low-level networking app, you need to make sure your socket code works correctly with both IPv4 and IPv6 addresses. Refer to RFC4038: Application Aspects of IPv6 Transition.
2.如果您正在编写服务器端应用程序或其他底层的网络应用程序，则需要确保你的socket代码能够在IPv4和IPv6地址下正确工作。参见RFC4038：IPv6转化的应用。
What’s Driving IPv6 Adoption
是什么推动IPv6的使用？
Major network service providers, including major cellular carriers in the the United States, are actively promoting and deploying IPv6. This is due to a variety of factors.
主要的网络服务提供商，包括美国主要手机运营商，正在积极推广和部署IPv6。这是由于多种因素造成的。
Note: World IPv6 Launch is an organization that tracks deployment activity at a global scale. To see recent trends, visit the World IPv6 Launch website.
注：World IPv6 Launch是一个在全球范围内跟踪部署活动的组织。想要看最近的趋势，请看World IPv6 Launch的网站
IPv4 Address Depletion
IPv4地址耗尽
For decades, the world has known that IPv4 addresses would eventually be depleted. Technologies such as Classless Inter-Domain Routing (CIDR) and network address translation (NAT) helped delay the inevitable. However, on January 31, 2011, the top-level pool of Internet Assigned Numbers Authority (IANA) IPv4 addresses was officially exhausted. The American Registry for Internet Numbers (ARIN) is projected to run out of IPv4 addresses in the summer of 2015—a countdown is available here.
几十年来，众所周知，IPv4地址终将耗尽。像无类域间路由技术（CIDR）和网络地址转换（NAT）这样的技术推迟了IPv4地址不可避免的耗尽。然而，在2011年1月31日，互联网数字分配机构（IANA）顶层地址池IPv4地址正式耗尽。美国互联网号码注册机构（ARIN）IPv4地址将在2015年夏天耗尽，从这里查看倒计时。
IPv6 More Efficient than IPv4
IPv6比IPv4更高效
Aside from solving for the IPv4 depletion problem, IPv6 is more efficient than IPv4. For example, IPv6:
除了解决IPv4耗尽问题外，IPv6比IPv4更高效。举例如下，IPv6：
1.Avoids the need for network address translation (NAT)
1.避免了网络地址转换（NAT）的需要。
2.Provides faster routing through the network by using simplified headers
2.通过使用简化的报文头部在网络上提供更快的路由。
3.Prevents network fragmentation
3.防止网络碎片。
4.Avoids broadcasting for neighbor address resolution
4.相邻地址解析时避免使用广播
4G Deployment
4G开发
The fourth generation of mobile telecommunication technology (4G) is based on packet switching only. Due to the limited supply of IPv4 addresses, IPv6 support is required in order for 4G deployment to be scalable.
第四代移动通信技术（4G）是基于分组交换的。由于IPv4地址的供应有限，为了使4G部署具有可伸缩性，IPv6支持是必需的。
Multimedia Service Compatibility
多媒体服务的兼容性
IP Multimedia Core Network Subsystem (IMS) allows services such as multimedia SMS messaging and Voice over LTE (VoLTE) to be delivered over IP. The IMS used by some service providers is compatible with IPv6 only.
IP多媒体子系统（IMS）允许一些服务通过IP传输，如多媒体SMS消息和VoLTE。有些服务提供商使用IMS时仅支持IPv6。
Cost
成本
Service providers incur additional operational and administrative costs by continuing to support the legacy IPv4 network while the industry continues migrating to IPv6.
业界在向IPv6迁移的过程中，需要继续支持古老的IPv4网络，这使运营商产生了额外的操作和维护成本。
DNS64/NAT64 Transitional Workflow
DNS64/NAT64转换流程
To help slow the depletion of IPv4 addresses, NAT was implemented in many IPv4 networks. Although this solution worked temporarily, it proved costly and fragile. Today, as more clients are using IPv6, providers must now support both IPv4 and IPv6. This is a costly endeavor.
为了缓解IPv4地址的耗尽，许多IPv4网络采用NAT技术。尽管这种方案临时奏效，但是实践证明耗资巨大并且不够可靠。如今，随着越来越多的设备使用IPv6，运营商必须同时支持IPv4和IPv6，这种努力却是花费巨大的。
Figure 10-1 A cellular network that provides separate IPv4 and IPv6 connectivity
图 10-1 蜂窝移动网络分别提供IPv4和IPv6链接
Ideally, providers want to drop support for the IPv4 network. However, doing so prevents clients from accessing IPv4 servers, which represent a significant portion of the Internet. To solve this problem, most major network providers are implementing a DNS64/NAT64 transitional workflow. This is an IPv6-only network that continues to provide access to IPv4 content through translation.
理想情况下，运营商希望丢掉对IPv4的支持。然而，这么做会导致客户端无法访问基于IPv4的服务器，而IPv4的服务器依然是网络的重要组成部分。为了解决这个问题，大多数的网络供应商实现了一个叫DNS64/NAT64的转换流程。这是个纯IPv6网络，并通过转换也可继续访问IPv4的内容。
Figure 10-2 A cellular network that deploys an IPv6 network with DNS64 and NAT64
图 10-2 蜂窝移动网络用DNS64和NAT64来部署一个IPv6网络
In this type of workflow, the client sends DNS queries to a DNS64 server, which requests IPv6 addresses from the DNS server. When an IPv6 address is found, it’s passed back to the client immediately. However, when an IPv6 address isn’t found, the DNS64 server requests an IPv4 address instead. The DNS64 server then synthesizes an IPv6 address by prefixing the IPv4 address, and passes that back to the client. In this regard, the client always receives an IPv6-ready address. See Figure 10-3.
在这个流程中，如果客户端向DNS64服务器发起一个DNS查询，当DNS找到一个基于IPv6的地址后，立刻返回客户端。如果无法找到对应的IPv6地址，DNS64服务器将请求IPv4地址，然后DNS64服务器将IPv4作为前缀合成一个IPv6地址，并且将其返回给客户端。这样，客户端将总是获得一个IPv6目标地址，见图10-3。
Figure 10-3 DNS64 IPv4 to IPv6 translation process
图 10-3 DNS64 IPv4到IPv6转换过程
When the client sends a request to a server, any IPv6 packets destined for synthesized addresses are automatically routed by the network through a NAT64 gateway. The gateway performs the IPv6-to-IPv4 address and protocol translation for the request. It also performs the IPv4 to IPv6 translation for the response from the server. See Figure 10-4.
当客户端向服务端发送请求时，目标地址为合成后的IPv6地址会自动由NAT64网关路由过去。对于请求，网关作的是IPv6到IPv4的转换。同样的，对于服务器响应，网关作的是IPv4到IPv6的转换。见图10-4
图 10-4 DNS64/NAT64转化方案的流程
IPv6 and App Store Requirements
IPv6和App Store的要求
Compatibility with IPv6 DNS64/NAT64 networks will be an App Store submission requirement, so it is essential that apps ensure compatibility. The good news is that the majority of apps are already IPv6-compatible. For these apps, it’s still important to regularly test your app to watch for regressions. Apps that aren’t IPv6-compatible may encounter problems when operating on DNS64/NAT64 networks. Fortunately, it’s usually fairly simple to resolve these issues, as discussed throughout this chapter.
对IPv6 DNS64/NAT64网络的兼容性，将是App Store的提交时的必须条件，所以兼容对于app来说是相当重要的。好消息是，大多数app已经是IPv6兼容的了。对于这些app，进行定期的回归测试依旧是必要的。对于那些IPv6不兼容的应用在面对DNS64/NAT64网路时可能遇到麻烦。幸运的是，解决问题通常很简单，下面章节会讨论这个问题。
Common Barriers to Supporting IPv6
常见的阻碍IPv6支持的行为
Several situations can prevent an app from supporting IPv6. The sections that follow describe how to resolve these problems.
有几个导致应用无法支持IPv6的场景。本节描述如何解决这些问题。
1.IP address literals embedded in protocols. Many communications protocols, such as Session Initiation Protocol (SIP), File Transfer Protocol (FTP), WebSockets, and Peer-to-Peer Protocol (P2PP), include IP address literals in protocol messages. For example, theFTPparameter commandsDATA PORT
and PASSIVE exchange information that includes IP address literals. Similarly, IP address literals may appear in the values of SIP header fields, such asTo,From,Contact,Record-Route, andVia. See Use High-Level Networking Frameworks and Don’t Use IP Address Literals.
1.嵌入IP地址的协议。许多通信协议，像SIP,FTP,WebSockets
,P2PP，都可能在协议的报文中包含了IP地址。例如，FTP参数命令DATA PORT和PASSIVE的交换信息中包含了IP地址。类似的，IP地址值可能出现在SIP的头部，像To,FROM,Contact,Record-Route以及Via。参见Use High-Level Networking Frameworks和Don’t Use IP Address Literals
2.IP address literals embedded in configuration files. Configuration files often include IP address literals. See Don’t Use IP Address Literals.
2.配置文件中使用IP地址。参见Don’t Use IP Address Literals
3.Network preflighting. Many apps attempt to proactively check for an Internet connection or an active Wi-Fi connection by passing IP address literals to network reachability APIs. See Connect Without Preflight.
3.网络状态监测。许多app试图主动的监测网络连接和wifi连接，却将IP地址作为参数而调用网络可达性相关的API。参见Connect Without Preflight
4.Using low-level networking APIs. Some apps work directly with sockets and other raw network APIs such asgethostbyname
,gethostbyname2
, andinet_aton
. These APIs are prone to misuse or they only support IPv4—for example, resolving hostnames for theAF_INET
address family, rather than theAF_UNSPEC
address family. See Use High-Level Networking Frameworks.
4.使用底层网络接口。一些app直接使用socket和其他的低层次网络API，比如gethostbyname gethostbyname2和inet_aton。这些API很容易因为错误使用而仅支持IPv4。比如，域名解析时使用AF_INET地址簇，而不是AF_UNSPEC地址簇。参见Use High-Level Networking Frameworks
5.Using small address family storage containers. Some apps and networking libraries use address storage containers—such asuint32_t,in_addr, andsockaddr_in—that are 32 bits or smaller. See Use Appropriately Sized Storage Containers
5.使用了小的地址簇存储容器。一些app和网络库，使用了例如unit32
,in_addr,sockaddr_in这种32位或更小的容器来存储地址。参见Use Appropriately Sized Storage Containers
Ensuring IPv6 DNS64/NAT64 Compatibility
确保IPv6 DNS64/NAT64兼容性
Adhere to the following guidelines to ensure IPv6 DNS64/NAT64 compatibility in your app.
附上下面的指导来确保IPv6 DNS64/NAT64的兼容性。
Use High-Level Networking Frameworks
使用高层次的网络框架
Apps requiring networking can be built upon high-level networking frameworks or low-level POSIX socket APIs. In most cases, the high-level frameworks are sufficient. They are capable, easy to use, and less prone to common pitfalls than the low-level APIs.
app请求网络时，可以构建在高层次的网络框架上，也可以使用底层的POSIX兼容的socket接口。在多数情况下，相比底层接口，高层次的接口效率高一些，兼容性好，容易使用，不容易掉入通常的编程错误陷阱中。
Figure 10-5 Networking frameworks and API layers
图 10-5 网络框架和API层次
1.WebKit. This framework provides a set of classes for displaying web content in windows, and implements browser features such as following links, managing a back-forward list, and managing a history of pages recently visited. WebKit simplifies the complicated process of loading webpages—that is, asynchronously requesting web content from an HTTP server where the response may arrive incrementally, in random order, or partially due to network errors. For more information, see WebKit Framework Reference.
1.WebKit。此框架提供一系列的类用来在窗口上显示web内容，而且实现了浏览器特性，诸如：链接、前进后退管理、最近访问历史。WebKit将加载网页的流程简化了，包括异步地从HTTP服务器上请求网页内容，这些服务器响应的数据包可能一点点送达，也可能以随机的顺序到达，甚至可能由于网络错误收不全。详见WebKit Framework Reference
2.Cocoa URL loading system. This system is the easiest way to send and receive data over the network without providing an explicit IP address. Data is sent and received using one of several classes—such asNSURLSession,NSURLRequest, and NSURLConnection—that work withNSURL objects.NSURL objects let your app manipulate URLs and the resources they reference. Create anNSURL object by calling theinitWithString: method and passing it a URL specifier. Call thecheckResourceIsReachableAndReturnError:
method of theNSURL class to check the reachability of a host. For more information, see URL Session Programming Guide.
2.Cocoa URL loading system。这个系统用于简单地通过网络发送和接收数据，却不需要提供显示的IP地址。数据的发送和接收使用这几个类中的一个：NSURLSession NSURLRequest NSURLConnection
，这些类使用NSURL对象。NSURL对象允许你操作URL。创建一个NSURL对象时使用initWithString:方法，并传入一个指定的URL。调用NSURL类的checkResourceIsReachableAndReturnError:
方法检测目标主机的可达性。详见URL Session Programming Guide
3.CFNetwork. This Core Services framework provides a library of abstractions for network protocols, which makes it easy to perform a variety of network tasks such as working with BSD sockets, resolving DNS hosts, and working with HTTP/HTTPS. To target a host without an explicit IP address, call theCFHostCreateWithName
method. To open a pair of TCP sockets to the host, call theCFStreamCreatePairWithSocketToCFHost
method. For more information, see CFNetwork Concepts in CFNetwork Programming Guide.
3.CFNetwork。这个核心服务框架提供了一个抽象网络协议的库。这个库提供了大量易用的网络操作，比如BSD socket，DNS解析，处理HTTP/HTTPS。调动CFHostCreateWithName方法，避免显示的使用IP地址来标识主机。调用CFStreamCreatePairWithSocketToCFHost
与主机建立TCP链接。详见CFNetwork Programming Guide中的CFNetwork Concepts
If you do require the low-level socket APIs, follow the guidelines in RFC4038: Application Aspects of IPv6 Transition.
如果你需要使用低层次的socket接口，参看如下指导:RFC4038: Application Aspects of IPv6 Transition
Note: Getting Started with Networking, Internet, and Web and Networking Overview provide detailed information on networking frameworks and APIs.
注：Getting Started with Networking, Internet, and Web和Networking Overview提供详细的网络框架API的说明
Don’t Use IP Address Literals
不要使用IP地址
Make sure you aren’t passing IPv4 address literals in dot notation to APIs such asgetaddrinfo andSCNetworkReachabilityCreateWithName
. Instead, use high-level network frameworks and address-agnostic versions of APIs, such asgetaddrinfo andgetnameinfo, and pass them hostnames or fully qualified domain names (FQDNs). Seegetaddrinfo(3) Mac OS X Developer Tools Manual Page andgetnameinfo(3) Mac OS X Developer Tools Manual Page.
在许多API中请确保不再使用点分十进制表示的IPv4地址，例如getaddrinfo或SCNetworkReachabilityCreateWithName。取而代之，应该使用高层次网络框架和地址无关的API，例如在使用getaddrinfo和getnameinfo时，传入主机名或域名。详见：getaddrinfo(3) Mac OS X Developer Tools Manual Page 和 getnameinfo(3) Mac OS X Developer Tools Manual Page。
Note: In iOS 9 and OS X 10.11 and later, NSURLSession and CFNetwork automatically synthesize IPv6 addresses from IPv4 literals locally on devices operating on DNS64/NAT64 networks. However, you should still work to rid your code of IP address literals.
从IOS9和OSX10.11开始，NSURLSession和CFNetwork会在本地自动将IPv4的地址合成IPv6地址，便于与DNS64/NAT64通信。不过，你依旧不该使用IP地址串。
Connect Without Preflight
连接时无需网络预检
The Reachability APIs (see SCNetworkReachability Reference) are intended for diagnostic purposes after identifying a connectivity issue. Many apps incorrectly use these APIs to proactively check for an Internet connection by calling theSCNetworkReachabilityCreateWithAddress
method and passing it an IPv4 address of0.0.0.0, which indicates that there is a router on the network. However, the presence of a router doesn’t guarantee that an Internet connection exists. In general, avoid preflighting network reachability. Just try to make a connection and gracefully handle failures. If you must check for network availability, avoid calling theSCNetworkReachabilityCreateWithAddress method. Call theSCNetworkReachabilityCreateWithName method and pass it a hostname instead.
检测网络可达性的API(参见SCNetworkReachability Reference)用来在遇到连接异常时进行诊断。许多app错误的使用了API，它们往往通过调用SCNetworkReachabilityCreateWithAddress方法，并将IPv4地址0.0.0.0
作为参数传入，来不断检查网络连接，实际表示是否至少可达一个路由(which indicates that there is a router on the network)。然而，即使有这样的路由也不保证互联网的连接存在。总之，避免进行网络可达性的检测。只需要直接进行连接，并且优雅的处理失败的情况。如果你确实需要检测网络可用性，需避免使用SCNetworkReachabilityCreateWithAddress，而是调用SCNetworkReachabilityCreateWithName，并传入主机名。
Some apps also pass theSCNetworkReachabilityCreateWithAddress
method an IPv4 address of169.254.0.0, a self-assigned link-local address, to check for an active Wi-Fi connection. To check for Wi-Fi or cellular connectivity, look for the network reachability flag kSCNetworkReachabilityFlagsIsWWAN
instead.
有些app还在调用SCNetworkReachabilityCreateWithAddress的时候传入IPv4地址169.254.0.0
(一个自动分配的本地IP)，试图检测Wi-Fi连接。若要检测Wi-Fi或蜂窝移动网络连接，参见网络可达标识kSCNetworkReachabilityFlagsIsWWAN。
Use Appropriately Sized Storage Containers
使用合适的Storage Container大小
Use address storage containers, such as sockaddr_storage, that are large enough to store IPv6 addresses.
使用Storage Container结构，如sockaddr_storage，用以有足够的空间存放IPv6地址。
Check Source Code for IPv6 DNS64/NAT64 Incompatibilities
检查代码不兼容IPv6 DNS64/NAT64的代码
Check for and eliminate IPv4-specific APIs, such as:
inet_addr()
inet_aton()
inet_lnaof()
inet_makeaddr()
inet_netof()
inet_network()
inet_ntoa()
inet_ntoa_r()
bindresvport()
getipv4sourcefilter()
setipv4sourcefilter()
查找并删除IPv4相关的API，如：
inet_addr()
inet_aton()
inet_lnaof()
inet_makeaddr()
inet_netof()
inet_network()
inet_ntoa()
inet_ntoa_r()
bindresvport()
getipv4sourcefilter()
setipv4sourcefitler()
If your code handles IPv4 types, make sure the IPv6 equivalents are handled too.
如果你处理的IPv4的类型，确保同时处理对应的IPv6类型
Use System APIs to Synthesize IPv6 Addresses
使用系统API合成IPv6地址
If your app needs to connect to an IPv4-only server without a DNS hostname, use getaddrinfo to resolve the IPv4 address literal. If the current network interface doesn’t support IPv4, but supports IPv6, NAT64, and DNS64, performing this task will result in a synthesized IPv6 address.
如果你的app需要连接到仅支持IPv4的服务器，且不使用DNS域名解析，请使用getaddrinfo处理IPv4地址串(译注：getaddrinfo可通过传入一个IPv4或IPv6地址，得到一个sockaddr结构链表)。如果当前的网络接口不支持IPv4，仅支持IPv6,NAT64和DNS64，这样做可以得到一个合成的IPv6地址。
Listing 10-1 shows how to resolve an IPv4 literal using getaddrinfo. Assuming you have an IPv4 address stored in memory as four bytes (such as {192, 0, 2, 1}), this example code converts it to a string (such as "192.0.2.1"), uses getaddrinfo to synthesize an IPv6 address (such as a struct sockaddr_in6 containing the IPv6 address "64:ff9b::192.0.2.1") and tries to connect to that IPv6 address.
代码10-1展示了如何用getaddrinfo处理IPv4地址串。假设你内存中有一个4个字节的IPv4地址串(如{192,0,2,1})，这个示例代码将之转化为字符串(“192.0.2.1”)，使用getaddrinfo合成一个IPv6地址结构(struct sockaddr_in6包含IPv6地址串为”64:ff9b::192.0.2.1”),然后尝试连接到这个IPv6地址。
Listing 10-1 Using getaddrinfo to resolve an IPv4 address literal
代码 10-1 使用getaddrinfo处理IPv4地址串
include <sys/socket.h>
include <netdb.h>
include <arpa/inet.h>
include <err.h>
uint8_t ipv4[4] = {192, 0, 2, 1};
struct addrinfo hints, *res, *res0;
int error, s;
const char *cause = NULL;
char ipv4_str_buf[INET_ADDRSTRLEN] = { 0 };
const char *ipv4_str = inet_ntop(AF_INET, &ipv4, ipv4_str_buf, sizeof(ipv4_str_buf));
memset(&hints, 0, sizeof(hints));
hints.ai_family = PF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
hints.ai_flags = AI_DEFAULT;
error = getaddrinfo(ipv4_str, "http", &hints, &res0);
if (error) {
errx(1, "%s", gai_strerror(error));
/*NOTREACHED*/
}
s = -1;
for (res = res0; res; res = res->ai_next) {
s = socket(res->ai_family, res->ai_socktype,
res->ai_protocol);
if (s < 0) {
cause = "socket";
continue;
}
if (connect(s, res->ai_addr, res->ai_addrlen) < 0) {
cause = "connect";
close(s);
s = -1;
continue;
}
break; /* okay we got one */
}
if (s < 0) {
err(1, "%s", cause);
/*NOTREACHED*/
}
freeaddrinfo(res0);
Note: The ability to synthesize IPv6 addresses was added to getaddrinfo in iOS 9.2 and OS X 10.11.2. However, leveraging it does not break compatibility with older system versions. See getaddrinfo(3) Mac OS X Developer Tools Manual Page.
从IOS9.2和OSX10.11.2开始合成IPv6地址的功能才被加入到getaddrinfo。不过，这么用不会对旧的系统产生兼容性问题。参见getaddrinfo(3) Mac OS X Developer Tools Manual Page.
Test for IPv6 DNS64/NAT64 Compatibility Regularly
测试IPv6 DNS64/NAT64兼容性
The easiest way to test your app for IPv6 DNS64/NAT64 compatibility—which is the type of network most cellular carriers are deploying—is to set up a local IPv6 DNS64/NAT64 network with your Mac. You can then connect to this network from your other devices for testing purposes. See Figure 10-6.
大多数蜂窝移动供应商已经开始部署IPv6 DNS64/NAT64网络，测试这种网络最简单的的方法是用Mac建立一个本地的IPv6 DNS64/NAT64网络。你可以将其他设备链接到这个网络来测试。见图10-6
Important: IPv6 DNS64/NAT64 network setup options are available in OS X 10.11 and higher. In addition, a Mac-based IPv6 DNS64/NAT64 network is compatible with client devices that have implemented support for RFC6106: IPv6 Router Advertisement Options for DNS Configuration. If your test device is not an iOS or OS X device, make sure it supports this RFC. Note that, unlike DNS64/NAT64 workflows deployed by service providers, a Mac-based IPv6 DNS64/NAT64 always generates synthesized IPv6 addresses. Therefore, it does not provide access to IPv6-only servers outside of your local network, and may behave in unexpected ways if the server you are trying to reach claims to support IPv6, but doesn’t. See Limitations of Local Testing for more details.
提示：IPv6 DNS64/NAT64网络仅在OSX 10.11及更高版本上可以设置。除此之外，基于Mac来建立的IPv6 DNS64/NAT64网络仅与支持RFC6106: IPv6 Router Advertisement Options for DNS Configuration的客户端设备兼容。如果你的设备不是iOS或OSX设备，请确保它支持RFC。还需注意的是：不同于运营商提供的DNS64/NAT64网络，基于Mac系统的IPv6 DNS64/NAT64总是返回合成后的IPv6地址。因此，它不能用于访问你本地网络以外的纯IPv6网络。
Figure 10-6 A local Mac-based IPv6 DNS64/NAT64 network
图 10-6 本地的基于Mac的 IPv6 DNS64/NAT64 网络
To set up a local IPv6 Wi-Fi network using your Mac
使用你的Mac建立本地的IPv6 Wi-Fi网络
1.Make sure your Mac is connected to the Internet, but not through Wi-Fi.
1.确保你的Mac连接到互联网，但不是通过Wi-Fi
2.Launch System Preferences from your Dock, LaunchPad, or the Apple menu.
2.启动System Preferences
3.Press the Option key and click Sharing. Don’t release the Option key yet.
3.按住Option键(标准键盘是Alt键)点击Sharing，不要放开Option键。
Figure 10-7 Opening Sharing preferences
图 10-7 打开Sharing preferences
4.Select Internet Sharing in the list of sharing services.
4.在共享列表中选择Internet Sharing
Figure 10-8 Configuring Internet sharing
图 10-8 配置Internet Sharing
5.Release the Option key.
5.放开Option键
6.Select the Create NAT64 Network checkbox.
6.勾选Create NAT64 Network复选框
Figure 10-9 Enabling a local IPv6 NAT64 network
图 10-9 启用一个本地IPv6 NAT64网络
7.Choose the network interface that provides your Internet connection, such as Thunderbolt Ethernet.
7.选择你用于互联连接的网络接口，例如蓝牙局域网(译者注：通常这里mac用以太网连接互联网，很少有用蓝牙的)
Figure 10-10 Choosing a network interface to share
图 10-10 选择共享的网络接口
8.Select the Wi-Fi checkbox.
选择Wi-Fi复选框
Figure 10-11 Enabling sharing over Wi-Fi
图 10-11 通过Wi-Fi开启共享
9.Click Wi-Fi Options, and configure the network name and security options for your network.
9.点击Wi-Fi Options，配置你网络的网络名和安全选项
Figure 10-12 Accessing Wi-Fi network options
图 10-12 勾选Wi-Fi网络选项
Figure 10-13 Setting up local Wi-Fi network options
图 10-13 设置本地Wi-Fi网络选项
10.Select the Internet Sharing checkbox to enable your local network.
10.勾选Internet Sharing复选框启动你的本地网络
Figure 10-14 Enabling Internet sharing
图 10-14 启动网络共享
11.When prompted to confirm you want to begin sharing, click Start.
11.当弹出确认是否开启共享时，点击Start
Figure 10-15 Starting Internet sharing
图 10-15 开启网络共享
Once sharing is active, you should see a green status light and a label that says Internet Sharing: On. In the Wi-Fi menu, you will also see a small, faint arrow pointing up, indicating that Internet Sharing is enabled. You now have an IPv6 NAT64 network and can connect to it from other devices in order to test your app.
一旦共享启动后，你应该可以看到一个绿色的状态指示灯和一段话说明共享已开启。在Wi-Fi菜单中，你同样将看到一个小的向上的箭头，表示网络共享已经开启。现在你拥有了一个IPv6 NAT64的网络，其他设备可以连接这个网络来测试app。
Figure 10-16 Internet sharing indicator
图 10-16 网络共享指示
Important: To ensure that testing takes place strictly on the local IPv6 network, make sure your test devices don’t have other active network interfaces. For example, if you are testing with an iOS device, make sure cellular service is disabled so you are only testing over Wi-Fi.
重要提示：确保测试严格地在本地IPv6网络上进行，确保测试设备没有其他活动的网络接口。例如，如果您正在测试iOS设备，请确保禁用蜂窝服务，这样您只需通过Wi-Fi进行测试。
Limitations of Local Testing
本地测试的局限性
A Mac-based IPv6 DNS64/NAT64 network is a useful tool for testing your app in an IPv6 environment. However, because it always generates synthesized IPv6 addresses and transmits data on the WAN side using IPv4, it’s not an exact replica of the networks supplied by service providers. These networks (as well as the one used during App Review) do allow for direct IPv6-to-IPv6 connectivity. If your server is misconfigured, this might result in your app behaving differently in regular use or during review than it does in your local testing. It might even result in an App Review failure that is hard to reproduce in your own environment.
基于MAC的IPv6 DNS64/NAT64网络是在IPv6环境中测试你的应用程序的一个有用的工具。然而，由于它总是使用IPv4生成合成的IPv6地址并在WAN侧传输数据，所以它不是服务提供者提供的网络的精确副本。这些网络（以及在应用程序审查用）不允许直接ipv6-to-ipv6连接。如果你的服务器配置错误，这可能会导致您的应用程序的行为不同，经常使用或评审中比在本地测试。它甚至可能导致在您自己的环境中很难重现的应用程序审查失败。
In particular, you may run into trouble if your server claims to support IPv6, but in practice does not. In this case, during your initial testing, your app appears to be communicating with your server via an IPv6 path, and thus behaves properly. However, your test network is actually translating the IPv6 traffic that your app generates to IPv4 traffic on the WAN. Therefore, you’re actually exercising your server’s IPv4 data path. Later, during App Review (or in the real world), the app operates identically, but the network makes a direct IPv6 connection to the server. If your server fails to respond properly to IPv6 traffic, your app fails to operate as expected, and might fail App Review.
特别地，如果您的服务器声称支持IPv6，但实际上并没有，您可能会遇到麻烦。在这种情况下，在您的初始测试期间，您的应用程序似乎通过IPv6路径与服务器通信，从而正确地运行。然而，您的测试网络实际上是将您的应用程序生成的IPv6流量转换为WAN上的IPv4流量。因此，实际上您正在运行服务器的IPv4数据路径。后来，在应用程序审查（或在现实世界中），应用程序运行相同，但网络直接连接到服务器的IPv6连接。如果您的服务器不能正确地响应IPv6流量，您的应用程序不能按预期运行，并且可能会失败应用程序审查。
To avoid this, in addition to using a Mac-based IPv6 DNS64/NAT64 test network to validate your app, independently verify that your server is working properly as an IPv6 server. For example, make sure that the server:
为了避免这种情况，除了使用基于MAC的IPv6试验网的处理/ nat64验证您的应用程序，还要独立地验证您的服务器作为一个IPv6服务器可以正常工作。例如，确保服务器：
1.Has the correct DNS information. In addition to examining the server itself, you can use the command line tool dig(1) from your Mac to see how server reports its AAAA record.
1.具有正确的DNS信息。除了检测服务器，您还可以使用命令行工具dig在你的Mac上看看服务器的AAAA记录报告。
2.Is actually listening on IPv6. Use a tool like ipv6-test.com to test a web server (HTTP or HTTPS). For other protocols, you’ll need to verify this from a native IPv6 network.
2.实际地监听IPv6。使用工具如 IPv6试验网测试一个Web服务器（HTTP或HTTPS）。对于其他协议，您需要从本地IPv6网络验证这一点。
3.Responds properly to IPv6 requests.If you have access, look at the server logs to verify that IPv6 traffic is being handled properly. If not, you’ll need to test from a native IPv6 network.
3.正确地响应IPv6请求。如果您有访问权限，请查看服务器日志以验证IPv6流量是否被正确处理。如果没有，则需要从本地IPv6网络进行测试。
