首先，就是轉發表項容量的問題
網絡設備轉發芯片為實現簡單，基本都是采用IPv4和IPv6公用轉發表的方式，一條IPv6占用兩條IPv4表項或者四條IPv4表項。IPv4存量網絡規模太大，不可能用IPv6將IPv4一下子替掉，就需要讓兩者在一個網絡中，甚至一臺設備上共存，IPv6要占用原有IPv4資源，IPv4和IPv6共存，IPv6要占用更多的資源，會使得IP轉發表資源急劇下降。網絡在設計之初，雖然IPv6作為網絡設備的基本功能都要求支持，但對容量并沒有明確要求，實際部署時IPv6功能也是擺設，沒有實際用，現在真要用了，就要認真考慮容量問題了。比如：設備若IPv4轉發表是16K，則只能支持IPv6轉發表是8K，如果是兩者公用，那么應該是IPv4+2*IPv6=16K。實際應用時可用轉發表項數量會更少，這是因為IPv4和IPv6的IP地址長度并不相同，IPv6是IPv4的四倍，有128個BIT，長度差異導致兩者向同一個IP轉發表下發時，極其容易出現HASH沖突，從而下不去，報資源不足。實際應用中，這種情況實際可用的容量也就達到原來的一半，16K的資源，總共也就下發8K左右，即IPv4+2*IPv6=8K，之后出現HASH沖突的概率大大增加了。顯然，若是現網中設備的IPv4表項已經使用的比較多，就不能再啟用IPv6了，轉發表資源會快速下降，出現不足。
其次，是IPv4與IPv6互通問題
部署IPv6不能將原來的IPv4網絡推倒重建，IPv6部署是循序漸進的過程，這就要求技術上處理好舊的IPv4網絡與新的IPv6網絡兼容性，尤其是兩者互通問題，有的網絡終端是IPv4的，網絡接入是IPv4的，核心部署是IPv6的，也有的網絡終端是IPv6的，網絡部分又是IPv4的，這就要解決互通問題。以我們最熟悉的QQ為例，如果IPv4和IPv6用戶不能互相通信將是非常糟糕的情況。顯然，大家已經為此設計了一些互通技術：雙棧、隧道和地址轉換三種。雙棧技術本身不解決網絡互聯互通，只是要求所有主機都支持兩種IP協議，這樣對用戶而言就是互通了，通過主機上的協議切換從而與兩個網絡的用戶實現互通，但這樣無法做到無縫切換，要同時與IPv4、IPv6網絡都要實時互通技術上就存在困難，只能將主機的網卡來回切換，分別與兩個網絡實現互通。隧道技術可以解決雙向互通，但還是需要強大的隧道服務器，隧道的帶寬是一定限制，另外隧道其實是通過雙層IP頭實現的，這樣增加了報文的長度，增加了占用帶寬，浪費掉了部分帶寬資源。地址轉換技術方面曾經有一個標準草案NAT-PT，但已被IETF放棄了。另外還有法國運營商Comcast提出的DS-Lite，國內CERNET2團隊提出的IVI，這些方案都是將隧道和地址轉換結合起來，可能更適合實現過渡的目的，但這些都大大增加了網絡開銷，對網絡帶寬是個考驗。顯然，這些互連互通技術還不能讓人滿意，只能作為過渡技術臨時被采用。
第三，是兩張網運維的問題
在兩張不同的網絡上，虛擬機如何遷移，遷移過程中的運維管理問題也需要考慮。我們面臨著要同時運維IPv6和IPv4兩張網絡，運維工作量是原來的兩倍還不止，IPv6的技術特點和IPv4并不是簡單的地址加長，在協議處理、安全保護、狀態計算等方面都有差異，所以運維的知識還要補充和學習，甚至要引入一些IPv6的技術專才，這些都給運維的工作和資金帶來壓力。同時，兩張網還不是隔離的，在同一臺設備上都要共存，還要考慮兼容問題，相同的命令看IPv4轉發表是一個結果，看IPv6又是一個結果，將兩者放在一起看又可能是另外的結果，如何分析，都需要積累經驗。原來運維的工具，顯然要將IPv6網路部分也要納入，但很多時候這些信息并不能分開統計與分析，比如端口流量，無法區分是IPv4流量還是IPv6流量，流量圖上看出是哪部分流量，出了問題自然也看不出是IPv4流量出了問題，還是IPv6流量出了問題，只能通過其它方面的表現來確定。在運維可視化、自動化工具方面都要考慮IPv6部分，尤其是兩種網絡共存的情況，如何顯示，哪個內容分開現實，哪些內容又要匯總在一起來顯示，這里都還不能用技術來解決。
當然還遠不止這幾個方面的問題，IPv6沒有廣播，只有組播，要占用不少的組播轉發表項，設備能否滿足，IPv6地址長，設備ACL匹配能力是否夠，匹配到IPv6地址比較深入的內容等等，這些都是IPv6在實際網絡部署時面臨的現實問題。IPv6的部署刻不容緩，很多網絡已經陸續上了IPv6，但真正能有IPv6流量跑起來的又有幾個網絡呢，這些擺在大家面前的現實問題若不能一一很好的解決，IPv6就算是已在所有設備上都啟用了，那IPv6也不過是一種擺設，空載跑跑而已，很難形成氣候，IPv6真正替換IPv4網絡還有很長的路要走。
京公網安備 11010502049343號