近期遇到一個IPv6的NAT問題，在解決了之後總想寫一點形而上的東西，什麼是正確的，什麼是錯誤的，什麼合理，什麼不合理，無關文檔，無關代碼，甚至無關技術，僅僅隨便聊聊。昨天下班的路上整理了一下思路，週末了，寫一點吧。
如果一個報文過大卻不能分片的時候，比方說攜帶了DF標誌的IPv4報文和所有的IPv6報文，轉發設備會給數據的始發站回送一則ICMP消息，意思是你這報文太大了，請縮小數據重新發。
對於IPv4的情況，我們不用太在乎這種ICMP消息，因爲IPv4網絡中，IP報文本身只要沒有DF標記，就是可以任意分片的，即便攜帶了DF標記，我們也有足夠的經驗去對應，但是對於IPv6的情況，事情就變得複雜了，特別是中間鏈路存在NAT設備的情況下。
IPv6報文除了始發站之外，全程不能分片，因此如果遭遇了MTU小於報文大小的設備，就必須保證該設備回送的ICMP too big消息可以正確到達始發站。在標準的逐跳IPv6網絡上，這沒有什麼問題，因爲無論沿着哪條路徑，ICMP消息只要到達始發站就萬事大吉。然而，如果原始報文中間經過NAT設備，那麼就必須嚴格保證回送的ICMP消息經過同一個NAT設備纔行，而這個條件在真實網絡中，不採用特殊手段是不能保證的，特別是ECMP情形下。
我們來看一個來自Linux內核nf_conntrack代碼註釋裏的case：
下圖展示了該case和NAT聯動的各種情況：
爲了讓ICMP too big消息經過同一NAT設備到達始發站，我們不得不採取一些手段讓ICMP too big消息和原始數據流做綁定，執行同一個Load Balance策略（比如ECMP的情況），顯然這會引入很多額外的工作量，是的，這非常令人沮喪。
嗟夫！
IPv6還要NAT麼，這是爲什麼？
顯然，IPv6並不存在地址不夠用的問題，顯然，IPv6可以攜帶安全頭保證安全，顯然，IPv6可以Random hostID來隱藏主機，顯然，IPv6根本就不需要NAT。
IPv4一開始也是乾乾淨淨的，NAT並不包含在一開始的設計中，這種後來引入的技術是爲了解決IPv4固有的一些問題的，然而爲什麼，爲什麼還要把IPv4的這個遺瘤帶到IPv6的新時代。繼承一個錯誤的東西，對於IPv6而言，毫無意義！
去除了NAT，IPv6完全靠路由全網互聯互通，這正是互聯網一開始的初衷，然而，更激進一點地說，即便是沒有NAT的IPv6，還是不如IPv4！
IPv6可能是另一個錯誤！
NAT是爲了解決IPv4的問題的，IPv6也是。NAT解決了IPv4的部分問題，IPv6則宣稱它解決了IPv4的所有問題，然而悲哀的是，人們在對新技術的狂歡過後，很難去想象背後的代價，爲了解決IPv4的問題，引入的代價。
是爲每一粒沙子分配一個IP地址重要，還是節省一度電重要？
IPv6需要更多的空間被存儲和傳輸，同時128位的IPv6地址將讓大多數的IPv4路由查找算法下課，同時最長前綴匹配算法卻沒有本質的變化，這需要更多的能量來平滑這個過度，設計更加複雜的算法，雖然層次化的地址分配有效降低了IPv6路由表的規模，然而也只是降低而已。
本質上，IPv6之於IPv4和64位處理器之於32位處理器一樣，只是希望大力出奇跡，然而背後的代價卻是各種支撐設施的質變，我還是舉那個老例子，600米的摩天大樓很容易建造，然而1200米的摩天大樓卻很難，因爲支撐系統的複雜度會指數級上升，不要怕螞蟻變成人這麼大，因爲它自己就會把自己壓垮。
可能一開始IPv4用同一個地址空間的IP地址同時標識終端和網絡本身就不妥，明明是兩個層次卻非要擠在一個地址空間，最終會發現，終端數量是越來越多，而網絡中間節點其實並沒有對應量級的擴張，近40年來，我們的終端數量增加到了幾十億，可是路由器的增長卻遠低幾個數量級，二者並不需要同等的可擴展性。終端和網絡並不是一回事，把它們放在同一個地址空間的同一個地址中，可能並不是最簡單的。
其實我一直覺得，LISP（Locator Identity Separation）協議的設計思想非常不錯，嗯，應該這就是最簡單的吧。
好了，這裏不適合引入LISP的話題，所以也就結束了吧，說好的，這只是一篇形而上的隨筆，無關技術細節，所以也就是無所謂對於不對了，技術細節的東西我也不會寫在這裏。
浙江溫州皮鞋溼，下雨進水不會胖。