摘要

  • 设想用户打开一项网络服务却迟迟收不到回复，尽管设备已有有效的IPv6地址：主机选出的源地址可能与网络路径上的过滤规则不匹配。RFC 5220记录的是这类条件，并非某起具体故障或发生频率。藤崎参与的IETF RFC讨论主机选址，APNIC档案讨论运营商获得的地址块大小，两者属于不同层级。
  • APNIC实施了一项移除初始分配聚合条件的变更；之后多项扩大分配规模的提案没有达成共识。
  • 记录证明了标准机制和程序结果，却没有测量RFC 7078的部署程度或分配政策的网络影响。

地址有效，不代表路径可达

同一条链路上的主机可能有多个IPv6地址。发送数据包时，它会选择一个源地址；路由、过滤规则与返回路径都必须容纳这一选择。RFC 5220列出了不匹配时可能出现的情况：入站过滤丢弃数据包、流量经过非对称路径，或者回复找不到可用路由。故障看似来自应用，根源却可能在主机本地规则与站点拓扑的交界处。

RFC 5220于2008年7月以信息性备忘录形式发布，作者为Arifumi Matsumoto、藤崎智宏、R. Hiromi和K. Kanayama。它描述一类问题，不是一次具体生产事故，也没有估计发生率。文件关注难以逐台配置的站点终端。设备数量较大时，让每位用户手工维护复杂策略表并非普遍可行的方案。

同月由这四位作者发布的RFC 5221把问题转成机制要求：策略应在选址前到达，并能随网络变化更新；机制要考虑不同节点、应用和多个接口。集中管理、兼容既有算法和安全性同样重要。这份文件提出要求，并未声称这些要求已全部得到满足。

策略可以下发，主机仍参与决策

2014年发布的RFC 7078由Arifumi Matsumoto、藤崎智宏和Tim Chown共同撰写，定义了用于地址选择的DHCPv6选项。站点管理员可以下发策略表及相关参数，调整RFC 6724的默认规则。公开文档因此呈现出从问题、需求到标准化机制的过程。

但DHCPv6服务器并没有因此成为所有终端的绝对控制者。RFC 7078把该选项描述为由节点处理的信息，并承认本地配置的作用。网络可以表达偏好，设备实现和主机管理设置仍会影响最终行为。

标准指出了具体风险：恶意服务器可能发送错误策略，让客户端选择被上游过滤的地址、造成意外费用，或把流量导向危险路径。RFC讨论了可信传输方式，并提到第二层DHCP snooping等缓解措施。策略表过大也可能形成某些客户端、服务器和中继无法可靠传输的消息。标准定义了选项，却没有证明现有设备普遍支持它。

地址分配属于另一项决策

藤崎在APNIC参与的提案讨论组织可以获得多少地址空间，而非主机怎样选择地址。多位作者提出的prop-076曾主张后续IPv6分配应满足聚合要求，讨论后撤回。共同提出的prop-082则建议取消初始分配的聚合条件。APNIC档案记载，该案在APNIC 29达成共识，经执行委员会认可后于2010年7月5日实施。这是规则变更的证据，不是网络影响的测量结果。

藤崎提交的prop-087试图允许某些RFC描述的部署阶段申请大于/32的初始分配。提案未获共识，作者于2011年8月撤回。2014年的prop-111提出最多扩展到/29的途径，APNIC记载它在APNIC 37和38均未取得共识。2015年的prop-112则为早期IPv6区块持有者提出另一种扩展方式，最终同样因无共识而放弃。

这段历史呈现的是不同结果：一项初始分配标准调整已实施，之后几项扩大区块的方案没有成为政策。档案无法证明未采纳方案在技术上不可行，也不能说明所有运营者都需要更大区块；它们也不足以推断未支持者拥有相同动机。

APNIC的候选人页面把藤崎列为NTT高级研究工程师，称他自1997年起在NTT从事IPv6研究，并列出参与日本部署和地址政策工作的经历。应把这些信息归因于候选人资料，而不是当作独立业绩评估。APNIC执行委员会纪要另记载，他获一致任命为2011年NRO Number Council成员。

两层机制，不能互作证明

分配规则影响运营者能设计怎样的地址计划；选址规则影响主机从已有地址中实际使用哪一个。来源材料没有证明更大的区块能够修复源地址选择问题，也没有证明DHCPv6策略表能弥补不合适的地址计划。

RFC 5220和5221各有四位作者，RFC 7078有三位。APNIC档案则区分藤崎独立提交和共同撰写的提案。这样的归属精度呈现了他的参与，同时避免把集体标准、政策程序或运行结果归功于个人。

可以确认的是：一个地址选择问题被记录、整理成要求，并出现了标准化分发机制；APNIC则实施了一项变更，其他提案未取得共识。现有资料没有RFC 7078使用比例、性能变化或prop-082的运维影响数据。回答这些问题需要在具体网络中测量。