參考:
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地址池的枯竭迫在眉睫,企業(yè)和手機運營商們正在增加對IPv6 DNS64 和 NAT64網絡的部署窃款。DNS64/NAT64網絡是一個通過轉化的方式持續(xù)提供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開發(fā)
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多媒體子系統(tǒng)(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.
業(yè)界在向IPv6遷移的過程中狞甚,需要繼續(xù)支持古老的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網絡喧伞,并通過轉換也可繼續(xù)訪問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服務器發(fā)起一個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.
當客戶端向服務端發(fā)送請求時哲思,目標地址為合成后的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網路時可能遇到麻煩镇草。幸運的是眶痰,解決問題通常很簡單,下面章節(jié)會討論這個問題梯啤。
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的場景凛驮。本節(jié)描述如何解決這些問題。
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.網絡狀態(tài)監(jiān)測。許多app試圖主動的監(jiān)測網絡連接和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。這個系統(tǒng)用于簡單地通過網絡發(fā)送和接收數據号杏,卻不需要提供顯示的IP地址婴氮。數據的發(fā)送和接收使用這幾個類中的一個:NSURLSession NSURLRequest NSURLConnection
,這些類使用NSURL對象盾致。NSURL對象允許你操作URL主经。創(chuàng)建一個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)衷畦。然而,即使有這樣的路由也不保證互聯網的連接存在知牌■伲總之,避免進行網絡可達性的檢測送爸。只需要直接進行連接,并且優(yōu)雅的處理失敗的情況暖释。如果你確實需要檢測網絡可用性袭厂,需避免使用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
使用系統(tǒng)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個字節(jié)的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情萤。不過鸭蛙,這么用不會對舊的系統(tǒng)產生兼容性問題。參見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系統(tǒng)的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.
一旦共享啟動后飒货,你應該可以看到一個綠色的狀態(tài)指示燈和一段話說明共享已開啟魄衅。在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環(huán)境中測試你的應用程序的一個有用的工具草巡。然而,由于它總是使用IPv4生成合成的IPv6地址并在WAN側傳輸數據型酥,所以它不是服務提供者提供的網絡的精確副本山憨。這些網絡(以及在應用程序審查用)不允許直接ipv6-to-ipv6連接。如果你的服務器配置錯誤弥喉,這可能會導致您的應用程序的行為不同郁竟,經常使用或評審中比在本地測試。它甚至可能導致在您自己的環(huán)境中很難重現的應用程序審查失敗由境。
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.實際地監(jiān)聽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網絡進行測試。