撰写于：2015年12月25日
作者：silex Wi-Fi专家

关于 IPv6(IP version 6)，我之前也已经多次提及过了。IPv6 的 RFC 是在 1995 年 12 月发布的，距今正好是 20 年前。上一次讲的是 TCP/IP（v4）辉煌的成功故事，而这次要讲的是 IPv6 的过去和现状。

关于IPv6

IPv6 最初是在1990年代，作为以拯救当时因消费急剧增长、IPv4 地址即将枯竭的互联网为主要目的的「IPng(IP Next Generation)」项目而开发的。相关工作以快速的节奏推进，1995 年 12 月，最初的 IPv6 规范作为 RFC1883 至 RFC1887 这 5 篇文档的合集被公布。 IPv6 基本上是作为将在 IPv4 中长度为 32bit 的地址扩展到 128bit（※注）的规范制定的。上层的 TCP 和 UDP 几乎没有变化，路由以及逻辑和物理地址的协作（IPv4 中的 ARP）也只是实现了对 IPv6 的支持，基本操作的概念直接从 IPv4 继承而来。据说关于这一点，和主张应该采用更先进模型的一派之间曾有过激烈的争论。不过，由于当时对预计在 2000 年左右就会枯竭的 IPv4 地址存在危机感，所以特意排除了新的要素，按照 “对于目前在 IPv4 中没有问题的部分不做改动” 的方针制定了规范，这便是其中的缘由。对于这个方针，我当时和现在都给予高度评价。

※注：在最初的 IPng 方案中地址长度是 64 比特，但由于担心即便这样地址仍可能会枯竭，所以就有了出于 “改成这样应该就没问题了吧” 的想法而将其扩展到 128 比特。另一方面，也有不少支持可变长度地址的声音，尤其是在支持 OSI 协议的 NSAP 地址（最短 64 比特～最长 160 比特）的一派之间，似乎曾有过激烈的争论。

IPv6 和 IPv4 的兼容性

另一方面，IPv4和IPv6之间并没有直接的兼容性。IPv4 和 IPv6 相同的地方仅仅在于 “运行原理的概念”，数据包头部的结构完全不同，在以太网中添加的协议编号也不一样。
 

IPv4 的头部结构
最小构成是5x32bit=20字节。
追加选项在目的地址之后添加，包含追加选项在内的头部全长记录在IHL字段中。
以太网中的识别代码是0x0800。

 

IPv6 的头部结构
最小构成是10x32bit=40字节。
追加选项采用独特的 “串联” 结构进行连接，头部长度固定。
以太网中的识别代码是0x86dd。

关于这一点也存在激烈的争论，似乎曾有人提出过这样的方案：通过将扩展地址 “隐藏” 在 IPv4 的扩展头部部分，来实现IPv4与IPv6的直接兼容。但这个方案被否决了。毕竟 “下一代 IP” 在过渡时期结束后可能还会持续使用数十年，甚至说不定是数百年，而让 IPv4 的兼容区域像“阑尾”一样长久地残留下去，这样的情况被认为是 “不美观” 的，似乎就是基于这样的判断。
 

IPv4/v6 混合头部方案
这是一个在 IPv4 的选项区域中存储两个 128 比特地址以及其他内容（＋α）的示例。
在这个例子中，头部长度为14x32bit=56字节。
以太网中的识别代码与 IPv4 相同，为0x0800。

刻意排除直接兼容性，这在某种程度上也像是 IPng 委员会表明 “在某个时间点要彻底舍弃 IPv4，完全过渡到新架构” 的态度。有人认为这种 “缺乏直接兼容性” 正是 IPv6 难以普及的根本原因，但我对此难以置评。即便采用了 IPv4/v6 地址可共存的混合格式，到头来 IPv6 字段说不定也会一直保持 0x00，仅作为 “未来扩展预留” 而不被真正使用。

（难以理解的）兼容地址

关于IPv4和IPv6的兼容性以及过渡期的应对措施，定义了两种类型：将 IPv4 的 32 比特地址纳入到 IPv6 的 128 比特长度中的 「IPv4 兼容地址」と「IPv4 映射地址」。然而，这两者都无法实现从名称上所想象的 “IPv4 设备与 IPv6 设备之间的通信”。“IPv4 兼容地址” 是指，用于IPv6设备通过IPv4网络进行“隧道”通信时的一种表示方法。它只是为了方便地表示IPv6设备在经过IPv4网络时所使用的地址，并不意味着IPv4设备能够与IPv6设备直接通信。“映射地址” 是指可以用 IPv6 地址的语法来表述 IPv4 地址…… 也就是说，不是写成 “192.168.0.1”，而是可以写成 “::ffff.192.168.0.1”，这只是一种表示上的便利，实际上发送到网络上的数据包是纯粹的 IPv4 格式。

如果按照 IETF 的预期，IPv6 专用设备得以普及并取代了互联网中的 IPv4 设备，那么 IPv4 专用设备就无法连接到网络了。不知是幸运还是不幸，截至 2015 年，情况尚未发展到那种地步。不过，即便真的到了那种情况，“IPv4 兼容地址” 和 “IPv4 映射地址” 也无法成为拯救老旧 IPv4 专用设备的办法。像这样的设备被称为协议转换器（翻译器），但 IETF 并没有制定协议转换器的相关规范。
我们公司考虑到可能会有这样的需求，开发了一款名为 “SX-2600CV” 的 IPv4 - IPv6 协议转换器，然而，“IPv6 专用网络兴起，导致 IPv4 专用设备陷入困境” 这样的情况根本就没有出现。

失去的十年

总之，IPv6 在 1995 年 12 月作为从 IP 地址枯竭危机中拯救网络的救世主登场了，但其实际应用却延迟了。起初，在 BSD 系列 Unix 系统上运行的 KAME 项目 事实上成为了先行的参考范例，而当时兴起的在 Linux 系统上的 USAGI 项目 ，比 KAME 项目稍晚，功能也比较薄弱。而且，最重要的是，当时占据压倒性市场份额的微软 Windows 系统，刚刚发布了标准配置了 TCP/IP（v4）的 Windows95 （※注）。Windows 系统中，IPv6 以功能受限的可选组件形式勉强得以实现，那已经是 Windows XP （2001 年）的时候了，而完整配置的 IPv6 被作为标准功能实现则更晚，要到  Windows Vista （2006 年）。

※注：在 Windows 3.1 及之前的版本中只支持 NetBIOS，为了连接到 TCP/IP 网络，需要购买并安装第三方公司生产的 TCP/IP 协议栈。这在现在看来真是让人难以置信啊。

可以说，IPv6 最初遭遇的挫折就在于微软 Windows 系统在对其支持上的滞后。从 1995 年末 IPv6 规范发布到产品将其作为标准配置实现，竟然花了长达 10 年的时间，这让人觉得微软并没有真心想要大力推进 IPv6 的发展。他们或许有自己的难处，但是由于 Windows 系统不支持 IPv6，网络服务提供商和周边设备制造商也都纷纷观望，没有跟进对 IPv6 的支持，结果在 IPv6 作为热门话题最具发展势头的 10 年间，几乎都白白浪费掉了。
这「失去的 10 年」对于 IPv6 来说是致命的。在这 10 年期间，“宽带” 得到了普及，家庭中也引入了路由器、以太网和 WiFi。这些设备都配有 IP 地址。这种情况原本就是预料之中的，也正因如此，考虑到 IPv4 届时会不够用才开发了 IPv6。然而，当实际情况真的发展到了这一步的时候，至关重要的 IPv6 普及却没能跟上，作为临时应急措施采用的 IPv4 的 NAT/NAPT 却得以固定下来。在 2006 年 Windows Vista 终于支持了 IPv6 的时候，又有多少人会想着 “那么从明天开始就不用 IPv4 了吧” 呢？至少我当时就觉得 “事到如今才说要支持 IPv6 啊……”。实在是太晚了，太迟了，本应该再早 5 年就做好应对的。

IETF的应对及其余波

IETF 并非对这种延迟现象坐视不管。不过，这种延迟似乎并没有被视为一种威胁，反而被当作是重新审视那些有些草率制定的 RFC1883 至 RFC1887 的好机会。从 1997 年到 2000 年左右，编号在 RFC2000 到 3000 之间的有关 IPv6 的 RFC 文档接连不断地发布…… 发布的速度之快，让人不禁想到「朝令夕改」这个词。Priority 字段被 Traffic Class 字段所取代，链路本地地址的划分规则发生了变化，站点本地地址在其定义几经反复之后被废除了。另一方面，提出了诸如移动地址、临时地址等好几种新的地址类型，为了对这些新地址进行统一管理，制定了堪称 RFC 中数一数二的复杂文档 ——RFC3484《Default Address Selection（默认地址选择）》。曾经以 “只要把数据包扔给默认路由器就能自动解决问题” 这种简洁性为傲的路由机制，在 RFC4191 中也追加设定了 Preference 值。
在主要操作系统（Windows）的 IPv6 实现延迟、普及进展缓慢的情况下，关于 “如果发生诸如○○之类的情况” 这种理论上的可能性的讨论及其对策相继被写进 RFC 文档，曾经在 RFC1883 时代以 “简单合理” 为傲的 IPv6 规范，因各种选项以及 MUST、SHOULD、SHOULD NOT、MUST NOT 等约束事项而变得复杂离奇，臃肿不堪。而在这一系列规范修订时期，具有代表性的功能是 IPsec 和 DHCPv6。

你应该听说过「IPv6 标准配备安全功能」这样的说法吧。这在 IPng 项目中也是引发激烈讨论的问题…… 在 “下一代互联网的基础规范如果不标准配备安全功能该怎么办！”“不，那还为时过早！” 这样的激烈争论之后，最终达成了 “将最低限度的安全功能作为标准实现” 的共识，把认证头 AH 和加密头 ESP 纳入了 “IPv6 全部功能” 之中。然而，这最终实际上成了一纸空文。这其中也有各种各样的原因…… 包括美国政府对最初选定的 DES 加密算法的管制，管制解除后 DES 加密算法的迅速过时，IPsec 尤其是 ESP 规范的频繁修订，密钥交换协议标准化的混乱等等…… 情况很复杂，不能简单地指责某一个因素是 “罪魁祸首”。但是，我认为它陷入了这样一个 IPv6 的延迟恶性循环：规范公布→实施延迟→在此期间 IPsec 规范被修订或新的加密算法被公布→反正实施已经延迟了，于是修订后的规范又被公布→实施进一步延迟。

另一个是 DHCPv6，它最初是被称为 “Stateful Autoconfiguration（有状态自动配置）” 的功能。在 IPv6 中考虑到了即插即用特性，也就是仅仅插入线缆，就能够尽可能自动获取网络所需的配置信息。对于 IPv6 地址和路由信息， Neighbor Discovery / Router Discovery 这样的自动配置流程在 IPv6 的核心规范层面被规定下来，并且是必须实现的。将这些内容统称为Stateless Autoconfiguraiton（无状态自动配置）。不过，人们认为也需要一个能进行更灵活、细致设置的配置协议，于是基于 UDP 运行的 DHCP 的 IPv6 版本 “DHCPv6” 作为 Stateful Autoconfiguration 被定义出来，而且它也被定位为必须实现的功能。
然而，DHCPv6 的制定却一直不断地延迟。DHCPv6 最初的规范 RFC3315 于 2003 年 7 月公布…… 距离 IPv6 公布已经过去了将近 8 年的时间。只是把 IPv4 中已有的功能移植到 IPv6 上，为什么会花费那么长的时间呢？从 RFC3315 的文本格式超过 200 千字节，行数超过 4000 行这一事实，我想大家应该能察觉到原因。DHCPv6 是一个 “过于努力” 的协议。它具备能够应对各种情况的多种多样的选项，并且试图以不容误解的严密表述来进行规范说明。我认为，DHCPv6 的精髓就体现在第 18.1.3 节中的这一句话里。

The client includes IA Address options in the IA option for the addresses associated with the IA.

...这到底是怎么回事呢。是把极其理所当然的事情写得无比复杂呢，还是把极其重要的事情删减到几乎让人不明所以的程度呢。总之，RFC3315 全文都是这种风格。仅仅是 “分配（多个）有期限的地址” 这样一个在 IPv4 的 DHCP 中凭借数十年的实际运行经验就能正常运作的功能，竟然被重新考虑得如此复杂，这让我感到惊讶、困惑，甚至绝望。简而言之，就是觉得「这可不行啊」。1995 年那种认真考虑 “互联网的未来”，不惜舍弃固执和颜面来制定现实可行规范的 IPv6 开拓精神已然丧失了。感觉现在变成了在远离开发现场的象牙塔里以撰写 “完美的规范说明书” 为目的了。

TACA 项目的来龙去脉

在 2000 年前后，当人们普遍认为 IPv6 即将真正大规模普及的时候，日本的制造业，尤其是家电制造商，曾憧憬着由 IPv6 带来的 “网络家电” 的未来。然而，在那个时候，像 ARM Cortex-M 这样的超廉价 32 位 MCU 还尚未实现实用化，在 8 位或 16 位的 MCU 上实现 IPv6 本身就是相当困难的事情。而且，如前面所述，正宗的 IPv6 相关的 RFC 一直在朝着愈发庞大和复杂的方向发展，要让 8 位或 16 位的 MCU 完全满足 IETF 所列出的 MUST，MUST NOT，SHOULD，SHOULD NOT 等一系列要求是非常困难的。
于是，在 2001 年，以日本家电制造商为核心发起了名为 “轻量 IPv6 规范” 的提案，这就是 TACA 项目 。TACA 是 “Tiny software and system Architecture for non-Computer Appliances（非计算机设备的微型软件与系统架构）” 的缩写，不过这也是遵循了当时日本 IPv6 相关项目的惯例，像 KAME、USAGI、TAHI 等都用动物名字命名，是一种文字游戏式的取名方式。它也被称为 LCNA (Low Cost Network Appliance)， 倒不如说在海外 LCNA 这个名称似乎更被人熟知。
那时我自己也在实现一套独立的 IPv6 协议栈，每当 RFC 更新时，那些突然增加的 SHOULD 和 SHOULD NOT 条款，以及为了严格遵循每一个字而不断增加的结构体标志和if语句，都让我苦不堪言。所以，对于作为 “日本首个”“实用型” 实现规范提案的 TACA 项目，我曾满怀期待。IPv6 参考实现项目 KAME 的成功，以及 IPv6 规范一致性检查系统 TAHI 的成功都是无比辉煌的，我曾认为日本终于要成为网络规范标准的输出者了。
然而，TACA 所面临的现实非常严峻。从会议记录中传来的是来自 IETF 的强烈拒绝。那是一场来自 RFC 中那些大名鼎鼎的人物的批判和质问的风暴。我感受到了一种无声的质问：“我们如此拼命地构建一个完美无缺的下一代网络规范，你们为什么非要推行这样一个不完整的东西呢？” 哎，其实恰恰是那种努力构建 “拼命打造的完美规范” 的行为，对于现场的工程师们来说，是好心办坏事、徒增麻烦，甚至成为了 IPv6 真正得以实现并应用于实际产品问世的障碍！？TACA 项目可是来自于直面这种两难困境的实际提案啊！？曾几何时，当 RFC 编号还是三位数的时候，你们不也是将 RFC 用作 “现场编写代码的工程师们交换意见” 的平台吗？你们不是还对自上而下制定的 OSI 规范的过程进行过那么多的批判吗？IETF 和 RFC，难道不是正在重蹈你们曾大肆批判过的 OSI 的覆辙，而且还变本加厉吗！？
我只是通过网络以旁观者的身份关注，并没有直接参加 TACA 的会议，也不清楚 TACA 的推进成员是否也有同样的想法。但现实情况是，TACA 项目迅速失去了发展的动力。最终，TACA 所提出的草案没有一个能够进入 Standard Track ，TACA/LCNA 项目仅仅持续了不到两年就结束了相关活动。

之后的 IPv6

IPv6 并没有走向消亡。如今，大多数操作系统都已对其进行了标准实现，而且据说许多网络服务提供商也具备了随时能够提供 IPv6 服务的体制。与 2000 年前后那种只高呼 “下一代互联网标准” 的口号，而实际实现却完全跟不上的情况相比，可以说 IPv6 如今已充实得多且得到了更广泛的普及。尽管如此，却依然没有让人切实感觉到 IPv6 “正在被使用”。一提到 “IP 地址”，人们仍然指的是十进制四位数的 IPv4 地址，而且面向普通消费者的许多低价路由器至今也仍只支持 IPv4。在交付的产品中，对于支持 IPv6 也往往只是在规格说明书上写上一句 “考虑到未来的兼容性” 就敷衍了事，实际上大多最终都没有真正实现对 IPv6 的支持。究竟为什么会变成这样呢？…… 回想起我曾对 IPv6 的未来满怀期待的 90 年代末到 2000 年代初，于是写下了本次的专栏文章。

就如同 IPv6 没有走向消亡一样，IPv4 的地址枯竭问题也尚未得到解决。即便在网络终端可以通过 NAT 来蒙混过关，但在广域网的连接点上依然需要全球地址，而这些地址正确实地朝着枯竭的方向发展。2011 年春天，亚太地区的地址库存耗尽，无法再进行新的地址分配。据说即便是拥有大量地址库存的美国，IPv4 地址枯竭也已为期不远。人们正在进行诸如挖掘和再利用已分配但未使用的 “休眠地址”，以及对地址空间进行重新划分和重新分配等令人心酸的努力，但这就像是把空的油罐倒过来收集油滴一样，可回收的地址数量是有限的。如果这些可回收的地址也用尽了，那么之后要么切换到 IPv6，要么就只能采用那种会让 IETF 的专家们气得满脸通红的方法…… 那就是把 NAT 路由器纳入骨干网络，除此之外别无他法。
向 IPv6 的迁移由于设备的兼容性问题以及相关技术诀窍的缺乏，导致成本难以估算，也有人说因此难以迈出实质性的步伐。嗯…… 是「缺乏技术诀窍」吗？从 1995 年末 IPv6 的 RFC 发布以来的 20 年间，我们究竟都在做些什么呢？总说着还早呢，现在太忙所以把问题往后推，这不禁让人想起 1999 年下半年开始陷入 “怎么办，怎么办” 的慌乱状态的 Y2K 风波。人类似乎意外地总是会多次重复同样的错误。

近来，诸如「IoT(Internet of Things)」「IoE(Internet of Everything)」之类的话题闹得沸沸扬扬，据说体重秤、空调、电饭煲等各种 “物品” 都将连接到互联网，而且还称会有多达数亿数量级的新节点接入互联网。各家公司已经提出了超过 20 种物联网连接协议，其中大多数都是着眼于地址数量会出现爆发式增长，因而以 IPv6 为基础（※ 注）。IoT/IoE 会与 IPv6 一起构建起 “新时代的网络” 吗？又或者说，“IoT/IoE” 这个说法本身，最终只会作为一个曾让社会为之骚动的流行词汇而告终呢？亲身经历过 IPv6 曾被寄予如此厚望、曾被认为成功无疑的历程，我深切地体会到预测未来是多么地具有不确定性。

※注：不过，在几乎所有已提出的 IoT/IoE 规范中，都是采用TLS/SSL来实现安全性的。这正是前面提到的“IPv6中IPsec安全性作为标准实现的说法，实际上是一张空头支票”。