01 · 机制演进与算法要点
1.1 从RFC 6555到RFC 8305
双栈客户端面临一个体验问题：若优先尝试IPv6而路径不通（中间设备黑洞），用户要等待TCP超时才能回退IPv4，体验极差。"Happy Eyeballs"（开心眼球）算法通过并行竞速连接解决这一矛盾：RFC 6555（2012，v1）确立基本框架，RFC 8305（2017，v2）取代之并细化状态管理。该算法已被主流浏览器与操作系统广泛实现，成为双栈时代客户端行为的事实标准——也因此塑造了双栈安全策略的实际生效路径。
1.2 算法核心步骤（依RFC 8305归纳）
- 地址收集与排序：DNS返回A与AAAA记录后，按RFC 6724地址选择策略排序，IPv6目的地整体优先。
- 并行竞速：先向第一个IPv6目的地发起连接；推荐延迟250ms后向IPv4目的地并行发起（v1为300ms，v2收紧至250ms——这是两版最常被引用的参数差异）。
- 先到先得：任一连接率先完成握手即胜出，其余尝试取消。
- 状态化缓存：记录各地址族/目的的成功与失败经验，影响后续排序与回退决策（v2明确该状态机要求）。
1.3 v1与v2的关键差异
| 维度 | Happy Eyeballs v1（RFC 6555，2012） | Happy Eyeballs v2（RFC 8305，2017） |
|---|---|---|
| IPv4尝试推荐延迟 | 300ms | 250ms |
| 状态管理 | 未充分定义 | 明确要求维护尝试状态与失败记忆（de-preference机制） |
| 地址排序依据 | 引用RFC 3484 | 引用更新的RFC 6724策略表 |
| 重复地址处理 | 基础处理 | 明确去重与并行尝试的报文交错要求 |
| 标准状态 | 已被取代（Obsoleted by RFC 8305） | 现行标准 |
02 · 路径选择的安全语义
2.1 路径即边界
在双栈网络中，IPv4与IPv6路径往往经过不同的安全设施序列：不同的边界设备、不同的WAF集群、不同的清洗中心、不同的出口审计点。Happy Eyeballs的"竞速胜出"机制意味着：客户端实际走哪条路径，取决于两条路径的实时连通性与时延表现，而非管理员的安全策略意图。若v6路径被注入劣化信号（延迟、丢包、握手失败），大量客户端将瞬时回退v4——反之亦然。谁影响路径质量信号，谁就事实上选择了用户的安全边界。
2.2 三类路径操纵模式（概念级）
| 模式 | 机理（概念描述） | 检测思路 |
|---|---|---|
| 劣化注入 | 对其中一栈的路径注入延迟/丢包/握手失败信号，诱导客户端竞速选择另一栈 | 对比两栈端到端时延基线与抖动异常；成功率不对称分析 |
| 解析操纵 | 影响A/AAAA记录的应答（如仅应答A），直接决定地址族可用性 | 被动DNS监测；多解析器交叉验证 |
| 局部劫持 | 在链路层（Rogue RA，衔接子课题02）或接入网使一栈"不可用"，迫使用户经攻击者控制路径 | NDP异常监测；网关一致性核查 |
2.3 为什么操纵有效：竞速窗口的放大效应
HEv2推荐的250ms窗口看似很短，但在路径操纵场景下攻击者并不需要持续劣化——只需在客户端发起新连接的关键时刻制造一次握手失败，状态化缓存机制就会将该地址族降权，影响后续大量连接。RFC 8305要求的状态缓存本意是规避"瘫痪但优先"的路径，攻击者可借同一机制放大操纵的持久效果。这构成双栈环境特有的、值得专项监测的攻击面。
03 · 部署成效与测量
3.1 历史验证：World IPv6 Day / Launch
2011年6月8日的World IPv6 Day与2012年6月6日的World IPv6 Launch是Happy Eyeballs思路的大规模实证：全球主要网站与运营商联合开启AAAA记录，各参与方公开报告的问题比例处于极低量级（千分之几以下），证明"双栈+竞速回退"路线的可行性，直接推动了RFC 6555/8305的标准化进程。这一历史经验也说明：双栈路径问题本质上是可测量、可工程化解决的。
3.2 现行测量方法
- 终端侧测量：APNIC Labs的嵌入式脚本测量全球IPv6能力与双栈行为分布；test-ipv6.com等工具提供单点双栈连通性自检。
- 网络侧测量：基于NetFlow/IPFIX的协议族流量分布、连接成功率与回退率统计；主动探测（双栈目标往返测量）绘制路径质量地图。
- 应用侧遥测：服务端记录客户端连接使用的地址族、握手时延与失败原因——这是检测路径操纵最有价值的数据源（连接级而非流级）。
04 · 路径操纵检测指标体系
4.1 核心指标
| 指标 | 定义 | 异常判读 |
|---|---|---|
| 地址族成功率比 | v6连接成功率 / v4连接成功率（分目的、分时段） | 单侧骤降且与网络变更无关→疑似劣化注入 |
| 竞速胜出分布 | 双栈客户端最终使用v6的比例（服务端遥测） | 短期内大幅漂移→解析或路径被操纵 |
| 握手失败指纹 | 失败类型分布（超时/RST/ICMP错误）与地理位置聚类 | 聚类性失败指向局部劫持而非全局故障 |
| 解析一致性 | 多解析点A/AAAA应答一致性 | 单侧缺失或顺序异常→解析操纵嫌疑 |
4.2 演练验证方法（授权环境）
- 受控劣化实验：在测试网段对v6路径施加可计量的延迟/丢包，观测服务端遥测中地址族胜出分布的变化曲线，标定检测阈值。
- 解析扰动演练：变更测试域名的AAAA发布策略，验证监测管线的告警时延与准确性。
- 红蓝对抗：红队尝试通过链路层手段（经授权仿真）影响客户端路径选择，检验NDP监测与路径遥测的联合检出能力。
防御侧根本对策：路径操纵之所以构成风险，根源在于两栈防护不等价（第2页）。若两栈策略严格等价，攻击者操纵路径选择就无法获得额外收益——等价性核查是消解路径操纵价值的结构性措施，路径遥测则负责发现"有人在尝试操纵"。
05 · 与翻译技术的联动行为
- DNS64环境下的HE：464XLAT场景中，CLAT终端访问IPv4字面量或服务时使用本地翻译路径，不依赖DNS64合成；但普通IPv6-only终端仍依赖DNS64——两类终端的Happy Eyeballs输入不同，服务端遥测应按接入类型分层解读。
- 回退与兼容：Happy Eyeballs的历史价值在于容忍"部分v6路径不通"的现实；在IPv6-only演进（子课题06）中，应用回退行为同样需要治理——回退策略应显式化、可审计，而不是散落在客户端默认行为中。
- 接入类型分层解读："IPv6-mostly"部署模式（RFC 8925：经DHCPv4选项引导终端优先IPv6-only）正在兴起，IETF v6ops同步推进部署考量草案（draft-ietf-v6ops-6mops）。该模式下终端的Happy Eyeballs输入与原生双栈、464XLAT均不同——服务端路径遥测应按"原生双栈/IPv6-mostly/464XLAT/翻译直连"四类接入分层建基线，避免模式混用掩盖操纵信号。
06 · 研究边界小结
- 本章机制参数（250ms、状态缓存等）以RFC 8305原文为准；操纵模式仅作概念级描述，检测方案须在授权环境验证。
- Happy Eyeballs是双栈时代最重要的"行为层"标准：它既是双栈体验的支撑，也是路径安全语义的塑造者——安全团队应将其纳入可观测性建设。
- 下一页转入过渡网关与边界安全——隧道与翻译设施的落地加固与合规审计。
本节参考来源（第5页）
以下均为真实可查的权威来源，用于支撑本页事实性表述。
IETF RFC 6555《Happy Eyeballs: Success with Dual-Stack Hosts》（2012，已被RFC 8305取代）：rfc-editor.org/rfc/rfc6555。
IETF RFC 8305《Happy Eyeballs Version 2: Better Connectivity Using Concurrency》（2017）：rfc-editor.org/rfc/rfc8305。
IETF RFC 6724《Default Address Selection for IPv6》（2012，HE排序依据）：rfc-editor.org/rfc/rfc6724。
ISOC《World IPv6 Day/Launch》历史档案（2011—2012年双栈大规模验证事件）：internetsociety.org。
APNIC Labs测量项目（全球IPv6能力与双栈行为测量）：labs.apnic.net；test-ipv6.com（双栈连通性自检工具）：test-ipv6.com。
IETF RFC 7050《Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis》（2013，DNS64/CLAT路径发现）：rfc-editor.org/rfc/rfc7050。
IETF RFC 8925《IPv6-Only Preferred Option for DHCPv4》（2020，IPv6-mostly基础）：rfc-editor.org/rfc/rfc8925；IPv6-mostly部署考量草案（draft-ietf-v6ops-6mops，进行中）：datatracker.ietf.org。