闲谈IPv6-我们在技术思维上需要作出改变(1)

浙江温州皮鞋湿，下雨进水不会胖。

IPv6时代即将来临，这是一个新的时代，需要我们在很多方面作出改变，《闲谈IPv6》系列文章准备抽出几篇，专门来描述这些个IP协议本身的变化，以及我们需要作出什么改变来应对这些变化。

IPv6强网络而弱主机

这个是非常重要的，我也是一直在强调这一点。

在IPv4时代，你很容易将一个IP地址对应到一台主机，比如给出一个IP地址100.123.201.34，我们脑海里很容易会有 它被配置在某个地方的某一台设备上 的印象。如果我们给出一个私有段的固定前缀192.168.188.123/24，不用说我就能知道这个网络里有最多253台设备，这个.123只是其中一台，假设我能通过某种方式进入到这个内网，我很容易就可以对全网进行一次暴力扫描…

但是IPv6时代，不一样了。

IPv6地址包括两个部分，其中高64位是网络位，而低64位则为主机位，也叫做标识符，IPv6地址分配机制只管高64位的分配，低64位的标识符则由主机自己来保证唯一性。标识符的生成算法包括但不限于：

EUI-64规则根据MAC地址生成，用于一般局域网或者物联网
低碰撞的随机数算法随机生成，用于生成临时地址实现隐私扩展
人工配置保证唯一，用于配置一个服务器集群
anycast地址，全0，本来就可以多路访问
…

当然了，IPv6新手估计还不太习惯这种方式，他们一般都会像管理IPv4网络那样去管理IPv6网络，比如说它们会对一个64位长度的IPv6前缀的低64继续进行子网分割，比方说他们会用下面的网段指示一个IPv4的C类子网：
2034:1:123::0a01:1200/126
留253台主机嘛…

完全可以这么配，但是标准却非常不建议这么乱搞。还是那句话，IPv6并不仅仅是把地址空间从32位扩展到了128位这么简单。

我们来说说IPv6的网络标识，主机标识相分离带来了什么改变。

IPv6地址很难被跟踪溯源
IPv6地址又很容易被跟踪溯源

完全相矛盾的说法，但是这就是真相！

为什么很难被溯源？因为给出一个IPv6地址，你根本就不知道它的主机标识符是如何生成的，你甚至不知道它的主机标识符是不是真的被用作了标识主机而不是编码了别的信息，比如用于子网划分。

如果运营商给了你一个64位前缀的段，你看到一个IP地址，你只能知道这个IP地址是 $2^{64}$ 个地址中的一个，仅此而已。如果你自己在这个空间中随机生成了几个标识符作为临时IPv6地址去连接一台固定的服务器，那么当这个临时地址过期后，它就永远地消失了。

你用同一台设备生成不同的主机标识符去连接服务器，服务器会知道这是同一台机器吗？不会。

另一方面，如果你使用EUI-64生成主机标识符，即便你改变了你的物理位置，你的网络标识符发生了改变，只要你依然使用EUI-64生成主机标识符，由于MAC地址的全球唯一性，依然可以定位到你的设备。

也正是因为这个原因，才有了IPv6的隐私扩展，实现了一种使用临时地址访问服务器的方式。

64位主机标识符空间比整个IPv4的地址空间都要大得多，这种指数级的地址空间扩展背影下，是你完全想像不到的新玩法。思维方式必须改变。

不是有人说过吗，如果所有的IPv4地址可以装入一个BlackBerry，那么需要地球这么大的存储介质才能存完IPv6地址。

想象一下，如果IPv6地址也像IPv4那样管理全部128个比特位，那么为了存储这些管理信息和元数据，我们真的找不到地球这么大的存储介质啊！这又是一个 电梯比办公室还占地方 的例子。

所以，思维方式必须改变。当我们看到一个IPv6地址的时候，我们必须同时看到这两部分的信息。我们必须自己接管IPv6地址部分管理，这是理解和使用EUI-64，隐私扩展，anycast的关键。

组播替代广播

要说为什么，很简单，因为在IPv6网段广播的代价太大了！

按照IPv6的编址规则，全世界所有的主机都可以被放在同一个::/64的子网中。运营商确实可能会给你一个::/64的段，虽然你不可能拥有 $2^{64}$ 台主机，但至少你可以将 足够多 数量的主机塞进去！到底是多少，反正是个天文数字。在概念上，如果底层是一个广播式的网络，你就有可能有能力用广播去做一些事情，比如解析MAC地址。

IPv6本来就是为拥有海量物件的物联网设计的，说实话它真的不太适合用人惯常的思路去理解其某一个特性。

IPv4和以太网都是为人设计的，它们天然地走在一起，承载的其实都是人使用的电脑，基本上这个电脑的数量和在同样的区域内可以承载的人的数量是一致的，至少数量级是一致的。

在一个以百米论的空间中，以平均舒适的环境来算，去除建筑物，家具等占据的空间，大概会有百级别的人会同时使用这个空间，电脑的数量大概也就是这个数量级，而我们的以太网双绞线信号有效传输范围同样恰好也是这个距离，对于其承载的IPv4网络，这大概也就是个C段或者几个C段，我就说20位前缀长度足够了吧，可以容纳 $2^{12}-2$ 台主机。

OK，这就是了，百米论的范围内的 交换式以太网 在不影响传输质量的前提下完全有能力承载百余台主机使用广播来解析MAC地址！这就是为什么IPv4的ARP可以使用广播的原因。

其实，在界定这些个恰好的数字之前以及之后，以太网配合IPv4也是经过了若干次的进化，我们先看看这些恰好的数字：

做同一类事情的人的活动范围：100米-500米
以太网10BaseT/100BaseT的传输距离：大概100米-500米
百米方圆不影响舒适度前提下容纳的人数：50人-200人
人数和主机数量的对应关系：1人一般拥有1台主机办公
IPv4的C类网段容纳主机数量：200余台

这些数字恰如其分地耦合在了一起，让广播式ARP协议在以太网上服役到了现在。但是这些数字随着社会和科技的进步，会发生变化，如果其中一个发生了数量级的变化，其它的技术就必须作出调整以适应这种变化。我们通过以太网的进化来看一番：

CSMA/CD时代
编码继续的进步，社会需求的增加，接入以太网的主机变多了，总线式以太网信号冲突太厉害了，主机数量越多，越冲突，为了适应更多的主机接入，必须进化
交换式以太网时代
隔离了冲突域，解决了信号冲突的问题。但是广播域还是一个，随着线缆有效传输长度的增加，同时主机数量的继续增多，频繁的ARP广播将会严重影响性能，必须进化。
当然了，ARP广播对性能的影响只是进化之一源泉，还有管理和安全上的考虑。
VLAN时代：
以太网配合IP又一次作出了突破性的创新，这就是VLAN技术，把广播域也给隔离了。

最终，我们回望那些恰巧耦合在一起的数字，虽然主机多了，线缆长了，但是广播域并没有扩大，VLAN技术让一切回到了最初，依然是那些数字，唯一不同的是，以太网换成了VLAN，普通交换换成了三层交换。广播域大致还是那么大，一切都还hold住！

但是IPv6让广播变得不再可能。它一开始预留64位主机标识符的时候就切断了广播的路子。

广义的来讲，广播和组播都属于多播，不管怎么称呼，技术上迫切需要解决的就是 在必须使用多播的时候，限制多播域的范围。

显然，IPv6在地址解析时，并不知道目标MAC地址，在基于目标MAC地址收包的以太网环境下，为了让 相关的主机 收到这个请求报文，必须用多播MAC地址。而多播MAC地址可以由多播IPv6地址映射而成。IPv6的目标是， 使得接收并处理这个请求的主机尽可能地少！ 在IPv6中，Solicited-Node组播地址指示都有谁可以收到这个请求报文。

IEEE的MAC地址构造恰好让这个要求得到了满足。

MAC地址高24位是OUI，这个每一个网卡厂商大概分配一个，可以从下面这个站点获取哪个厂商分配了哪个OUI的信息：
http://standards-oui.ieee.org/oui/oui.txt

比方说，00-03-47这个是Intel的OUI，只要你看到你的网卡的MAC地址的高24位是这个数字，那它就是Intel的网卡。

在这个意义上，MAC地址的构成和IPv6地址的构成异曲同工！都是分为了两个部分，低一半的比特空间都是一个 个体标识符 ，高一半的比特空间是 组织标识 。

理解了这个，我们就知道，存在一类特殊的组织，它们并不生产网卡，但是它们却需要MAC地址，比如IANA，这是一个管理IP地址分配的组织，它需要MAC地址做什么？

答案就是 做地址解析 。

这段地址就是： 01-00-5E-00-00-00～01-00-5E-FF-FF-FF (最高字节的最低位为1代表多播)

IANA的意思是希望， 给出一个IP地址，就能映射成一个组播MAC地址！ 这简直太妙了！

我们知道IPv4地址中，224.0.0.0/8是一个组播地址段，那么给定一个IP地址192.168.78.20，如何将其映射成组播MAC呢，很容易，最简单的映射方法就是：

192.168.78.20映射成组播IP地址224.168.78.20；
组播IP地址224.168.78.20映射成组播MAC地址0x01-0x00-0x5e-168-78-20

我勒个去啊，IPv4用这中方式去做ARP岂不是要比广播更好吗？比如说要解析IP地址192.168.78.20的MAC地址，只需要以下步骤：

用224.168.78.20封装IP头的目标IP地址
用0x01-0x00-0x5e-168-78-20封装以太头的目标MAC地址
发包

这个实现比ARP要好，因为它使用标准的IPv4协议封包，要比独立的ARP优雅很多。但是有个前提，一旦一个IP地址被添加到一个网卡，该网卡就必须加入一个组播组，该组播组由IP地址就可以获得。

但是IPv4没有选择这种方式，它依然采用了ARP广播的方式！Why？因为简单！

对于IPv4而言，一共就4个字节，取3个字节来做组播组映射，其实和单播差不多，平添了组播管理的复杂性，于是，简单占据了上风！组播被抛弃！

IPv6来了，IANA的组播又回来了！

我们来看一下RFC3513中IPv6地址解析时使用的组播地址的生成细节：

Solicited-Node Address: FF02:0:0:0:0:1:FFXX:XXXX

Solicited-node multicast address are computed as a function of a
node’s unicast and anycast addresses. A solicited-node multicast
address is formed by taking the low-order 24 bits of an address
(unicast or anycast) and appending those bits to the prefix
FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the
range

FF02:0:0:0:0:1:FF00:0000
to
FF02:0:0:0:0:1:FFFF:FFFF

For example, the solicited node multicast address corresponding to
the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C. IPv6
addresses that differ only in the high-order bits, e.g., due to
multiple high-order prefixes associated with different aggregations,
will map to the same solicited-node address thereby, reducing the
number of multicast addresses a node must join.

A node is required to compute and join (on the appropriate interface)
the associated Solicited-Node multicast addresses for every unicast
and anycast address it is assigned.【最后这段是关键】

简单点说，IPv6发送地址解析请求(叫做邻居请求)的时候， 只有IP地址共享低24位的节点 才会被骚扰到！那么在一个::/64的超大子网中，按照概率算，一个节点被打扰到的概率只有 $0.5^{24}$ ，已经很低了。

要说为什么是低24位，为了迎合IANA的MAC组播地址格式呗，毕竟6字节的MAC地址除了OUI之外，只有3个字节的空间可供填充，索性就用完了它！

假设组播MAC地址没有3个字节24位的限制，我们再看一下为什么低24位映射组播地址就够了。

我们看到IPv6用一个 共享IP地址或者说主机标识符的低24位 作为一个邻居请求组播组的特征。那么为什么是24位，为什么不是1位，为什么不是4位，或者干脆为什么不是64位？

我们先从1位开始，一个比特，非0即1，只有两种可能性。共享最低1位意味着一个子网内有 $\dfrac{1}{2}$ 的节点可能被这个邻居请求打扰到，如果是共享低2位呢，那么这个比率将变成 $\dfrac{1}{4}$ ，共享的比特数越多，被打扰到的主机就越少。

我们来看另一个极端，即共享全部的64位主机标识符，那么由于主机标识符在一个子网内要保证唯一性，那么这个邻居请求便成了单播！岂不是非常明确了吗？为什么还要用 共享IP地址或者说主机标识符的低24位 的组播呢？

其实上面 使用64位很方便 的说法，我们默许了一个前提，那就是主机标识符都是通过EUI-64生成的。MAC地址和EUI-64标识符严格一一对应！但事实上，这并不能保证：

如果使用临时地址呢？
如果使用anycast地址呢？
如果使用手工配置的主机标识符呢？
…

上述情况，MAC地址和IPv6地址的主机标识符将不会有任何关系，你将无法从目的IPv6地址中解出其MAC地址！为了解析出MAC地址，还是要 用发组播的方式实际上发单播 ，问题又和IPv4一样了。

是IP路由还是邻居解析

IPv4中，我们知道数据包基于IP路由技术逐跳路由到目的地，但是在IPv6中，我们最好换一种理解这个过程的方式。

既然IPv6将网络和主机分开了，那么最好把它们的寻址技术也分开理解的好。

在网络上，IP路由依然在进行着，随着数据包被越来越近地推向目的地，前缀越来越推向目标地址的低位，最后当剩下64位的时候，就意味着数据包已经离开了网络，接下来的过程将不再是IP路由的过程，而是邻居解析的过程了！

以上这个说法不是我自己的杜撰，而是最初OSI模型的设想。详情参见我的这篇文章：
OSI/RM模型的编址方案与TCP/IP编址方案的对比： https://blog.csdn.net/dog250/article/details/62443365

看下面的图示，表示OSI模型是如何定义网段的：
在这里插入图片描述

IPv6与此类似。与IPv4不同， OSI/RM和IPv6都不是用路由器接口来作为网段边界的，而是用两个直连路由器接口的中点作为网段的边界。这是理解Anycast的关键！

最后一跳的路由并不是靠的IP路由，而是靠的邻居解析。如果没有理解这个，你总是会觉得Anycast其实是一种地址冲突！如果你理解了邻居解析会IP路由的不同，就会明白，只有IP路由才会害怕地址冲突！

IPv4，确切地说也和这个差不多，你也可以说ARP也是一种邻居解析的过程，但是确切地说，ARP之所以可以解析到MAC地址，完全是因为有一条IP路由的存在才有可能，这条路由就是 链路层路由 。而IPv6则不太依赖这个链路层路由，而是依赖了 Solicited-Node组播 来做邻居解析，这是本质的不同。

之所以我会强调这一点，是因为早在很久以前学习IPv4路由的时候，我就曾经对这 最后一跳寻址 的与众不同持有疑问…

更安全了还是更危险了

我们长期待在IPv4的NAT庇护者之后，早就忘了互联网其实是对称对等的，甚至我们很多人都不知道公网地址怎么玩。

直接上公网IPv4地址意味着什么？完全不知道。因为没有必要。

我们被NAT保护着，外面的非法连接和攻击被NAT挡掉了绝大部分，以至于我们天然认为互联网是适合裸奔的。但是，你有没有感受过正常情况下你要连进内网时的那种遗憾和无助？

如果你想连入内网，你大致需要三样东西中的其中一样：

uPnP服务
TCP/UDP打洞
在网关上配置一条端口转发规则

这些都是很复杂的东西，且不好玩。这些技术并不是给人们带来收益的，相反，它们是解决某种技术缺陷而引入的拆东墙补西墙的技术。我对这种技术是比较反感。

NAT本来就是转换一下IP地址而已，然而为了实现上的简单以及为了便于多个内网IP复用同一个外网IP，它却为无状态的IP协议引入了连接状态跟踪，这种连接状态跟踪有个副作用：

它识别了连接的方向

因此，后果就是，所有从外向内首先发起的数据流无法匹配到既有的连接状态，同时也无法出发新的连接状态跟踪的创建，这给人的感觉好像是NAT网关主动保护了内网，阻止了外部数据请求进入内网一样，其实， NAT带来的安全是感觉上的，它是一种副作用！它不光阻止了恶意的连接，同时也阻止了授权的连接！

想安全就上TLS，就上防火墙啊，这才是正道。

进入IPv6时代，这种NAT带来的额外的安全不存在了。因为没有NAT了，所有的IPv6数据报文都可以从任意地方被路由到任意地方，你从公司的电脑就可以直接访问家里电视的IP地址，当然，其它人也可以。这让人感到不适。

IPv6数据报文在整个生命周期是不会改变的！

这是不是意味着IPv6相比IPv4更加不安全呢？非也！再说一遍，IPv4只是让你感觉到安全，它是NAT的副作用带来的。

常常听说，IPv6自带IP端到端安全机制。那么这种安全机制到底何在？

IPv6对IPSec提供了天然的支持，而不再需要再像IPv4时那样通过打补丁或者通过Netfilter，xfrm框架来实现。在IPv6协议中，IPSec是标准的 协议头，协议栈不得不去按照像TCP那样的实现去实现IPSec。

这意味着， 如果你想获得安全保护，你必须自己动手！ 没有谁会帮你把IPsec的ESP头插入到你的TCP头之前，保护你的IP载荷，这些你必须自己来做。因此，如果你想获得IP端到端的安全，你就必须要懂IPSec的运作方式，如果你不这么做，那你就是裸奔了…

且慢，也不全是裸奔。你还可以去信任经由网络的防火墙！

但是，IPv6时代，防火墙何尝不是同样也需要改变！防火墙同样面临着挑战。

IPv6在编程意义上的新玩法

曾经，我以为互联网公司的人不是很懂网络底层技术，只懂照着需求文档和设计文档编程，后来我发现互联网公司的人其实更在意产品和变现，至于说什么网络协议栈技术，编程，那都是手段。

这是基因里面的东西。你不能指望他们去写波音737 Max的飞控，然而他们至少可以做抖音。

一个互联网公司的高级工程师，怎么可能懂什么BGP，他们接触过大规模路由注入吗？他们懂水平分割吗？他们知道IBGP如何优化吗？曾经，像腾讯这种外界传播的典型有产品无技术的互联网公司所做出来的类似DCI传输协议的东西，放在华为中兴这种老牌网络通信厂商看来，就是业界的笑话。

基于此，我曾经也说过，随便一个华为核心网络部门的售前都可以吊打腾讯的技术专家(别不信，真事儿)，确实是。

腾讯的专家想的是数据到了我这里，我该怎么高效处理，而Cisco，华为的人想的是，数据如何高效的怼到你那里！

完全不同的好嘛！你理解成接力也可以。

我的这种偏见，在正儿八经云管端的IPv6时代，必须改变。

去年年底我适配了一个基于Netfilter的内核模块，使它支持IPv6，我曾天真地以为，只要把IP地址改了就可以了：
从32位的IPv4地址，从下面的样子

/* Internet address. */
struct in_addr {
    __be32  s_addr;
};

变成新的形式：

/*
 *  IPv6 address structure
 */

struct in6_addr {
    union {
        __u8        u6_addr8[16];
        __be16      u6_addr16[8];
        __be32      u6_addr32[4];
    } in6_u;
#define s6_addr         in6_u.u6_addr8
#define s6_addr16       in6_u.u6_addr16
#define s6_addr32       in6_u.u6_addr32
};

这样就足够了。

是的，我也是这么做的，并且这种烧锅炉的活儿，只要花时间，闭着眼睛都是可以做完的。

也确实，如此便完成了任务，但是我错过了很多精彩的东西！

我错过了什么？我错过了IPv6的几乎所有新特性！

我该如何获得这些新的特性，前文已经说过， IPv6报文在其生命周期内是不会改变的！ 那么，如果我想注入而不是仅仅处理一个报文的一个IPv6所特有的特性，就必须在报文的始发站进行，如何来做？只能靠编程来解决。

比如说，IPv6的相关socket API就增加了很多的sockopt，来让你通过程序使能或者禁用某种IPv6的特性，所以说，在我们从IPv4向IPv6改造的过程中， 绝不仅仅是换一个地址那么简单！

IPv6的链式处理方式，决定了必须有一种可编程的方案让程序员可以操作这个协议链，而不像IPv4那样在中间节点对数据包各种mangle(虽然说IPv4也能进行链式处理，但基本都是靠HOOK机制，比如Linux的Netfilter，Windows的NDIS中间层协议驱动，而不是原生的应用层编程方式)。

哈哈，我还曾经以拥有可以任意HOOK并mangle数据包的能力而自豪，比方说去掉TCP的时间戳选项以支持NAT，现在看来，不过是笑话。

我曾经在几年前做一个网络项目时就曾吐槽过一群程序员不懂BGP，一群网管不懂panic和gdp。现在，一个IPv6程序员如果想利用IPv6那些好玩的特性，就不得不懂网络传输的细节了。他不可能简单写一个socket程序，能连接对端服务器就算懂网络了，他必须知道各种sockopt代表什么含义，能带来什么副作用，这些sockopt在中间节点会被如何处理，换句话说，他必须懂网络！

可以使用ULA组建网中网

曾经，我为一个金融城域网编写和部署VPN，实现传输加密。

我不得不使用172.16.0.0/16这个私段的地址去管理节点，并且很大程度上是人工管理…使我不得开心颜。

IPv6有了ULA，效果太好了！我可以用ULA在公网上组建内网了。什么是ULA？

FC00::/7
| 7 bits |1| 40 bits | 16 bits | 64 bits |

足足40位的GlobalID来定义地址啊！仅仅这个数字就足以吊打所有IPv4地址空间的地址总量了！

ULA是IPv6地址空间中的一个段，它的用法和其它的全球全局地址完全一致，唯一的不同是，它只能在内部被使用和被路由，如何定义这个 “内部” 呢？看看RFC4193怎么说：
https://tools.ietf.org/html/rfc4193

Local IPv6 addresses are designed to be routed inside of a site in
the same manner as other types of unicast addresses. They can be
carried in any IPv6 routing protocol without any change.

It is expected that they would share the same Subnet IDs with
provider-based global unicast addresses, if they were being used
concurrently [GLOBAL].

The default behavior of exterior routing protocol sessions between
administrative routing regions must be to ignore receipt of and not
advertise prefixes in the FC00::/7 block. A network operator may
specifically configure prefixes longer than FC00::/7 for inter-site
communication.【重点！重点！重点！】

If BGP is being used at the site border with an ISP, the default BGP
configuration must filter out any Local IPv6 address prefixes, both
incoming and outgoing. It must be set both to keep any Local IPv6
address prefixes from being advertised outside of the site as well as
to keep these prefixes from being learned from another site. The
exception to this is if there are specific /48 or longer routes
created for one or more Local IPv6 prefixes.

For link-state IGPs, it is suggested that a site utilizing IPv6 local
address prefixes be contained within one IGP domain or area. By
containing an IPv6 local address prefix to a single link-state area
or domain, the distribution of prefixes can be controlled.【重点！重点！重点！】

将ULA限制在内部的方式就是，BGP忽略ULA通告！

如果一个 内部网络 (比如金融网…)希望和公网进行隔离，那就用ULA吧，反正你的网段不会被通告出去，别人自然进不来。

至于说连通性，可以用个隧道连接，也可以让运营商做策略路由，路子很多。

管理变得更轻松了

IPv6拥有更长的地址，那么它的路由管理是不是更加复杂呢？

事实上，是更简单了，管理员也因此变得更加轻松了。

IPv6的路由表项更少，收敛更快，更不容易出错。IPv6地址在分配的时候就要严格要求按照层次化聚合分配，地址段不得在同级别机构之间互相转移，从而不允许在不同的AS之间互相转移。这种聚合分配直接简化了路由。

地址聚合进而路由聚合，这很容易理解。因为地址是通告路由通告的，而BGP的AS以及IGP的Area往往也和地址分配机构保持同样的层次结构。

比如有如下路由：

2004:444::0/32 via S0

那么它的所有子网的路由均应用via S0，不允许像IPv4那样由于地址飘到了别的AS，不得不在聚合路由项里抠出一个前缀更长的洞，从而增加一条路由。

我们必须摒弃掉很多以往管理IPv4网络时的Trick习惯，用简单的方式去理解IPv6，简单就是美。

5G的挑战

风口浪尖上，很多人把5G和IPv6联系在了一起。

确实，在海量终端接入这个维度，他俩是异曲同工，5G改变了编码和信道的使用方式，IPv6改变了节点的接入方式，一切都为海量接入而来！

大家都是为了迎接 物联网 ，但是谁更真实？我们又该如何来看二者是怎么相辅相成，这些，我想留到下一篇软文去解释。

现在，夜深人静，能说的只有一句话，浙江温州皮鞋湿，下雨进水不会胖。

嗯，浙江温州皮鞋湿，下雨进水不会胖！