李 實

（中國電信股份有限公司上海研究院 上海200122）

1 引言

基于IPv4的互聯(lián)網(wǎng)是由美國軍方的網(wǎng)絡發(fā)展起來的，采用了32 bit的地址，總地址空間為232≈42億個。但后來IPv4網(wǎng)絡迅速擴展到全球，再加上一些比較奢侈的設計浪費了較多的地址，地址資源早已經(jīng)枯竭?；ヂ?lián)網(wǎng)迫切需要一個新的方案來解決地址不足的問題。

2 現(xiàn)有解決方案特點及前景

2.1 IPv6

早在20世紀90年代初期，互聯(lián)網(wǎng)工程任務組（IETF）就已經(jīng)預見到這個問題并著手下一代互聯(lián)網(wǎng)協(xié)議（IP-the next generation，IPng）的制定工作。IETF在RFC1550里進行了征求新的IP（互聯(lián)網(wǎng)協(xié)議）的呼吁，并公布了新的協(xié)議需實現(xiàn)的主要目標：

·支持幾乎無限大的地址空間；

·減小路由表的大??；

·簡化協(xié)議，使路由器能更快地處理數(shù)據(jù)分組；

·提供更好的安全性，實現(xiàn)IP級的安全；

·支持多種服務類型，尤其是實時業(yè)務；

·支持多目傳送，即支持多播；

·允許主機不更改地址實現(xiàn)異地漫游；

·支持未來協(xié)議的演變；

·允許新舊協(xié)議共存一段時間；

·支持未來協(xié)議的演變以適應底層網(wǎng)絡環(huán)境或上層應用環(huán)境的變化；

·支持自動地址配置；

·協(xié)議必須能擴展，它必須能通過擴展來滿足將來互聯(lián)網(wǎng)的服務需求；擴展必須是不需要網(wǎng)絡軟件升級就可實現(xiàn)的；

·協(xié)議必須支持可移動主機和網(wǎng)絡。

作為對RFC1550的響應，包括SIPP等在內(nèi)的若干IPng提案被提交到IETF。最終IETF決定以SIPP作為IPng的基礎，同時把地址長度由64 bit增加到128 bit。新的IP稱為IPv6。其版本是在1994年由IETF批準的RFC1752，在RFC1884中介紹了IPv6的地址結構（現(xiàn)在RFC1884已經(jīng)被RFC2373所替代）。

2.1.1 技術特點

IETF在RFC1550中提出了若干要求，但不幸的是，其中偏偏沒有對兼容性的要求。最終選定的IPng方案——IPv6，也確實與IPv4不兼容。IPv4的地址空間約為42億個，當這個網(wǎng)絡因為地址不足而要升級的時候，可以想象網(wǎng)絡中已經(jīng)有了太多的IPv4終端和網(wǎng)絡設備。兼容性的缺失導致全球網(wǎng)絡升級變得極端復雜與昂貴。

2.1.2 推廣面臨的困難

雖然用IPv6來解決IPv4地址不足的問題儼然已是眾望所歸，但IPv6從1994年誕生至今已經(jīng)過去了20年，使用范圍仍然局限于少數(shù)的教育機構和實驗場所，沒有進行大規(guī)模的商用。究其原因，還是因為IPv6不兼容IPv4所致。

對網(wǎng)絡而言，初期IPv4地址很多，用戶很少，沒有升級的必要；后期IPv4地址基本耗竭，但同時已經(jīng)有太多的IPv4用戶。網(wǎng)絡需要升級以允許更多新用戶加入，但需要首先解決數(shù)以億計的既有用戶的升級問題。實際上，由于IPv6與IPv4不互通，IPv6網(wǎng)內(nèi)可以訪問的資源極其貧乏，SP和用戶并沒有加入IPv6網(wǎng)絡的愿望。

2.1.2.1 運營商的困境

（1）由于西方國家在IT產(chǎn)業(yè)上的領先，西方國家的IP地址資源相對豐富，不急于升級到IPv6；非西方國家因地址相對匱乏，更有升級的緊迫性。但是同樣由于西方在IT產(chǎn)業(yè)上的領先優(yōu)勢，非西方國家又必須保持訪問西方國家IPv4網(wǎng)絡中的資源的能力。這就導致非西方國家的運營商即使在升級到IPv6之后也必須長期向公眾提供IPv4接入服務（無論運營商自身網(wǎng)絡運行在何種協(xié)議棧上）而不可能斷然關閉IPv4服務。

（2）由于IPv4地址緊張，長期以來運營商給每個寬帶公眾用戶只分配1個IP地址，而用戶又確實存在多終端接入的需求，這導致用戶自備NAT型家庭網(wǎng)關成為普遍現(xiàn)象，而這些家庭網(wǎng)關又普遍不支持IPv6。如果運營商希望用戶默認使用IPv6網(wǎng)絡，將不得不為用戶提供支持IPv6的家庭網(wǎng)關。否則，對用戶而言，既然運營商仍然支持IPv4接入，那就繼續(xù)使用原有家庭網(wǎng)關和IPv4吧！以中國為例：到目前為止中國已經(jīng)有了約2億戶寬帶用戶，升級到IPv6需要為所有用戶更換家庭網(wǎng)關。按保守價格每只150元計算，光家庭網(wǎng)關就要花費300億元，代價極為巨大。同時，由于需要上門為用戶更換設備，工程量也是巨大的。而這些被換下的用戶家庭網(wǎng)關將很難再有新的用處，又形成了巨大的浪費。

（3）升級到IPv6需要大規(guī)模地升級網(wǎng)絡中的設備（多數(shù)是基于硬件的替換），而這個行為客觀上只是替換了目前運行良好的IPv4設備。運營商投資巨大卻無實際回報，從企業(yè)運營的角度來說不是個理性的行為。所以運營商更傾向于深入挖掘已有IPv4設備的潛力而沒有升級到IPv6網(wǎng)絡的積極性。

（4）就過渡方案而言，兼容性太差會嚴重影響網(wǎng)絡的正常使用，兼容性太好又會讓用戶感覺沒有必要切換到IPv6網(wǎng)絡，從而導致IPv6遲遲不能成為主流。目前主流運營商已經(jīng)計劃通過NAT444、DS-Lite和LAFT等技術來過渡。這些技術都包括了運營商給用戶分配私網(wǎng)IPv4地址+NAT，在解決IPv4接入的同時又導致網(wǎng)絡進一步向NAT結構的IPv4網(wǎng)絡深度深化了。同時一些主流過渡方案也要求運營商對用戶的家庭網(wǎng)關擁有最高控制權，這也導致必須由運營商來負責給用戶提供家庭網(wǎng)關。

（5）運營商需要為過渡準備若干軟硬件設備，而這些設備僅僅是在過渡過程中臨時使用的，在過渡完成后將沒有任何價值，也形成巨大的浪費。

2.1.2.2 SP的困境

IPv4網(wǎng)絡采用32 bit的地址標識主機，而IPv6網(wǎng)絡采用128 bit的地址標識。對于很多在應用層標識主機的應用而言，如果要升級到IPv6，必須修改應用層的主機標識。而要做到這一點，往往意味著軟件甚至在應用層面也必須做出較大的調(diào)整。事實上這是所有在IP網(wǎng)絡上提供較大范圍業(yè)務的組織的困境，包括通常意義上的互聯(lián)網(wǎng)SP、擁有復雜內(nèi)部業(yè)務網(wǎng)絡的大型企業(yè)以及擁有諸多業(yè)務平臺的運營商。對他們而言，這個升級實際上也只是替代了目前運營良好的業(yè)務系統(tǒng)，并沒有功能的增強或者性能的提升，也是投入巨大但沒有實際回報的行為。

另一方面，既然運營商仍然支持用戶的IPv4接入，即使分配給用戶的是私網(wǎng)地址并且需要經(jīng)過NAT才能訪問SP提供的業(yè)務，經(jīng)過這么多年的發(fā)展，對大多數(shù)業(yè)務而言，這種模式也已經(jīng)工作得足夠好。也就是說，業(yè)務本身不要求SP升級。

如果SP不升級，那么將來還可能面臨公網(wǎng)IPv4地址不足導致服務器無法開通的問題?？紤]到目前有大量公網(wǎng)IPv4地址是動態(tài)分配給寬帶用戶的，隨著分配私網(wǎng)地址的過渡方案的逐漸成熟，收回一些公網(wǎng)地址給服務器使用將是很容易做到的事。那么地址不足的問題對服務器而言也不復存在了。既然如此，為什么還要升級到IPv6呢？

2.1.2.3 寬帶用戶的困境

對寬帶用戶而言，升級不僅沒好處，反而可能有諸多不便之處：需要追加投資、升級操作系統(tǒng)、更換家庭網(wǎng)關等。但因為網(wǎng)絡轉(zhuǎn)發(fā)IPv6報文效率偏低以及IPv6網(wǎng)絡上資源不足等原因，用戶得到的卻是網(wǎng)絡體驗的下降。而如果什么也不做，現(xiàn)有的網(wǎng)絡已經(jīng)能夠很好地滿足需要。既然如此，為什么要升級到IPv6呢？

2.1.3 小結

概言之，對運營商、SP和寬帶用戶而言，升級到IPv6帶來的感受都是負面的。眼下就要付出很大的代價，面對很大的麻煩，好處卻還在遙遠的未來。所以各方都是口號大于行動也就很好理解了。

在2011年6月舉辦的“世界IPv6日”活動上，有不少專家認為：“盡管IETF、ISOC和其支持者正在不遺余力地推廣IPv6，但是IPv6并不是一件必然要發(fā)生的事情?！?/p>

2.2 NAT

網(wǎng)絡中的地址至少有兩個含義：主機在網(wǎng)絡中的唯一標識；網(wǎng)絡將報文轉(zhuǎn)發(fā)至主機的尋路依據(jù)。NAT協(xié)議通過為內(nèi)網(wǎng)主機分配私網(wǎng)地址，并將私網(wǎng)的IP:port對映射為公網(wǎng)的IP:port對，一定程度上緩解了IPv4地址不足的問題。但NAT為主機分配私網(wǎng)地址，導致主機失去了網(wǎng)絡中的唯一標識。NAT破壞了網(wǎng)絡的對稱性，導致網(wǎng)絡日益向C/S結構演化。同時，家庭網(wǎng)關層面采用NAT技術也沒有徹底解決IPv4地址不足的問題，運營商仍然缺乏足夠的地址分配給用戶。

前已述及，運營商計劃通過給用戶分配私網(wǎng)IPv4地址+NAT將新用戶接入IPv4網(wǎng)絡。這樣的方案同時包括在主流運營商優(yōu)選的幾個過渡方案如NAT444、DS-Lite和LAFT 4over6等方案中，雖然細節(jié)各有不同。雖然NAT的引入會破壞網(wǎng)絡的對稱性，但NAT技術在家庭網(wǎng)關上的廣泛應用已經(jīng)充分證明了它的生命力。

雖然這些方案都是作為過渡方案出現(xiàn)的，但這些方案應用后的確會有效緩解IPv4網(wǎng)絡中地址不足的問題。如果業(yè)界以IPv6為下一代互聯(lián)網(wǎng)解決方案，考慮到所有各方升級到IPv6將要付出的成本和面對的麻煩，有理由相信這些過渡模式中的NAT成分會得到充分的發(fā)展。人們會信任并依賴這些方案中包含的NAT技術而忽略這些方案中的IPv6部分，地址不足不再是個問題，進而網(wǎng)絡會長期停留在“過渡階段”并失去向IPv6演化的動力。

3 IPng應有的特點

如果不希望網(wǎng)絡長久地停留在邁向IPv6的過渡狀態(tài)中，不希望網(wǎng)絡長久地停留在被NAT破壞了對稱性的狀態(tài)中，那么應該重新考慮：下一代互聯(lián)網(wǎng)解決方案，是否還有更好的選擇？

IPng應該具備哪些特點？1993年IETF提供的RFC1550列舉了若干條件，唯獨沒有要求與已有的IPv4兼容。20年后再來審視這份文稿，已經(jīng)可以清晰地看到兼容性要求的缺失導致網(wǎng)絡升級所面臨的巨大困難。因為IPv6與IPv4不兼容，升級遲遲不能完成，甚至在IPv4地址已經(jīng)耗竭的今天，仍然沒有足夠的樂觀的理由。

有理由要求一個合格的IPng技術必須同時具備兩個特點：地址空間充分大，以解決IPv4地址不足的問題；與IPv4網(wǎng)絡兼容，以方便順利升級。

一個偶然的機會，筆者想到了一個可以同時滿足上述兩個要求的方案。因為高度兼容IPv4網(wǎng)絡，需要升級的網(wǎng)絡設備極少，升級既經(jīng)濟又容易，與IPv6方案相比成本幾乎可以忽略不計。在此將這個新方案介紹給大家。

4 新思路：雙網(wǎng)絡層方案

4.1 協(xié)議棧

新協(xié)議在原IP層之上增加一層，放入報文的源、目標主機的域名——姑且稱之為域名層。以常見的IP over Ethernet為例，增加了域名層的新協(xié)議棧如圖1所示。鑒于原協(xié)議被稱為TCP/IP，此處姑且將新協(xié)議稱為TCP/DN/IP（DN=domain name）。

新協(xié)議使用域名作為主機全球唯一的標識和尋址依據(jù)。

新協(xié)議在域名覆蓋的范圍內(nèi)（可以包括部分或全部子域）使用整個IPv4地址空間進行編址，因此域名還可代表IP域。

圖1 TCP/DN/IP協(xié)議棧

IP域的特點如下。

·每個IP域獨立編址，IP地址在單個IP域內(nèi)唯一。

·IP域內(nèi)的路由器按傳統(tǒng)方式根據(jù)IP地址轉(zhuǎn)發(fā)報文。也就是說，IP域內(nèi)的IP路由器不需要升級。（TCP/DN/IP報文因為沒有修改IP層報文格式，仍是標準的IP報文，在IP域內(nèi)轉(zhuǎn)發(fā)時可以在傳統(tǒng)IP路由器上正常轉(zhuǎn)發(fā)）。

·不同的IP域在IP層不互通。報文跨IP域轉(zhuǎn)發(fā)時，需要域名路由器（domain name router，DNR）根據(jù)報文頭部的域名層信息進行轉(zhuǎn)發(fā)。

不考慮少數(shù)被保留用于特殊目的的地址段，目前的IPv4地址正是在全球范圍內(nèi)統(tǒng)一編址的，正好符合定義，姑且稱之為“全球域”。

第4.2節(jié)的“轉(zhuǎn)發(fā)場景”可幫助理解上述概念、特點以及本方案的實現(xiàn)機制。

4.2 完整的轉(zhuǎn)發(fā)場景

4.2.1 跨域訪問

如圖2所示，有3個IP域，分別是全球域(.)、中國國家域(cn.)和美國國家域（us.）。每個IP域獨立編址。不同的IP域在IP層不互通，須通過域名路由器轉(zhuǎn)發(fā)。

圖2中各設備基本配置見表1。

表1 典型流程中各網(wǎng)絡設備基本配置

圖2 典型的TCP/DN/IP報文跨域轉(zhuǎn)發(fā)流程

可以看到，由于劃分了不同的IP域，同一個域名在不同的域中可以映射為不同的IP地址，不同域中的主機也可以擁有同樣的IP地址。

另外，需要在DNS中新增DNA資源類，已升級的主機在DNS中注冊DNA資源，仍舊映射為IP地址，用以告知查詢方目標主機已升級。未升級的主機只有A類型的資源。

host.cn向host.us發(fā)出的報文全程轉(zhuǎn)發(fā)流程如下。

（1）host.cn向本域的DNS服務器查詢host.us的IP地址（DNA資源類型）。

（2）dns.cn在cn域內(nèi)的接口上維持表2所示的解析。

表2 dns.cn在cn域內(nèi)的解析

此表將域內(nèi)的域名（以cn.結尾）解析為對應的域內(nèi)IP地址，將所有其他域名（根據(jù)DNS命名規(guī)則，一個域名要么屬根域，要么屬根域的子域，必然可與“*.”匹配）解析為通向全球域的DNR的IP地址。

在本例中，dns.cn發(fā)現(xiàn)是域內(nèi)主機在查詢域外主機host.us，返回相應的CN DNR在cn域內(nèi)的接口IP地址：1.1.1.1。

（1）host.cn收到DNS查詢結果后，域名層填入host.us為目標地址，host.cn為源地址，IP層填入DNS返回的CN DNR IP作為目標地址，見表3，然后將報文發(fā)出。

表3 host.cn發(fā)送報文前的報頭內(nèi)容

（2）此報文被cn域內(nèi)的所有IP路由器作為標準IP報文轉(zhuǎn)發(fā)，并最終抵達dnr.cn。

（3）dnr.cn收到報文后，發(fā)現(xiàn)目標地址是host.us，在全球域內(nèi)查詢host.us對應的IP。

（4）全球域DNS維持的表格中包含表4所示記錄。

表4 全球域DNS（dns.）解析

根據(jù)DNS的實現(xiàn)機制，全球域中的DNS 3.3.3.4負責解析us.域內(nèi)的域名。此時查詢會被轉(zhuǎn)向到dnr.us。

dns.us面向全球域的接口維持這樣的解析表格，見表5。

表5 dns.us在全球域內(nèi)的解析

也就是說，對所有從us.域外查詢us.域內(nèi)主機的請求，一律返回3.3.3.3。

對于dnr.cn的查詢host.us的請求，DNS最終返回

3.3.3.3 。

（5）dnr.cn將IP層的目標地址替換為DNS返回值，IP層的源地址替換為本機出口地址，見表6。

表6 dnr.cn轉(zhuǎn)發(fā)前的報頭內(nèi)容

然后，dnr.cn將報文從全球域端口發(fā)送出去。

（6）dnr.us收到報文后，在us.域內(nèi)通過DNS查詢到host.us的IP地址為100.100.100.100，將IP層目標地址替換為DNS返回的100.100.100.100，IP源地址替換為dnr.us出口地址1.1.1.1，見表7。

表7 dnr.us轉(zhuǎn)發(fā)前的報頭內(nèi)容

然后將報文從us.域內(nèi)接口發(fā)出。報文在us域被若干IP路由器視為普通IP報文轉(zhuǎn)發(fā)，直至抵達目標主機host.us。

作一個類比：IP報文穿越不同的以太網(wǎng)廣播域時，IP層的源和目標地址保持不變，而MAC層的源和目標地址在不停地變化。TCP/DN/IP報文穿越不同的IP域時，域名層的源和目標地址保持不變，而IP層的源和目標地址在不停地變化。兩者的思路是一致的。

最后，由于域名層含有源地址“host.cn”，反向報文可以循相同的機制返回。

4.2.2 域內(nèi)訪問

（1）hostA.cn（已 升級主機）發(fā) 出 基 于TCP/DN/IP的DNS query到DNS服務器，查詢hostB.cn的IP地址（DNA資源類型）。

（2）DNS服務器發(fā)現(xiàn)是域內(nèi)主機在查詢域內(nèi)主機的IP地址，返回hostB.cn的IP地址。

（3）hostA.cn將hostB.cn和hostA.cn分 別 作 為 報 文 的目標地址和源地址填入報文的域名層，DNS返回的IP地址作為目標地址填入IP層，即可正常訪問hostB.cn。

可以看到，域內(nèi)的訪問流程與既有模式是完全一致的。

值得一提的是，本協(xié)議中在單個IP域內(nèi)域名與IP地址保持一一對應關系，既可以用域名標識主機，也可以繼續(xù)使用IP地址標識主機。這個特點為那些只需要在單IP域內(nèi)運作的業(yè)務平臺提供了很大的方便——它們根本就不需要升級。

4.3 NAT家庭網(wǎng)關之后的終端接入方案

如前所述，目前NAT型家庭網(wǎng)關得到了最為廣泛的應用。

TCP/DN/IP報文無法通過NAT路由器（即使能通過，因為NAT路由器無法進行反向映射，返回的報文將無法到達正確的內(nèi)網(wǎng)主機）。

可以考慮用如圖3所示的方案來解決這個問題。

如圖3所示，在IP層與DN層之間再插入一個標準的UDP層。這個新增的UDP層可以保證報文正常通過NAT網(wǎng)關。需要為TCP/DN/IP分配一個標準的UDP端口，所有支持TCP/DN/IP的設備都在這個端口偵聽，DNR則仍然按前述規(guī)則根據(jù)域名轉(zhuǎn)發(fā)。

用戶不必對NAT路由器做任何改動，只要升級所有的終端使用這樣的協(xié)議棧，就可以同時實現(xiàn)多終端接入以及對全球網(wǎng)絡的無障礙訪問。

如果將來家庭網(wǎng)關設備商生產(chǎn)支持TCP/DN/IP的路由器，那么每個家庭內(nèi)部將有一個獨立的IP域，而且仍然只需要運營商分配1個IP地址作為WAN口地址，路由器根據(jù)域名進行轉(zhuǎn)發(fā)，那么家庭內(nèi)部可以接入任意多個主機并且全部全球可達。

這個設計還有個附帶的優(yōu)點是：升級對用戶的影響是正向的。用戶如果不升級家庭網(wǎng)關，那么可以獲得與當前一樣的服務（可以主動發(fā)起連接，但不能接收傳入的連接）；用戶如果升級家庭網(wǎng)關，那么家庭所有終端就外部可達了。因此用戶會傾向于主動升級。

4.4 域名解析方案

4.4.1 DNS響應規(guī)則

比較前述跨域訪問與域內(nèi)訪問的全過程，可以發(fā)現(xiàn)在兩種場景下主機的行為并無不同。差異完全來自DNS的解析機制。事實上本方案嵌入的域名層成為了新的網(wǎng)絡層，DNS實際上構成了域名層的路由平面。

本方案中DNS響應規(guī)則如下。

·對于同域的查詢，返回目標主機在本域內(nèi)的IP地址。

·對于跨域的查詢，返回可以轉(zhuǎn)發(fā)報文到目標域的DNR在本域內(nèi)的接口IP地址。

在這個機制中，DNS實際負責域名層的路由，而DNR只負責轉(zhuǎn)發(fā)。

4.4.2 固定域名解析

DNS中增加一個DNA資源類型，值為升級后的TCP/DN/IP主機的IP地址。DNS以此方式告知查詢發(fā)起方：目標主機已支持TCP/DN/IP。

主機完成升級后增加DNA類型的項目到DNS數(shù)據(jù)庫中。

4.4.3 動態(tài)接入用戶的域名自動配置方案

新協(xié)議要求每臺主機都需要一個可解析的域名。這對原先已有域名的網(wǎng)站來說不是問題，但動態(tài)接入的寬帶用戶則比較麻煩。目前的寬帶用戶多數(shù)是按需接入并動態(tài)分配IP地址的，如果為它們提供可解析的域名，則DHCP系統(tǒng)要進行調(diào)整，涉及幾乎所有的寬帶用戶（數(shù)以億計）。建議采用如下的自動配置主機域名方案，只需對DNS稍作調(diào)整，即可給動態(tài)接入的主機分配合法、可訪問的域名而完全不必觸及DHCP。

自動配置主機域名方案如下。

（1）在本域DNS中添加localdomain對應的別名，值設置為本域域名。譬如cn.域內(nèi)就將localdomain對應的別名設置為“cn.”。

（2）升級到TCP/DN/IP的主機接入網(wǎng)絡后，按傳統(tǒng)方式通過DHCP向網(wǎng)絡申請IP地址和DNS服務器。

圖3 可通過NAT路由器的TCP/DN/IP協(xié)議棧

（3）主機在配置IP并得到DNS地址后，向DNS服務器查詢“l(fā)ocaldomain”對應的CName字段，并將返回的別名設置為本機所在域的域名。

（4）將本機的IP地址的點分十進制字符串，用“[]”括起來作為主機名。

（5）通過以上方式生成本機的完整域名。譬如一臺主機分配到的IP地址是100.100.100.100，所在域是“cn.”，那么按這個規(guī)則生成的域名就是“[100.100.100.100].cn”。也可以考慮采用其他編碼方式如十六進制等以充分縮短域名長度。

（6）可以考慮前述生成規(guī)則允許嵌套（例如當主機位于支持TCP/DN/IP的家庭網(wǎng)關之后時），這樣會生成諸如“[192.168.1.10].[100.100.100.100].cn”形式的地址。這樣的地址客觀上具備源路由性質(zhì)，但過長的域名同時也會降低報文的效率，需要謹慎考慮。

網(wǎng)絡上的TCP/DN/IP主機在解析域名時，先比較目標主機所在域與本機所在域是否相同。若相同，視為處于同一個域。再看去掉域名后最右的部分是否符合自配置的主機域名的格式。如是，則直接從中還原出IP地址，不必再向DNS查詢。其他情況仍舊向DNS查詢目標主機IP地址。

（7）還可以再擴展一下：假設一個NAT網(wǎng)關公網(wǎng)地址為100.100.100.100，一臺位于該NAT網(wǎng)關之后的主機地址為192.168.1.10，在UDP端口2000偵聽TCP/DN/UDP/IP格式的報文，而NAT網(wǎng)關已經(jīng)預先配置好將UDP端口2010映射到該主機的2000端口。該主機知道自己位于NAT網(wǎng)關之后并且知道端口對應關系，則可以將自己的地址配置為[100.100.100.100:2010].cn。域內(nèi)其他主機看見這樣格式的目標地址時，即可啟用TCP/DN/UDP/IP協(xié)議棧并將目標端口設為2010。通過這種方式，NAT網(wǎng)關之后的多臺主機能夠接收外部發(fā)起的到TCP/DN/UDP/IP協(xié)議棧任意端口的傳入連接。

這個機制同時還會帶來另一個好處：主機除了在接入時查詢一次本域域名外，同域其他主機訪問時不需要查詢DNS，充分節(jié)省DNS資源。

4.5 過渡方案

4.5.1 未升級主機訪問域內(nèi)主機

（1）hostA.cn（未升級主機）向DNS服務器查詢hostB.cn的IP地址（A型資源）。

（2）DNS服務器發(fā)現(xiàn)查詢的是本域的目標主機，返回hostB.cn的IP地址（A型資源）。

（3）hostA.cn通過TCP/IP與hostB.cn通信。

此例中無論hostB.cn是否已升級，hostA.cn均可使用TCP/IP與hostB.cn正 常 通 信。

事實上，如果hostA沒有訪問域外主機的需求（可以相信較長一段時間之內(nèi)cn域會是中國唯一的IP域，亦即用戶沒有訪問境外主機的需求），那么用戶主機甚至不需要升級。

4.5.2 已升級主機訪問域內(nèi)主機

（1）hostA.cn（已升級主機）發(fā) 出 基 于TCP/DN/IP的DNS query到DNS服務器，查詢hostB.cn的IP地址。為了促進全網(wǎng)早日完成升級，操作系統(tǒng)默認優(yōu)先查詢DNA類型。

（2）DNS服務器發(fā)現(xiàn)查詢的是本域目標主機，應返回hostB.cn的IP地址：

·如果數(shù)據(jù)庫中有對應于hostB.cn的DNA資源類型，說明hostB.cn已升級，返回標明為DNA類型的IP地址；

·如果數(shù)據(jù)庫中只有對應于hostB.cn的A資源類型，說明hostB.cn未升級，返回標明為A類型的IP地址。

（3）hostA.cn收到DNS查詢結果：

·如果收到的是DNA類型的返回結果，說明目標主機已升級，采用TCP/DN/IP與之通信；

·如果收到的是A類型的返回結果，說明目標主機未升級，采用TCP/IP與之通信。

4.5.3 未升級主機訪問域外主機

未升級主機是無法訪問域外主機的。本方案可以自然地將用戶導向指導升級的網(wǎng)頁。

（1）host.cn（未 升 級 主 機）發(fā) 出 基 于TCP/IP的DNS query到DNS服務器，查詢host.us的IP地址（A型資源）。

（2）DNS服務器發(fā)現(xiàn)這是一個域外的主機域名，且源主機未升級（因其查詢A型資源），返回引導升級的Web服務器的IP地址。

（3）host.cn如果是想打開目標主機上的Web網(wǎng)頁，此時會自然打開引導升級的Web頁面。

4.5.4 已升級主機訪問域外未升級主機

4.5.4.1 NAT方案

如圖4所示，本場景中，中國國家域內(nèi)的主機host.cn和DNS.cn均已升級，而全球域中的目標主機server.com未升級。

步驟（1）～步驟（3）同第4.2.1節(jié)，步驟（4）如下。

CN DNR收到報文后，發(fā)現(xiàn)目標地址是host.us，在全球域內(nèi)查詢host.us對應的IP地址。由于server.com未升級，CN DNR只能得到一條A記錄的返回。

圖4 TCP/DN/IP主機訪問TCP/IP主機-NAT型過渡方案

·如果繼續(xù)轉(zhuǎn)發(fā)報文到server.com，連接將會因為server.com無法解析TCP/DN/IP協(xié)議棧而失敗。為避免這種情況，CN DNR轉(zhuǎn)入NAT模式，將cn域內(nèi)的（DN圳DN）報文映射為全球域內(nèi)的（IP圳IP）報文。

·目前已經(jīng)從IANA申請到的所有IP地址均可視為全球域中的地址，可作為此NAT中的源地址。由于地址數(shù)量充足，此處的NAT甚至不需要進行端口轉(zhuǎn)換。此舉可以節(jié)省相當多的路由器資源。

本方案屬過渡方案，是DNR的可選功能。

4.5.4.2 VPN方案

通常NAT方案已經(jīng)滿足要求。有一些特殊的應用如果未及時升級，可能會因為ALG問題不能成功連接。此時用戶可選擇VPN方案。

（1）用 戶 通 過TCP/DN/IP連 接 到 全 球 域 內(nèi) 的VPN服務器，獲得一個全球域內(nèi)有效的IP地址。此時即可通過TCP/IP訪問全球域內(nèi)任意主機。

（2）VPN建立期間，主機同時擁有兩個IP域的IP地址，可能會導致一定的混亂?？梢钥紤]利用協(xié)議棧區(qū)分兩者。即，只用TCP/DN/IP訪問物理接口所在的IP域，只用TCP/IP訪問VPN接口所在的IP域。需要為兩個協(xié)議棧啟用獨立的路由表。

（3）運營商鼓勵用戶和服務提供商盡快升級操作系統(tǒng)。VPN方案可交由社會上獨立的商業(yè)機構運營，運營商不一定需要自己建立這樣的服務器?；ヂ?lián)網(wǎng)上現(xiàn)有的VPN提供商的服務器稍加改造即可提供此項服務。

4.5.4.3 部署策略

客觀上，過渡技術始終面臨一個悖論：如果新技術的兼容性不好，那么會面臨強烈的反對；如果兼容性太好，那么用戶根本沒有過渡的愿望。所以運營商必須在過渡技術的選擇上尋找一個平衡點。

事實上，運營商可以完全不部署本節(jié)描述的兩個過渡方案，只需要在主流網(wǎng)站和多數(shù)終端升級之后從全球域中分離出國家域。這樣，未升級的主機將無法完成跨域的訪問，未升級的服務器也無法響應跨域的請求，如此也可以對用戶和服務商形成升級壓力，促進全網(wǎng)加速升級。

5 升級路線

5.1 運營商網(wǎng)絡升級

5.1.1 DNS服務器

IP域內(nèi)的全部DNS服務器需要升級以按前述本協(xié)議的響應規(guī)則動作。理論上在域邊界上至少設置一臺本域的DNS服務器以響應外部主機查詢本域主機地址的請求。

同時所有DNS服務器在數(shù)據(jù)庫中新增DNA數(shù)據(jù)類型，升級到TCP/DN/IP的主機在DNS數(shù)據(jù)庫中配置此數(shù)據(jù)。查詢方借此可獲得被查詢方是否已完成升級的信息。

5.1.2 邊界路由器

將域邊界 （相當于國際出口）上的路由器升級為DNR。這個升級可能是基于硬件的，但網(wǎng)絡一直在擴張，換下來的路由器可以用在IP域內(nèi)其他節(jié)點，不會形成浪費。

國際出口鏈路通常有多根，域邊界DNR也可能不止一臺。DNS可以順次返回不同的DNR域內(nèi)接口地址給查詢者以引導流量至不同的出口鏈路，以實現(xiàn)流量均衡。

5.2 用戶主機升級

5.2.1 家庭網(wǎng)關

家庭網(wǎng)關可以有如下調(diào)整辦法。

（1）家庭網(wǎng)關工作在二層橋接模式（關閉NAT功能）。運營商給用戶多個終端分配同網(wǎng)段的IP地址。此方案可以讓用戶使用TCP/IP訪問域內(nèi)主機、使用TCP/DN/IP訪問全球主機，但要求運營商分配較多的地址資源。

（2）家庭網(wǎng)關工作在三層路由模式（關閉NAT功能）。運營商給用戶分配WAN口地址以及LAN網(wǎng)段的地址段。此方案可以讓用戶使用TCP/IP訪問域內(nèi)主機、使用TCP/DN/IP訪問全球主機，但對運營商要求較高，運營商不僅要有足夠的資源分配給用戶，同時還要考慮分配的技術，如用戶的LAN網(wǎng)段的地址段如何分配（手工還是自動分配），用戶的內(nèi)網(wǎng)路由如何與運營商的網(wǎng)絡路由協(xié)同。

（3）家庭NAT網(wǎng)關保持不變

·用戶終端繼續(xù)使用TCP/IP，按傳統(tǒng)方式訪問域內(nèi)其他主機。

·用戶終端使用TCP/DN/IP中的TCP/DN/UDP/IP協(xié)議棧，訪問全球已升級主機。

（4）長遠來看，家庭網(wǎng)關會向支持TCP/DN/IP發(fā)展。此時運營商只需要分配1個IP地址給用戶，用戶的LAN網(wǎng)段自成IP域，自行分配地址即可。此時只需要做一個事情：將用戶的TCP/DN/IP路由器注冊到Internet的域名系統(tǒng)以實現(xiàn)正常解析。

比較而言，方案（1）、方案（2）對地址資源要求比較高，而且技術較復雜，運營商需要調(diào)整為數(shù)眾多的接入層設備。同時，因為需要分配較多的地址給用戶，將來可能不得不設立省級IP域，會帶來較大的復雜度（譬如，如果運營商只在國家級設一個IP域，那么運營商的業(yè)務平臺系統(tǒng)都在同一個IP域中，現(xiàn)有平臺不需要任何調(diào)整，可以繼續(xù)運行在TCP/IP上。而如果設立省級IP域，則運營商的業(yè)務平臺系統(tǒng)需要升級以支持TCP/DN/IP），不是筆者推薦的方案。方案（3）則比較合適，無論運營商還是用戶都不需要調(diào)整。如果有合適的協(xié)議讓新增的TCP/DN/IP路由器可以自動注冊到域內(nèi)DNS，方案（3）可以自然發(fā)展到方案（4）。

5.2.2 開發(fā)平臺

在操作系統(tǒng)升級之后，業(yè)界主流的開發(fā)平臺需要及時升級，提供新的API以支持新的協(xié)議棧。以此為基礎，應用軟件可以及時升級以使用新的協(xié)議棧。

5.2.3 操作系統(tǒng)

用戶如果不升級操作系統(tǒng)，不影響對域內(nèi)主機的訪問。

操作系統(tǒng)升級后處于TCP/IP和TCP/DN/IP的雙棧模式。操作系統(tǒng)升級以支持TCP/DN/IP后：

·按第4.4.2節(jié)的方案配置本機；

·為了支持VPN過渡方案，主機還應當支持在VPN接口啟用時，根據(jù)協(xié)議選擇網(wǎng)絡端口的路由方式（如第4.5.4.2節(jié)所描述）。

5.2.4 應用軟件

5.2.4.1 客戶端（發(fā)起方）

將目標主機的域名傳遞給操作系統(tǒng)提供的新API，理論上就足夠了。

有些應用在應用層攜帶的IP地址信息，如FTP、H.323等，這些協(xié)議/應用需要升級，用域名代替IP地址才可以在跨域的TCP/DN/IP網(wǎng)絡上正常運作。

5.2.4.2 服務端（接收方）

軟件打開一個TCP端口進行偵聽時，操作系統(tǒng)自動在TCP/IP和TCP/DN/IP兩個棧上同時打開。如果軟件涉及具體的IP地址，那么需要用域名代替IP地址；如果軟件不涉及具體的IP地址，那么服務端軟件就隨著操作系統(tǒng)的升級而自動升級了。

5.3 平滑升級方案

第一階段，業(yè)界形成共識，確定TCP/DN/IP方案為下一代互聯(lián)網(wǎng)方案。然后通信設備廠商研發(fā)支持TCP/DN/IP轉(zhuǎn)發(fā)的DNR，DNS軟件供應商研發(fā)支持TCP/DN/IP解析規(guī)則的DNS升級版本，操作系統(tǒng)廠商準備支持TCP/DN/IP協(xié)議棧的OS升級版本，開發(fā)軟件供應商提供支持TCP/DN/IP的API等。

第二階段，政府發(fā)出公告，向社會公示下一代互聯(lián)網(wǎng)升級方案，并明示不升級的主機可能面臨的訪問限制。運營商部署DNS（暫時按傳統(tǒng)規(guī)則解析）和DNR（暫時無流量）、用戶升級操作系統(tǒng)，服務提供商根據(jù)開發(fā)軟件供應商提供的新接口升級自己的應用軟件。這個方案需要至少一臺全球DNS根服務器升級。各方可以自行升級，不必以其他任意一方已升級為前提。

第三階段，運營商從DNS查詢的資源類型比例統(tǒng)計出網(wǎng)絡中已升級終端比例。當新協(xié)議支持率到達一定比例時，可以確定升級0時。0時到來時，讓DNS按TCP/DN/IP要求進行解析，正式從全球域中分離出國家域，將流量引導至DNR進行跨域轉(zhuǎn)發(fā)。國家域一旦分離，可能出現(xiàn)第4.5.3節(jié)描述的“未升級主機訪問域外主機”以及第4.5.4節(jié)描述的“已升級主機訪問域外未升級主機”兩種需要特殊處理的情況，按各自的預案處理即可。由于操作系統(tǒng)已經(jīng)準備好了升級版本，境外的未升級主機可以認為不打算接受TCP/DN/IP主機的訪問，可以考慮為這樣的訪問提供NAT，也可以直接忽略這樣的主機。

在升級階段可能遭遇DNR和DNR NAT性能瓶頸。國際出口可能有巨大的流量，需要較多的路由器（包括NAT）資源。同時，本方案采用長度可變的域名作為唯一尋址依據(jù)。比起定長的IPv4/IPv6地址，路由器在處理變長的地址時效率會略低。對策為：多設置DNR數(shù)量。在遇到跨域查詢時，DNS返回不同的DNR的IP地址作為網(wǎng)關，可以有效地均衡負載。

6 方案優(yōu)勢

（1）此方案與既有IPv4網(wǎng)絡兼容度極高。IP域內(nèi)所有三層設備不需要升級。包括運營商設備中的絕大多數(shù)，單此一項就可為運營商節(jié)省大量投資。

（2）本方案不要求家庭網(wǎng)關升級。推薦的方案是保持NAT網(wǎng)關不動，任其自行向TCP/DN/IP路由器演進。目前中國有1.9億戶寬帶用戶、全球有6.7億戶寬帶用戶，除歐美（約2億戶用戶）地址比較富裕之外，其他地方（包含中國共4.7億）絕大多數(shù)寬帶接入用戶不可避免地用到NAT型家庭網(wǎng)關。對比IPv6方案必須升級家庭網(wǎng)關的要求，本方案既可以在經(jīng)濟上、工程上和時間上做到極其可觀的節(jié)省，同時也完全避免了家庭網(wǎng)關對升級形成的阻礙。

（3）DNS需要升級，但數(shù)量極為有限，與家庭網(wǎng)關和路由器的數(shù)量不在同一數(shù)量級上，且升級基本屬于軟件升級。另外IPv6方案一樣要求DNS升級（只是可能很多DNS已經(jīng)完成了這個工作而已）。但是本方案要求DNS做一點路由平面的控制工作，這是特別的地方。

（4）邊界（初期相當于國際出口）上的路由器需要升級為DNR，但數(shù)量也極其有限。同時由于網(wǎng)絡仍處于擴張當中，換下的路由器可用于網(wǎng)絡其他節(jié)點，不會造成任何浪費。截至2013年底中國出口總帶寬3.4 Tbit/s。如果DNR可以在10 Gbit/s鏈路上線速轉(zhuǎn)發(fā)（包括NAT），那么需340條鏈路。如果用高密度服務器或者插卡式路由器，也就20～30臺，占用的機房面積也很小。如果可以在更高速率的接口上實現(xiàn)，數(shù)量還可以大大縮減（視業(yè)界實現(xiàn)水平而定）。

（5）此方案中地址空間是真正無限的。IPv6的地址雖然號稱無限，但其分配規(guī)則仍然是“先到先得，按需分配”，要求使用者向國際組織申請地址。而在本方案中，任何組織或個人只要獲得一個DNS域名，就可以在其下任意派生無限子域，每個子域都可以作為一個獨立的IP域并擁有整個IP地址空間。相比IPv6方案，本方案對后發(fā)國家更加公平。

（6）如果規(guī)劃得當，即便是中國這樣的人口大國，運營商設立一個國家級的IP域就可以了。運營商已有的業(yè)務平臺的內(nèi)部管理可以繼續(xù)使用現(xiàn)有的模式而不必升級。

目前DNS已經(jīng)是個部署完善的系統(tǒng)。根據(jù)早期的一些反饋，有專家認為觸動DNS不妥。但綜合比較下來，特別是比較不同方案需要升級的設備數(shù)量與資金投入，通過升級DNS和邊界路由器來升級到下一代互聯(lián)網(wǎng)的方案，比起IPv6方案還是擁有巨大的優(yōu)勢。

IPv6是現(xiàn)在被廣泛認同的下一代互聯(lián)網(wǎng)協(xié)議，而NAT是實際應用最廣泛的解決方案。表8比較了一下TCP/DN/IP與IPv6、NAT技術的各方面特點。

概括而言，如果以IPv6為目標，則會出現(xiàn)以下情況。

表8 TCP/DN/IP與IPv6、NAT技術的各方面特點

·運營商不得不向用戶提供雙棧接入，需要升級所有三層及三層以上設備，包括路由器、DNS以及所有寬帶用戶的家庭網(wǎng)關（數(shù)以億計），過渡方案還要求在網(wǎng)內(nèi)新增部署地址翻譯設備等，耗時耗力，投資巨大。

·因為運營商會（不得不）在較長一段時間內(nèi)繼續(xù)提供IPv4接入，并且運營商為數(shù)以億計的寬帶用戶替換支持IPv6的家庭網(wǎng)關需要很長時間，SP會傾向于留在IPv4平臺，不會急于向IPv6遷移。等到運營商經(jīng)過漫長的時間終于將所有的家庭網(wǎng)關都換完時，SP會覺得經(jīng)過長期考驗的私網(wǎng)IP地址+NAT的訪問模式已經(jīng)很成熟，沒有升級的必要。

·因為IPv6網(wǎng)內(nèi)資源較少，已升級到雙棧的寬帶用戶也會更多地使用IPv4訪問，IPv6流量寥寥無幾。

也就是說，運營商花費了漫長的時間、付出了巨大代價將網(wǎng)絡升級到雙棧之后，用戶會繼續(xù)使用NAT技術訪問IPv4平臺上的SP而對IPv6平臺置之不理，網(wǎng)絡最終會演變成一個充分NAT化的網(wǎng)絡，甚至可能包括嵌套的NAT模式。

如果以TCP/DN/IP為目標：

·運營商只需要升級國際出口路由器和DNS（兩者數(shù)量都極少）并適時從全球域中分離出國家域（讓DNS改變解析策略即可），不必觸及所有其他路由器，不必再新增其他設備；投資極低，工程量極小，可以迅速地部署完成；

·對于SP和寬帶用戶而言，升級以支持TCP/DN/IP可以獲得全球訪問的能力，不升級也不影響域內(nèi)（相當于國內(nèi)）的訪問。

也就是說，運營商只要付出極低的代價將網(wǎng)絡升級到支持跨域的TCP/DN/IP轉(zhuǎn)發(fā)（域內(nèi)不觸及），運營商的所有工作就完成了。剩下的只是SP決定是否以及何時讓自己的業(yè)務平臺支持新協(xié)議。同時，因為分離出了自己的IP域，運營商在自己的IP域內(nèi)有了足夠多的地址，運營商不再需要部署NAT。而用戶仍可以繼續(xù)使用他們的NAT家庭網(wǎng)關且不會有任何不便。

從歷史的經(jīng)驗來看，升級終端是比升級網(wǎng)絡要容易許多的。20世紀90年代初IETF開始考慮下一代互聯(lián)網(wǎng)方案的時候，很多提議均假設網(wǎng)絡會先于終端完成升級。但歷史已經(jīng)證明互聯(lián)網(wǎng)實際的發(fā)展恰恰與這個假設完全相反。經(jīng)過20年的高速發(fā)展之后，IP地址已經(jīng)基本耗竭，幾乎所有主流操作系統(tǒng)都已經(jīng)支持IPv6，但網(wǎng)絡卻遲遲沒有完成升級。細究原因，恐怕還是因為終端升級主要是以軟件形式進行的，而且網(wǎng)絡協(xié)議只是操作系統(tǒng)的一小部分，因此操作系統(tǒng)在升級的時候順便就可以完成網(wǎng)絡協(xié)議的升級。而對運營商網(wǎng)絡而言，首先部署零星的IPv6設備沒有意義，其次升級通常是基于硬件的而且每個IPv6的許可都需要單獨支付費用，因此運營商沒有部署IPv6路由器的愿望。而本方案最大的特點恰恰在于運營商需要升級的部分被最小化，主要的升級工作由終端通過操作系統(tǒng)軟件升級來完成。

另外，隨著用戶終端和家庭網(wǎng)關的不斷升級，網(wǎng)絡將自動從被NAT技術扭曲的狀態(tài)下解放出來，恢復為對稱結構，在不需要任何特殊配置的情況下，所有的終端都將在全球范圍內(nèi)可達。

7 TCP/DN/IP發(fā)展遠景

7.1 待明確和解決的問題

（1）協(xié)議棧選擇

先后提出了兩個協(xié)議棧，TCP/DN/IP和TCP/DN/UDP/IP。前者報文頭開銷較小，后者可以保證報文順利通過NAT路由器。是同時支持兩個協(xié)議棧，還是僅僅支持后者？

（2）TCP/DN/IP報文頭

本文只是描述了報文頭部必需的關鍵字段，其他還需要哪些字段以及各字段具體該如何定義，需要業(yè)界共同明確。

（3）用SDN實現(xiàn)的可能性

在本方案中，域名層構成新的網(wǎng)絡層，DNS成為DNR分離的路由平面。用DNS進行流量引導，DNR執(zhí)行轉(zhuǎn)發(fā)和地址翻譯功能，正好與SDN的控制平面與轉(zhuǎn)發(fā)平面分離的理念相吻合。本協(xié)議可能成為SDN技術的研究方向。

（4）最優(yōu)路由策略

由于DNS體系是嚴格的樹型結構，如果IP子域有多個出口連接到父域（如中國有多個國際出口），或者同一個父域下的多個子域彼此相鄰時，網(wǎng)絡的實際拓撲與DNS的架構有一定的偏離。需要研究這些情況下的最佳路由策略。

同時，因為TCP/DN/IP中有IP和DN兩個網(wǎng)絡層，還可能會有兩個平面路由協(xié)同優(yōu)化的問題，需要進一步研究加以解決。

7.2 定位

（1）作為IPng的最終解決方案

TCP/DN/IP采用變長的域名作為地址。變長的域名優(yōu)點是與真實的世界相一致，缺點是轉(zhuǎn)發(fā)效率略低。

TCP/DN/IP本身具有極大的地址空間，事實上可以作為下一代互聯(lián)網(wǎng)的最終解決方案。

（2）作為向IPv6的過渡方案

如果業(yè)界偏愛定長的IP地址，堅持以IPv6作為最終的互聯(lián)網(wǎng)解決方案，事實上TCP/DN/IP也可以作為從IPv4到IPv6的過渡方案。

主機同時支 持3個協(xié)議棧：TCP/IPv4、TCP/DN/IPv4和IPv6。先從TCP/IPv4平滑過渡到TCP/DN/IPv4，再從TCP/DN/IPv4平滑過渡到TCP/IPv6。從IPv4平滑過渡到TCP/DN/IPv4的方案已在前文詳述，從TCP/DN/IP過渡到IPv6時，DNS和DNR對于TCP/DN/IPv4報文按不同IP域處理，對IPv6報文按同IP域處理，即可完全平滑地實現(xiàn)過渡。

8 結束語

概而言之，雙網(wǎng)絡層方案有這樣一些特點：地址空間無限、與IPv4網(wǎng)絡高度兼容、升級過程非常平滑、投資極小，很好地滿足了對下一代互聯(lián)網(wǎng)技術方案的要求。

特別有趣的是，這個方案對升級的激勵是正向的，所有各方都會有升級的主動性：對運營商而言，升級只需要極少的投資，就可以獲得無限的地址空間；對SP而言，如果只是服務于IP域內(nèi)用戶那么就根本不需要升級，如果升級就可以服務于全球用戶；對寬帶用戶而言，如果滿足于目前的主動訪問域內(nèi)服務器的模式也不用升級，如果升級就可以雙向訪問全球網(wǎng)絡，而且升級還很可能是完全自動的。

但一個新的協(xié)議從提出到成熟，畢竟需要較長的時間來充分發(fā)展。本文只是提出了一個簡單的框架。筆者希望這個方案能得到大家的認同。更多的工作，還要期待業(yè)界共同推進和完成。

1 RFC1550.IP:Next Generation(IPng)White Paper Solicitation,1993

2 RFC1752.The Recommendation for the IP Next Generation Protocol,1995

3 RFC2373.IP Version 6 Addressing Architecture,1998

4 RFC1034.Domain Names-Conceptsand Facilities,1987

5 RFC1035.Domain Names-Implementation and Specification,1987

6 RFC1123.Requirements for Internet Hosts——Application and Support,1989

7 IETF.NAT444(draft-shirasaki-nat444-06),2012

8 IETF.LAFT6:Lightweight Address Family Transition for IPv6(draft-sun-v6ops-laft6-01),2011

9 IPv6發(fā)展為何如此糾結.人民郵電報,2013-10-10

10 姜明.IPv6協(xié)議產(chǎn)生的背景過程和現(xiàn)狀.http://tech.ccidnet.com/art/218/20030605/48972_1.html

11 Marsan D C.What happens if IPv6 fails.Network world,2011