摘要
- RFC 5220 描述了一种 IPv6“半封闭网络”：主机依照默认规则选出的源地址，可能来自公网无法返回的网络前缀。
- 源地址由主机选择，下一跳由网络路径决定，两者并非同一项决策。RFC 记录的是可能出现的错位，不是具体部署、故障率，也不能代表所有多宿主主机的行为。
两段有效前缀，一条不可达的回包
RFC 5220 于 2008 年 7 月发布，属于信息类问题陈述。它讨论同一链路配置多个 IPv6 前缀后，默认的源地址和目标地址选择规则在运维中会遇到什么麻烦；它没有新增数据包格式。问题尤其出现在无人逐台配置的终端上，用户通常不可能维护一张准确反映网络策略的地址表。
文中最能说明问题的场景被称为“半封闭网络”。一个小型站点连接两个上游网络：一个通向公共互联网，另一个是通过 VPN 接入的封闭网络。主机同时拥有两边分配的有效 IPv6 地址。封闭网络内的同事可以通过内部地址联系它；公网服务器却无法经由开放互联网把回包送到封闭前缀。
当主机主动连接公网目标时，问题就显现出来。RFC 5220 的示例指出，默认的最长前缀匹配规则可能选中封闭网络的地址作为源地址；站点的默认路由却可能将数据包送往互联网服务商。服务商可能丢弃自己未分配的源前缀。即便首个数据包成功发出，公网回包的目的地址仍落在封闭网络的前缀上，公网没有返回路径。地址本身有效，不代表一段会话能够往返。
标准文本把断点分成两类。入站过滤可能因为源地址不属于当前出口服务商而丢掉外发包；半封闭的返回域则可能让回包无法抵达，即使外发包已被接受。这既不只是 DNS 故障，也不能据此断定主机地址格式错误。
地址并没有携带上游策略
RFC 3484 给候选地址规定了默认比较方式，但不会自动告诉主机哪个服务商会承载当前数据包，也不会说明该源前缀能否沿这条路径收到回复。RFC 5220 因此把若干风险视作主机选择与网络路由策略之间的协调问题。对半封闭网络，修改主机的策略表可以避开错误选择；前提是有人了解拓扑，并在策略变化时及时更新它。
这份问题陈述也明确了边界：有些场景可以放进现有选择规则处理，另一些可能需要向主机提供更多信息，或采用不同机制。RFC 5220 没有声称所有多上游 IPv6 网络都无法工作，也没有统计这些场景在生产网络中的占比。拓扑图说明一种工程师需要检查的故障模式，不等于真实事故报告。
后续标准把其中一部分边界说得更清楚。RFC 6724 后来取代了 RFC 3484。2016 年发布的标准轨 RFC 8028，讨论多前缀网络中的首跳路由器选择，以及已通告前缀、源地址和实际出口之间的关系。它可以帮助追踪标准如何演进，但不能反推 2008 年这些场景有多常见，也不能替代对现实网络返回路径的验证。
标准中的警示不是流量测量
RFC 5220 的历史价值，在于它把容易混为一谈的事实拆开：源地址选择、下一跳、上游过滤和返回可达性相互影响，却不能彼此作证。文中给出的是合理的配置情境和分析，没有操作系统普查、数据包捕获、具名故障或前后对照测量。若要判断有多少主机曾经选错，或后续工作实际改善了多少连接，还需要标准之外的实现与运行证据。
来源
会员简报
档案背景详情
使用相应会员等级登录，即可解锁完整简报与来源注释。
仅限 Strategic Circle
Strategic Circle
所有读者均可浏览。加入并登录后可解锁档案简报。
加入 Strategic Circle仅限 Leadership Alliance
Leadership Alliance
符合条件的 IP 资产所有者和管理层可登录查看 Leadership Alliance 简报。
加入 Leadership Alliance