我們都知道大家面臨IPv4地址壓力，以及我們網絡是不是要升級到或者說有可能升級到IPv6，面臨這些壓力我們一個重要問題如果我們把網絡升級到IPv6，現在我們的CP，SP，內容提供商，應用程序對IPv6他們支持程度如何，他們是不是全面支持了我們IPv6特別是P2P應用，無論是BT還是QQ，還是MSN，是否支持IPv6，我們現在知道結果不是太理想，也許后期會支持。

從網絡方面看，大家一直探討重要問題，如果我們把邊緣網升級到IPv6，因為我們地址不夠用，升級到IPv6以后，我們如何能夠滿足我們用戶大量用戶，我現在沒有IPv6應用，沒有IPv6SAP供我們訪問，我們還得訪問IPv4，我們升級IPv6用戶如何接著訪問我們現有大量IPv4服務器，或者是IPv4內容。

既然提出這樣一個問題，大家自然想到我是不是采用一個翻譯技術，就是說我們在邊緣網用戶上已經有了IPv6或者說只有IPv6情況下，我們要訪問原有IPv4資源，這時候要用翻譯，大家自然而然想要用翻譯，我們是不是只能用翻譯，不能用其他技術，翻譯是一個很重要解決方案，但是我們要探討是不是翻譯是唯一的解決方案。

翻譯當中終端使用IPv6協議站，自然一個問題就是我們上層應用是不是要基于IPv6，如果不基于IPv6，沒有IPv6的話，像我說的MSN應用軟件，客戶端不支持IPv6的時候，這時候是不是翻譯究竟翻誰，會存在這個問題，在翻譯技術當中，我們這個圖，作片是一個V6，中間有一個兩種協議類型轉換網關，這個轉換網關我們要做的事情，把4和6的東西進行互相翻譯，面臨一些問題，比如說翻譯開銷很多，其次就是我們在翻譯的時候，可能是需要對不僅是傳統的FTP應用層翻譯，而且我們對像很重要的大量P2P協議等等。

凡是我們一個協議應用層寫入一個IPv4地址程序翻譯需要針對它進行開發，將來有多少種這樣的應用，這件事我們誰也不知道，我們在真正互聯網關一個網絡層設備商做一些上層應用應該要做的事情，改P2P協議的傳輸，這件事而言不僅是開銷大，也破壞網絡傳輸端到端透明性這一點是非常重要的問題，再進一步是我剛才說的如果我們現在無論是MSN，QQ，甚至是網站沒有提供IPv6服務，現在究竟我這個翻譯東西放到中間以后，我究竟是要翻什么東西，沒有東西可讓我翻，換句話說一個主機也好還是一個手機也好，如果僅僅有IPv6協議站，上面無數應用運行不起來，僅僅翻譯在我們現在網絡過渡里面還是不夠的。

所以再次基礎上我們考慮是不是有可能另外一種問題，就是我們不是要基于6和4之間翻譯，是不是有可能基于隧道實現我們所謂的6和4互訪，這里面我們再補充一句，我們即便使用翻譯的時候，我們兩個網絡4和6網絡至今AFBR做了一個什么事情，實際上就是我究竟如何管理我的IPv4地址，我究竟針對每一個應用我如何維護一個所謂的五原組或者IPv4和IPv6我們不管是如何做IPv4和IPv6之間翻譯，我們最終要解決在AFBR設備上面必須實現我凡是從IPv6出來一個流，一個主機上數據，一定要分配一個IPv4地址，這樣才能進入IPv4世界，同樣IPv4地址端口號給他的時候，我仍然要使用IPv4地址端口號。

所以這時候我們資源分配，IPv4地址和IPv4端口號資源分配在我們AFBR仍然要進行，我們在AFBR上進行，面臨剛才說的諸多問題，還有一種方式就是我們是不是有可能把這樣的資源分配分配以后我們是不是有可能讓我們通信對端左邊IPv6的主機或者IPv6CP設備感知到你這樣的分配，一旦感知以后，是不是有可能采用隧道的形式進行。

所以這樣我們就提出了我們的4over6，在AFBR分配針對每一個用戶，分配IPv4地址端口號，我把分配結果直接想辦法讓我們端系統感知，可能是CPE，也可能是我們主機，感知到IPv4技術分配以后，我們在主機可以直接使用我們IPv4協議站，那么在傳輸的時候，我們就使用IPv4OVERIPv6兩邊進行分裝，IPv6網絡設備跟IPv4網絡上互聯網進行實施通信，避免在我們中間盒子上翻譯，避免開銷太大問題等等。

網絡實際應用場景可以換一個角度再想一想，實際網絡當中不存在IPv6單站設備，這一點大家理解如何，有沒有見過一個主機，這樣主機是不是僅支持IPv6協議站，不支持IPv4協議站有沒有這樣的設備，據我所知是不存在這樣的設備，可能存在僅支持IPv4不支持IPv6，隨著IPv6推廣絕大多數設備都會支持IPv6，支持IPv6是不是不支持IPv4協議站呢，是不會，這樣我的端系統盡量利用已有廣泛支持IPv4協議站，支持IPv4協議站我采用翻譯方式也要分配資源，只是在AFBR上分配資源，干脆把這樣一個資源分配讓你的終端設備能夠感知，一旦終端設備感知，終端上層應用可以直接使用IPv4協議站向這邊發送使用一個4over6，能夠實現上層應用友好性。

這里面有一些技術難點，比如說我們在AFBR確保流量是不是使用共有地址和端口我們才能實現雙向互訪，這一點是非常重要，我們知道現在家庭用戶遷移到IPv6，為什么大家不愿意，就是說遷移到IPv6沒有SAP給我資源訪問，SAP為什么不愿意遷移到IPv6上，我沒有提供新效益，如果說運營商給我提供是一個IPv6網絡傳輸我會不會把IPv4用戶丟掉這一點SAP是絕對不敢，我們使用一個共有IPv4地址，我們在建我們新服務器，SAP服務器，把我們服務器建到一個IPv6網絡里面，我們可以通過4OVER6隧道將來新興IPv6用戶訪問同時，保障我們不丟失原有大量IPv4用戶，如果我們使用公有IPv4可以實現面向服務器的用戶遷移。

對于我們運營商，已經擁有大量IPv4地址，我們如果直接全部使用私有地址，還有一個問題是什么問題，我們IPv4地址資源是不是一下子變成沒有用的東西，這一點也不是我們運營商想看到的，所以還有一種辦法就是對于一些比如說高端的用戶，高端用戶無論企業還是個人用戶給他們可以分配一些公有地址，他們可以使用各式各樣P2P軟件，使得他們能夠進行一些增值業務體驗。

我們強調一種方式是使用公有IPv4地址，如果不夠用的時候，我們可以把公有價值加上IPv4端口號，從AFBR雙棧接入點下發到用戶端，用戶端作為一般的用戶端他們可以采用加上端口號實現這種地址的復用。這里面還有一些技術問題，是有狀態影射還是無狀態影射，甚至是無狀態加上地址端口，一系列關系維護在AFBR里面，使得我們AFBR變成一個沉重的負擔。

這個完全不會，我們跟所有翻譯方式相比，翻譯方式不僅在這里面維護這樣的影射還要進行翻譯，網絡層翻譯還有應用層翻譯，對一些特殊應用還不能支持，獲得IPv4地址上面IPv4服務就可以使用了。這里面還有一些具體技術，必須細節問題這里面就不一一講了，簡單說一句我們通過DHCP，IPv4OVERIPv6使得我們邊緣主機或者網絡獲得遠端給我們分配IPv4地址，IPv4地址分配不是在IPv4網絡是跨越了IPv6網絡，我們需要是一個DHCP，OVERM2M的機制，發出去，從我們小網向戶發數據，一個數據過來以后在我們IPv4應用只看到IPv4協議站，在IPv4報文前面加上IPv4頭，由集中點把IPv4頭去掉，獲得原始的IPv4頭，加一個封裝，對于應用跟我們IPv4還是完全一樣的。

除了一個前面說的是一個每一個主機或者是CP獲得是一個完整的公有IPv4地址以外，還有可能進行相應地址復用，這里面必然存在一個問題，我一定要把端口當做一個重要資源，當做一個區分地址，主機一個資源，這里面我們使用就是現在有一個專門PCP工作組，如何分配端口號，當做地址資源一部分進行分配，把端口號地址一塊分配到我們客戶端，客戶端拿著這樣地址一塊使用，上層應用我們仍然是在IPv4上面的應用。并且實現了地址的復用，大家說這種不太好，我們只能做stateless一個基本想法把我們的地址直接嵌入到一個IPv6地址里面去，把IPv4地址嵌入到IPv6地址，通過地址嵌入實現狀態遷移，原來是我們在兩個雙棧路由器維護4和6地址影射，我們直接把4地址嵌入到6里面去，這里具體嵌入模式，我們除了一個特定網絡前綴，加上一個IPv4地址以外，如果我們要實現地址復用，我們在后面進一步加上一個端口號信息，可以實現這種基于無狀態地址復用，這一點是跟我們翻譯機制都是非常一樣。現在除了前面說的這些4over6還有是做prieate4over6我拿一個IPv4地址，你給我分配什么內容，我發送到你的遠端愛做什么做什么，維護相應的狀態信息，這一點是跟前面非常類似，我們地址分配相應信息，是不是要傳送到這一端。

把前面4over6技術總結一下，跟我們6、4翻譯技術做一個簡單對比，大家一直認為，6、4之間互訪只能用翻譯進行，不僅可以通過6、4之間翻譯實現互訪而且可以通過4over6支持我們之間的互訪，之所以能夠通過4over6技術支持我們的互訪，最重要原因就是我們現在任何一個設備一定是擁有IPv4協議站，為什么一定要把它放棄了，不用它呢，哪怕是用一個假協議站，虛擬協議這樣一個協議站放到這兒應該用它，我們有很多好處，比如說一個是地址復用，僅僅是一個網絡中間一個設備進行翻譯的時候，我可以支持有狀態地址復用，但是難以支持無狀態，如果只有一個盒子做翻譯點難以支持無狀態復用，對于我們在中間集中控制點公有地址維護，邊界上需要進行統一維護。

從開銷上面講翻譯技術自然設計到4、6協議之間翻譯，開銷是一個重要問題，我們使用翻譯要好很多但是仍然有很多開銷，可擴展性會好很多，性能可擴展方面，翻譯技術，44、46性能可擴展都是存在問題，應用友好型是特別重要，應用持續首先支持6，我們才可以談上如何做4、6翻譯，如果你不支持IPv6你究竟翻什么東西，沒有東西讓你去翻，但是我們4over6可以很好支持IPv4應用，對IPv4應用是具有透明性。

簡單回顧一下我們清華大學在4over6取得成果，邊緣網絡如何實現IPv4和IPv6的互通。我們從03、04年一直參與IETF，當初最初是解決骨干網上IPv4OVERIPv6傳輸問題，包括中國教育科研網下一代網絡也建立了純IPv6全國性主干網。我們建立這個全國性主干網我們提供IPv6接入同時也需要IPv4，我們去IETF完全相應的RFC也是吳建平老師牽頭完成的。當時都是我們通過4over6使得4連接到對端的網絡，CNGI支持下要全面部署的4over6系統。

在IETF獲得一些成果在我們國內CCSA也獲得一些標準，特別是我們跟現在運營商合作也是非常密切。中國電信業有一個聯合實驗室，把我們如何做過渡技術作為其中一個重點，我特別提出合作，這個合作可能不僅是包括跟我們廠商合作，跟運營商合作，更多我也是希望我們能夠開展跟上層應用合作，昨天我們有的專家也說過，如果我們一些運營商，或者國家政府提供一些IPv6接入，甚至是一些價格方面比較優惠的IPv6接入，這時候我們內容服務提供商可能更好的推動。

我會遇到另外一個問題，我們內容提供商應用程序提供商，應用程序客戶端全部要支持IPv6，如果能夠支持更好，如果不能支持的情況下，我們如何盡量大力度使用我們現在提供的價格比較優惠的，IPv6傳輸，這時候我想我們4over6技術應該是一個先驅，所以4over6技術我希望是能夠在我們IPv6過渡的時間至少在先期起到一個促進作用，我能夠積極接入到IPv6網絡上，無論是SAP，服務器，積極接入到IPv6網絡上，以后即便在上層應用沒有大量修改情況下，我能夠保持我們IPv4原有信息能夠訪問了，不會丟失用戶資源，部署到IPv6網絡上，IPv6用戶訪問你自然拿IPv6訪問，有IPv4用戶能夠不丟失這是我們希望看到的事情。