0x00 常见问题IPv6 是否区分公网和内网？
网段毕竟是人为划分的，技术上一定是支持的，与是 IPv6 还是 IPv4 没有关系。将公网地址用在内网上也是可行的，这一点可以参见各地二级运营商宽带分配假公网 IPv4 的情况。由于 IPv6 地址储备丰富，运营商没必要为 IPv6 架设 NAT 设备（NAT 设备成本较高）。目前运营商给客户分配的 IPv6 地址多为公网地址，部分运营商支持分配整块独立的地址（/64，/56 或者 /48 前缀）。
IPv6 如何判断公网和内网地址？
目前已分配的公网地址开头形如：2xxx。
常见 2002（2002::/16）开头的是 6to4 地址，由用户端设备自动建立，通过隧道技术连接至 IPv6 互联网，不是运营商管理和分配的，服务质量与运营商无关。建立条件包括：拥有 IPv4 公网地址，设备支持 6to4 协议，且未被运营商封锁。
6to4 是一种 IPv6 转换传输机制，是将 IPv6 的数据包直接封装在 IPv4 的数据包中，并通过内嵌于 IPv6 地址的 IPv4 地址信息实现无需显式配置隧道就可以直接在 IPv4 网络上传输。同时一种特殊配置的中继路由允许其能与原生 IPv6 网络进行通信。
在从纯 IPv4 网络完全过渡到纯 IPv6 网络完全部署前，6to4 技术尤其重要，因为这请求主机和目标主机之间都不需要 IPv6 网络支持，但是这是一种过渡性的转换传输机制，并不意味永久使用。
6to4 可以使用在一台单独主机上，或一个本地网络上。如果是单独主机的话，则该主机需要一个非专用的公开 IPv4 地址，并且实现对 IPv6 数据包装解封，如果这台主机是服务于本地网并能转发本地网络其他主机的通信，则其作为该 IPv6 本地网络的路由器。
6to4 不利于仅支持 IPv4 的主机和仅支持 IPv6 的主机之间的互操作。6to4 只是一个透明机制，用作 IPv6 节点之间的传输层。
另有一种 6in4 隧道，其地址范围不固定，由服务商分配。提供此服务的运营商有 HE.net、台湾的中華電信 HiNet（非标准 6in4 隧道）等。HE.net 的隧道和 Microsoft 的 Teredo 隧道是以 2001 开头的。
6in4 是一种 IPv6 转换传送机制，是将 IPv6 的数据包直接封装在 IPv4 数据包中，通过 IPv4 链路一条明确配置的隧道中进行传送，相应定义在 RFC 4213 中（废除自 RFC 2893 和 RFC 1933）。这种 IPv4 数据包的 IP 协议号为 41，这个协议号专门定义为“IPv6 封装（IPv6 encapsulation）”，在 6in4 中，其 IPv6 的数据包比特串直接跟接着 IPv4 的数据包头ipv6转换服务，这意味着 IPv6 数据包的负载量需要腾出至少 20 字节用于 IPv4 数据包头作为封装开销。6in4 隧道又被称为“proto-41 static”，因为隧道端点是需要手动配置的，虽然如此，但也可以使用 AICCU 通过隧道信息与控制协议服务器通信获得配置信息来自动配置。
虽然名字相似、封装方法相同，6to4 是将终端的 IPv4 地址嵌入到其 IPv6 地址，代替使用手工配置隧道终端信息，从而实现自动传输，而 6over4 则将 IPv4 基础网络视为数据链路层，通过特定的多播地址在 IPv4 网络进行多播来传输。ISATAP 也同样使用相同的协议号和封装方法来封装数据包。
通过以上 2 种隧道技术获得的地址也属于公网 IPv6 地址，但它们不是由运营商提供的，而是用户端设备把 IPv6 数据包封装到 IPv4 的数据包中，再通过第三方 Broker 服务器中转来访问 IPv6 互联网，速度通常比较慢。
以下是一些常见的非公网地址段。
现有对 IPv6 支持如何？
Windows XP 就有支持，但默认并未开启。无论桌面端还是移动端，主流操作系统均早已支持。
家用路由器中，Netgear 与 Asus 等厂商的路由器均有原生支持，其它未支持的型号（支持刷入第三方固件）亦可通过使用 OpenWrt / LEDE 固件的方式实现支持。
以浏览器为代表的桌面端软件中，Internet Explorer、Firefox、Chrome 等主流均早已支持（Internet Explorer 6 时代即开始支持）。BitTorrent 方面，µTorrent 早已支持，使用教育网 IPv6 的用户多有用此类软件挂 BitTorrent 的历史（教育网 IPv6 试验网名为 CERNET2，于 1998 年开通）。吸血雷于 2019 年亦全面支持 IPv6。eMule 原本认定不支持 IPv6（ed2k 服务器不支持）[1]，不过 Kad 后续实现支持。
0x01 ULA
IPv6 号称“每一粒砂子都可以获得一个地址”，所有设备都拥有公网地址，NAT 不再是刚需。而 ULA（Unique Local Addresses） 的提出，是为了提供“内网地址”，这个标准出现的目的是？
IPv4 下的私有网络
很久以前，IPv4 也能实现点对点，对等互联（因为设备少）。彼时几乎所有互联网设备都可以拥有公网地址，早期的 FTP 协议甚至被设计为只能支持点对点连接的设备互传文件。
同时，IPv4 有 3 个私有网络（private network）地址段，10.0.0.0/8、172.16.0.0/12 和 192.168.0.0/16，所有人均可以在自己的私有网络中任意使用。在 NAT 技术普及前，这样的地址段通常只能提供内网通信，不提供互联网访问服务。需要访问互联网时，往往需要依靠同时接入内外网的代理服务器。
之后 IPv4 地址不够用了，IPv6 被提出，还顺带解决 IPv4 暴露出来的问题。然而 IPv6 与 IPv4 完全不兼容，普及缓慢。为缓解地址紧缺的问题，NAT44 技术被大量应用，收效甚好，甚至容易让人们忘记这只是为普及 IPv6 所做的暂时性措施。普通用户的公网地址被收回并高价卖给企业用户，越来越多的用户被安排进“内网”。再往后，“不提供公网 IPv4”成为某些 ISP 服务条款的常见内容。
内网地址下的终端设备丧失了在互联网上点对点互联的能力，只能主动向拥有公网 IP 的设备发起连接，无法被动接受连接，P2P 使用受限。
IPv6 下的私有网络和 ULA
IPv6 拥有 128 位长的地址，试图捡回本来应该属于互联网用户的东西——人人皆有公网。
IPv6 时代，ISP 依然会为普通用户提供“动态”的 IPv6 地址：每次接入网络时，ISP 会重新分配一个 IPv6 地址前缀，这会导致用户侧所有终端的地址发生变化。如果用户的终端设备之间存在内部互联，就可能因此导致服务中断。这就是需要 ULA 解决的问题。
方法很简单：利用 ULA，给自己局域网分配一个 IPv6 的内网地址段。这和使用 NAT 有所区别：IPv6 当然可以 NAT，可以在终端分配内网 IPv6 地址，然后在网关部署 NAT66，重回 NAT 时代。不过通常而言，NAT66 没有必要，而且使用 NAT 技术还会造成非常明显的性能损失。在 IPv6 时代下，可以为每个网络接口分配多个 IPv6 地址，因此局域网中的设备可以同时持有公网地址和内网地址。
IPv6 提供一段称为 ULA（Unique Local Address）的地址段 fc00::/7，包括 fc00::/8 和 fd00::/8 两部分，fc00::/8 为待定义状态，因此应当使用 fd00::/8，地址段相当庞大，使用时需要从中选取一个 /48 的子网段分配给局域网。RFC 4193 建议使用随机生成的方法，使每个局域网的地址段都不同（这也是 ULA 名字的由来），从而避免局域网合并时地址冲突的麻烦。这主要是针对企业环境而言的，对于家庭使用的简单场景，随机生成或选择容易记忆的子段均可。许多在线工具都提供了生成随机子段的功能。
被分配 ULA 后，局域网设备互访可使用固定的 ULA，和外部互访则使用公网地址（默认路由表就应当使用这样的逻辑）。
为何不使用 link-local？
可以注意到局域网设备会持有 link-local 地址，即 fe80 开头的地址，但大量应用软件不支持使用 link-local 地址。有的软件不支持 zone index 后缀，如 fe80::2233:2233%eth0，典型案例是 Linux 的 DNS 配置中 /etc/resolv.conf 不支持这种写法。有的软件主动禁止在 link-local 地址下工作，如 Kubernetes。
子段大小调整？
家用网络使用一个 /48 子段似乎还是大材小用了，使用一个 /120 子段（256 个地址）也绝对够了，但是当前缀大于 64 时，无状态地址配置将不可用，只能使用 DHCPv6。
当连接到 IPv6 网络上时，IPv6 主机可以使用邻居发现协议对自身进行自动配置。当第一次连接到网络上时，主机发送一个链路本地路由器请求（solicitation）多播请求来获取配置参数。路由器使用包含 Internet 层配置参数的路由器宣告（advertisement）报文进行回应。
在不适合使用 IPv6 无状态地址自动配置的场景下，网络可以使用有状态配置（DHCPv6），或者使用静态方法手动配置。
“无状态”和“有状态”均属于自动分配 IPv6 地址的策略，仅针对分配，不包含其它参数。
在这种前提下，配置就存在 3 种方式。
无状态地址配置不可用会带来一些负面影响。如 Android 不支持 DHCPv6，对 Android 设备的地址分配会遇到困难；上游路由器重新拨号导致前缀变更后，通过 DHCPv6 下发的地址可能因租期未到而未能及时更新，从而导致下游设备持有无效 IPv6 地址。
关于 Android 是否加入 DHCPv6 的讨论如下。
0x02 PMTU
访问网站时，虽说可能存在支持 IPv6 的服务器、CDN 节点不够多的问题，但不至于卡顿影响正常使用。若出现，则需要排查是否由链路上的 PMTU 黑洞问题导致。
PMTU 黑洞
MTU（Maximum Transmission Unit）是一条链路上可以通过的三层数据包的最大尺寸（包含 IP 头信息）。以太网上的默认 MTU 大小为 1500 字节，但是用户和所访问的目标服务器之间的完整链路上可能存在 MTU 小于 1500 的部分，将整条链路上的最小 MTU 值称为此链路的 PMTU（Path Maximum Transmission Unit）。路由器在转发包时，遇到超过 MTU 大小的包会进行分片（Fragmentation），也就是拆成多个小于 MTU 的包再进行传输，这会降低传输效率。
终端设备在发包时，也可以设置 DF（Don’t Fragment）标记位来强制路由器不要分片，这时中间路由器会丢弃超过 MTU 的包，回复一条 ICMP Fragmentation Needed 数据包。发送者收到这个数据包后，之后会发送尺寸较小的包，这个反馈过程被称为 MTU Discovery。现实中的 HTTPS 流量通常带有 DF 标记。
然而，互联网中存在大量设备“出于安全考虑”设置或没有正确配置，不回应 ICMP Fragmentation Needed 包，导致用户访问某些网站时发送的超过 PMTU 大小的包被静默丢弃，直到 TCP 协议发现超时丢包触发重传，又增加了时间成本。这种情况，可以称为用户和所访问的目标服务器路径上存在 PMTU 黑洞。
由于 IPv6 不支持分片，可以理解为 IPv6 下的所有包都是带 DF 标记的，中间路由器遇到超过 MTU 限制的包时，应该回应 ICMPv6 Packet Too Big 数据包，同上，由于种种原因，某些中间设备可能会直接丢弃而不回应 ICMPv6 Packet Too Big 数据包，直到 TCP 协议发现超时丢包进行重传。
IPv4 是否有此问题？
有。使用 OpenWrt 搭建软路由的用户常常能见到这个问题，表现为访问某些网站时非常慢，有些能通过更换 DNS 解决（毕竟换 DNS 可能导致解析出来的目标 IP 不同），或者换用硬路由也能解决，但从另一个角度观察这个问题，就是原有链路上存在 PMTU 黑洞。多数家用路由器默认对 IPv4 下的 TCP 启用了 MSS Clamping，MSS 即 Maximum Segment Size。MSS 的意义和 MTU 相近，但 MSS 限制的是四层段数据的最大尺寸。
有时，网络路径上的路由器设置的 MTU 值低于典型的 1,500 字节。这可能会导致数据包丢失并且很难被发现。
为了确保数据包在这种情况下仍能到达目的地，一种选择是减少传入数据包有效负载的大小。这可以通过配置服务器以应用 MSS 限制来实现：在 TCP 握手期间，服务器可以向 MSS 发送它愿意接收的数据包的信号，“限制”来自其他服务器的最大有效负载大小。例如，如果服务器 A 和 B 正在建立 TCP 连接，并且服务器 B 通信的 MSS 为 1,436 字节ipv6转换服务，则服务器 A 将在连接期间发送最大有效负载大小为 1,436 字节的数据包。
MSS 限制的另一个应用是在 GRE 隧道的情况下，将 24 字节的标头添加到原始数据包中，以便将其发送到新的目的地。如果原始数据包大于 1,476 字节，这可能会使新数据包超过典型的 1,500 字节 MTU；即使在应用了 GRE 标头之后，也可以应用 MSS 限制来要求传入数据包小于 1,500 字节。
MSS Clamping 是针对 PMTU 黑洞的缓解办法，简单来说就是 TCP 握手时有个 MSS 字段决定单个 TCP 包的最大尺寸。路由器可以通过嗅探 TCP 握手包，把 MSS 值改小，使最终的三层 IP 包的尺寸（ MSS + TCP 头大小 + IP 头大小）不超过某个特定的值。
结论
当前国内 ISP 一般通过 PPPoE 虚拟拨号建立 WAN 口连接。以太网默认 MTU 为 1500，但 PPPoE 隧道有 8 个字节的开销，所以 PPPoE 虚拟连接的 MTU 为 1500 – 8 = 1492。在此基础之上，减掉 IPv4 包头的 20 字节 和 TCP 包头的 20 字节，可知 IPv4 下需要把 MSS 设置为 1452 以下。IPv6 的包头为 40 字节，因此 IPv6 下的 MSS 应当设为 1432 以下。
许多现有的光猫、家用路由器对 IPv6 缺乏优化，无法在 IPv6 下对 TCP 执行 MSS Clamping，就导致访问 IPv6 网站时，若路径中存在 PMTU 黑洞，则打开很慢。由于目前运营商给的光猫、家用路由器的硬件素质和固件问题，若想在日常生活中使用 IPv6，最好将光猫改成桥接模式，然后自行加装使用 OpenWrt 或 VyOS 这类对 IPv6 支持较好的软路由。
0x03 言论
一些针对 IPv6 发展状态的旧时言论。
云云。
参考资料
[1]
不支持 IPv6（ed2k 服务器不支持）:
限时特惠：本站每日持续更新海量各大内部网赚创业教程，会员可以下载全站资源点击查看详情
站长微信：
相关文章
