1. 程式人生 > >IPV6 官方文件 解決ipv6 的問題

IPV6 官方文件 解決ipv6 的問題

支援IPv6 DNS64 / NAT64網路

隨著IPv4地址池耗盡即將來臨,企業和蜂窩提供商越來越多地部署IPv6 DNS64和NAT64網路。DNS64 / NAT64網路是一個僅IPv6網路,通過翻譯繼續提供對IPv4內容的訪問。根據應用程式的性質,轉換具有不同的含義:

  • 如果您正在使用高階網路API(如CFNetwork框架)編寫客戶端應用程式,並按名稱進行連線,則不需要為應用程式更改任何內容以使用IPv6地址。如果你不是通過名字連線,你可能應該是。請參閱以瞭解如何操作。有關CFNetwork的資訊,請參閱“ 。

  • 如果您正在編寫伺服器端應用程式或其他低階網路應用程式,則需要確保您的套接字程式碼在IPv4地址和IPv6地址之間正常工作。參見。

什麼是推動IPv6採用

主要的網路服務提供商,包括美國的主要蜂窩運營商正在積極推廣和部署IPv6。這是由於各種因素。

注意:  世界IPv6釋出是一個在全球範圍內跟蹤部署活動的組織。要檢視最近的趨勢,請訪問。

IPv4地址耗盡

數十年來,世界已經知道IPv4地址最終將耗盡。諸如無類別域間路由(CIDR)和網路地址轉換(NAT)等技術有助於延遲不可避免。然而,2011年1月31日,網際網路號碼分配機構(IANA)IPv4地址的頂級池正式耗盡。美國網際網路號碼註冊機構(ARIN)預計在2015年夏季將會用盡IPv4地址 - 這裡提供倒計時。

IPv6比IPv4更有效率

除了解決IPv4耗盡問題外,IPv6比IPv4更有效率。例如,IPv6:

  • 避免需要網路地址轉換(NAT)

  • 通過使用簡化的標頭提供更快的通過網路的路由

  • 防止網路破碎

  • 避免廣播用於鄰居地址解析

4G部署

第四代移動通訊技術(4G)僅基於分組交換。由於IPv4地址的供應有限,需要IPv6支援,以便4G部署可擴充套件。

多媒體服務相容性

IP多媒體核心網路子系統(IMS)允許多媒體簡訊和LTE語音(VoLTE)等服務通過IP傳送。一些服務提供商使用的IMS僅與IPv6相容。

成本

服務提供商通過繼續支援傳統IPv4網路,同時業界繼續遷移到IPv6,從而帶來額外的運營和管理成本。

DNS64 / NAT64過渡工作流程

為了減緩IPv4地址的耗盡,在許多IPv4網路中實現了NAT。雖然這個解決方案暫時工作,但它證明是昂貴和脆弱的。今天,隨著更多的客戶端正在使用IPv6,供應商現在必須支援IPv4和IPv6。這是一項昂貴的工作。

圖10-1   提供單獨的IPv4和IPv6連線的蜂窩網路

理想情況下,提供商希望放棄對IPv4網路的支援。但是,這樣做可以防止客戶端訪問代表網際網路重要部分的IPv4伺服器。為了解決這個問題,大多數主要的網路提供商正在實施一個DNS64 / NAT64過渡工作流程。這是一個僅IPv6網路,通過翻譯繼續提供對IPv4內容的訪問。

圖10-2   使用DNS64和NAT64部署IPv6網路的蜂窩網路

在這種型別的工作流程中,客戶端向DNS64伺服器傳送DNS查詢,DNS64伺服器從DNS伺服器請求IPv6地址。當找到一個IPv6地址時,它立即被傳回給客戶端。但是,當未找到IPv6地址時,DNS64伺服器會請求IPv4地址。然後,DNS64伺服器通過在IPv4地址字首來合成IPv6地址,並將其傳遞給客戶端。在這方面,客戶端始終接收到IPv6就緒地址。參見圖10-3

圖10-3   DNS64 IPv4到IPv6的轉換過程

當客戶端向伺服器傳送請求時,將通過NAT64閘道器自動路由目的地為合成地址的任何IPv6資料包。閘道器對請求執行IPv6到IPv4地址和協議轉換。它還對伺服器的響應執行IPv4到IPv6的轉換。參見圖10-4

圖10-4   DNS64 / NAT64過渡解決方案的工作流程

IPv6和App Store要求

與IPv6 DNS64 / NAT64網路的相容性將成為App Store提交的要求,因此應用程式必須確保相容性。好訊息是,大多數應用程式已經是IPv6相容的。對於這些應用程式,定期測試應用程式以觀察迴歸仍然很重要。不相容IPv6的應用程式在DNS64 / NAT64網路上執行時可能會遇到問題。幸運的是,如本章所討論的那樣,解決這些問題通常很簡單。

支援IPv6的常見障礙

幾種情況可能會阻止應用程式支援IPv6。以下部分介紹如何解決這些問題。

  • 協議中嵌入的IP地址文字。許多通訊協議,例如會話發起協議(SIP),檔案傳輸協議(FTP),WebSockets和對等協議(P2PP),包括協議訊息中的IP地址文字。例如,FTP引數命令DATA PORTPASSIVE交換包含IP地址文字的資訊。類似地,IP地址文字可能出現在SIP報頭欄位,例如的值ToFromContactRecord-Route,和Via。請參閱和。

  • 嵌入在配置檔案中的IP地址文字。配置檔案通常包括IP地址文字。請參閱。

  • 網路預檢。許多應用程式嘗試通過將IP地址文字傳遞到網路可達性API來主動檢查Internet連線或活動的Wi-Fi連線。請參閱。

  • 使用低階網路API。有些應用與插座等原始網路API,如直接工作gethostbynamegethostbyname2inet_aton。這些API容易被濫用,或者它們僅支援IPv4,例如,解析AF_INET地址族的主機名,而不是AF_UNSPEC地址族。請參閱。

  • 使用小地址家庭儲存容器。一些應用程式和網路庫使用地址儲存容器-如uint32_tin_addr,和sockaddr_in-即是32位或更小。請參閱。

確保IPv6 DNS64 / NAT64相容性

遵守以下準則,以確保您的應用程式中的IPv6 DNS64 / NAT64相容性。

使用高階網路框架

需要聯網的應用程式可以建立在高階網路框架或低階POSIX套接字API上。在大多數情況下,高階框架就足夠了。它們具有能力,易於使用,並且不如低階API容易出現常見的陷阱。

圖10-5   網路框架和API層
  • WebKit的。該框架提供了一組用於在Windows中顯示Web內容的類,並且實現諸如以下連結之類的瀏覽器功能,管理後退列表以及管理最近訪問的頁面的歷史。WebKit簡化了載入網頁的複雜過程,即從HTTP伺服器非同步請求Web內容,響應可以按照隨機順序遞增執行,或部分由於網路錯誤。有關更多資訊,請參閱。

  • 可可URL載入系統。該系統是通過網路傳送和接收資料而不提供顯式IP地址的最簡單方法。資料被髮送並且使用幾類-如之一接收NSURLSessionNSURLRequest以及NSURLConnection與工作-即NSURL物體。NSURL物件讓你的應用程式操縱URL和他們引用的資源。NSURL通過呼叫該方法並傳遞一個URL說明符來建立一個物件。呼叫類的方法NSURL來檢查主機的可達性。有關更多資訊,請參閱。

  • CFNetwork的。該核心服務框架提供了一個網路協議抽象庫,可以輕鬆執行各種網路任務,例如使用BSD套接字,解析DNS主機以及使用HTTP / HTTPS。要定位沒有顯式IP地址的主機,請呼叫該方法。要開啟一對TCP套接字到主機,請呼叫該方法。欲瞭解更多資訊,請參見在。

注意: 和網路入門概述提供有關網路框架和API的詳細資訊。

不要使用IP地址文字

確保你不及格的IPv4地址文字的點符號API,如getaddrinfo和。相反,使用高階網路框架和地址不可知版本的API,例如getaddrinfogetnameinfo,並傳遞他們的主機名或完全限定域名(FQDN)。看到getaddrinfo(3) Mac OS X Developer Tools Manual Pagegetnameinfo(3) Mac OS X Developer Tools Manual Page

注意:  在iOS 9和OS X 10.11及更高版本中,NSURLSessionCFNetwork在DNS64 / NAT64網路上執行的裝置上本地從IPv4文字自動合成IPv6地址。但是,您仍然應該刪除IP地址文字的程式碼。

連線沒有預檢

使用適當尺寸的儲存容器

使用sockaddr_storage足夠大的地址儲存容器來儲存IPv6地址。

檢查IPv6 DNS64 / NAT64不相容的原始碼

檢查並消除IPv4特定的API,例如:

  • inet_addr()

  • inet_aton()

  • inet_lnaof()

  • inet_makeaddr()

  • inet_netof()

  • inet_network()

  • inet_ntoa()

  • inet_ntoa_r()

  • bindresvport()

  • getipv4sourcefilter()

  • setipv4sourcefilter()

如果您的程式碼處理IPv4型別,請確保處理IPv6等價物。

IPv4的

IPv6的

AF_INET

AF_INET6

PF_INET

PF_INET6

struct in_addr

struct in_addr6

struct sockaddr_in

struct sockaddr_in6

kDNSServiceProtocol_IPv4

kDNSServiceProtocol_IPv6

使用系統API來合成IPv6地址

如果您的應用程式需要連線到沒有DNS主機名的純IPv4伺服器,請使用此方法getaddrinfo來解析IPv4地址字面值。如果當前網路介面不支援IPv4,但是支援IPv6,NAT64和DNS64,則執行此任務將導致合成的IPv6地址。

清單10-1顯示瞭如何解決使用的IPv4文字getaddrinfo。假設您將IPv4地址儲存在四個位元組(如{192, 0, 2, 1})中,則此示例程式碼將其轉換為字串(例如"192.0.2.1"),用於getaddrinfo合成IPv6地址(例如struct sockaddr_in6包含IPv6地址"64:ff9b::192.0.2.1"),並嘗試連線到那個IPv6地址。

清單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提示,* 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));
        /*還沒到*/
    }
    s = -1;
    for(res = res0; res; res = res-> ai_next){
        s = socket(res-> ai_family,res-> ai_socktype,
                   水庫> ai_protocol);
        if(s <0){
            cause =“socket”;
            繼續;
        }
        if(connect(s,res-> ai_addr,res-> ai_addrlen)<0){
            cause =“connect”;
            關閉(多個);
            s = -1;
            繼續;
        }
        打破; / *好吧,我們有一個* /
    }
    if(s <0){
        err(1,“%s”,原因);
        /*還沒到*/
    }
    freeaddrinfo(RES0);

注意:getaddrinfo在iOS 9.2和OS X 10.11.2  中添加了合成IPv6地址的功能。但是,利用它不會破壞與舊系統版本的相容性。見getaddrinfo(3) Mac OS X Developer Tools Manual Page

測試IPv6 DNS64 / NAT64相容性

測試您的應用程式的最簡單方法是IPv6 DNS64 / NAT64相容性 - 這是大多數蜂窩運營商正在部署的網路型別 - 是使用Mac設定本地IPv6 DNS64 / NAT64網路。然後,您可以從其他裝置連線到此網路進行測試。參見圖10-6

重要資訊:  IPv6 DNS64 / NAT64網路設定選項在OS X 10.11及更高版本中可用。此外,基於Mac的IPv6 DNS64 / NAT64網路與實施了對RFC6106的支援的客戶端裝置。如果您的測試裝置不是iOS或OS X裝置,請確保它支援此RFC。請注意,與服務提供商部署的DNS64 / NAT64工作流不同,基於Mac的IPv6 DNS64 / NAT64始終生成合成的IPv6地址。因此,它不提供對本地網路之外的僅限IPv6的伺服器的訪問,如果您嘗試提供支援IPv6的伺服器但不支援IPv6,則可能會出現意外的方式。有關詳細資訊,請參閱本地測試的限制。

圖10-6   本地基於Mac的IPv6 DNS64 / NAT64網路

使用Mac設定本地IPv6 Wi-Fi網路

  1. 確保您的Mac連線到網際網路,但不能通過Wi-Fi

  2. 從Dock,LaunchPad或Apple選單啟動系統偏好設定。

  3. 按Option鍵,然後單擊共享。不要釋放Option鍵。

    圖10-7   開啟共享首選項
  4. 在共享服務列表中選擇Internet共享。

    圖10-8   配置Internet共享
  5. 釋放Option鍵。

  6. 選中“建立NAT64網路”複選框。

    圖10-9   使能本地IPv6 NAT64網路
  7. 選擇提供Internet連線的網路介面,如Thunderbolt乙太網。

    圖10-10   選擇要共享的網路介面
  8. 選中Wi-Fi複選框。

    圖10-11   啟用Wi-Fi上的共享
  9. 單擊Wi-Fi選項,並配置網路的網路名稱和安全選項。

    圖10-12   訪問Wi-Fi網路選項圖10-13   設定本地Wi-Fi網路選項
  10. 選中“Internet共享”複選框以啟用本地網路。

    圖10-14   啟用Internet共享
  11. 當系統提示您確認要開始共享時,單擊開始。

    圖10-15   啟動Internet共享

共享啟用後,您應該看到一個綠色狀態指示燈和一個標籤,表示Internet Sharing:On。在Wi-Fi選單中,您還將看到一個小而微弱的箭頭向上,表示啟用了Internet共享。您現在有一個IPv6 NAT64網路,可以從其他裝置連線到它,以測試您的應用程式。

圖10-16   網際網路共享指標

重要提示:  要確保測試嚴格在本地IPv6網路上進行,請確保測試裝置沒有其他活動的網路介面。例如,如果您正在使用iOS裝置進行測試,請確保移動服務已禁用,因此您只能通過Wi-Fi進行測試。

區域性測試的侷限性

基於Mac的IPv6 DNS64 / NAT64網路是在IPv6環境中測試應用程式的有用工具。然而,由於它總是生成合成的IPv6地址並使用IPv4在WAN側傳輸資料,因此它不是由服務提供商提供的網路的精確副本。這些網路(以及在App Review中使用的網路)確實允許直接的IPv6到IPv6連線。如果您的伺服器配置錯誤,這可能會導致您的應用程式在常規使用或審查期間的行為與本地測試中的行為不同。甚至可能導致在您自己的環境中難以重現的App Review失敗。

特別是,如果您的伺服器聲稱支援IPv6,您可能遇到麻煩,但實際上並不支援。在這種情況下,在初始測試期間,您的應用程式似乎通過IPv6路徑與您的伺服器進行通訊,從而正常執行。但是,您的測試網路實際上是將您的應用程式生成的IPv6流量轉換為WAN上的IPv4流量。因此,您實際上正在執行伺服器的IPv4資料路徑。後來在應用程式審查(或現實世界)期間,應用程式執行相同,但是網路直接連線到伺服器的IPv6。如果您的伺服器無法正確響應IPv6流量,您的應用程式無法按預期執行,並且可能會失敗App Review。

為了避免這種情況,除了使用基於Mac的IPv6 DNS64 / NAT64測試網路驗證您的應用程式外,還可以獨立驗證您的伺服器是否正常工作為IPv6伺服器。例如,確保伺服器:

  • 具有正確的DNS資訊。除了檢查伺服器本身之外,您還可以使用dig(1)Mac上的命令列工具檢視伺服器如何報告其AAAA記錄。

  • 實際上是在聽IPv6。使用像這樣的工具測試Web伺服器(HTTP或HTTPS)。對於其他協議,您需要從本機IPv6網路進行驗證。

  • 正確響應IPv6請求。如果您有訪問許可權,請檢視伺服器日誌以驗證是否正確處理IPv6流量。如果沒有,您將需要從本機IPv6網路進行測試。

資源

有關實施網路的更多資訊,請參閱:

有關IPv6轉換的更多資訊,請參閱:

有關轉換到IPv6時遇到的技術問題,請參閱: