IPv6隧道已有不少種，比如：基于MPLS網絡跑IPv6的6PE技術；基于GRE的IPv6隧道技術，其可以在IPv4的GRE隧道上承載IPv6數據報文；基于UNDP的IPv6隧道技術，其解決了傳統NAT不能夠支持IPv6-over-IPv4數據包穿越的問題，這種技術將IPv6數據封裝在UDP載荷中穿越NAT，叫做Teredo隧道；還有用于簡化隧道配置的代理技術，提供自動的配置手段；ISATAP隧道、手工隧道、IPv4兼容IPv6自動隧道等等，IPv6隧道形式多樣，之所以這么多種，主要還是為了適配現有的IPv4網絡，IPv4網絡中GRE、MPLS、NAT等技術應用普遍，IPv6需要能夠穿透這些網絡才能真正達到與IPv4共存。IPv6隧道技術儼然已經成為IPv6技術的重要組成部分。
如今，全網開啟建設IPv6網絡的熱潮，絕大多數是在現有的IPv4網絡上改造，即保持原有的IPv4網絡應用不變，再開通IPv6網絡以便支持IPv6用戶，兩大網絡技術共存到處都需要隧道技術。在這里我們不去具體講這些隧道，每種隧道的特點和實現方式在網絡上都能搜索得到，掌握起來也并不復雜，每臺網絡設備都會提供每種隧道如何使用和配置的指導。但是，如果真正想要用起來，必須要注意一些技術坑，避免掉進去，走很多彎路。
MTU問題
隧道使用首先要考慮MTU問題，隧道的最大傳輸單元和分段：IPv6的MTU最小值為1280字節，而經過tunnel后又增加了IPv4的包頭使得數據包的MTU由1500減少到1480字節。帶有隧道封裝報文的報文頭要比正常報文長，一個報文在加封裝之前，還沒有超過最大以太幀長，加上MTU就可能超過了，這種處于邊界值的報文要處理好分片問題，否則就會因為報文長度問題而無法通過。隧道的MTU支持靜態指定和動態協商，我們可以將隧道的MTU改大一些，這樣避免出現加隧道后報文超過最大以太幀，要分片的問題，這樣處理得當雖沒有問題，但轉發效率變低了。MTU加上了，也要考慮隧道鏈路上的其它設備是否支持，否則就會因為MTU的大小設置差異，導致一些處于兩者之間的報文無法通過。有時這種情況還不容易排查，比如經過隧道的BGP鄰居建立不起來，這就可能是BGP協議發送的長度不一的報文，有的無法通過所導致，這樣的問題分析起來找到MTU的原因并不容易，如果能提前做好設計規劃，就可以避免這點。
隧道鄰居建立問題
IPv6隧道有很多種，但是基本在一個網絡中只采用一種方式，而且一臺網絡設備也不支持同時配置兩種以上的隧道，至少兩個隧道之間的流量是無法互通的。所以，在隧道的類型選擇上，根據網絡需求最先要確定下來。隧道的建立非常簡單，只要隧道兩端的IP地址可達，就可以建立起隧道。IPv6的隧道還不像VXLAN隧道那么豐富，不支持水平分割，所以多見的都是只有一個隧道，將處于獨立的兩部分網絡打通。既然只要可達就行，隧道兩端的IP地址可以二層互通，也可以三層互通，還可以在隧道經過的鏈路上做各種的QoS。隧道類問題無外乎有無法建立、隧道震蕩、不通這三種問題，原因可能千奇百怪，因設備而異。表面上看隧道實現比較復雜，其實問題并不多，就將隧道外部轉發時，不看內層即可，而看內層轉發時，不關心外層就行，與IPv6其它技術相比，隧道技術表面上看起來嚇人，實際掌握起來并不復雜。
隧道安全
隧道要比普通的網絡轉發不安全，這是一定的，為何這樣講？是因為隧道要面臨內外層兩方面疊加的安全威脅。如果IPv4地址被欺騙，任何人都可以向隧道內想注入多少流量就注入多少流量，6over4還有可能受到地址欺騙攻擊，外部偽造的6over4包有可能侵入6over4域內。由于隧道技術會在優化過程中屏蔽掉有效載荷以及很多語音電話和FTP客戶端經常使用的臨時端口，這將導致無法建立起有效的安全策略等問題。并且還可能導致網絡在連接時出現其它類型的潛在錯誤，按照邁克•莫里斯在《回歸思科子網》一文中所說的：“......次優路由，最大傳輸單元的問題，以及硬件和軟件可擴展性方面的風險”都屬于可能出現的情況。總之，隧道技術的安全問題將更加突出，對于那些特別關注網絡安全的數據中心，如何建立一條安全的隧道是一個長期研究的課題，現在還缺少專門針對隧道方面的安全防護技術。
IPv6隧道是打通IPv4網絡中的IPv6孤島，IPv6網絡中的IPv4孤島的必要技術，經過2018年全網大張旗鼓地建設以來，涉及IPv6隧道的應用極小，絕大多數還是以開啟IPv4/IPv6雙棧為主要方式，隨著IPv6部署的深入化，有些局域網絡就可能涉及到隧道的應用，到時就要認真考慮本文所提到的問題。IPv6隧道雖然理論比較健全，但實際應用案例卻很少，在實踐中也可能會遇到新的問題。在IPv6全網改造進行的過程中，IPv6隧道作為一種應用特性，必將在網絡改造中發揮重要作用。
京公網安備 11010502049343號