9. 可扩展性 - 选项处理

Neighbor Discovery 协议被设计为可通过添加新选项进行扩展. 本节说明节点如何处理收到的 Neighbor Discovery 消息中的选项, 以确保未来扩展可以与当前实现共存.

9.1. 通用原则

为确保向后兼容性和向前可扩展性:

• 无法识别的选项: 所有节点必须静默忽略收到的 Neighbor Discovery 分组中任何无法识别的选项, 并继续处理该分组. 这使得未来可以定义新选项, 而不会破坏现有实现.

• 多个选项: 选项可以在同一消息中多次出现. 节点必须准备好适当地处理这种情况.

• 选项顺序: 除非对特定选项类型明确规定, 选项在消息中出现的顺序通常没有意义.

• 填充: 必要时应对选项进行填充, 以确保它们在其自然的 64-bit 边界处结束.

9.2. 处理规则

处理包含选项的 Neighbor Discovery 消息时:

1. 解析所有选项: 节点必须解析消息中的所有选项, 即使其中一些无法识别.

2. 忽略未知选项: 如果某个选项无法识别 (基于其 Type 字段), 节点必须忽略它, 并继续处理后续选项以及消息本身.

3. 验证已知选项: 对于可识别的选项, 节点必须按该选项类型规定的规则验证该选项. 如果选项验证失败 (例如长度不正确或字段值无效), 其行为取决于具体的选项类型和消息类型.

4. 继续处理: 即使一个或多个选项无效或无法识别, 节点应该继续处理该消息以及任何剩余的有效选项, 除非特定消息类型或选项的规范另有要求.

9.3. 选项格式要求

为 Neighbor Discovery 定义的所有新选项必须遵循第 4.6 节规定的通用选项格式, 包含 Type 和 Length 字段. Length 字段以 8 octets 为单位指定.

定义新选项时, 协议设计者 应该:

• 确保未实现该选项的节点可以安全地忽略该选项, 且不会导致运行问题.
• 考虑对消息大小和链路 MTU 的影响.
• 为该选项指定清晰的验证规则.

9.4. 未来扩展

未来对 Neighbor Discovery 协议的向后兼容变更可以:

• 定义新的选项类型
• 指定消息格式中当前 Reserved 字段的用途
• 在现有消息中定义新的标志位 (前提是无法识别的标志会被忽略)

不向后兼容的变更需要定义新的消息类型 (使用不同的 ICMP Type 或 Code 值), 或定义协议的新版本.

9.5. 实现考虑

实现 应该:

• 设计为能够方便地容纳新的选项类型, 而不需要重大代码变更.
• 记录或提供关于无法识别选项的诊断信息, 以帮助调试和未来协议部署.
• 处理选项时考虑安全影响, 尤其是那些可能影响路由决策或缓存条目的选项.

9.6. 安全性和可扩展性

可扩展性机制本身并不提供安全性. 如果新选项没有经过仔细设计, 可能会引入新的安全漏洞. 定义新选项的协议设计者 应该:

• 考虑该选项如何与 Secure Neighbor Discovery (SEND) [RFC3971] 交互.
• 分析可能利用该新选项的潜在攻击.
• 记录该新选项特有的安全考虑.

实现应该提供机制, 根据本地安全策略有选择地启用或禁用对特定选项类型的支持.

---