IPv6 现代栈

IPv6 地址 128 bit，写成 8 组 4 位十六进制。每组可省前导零；连续的全零组只能用一次 :: 压缩。没有广播，广播的活交给组播。

单播三类：GUA / ULA / LLA

Zone ID：fe80::1%en0

链路本地和有限范围组播在节点上可能对应多条链路。RFC 4007 规定文本形式 <address>%<zone_id>。zone id 只在本机有意义：macOS / BSD 常用接口名（en0），Linux 用接口名或 ifindex（eth0 / 2）。% 后面那截不上线，抓包里看不到。

组播 ff00::/8

   |   8    |  4 |  4 |                  112 bits                   |
   +--------+----+----+---------------------------------------------+
   |11111111|flgs|scop|                  group ID                   |
   +--------+----+----+---------------------------------------------+
                        flgs = |0|R|P|T|     （RFC 4291 §2.7）

最高 8 bit 全 1。接着 4 bit 标志（T=0 是 IANA 永久组，T=1 是临时组；P / R 见 RFC 3306 / 3956），再 4 bit 范围（scop）：

以太网把 IPv6 组播映成 33:33:xx:xx:xx:xx（RFC 2464）：取 IPv6 组播地址的最后 32 bit 接到 33:33 后面。交换机按这个 MAC 做组播转发，不是广播。

Solicited-node 组播

NDP 不用以太网广播做地址解析。每个单播 / 任播地址对应一个 solicited-node 组播：取该地址的低 24 bit，接到前缀 FF02:0:0:0:0:1:FF00::/104 上（RFC 4291 §2.7.1）。

  单播   2001:0db8:0000:0000:021a:2bff:fe3c:4d5e
  低 24 bit .............................. 3c:4d5e
  SNMA   ff02:0000:0000:0000:0000:0001:ff3c:4d5e
  压缩   ff02::1:ff3c:4d5e
  以太网 33:33:ff:3c:4d:5e

同一链路上 IID 后 24 bit 相同的地址会撞到同一个组，但这比“全节点组播”安静两个数量级。节点必须为自己配置过的每个单播 / 任播加入对应 SNMA。

EUI-64 与隐私扩展

Modified EUI-64（RFC 4291 附录 A）曾是 SLAAC 生成接口标识的默认算法。从 48 bit MAC 做：中间插入 ff:fe，再翻转第一字节的 U/L 位（universal/local，书面形式第一字节从左数第 7 bit，也就是该字节值异或 0x02）。

  MAC        00:1a:2b:3c:4d:5e
  插入 ff:fe  00:1a:2b:ff:fe:3c:4d:5e
  翻转 U/L    02:1a:2b:ff:fe:3c:4d:5e
  IID         021a:2bff:fe3c:4d5e
  LLA         fe80::21a:2bff:fe3c:4d5e

固定 40 字节。没有 IHL、没有首部校验和、没有分片字段。可选项全部挪到扩展头链，由 Next Header 串起来。

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version| Traffic Class |           Flow Label                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Payload Length        |  Next Header  |   Hop Limit   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         Source Address                        +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                      Destination Address                      +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                         RFC 8200 §3 · 40 octets

对照 IPv4：少了什么

扩展头链

可选的网络层信息放在基本首部和上层头之间，用 Next Header 逐个串。RFC 8200 §4.1 推荐顺序：

  IPv6 header
  Hop-by-Hop Options          Next Header = 0     唯一允许沿途处理；须紧跟基本首部
  Destination Options         60                  给 Routing 头里的中间目的
  Routing                     43
  Fragment                    44                  仅源端插入
  Authentication (AH)         51
  Encapsulating Security (ESP) 50
  Destination Options         60                  只给最终目的
  Upper-Layer                 6 / 17 / 58 / …
  No Next Header              59                  后面没有上层头

除 Destination Options 最多两次外，每种扩展头建议至多一次。Hop-by-Hop 是唯一允许沿途处理的扩展头，且必须紧跟 IPv6 基本首部（RFC 8200 §4 / §4.3）。RFC 8200 已改为：只有显式配置处理的节点才查看它；未配置的节点跳过该头、正常转发，存在 HbH 不构成丢包理由（RFC 9673 §5.1）。节点必须能接受乱序和重复的扩展头（Hop-by-Hop 除外），但源端应按上面的顺序发。

Neighbor Discovery 取代 IPv4 的 ARP、ICMP 路由器发现和 Redirect。五种报文全是 ICMPv6，Code 一律 0，IPv6 Hop Limit 发送填 255、接收也必须是 255——跨 hop 改过 Hop Limit 的伪造包直接丢。

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Type      |     Code      |          Checksum             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                            Reserved                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Options ...
                    RFC 4861 §4.1

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Type      |     Code      |          Checksum             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Cur Hop Limit |M|O|  Reserved |       Router Lifetime         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                         Reachable Time                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                          Retrans Timer                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Options ...
                    RFC 4861 §4.2

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Type=3        | Length=4      | Prefix Length |L|A|P| Reserved1|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                         Valid Lifetime                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                       Preferred Lifetime                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                           Reserved2                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                            Prefix (128 bit)                   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    RFC 4861 §4.6.2 · RFC 9762 P · 32 octets

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Type      |     Code      |          Checksum             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                           Reserved                            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                       Target Address (128 bit)                |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Options ...
                    RFC 4861 §4.3

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Type      |     Code      |          Checksum             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |R|S|O|                     Reserved                            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                       Target Address (128 bit)                |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Options ...
                    RFC 4861 §4.4

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Type      |     Code      |          Checksum             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                           Reserved                            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                       Target Address                          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                     Destination Address                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Options ...
                    RFC 4861 §4.5

ARP → NS / NA 逐项对应

DAD

RFC 4862 §5.4：任何单播地址——手工、SLAAC、DHCPv6——赋给接口之前都必须做重复地址检测，除非管理员关了该接口的 DAD。anycast 地址 MUST NOT 做 DAD（任播本就不唯一）。过程：

Optimistic DAD（RFC 4429）允许在探测未完成时用该地址做外出连接，本页按 4862 基线讲。

主机先有链路本地，再听 RA。RA 的 M/O 是信息可用性指示，典型主机策略据此决定要不要找 DHCPv6，但不是强制开关——RFC 8415 §18 允许本地策略独立发起。每个前缀选项上的 A 位决定要不要用 SLAAC 拼地址。三套旋钮是正交的，不是“开了 DHCP 就没有 SLAAC”。

SLAAC 步骤（RFC 4862）

地址寿命

Preferred Lifetime 到期 → Deprecated：已有连接可继续用，新连接不应再选它当源。Valid Lifetime 到期 → Invalid：从接口上拿掉。Valid 全 1 表示无穷。这是站点重编号的挂钩。

M / O / A 怎么组合

无状态 DHCPv6 vs 有状态 DHCPv6

DHCPv6 现行文本是 RFC 8415（吸收了 3315）。UDP：客户端 546，服务器 / 中继 547。链路上的服务器组播 ff02::1:2。

• 无状态：客户端发 Information-Request，服务器 Reply 带回 DNS、NTP、域名等，不分配地址。典型对应 M=0、O=1；本地策略也可独立发起（RFC 8415 §18）。
• 有状态：Solicit → Advertise → Request → Reply，用 IA_NA（或 IA_PD 前缀委托）租地址。典型对应 M=1，同样不是强制开关。

IPv4 的“DHCP 失败就 APIPA（169.254/16）”在 v6 不成立：LLA 是每个接口的必选项，不是兜底失败态。

ICMPv6 的 Next Header 是 58，不是 IPv4 的 Protocol 1。它是 IPv6 的一部分：每个节点必须实现 RFC 4443 的基线。NDP、MLD 都挂在这张类型表上，但定义在别的 RFC。

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Type      |     Code      |          Checksum             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                         Message Body                          |
                    RFC 4443 §2.1

Type 最高位为 0（0–127）是差错，为 1（128–255）是信息。校验和覆盖整条 ICMPv6 消息外加 IPv6 伪首部，伪首部里的 Next Header 固定写 58（RFC 4443 §2.3）。这是相对 ICMPv4 的明确变化。

与 ICMPv4 的差异

• 校验和含伪首部；IPv4 ICMP 不含。
• Packet Too Big 是独立 Type 2。IPv4 把“需要分片”放在 Destination Unreachable（Type 3）Code 4。
• 没有 Source Quench（IPv4 里也早已不用）。
• 差错报文必须尽可能带回引发包，整包（IPv6 首部 + ICMPv6）不超过最小 MTU 1280。
• 不得对 ICMPv6 差错、Redirect、组播 / 链路层组播广播目的再发差错。组播目的有两条例外（RFC 4443 §2.4(e.3)）：Packet Too Big（Type 2，§3.2）仍要回，以便组播 PMTUD；Parameter Problem Code 2（无法识别且 Option Type 高两位为 10 的选项，§3.4）。

PMTUD 在 v6 是强制路径

RFC 8200 §5：每条链路 MTU 至少 1280；不能一次塞下 1280 的链路必须在 IPv6 之下自己做分片重组。中间路由器不得在 IPv6 层切开数据报。于是：

• 要发送大于 1280 的包，节点必须跑 Path MTU Discovery（现行 RFC 8201，取代 1981），或自己用 Fragment 头在源端切开（被劝阻）。
• 路由器转发时若包 > 出接口 MTU：丢弃，回 Type 2，MTU 字段填该出接口 MTU。
• 源端据此缩小；不能再指望“沿途某台路由器切一切”。
• 最小实现（例如引导 ROM）可以永远不发超过 1280 的包，从而省略 PMTUD——这是规范给的退路，不是正常主机栈的做法。

今天的默认答案是双栈。隧道（6to4、Teredo）大多已淘汰。IPv6-only 接入网靠 NAT64/DNS64；应用层靠 Happy Eyeballs 避免“AAAA 能解析、路径却是死的”。

双栈

同一接口同时有 IPv4 和 IPv6。DNS 既回 A 也回 AAAA。选哪套地址由 Happy Eyeballs 和目的地址选择（RFC 6724）决定，不是“有 AAAA 就只走 v6”。

NAT64 / DNS64（RFC 6146 / 6147）

给只有 IPv6 的主机访问只有 IPv4 的服务器（DNS64 见 RFC 6147，NAT64 见 RFC 6146）：

Happy Eyeballs v2（RFC 8305）

偏好 IPv6，但不为它空等。

• Resolution Delay：正 AAAA 先到就立即开始 IPv6 连接；正 A 先到才短等 AAAA（推荐 50 ms）。等到否定 AAAA 或超时后，才带着已有的 A 往下走（RFC 8305 §3 / §8）。
• 地址排序之后交错发起连接，通常 IPv6 在前。
• Connection Attempt Delay：建议默认 250 ms 再试下一个地址；下限不得小于 10 ms，建议最小 100 ms，最大 2 s（RFC 8305）。
• 谁先建立成功就用谁，其余连接关掉。

“v6 优先”不是“AAAA 解析失败才试 A”，更不是“SYN 发给 v6 之后空等三次超时”。抓包里常见：一条 AAAA、一条 A，两条 SYN 前后相差约 250 ms，先回来的那条留下。

先看本机地址和默认路由，再看邻居缓存，最后抓 NDP / PTB。IPv6 坏了却“能 ping 通网关 LLA”，多半是 RA 没来或 ICMPv6 被滤。

邻居缓存状态（RFC 4861 §7.3.2）

Linux 的 FAILED 是实现层对“解析失败”的汇总，规范五态里没有这个词。长时间 INCOMPLETE / FAILED 盯网关：RA 里的路由器 LLA 和你 ping 的不是同一个，或二层隔离了组播。

Wireshark / tcpdump