【编者按】人从青涩到成熟的过程中需要付出不少的代价，机器设备也大致如此。不同的是，人的成长所付出的代价没有固定的衡量标准，设备可以却有很多参数反映出它值还是不值……
近期遇到一个 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 可以 Random hostID 来隐藏主机。IPv4 一开始也是干干净净的，NAT 并不包含在一开始的设计中，这种后来引入的技术是为了解决 IPv4 固有的一些问题的。那为什么还要把 IPv4 的这个遗瘤带到 IPv6 的新时代。继承一个错误的东西，对于 IPv6 而言，毫无意义！去除了 NAT，IPv6 完全靠路由全网互联互通，这正是互联网一开始的初衷。然而，更激进一点地说，即便是没有 NAT 的 IPv6，还是不如 IPv4！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）协议的设计思想非常不错。
☞苹果或于明年9月发布电动汽车；10家头部平台紧急下架互联网存款产品；Go 1.16首个Beta版本发布|极客头条
☞最令人讨厌的编程语言：C++ Java 上榜
☞Rust 2020 调查报告出炉，95%的开发者吐槽Rust难学
☞从“卡脖子”到“主导”，国产数据库 40 年的演变！
☞毫秒间完成行为分析，飞猪端智能技术实践！
☞Windows 拥抱 Android，微软在下怎样的一步棋？