跳到主要内容

4.2. 协议报文处理

OSPF for IPv6 直接运行在 IPv6 network layer 之上. 因此, 它被封装在一个或多个 IPv6 header 中, 其中直接封装它的 IPv6 header 的 Next Header 字段设置为 89.

与 OSPF for IPv4 一样, OSPF for IPv6 的 OSPF routing protocol packet 只沿 adjacency 发送 (用于发现 adjacency 的 Hello packet 除外). OSPF packet 类型和功能在 IPv4 与 IPv6 中相同, 由标准 OSPF packet header 的 Type 字段编码.

4.2.1. 发送协议报文​

当 IPv6 路由器发送 OSPF routing protocol packet 时, 它按如下方式填写标准 OSPF for IPv6 packet header (见 Appendix A.3.1) 的字段:

Version #

设置为 3, 即本规范中记录的 protocol version number.

Type

OSPF packet 的类型, 例如 Link State Update 或 Hello packet.

Packet length

整个 OSPF packet 的长度, 以字节为单位, 包括标准 OSPF packet header.

Router ID

路由器自身的标识 (即发起该 packet 的路由器).

Area ID

发送该 packet 的 interface 所属的 OSPF area.

Instance ID

与发送该 packet 的 outgoing interface 关联的 OSPF Instance ID.

Checksum

标准 IPv6 Upper-Layer checksum (如 [IPV6] Section 8.1 所述), 覆盖整个 OSPF packet 和前置的 IPv6 pseudo-header (见 Appendix A.3.1).

OSPF routing protocol packet 的 IPv6 source address 和 destination address 的选择方式与 [OSPFV2] Section 8.1 中的 IPv4 逻辑相同. IPv6 destination address 从 AllSPFRouters, AllDRouters 以及与 adjacency 另一端关联的 Neighbor IP address 中选择 (在 IPv6 中, 对于除 virtual link 之外的所有 link, 该地址是 IPv6 link-local address).

Link State Request packet 和 Link State Acknowledgment packet 的发送分别与 [OSPFV2] Sections 10.9 和 13.5 中记录的 IPv4 过程保持不变. Hello packet 的发送记录在 Section 4.2.1.1 中, Database Description packet 的发送记录在 Section 4.2.1.2 中. Link State Update packet 的发送记录在 Section 4.5.2 中.

4.2.1.1. 发送 Hello 报文​

IPv6 按以下方式改变 OSPF Hello packet 的发送方式 (与 [OSPFV2] Section 9.5 比较):

  • 在 interface 上发送 Hello packet 之前, 该 interface 的 Interface ID 必须复制到 Hello packet 中.

  • Hello packet 不再包含 IP network mask, 因为 OSPF for IPv6 按 link 运行, 而不是按 subnet 运行.

  • Designated Router 和 Backup Designated Router 的选择现在在 Hello 中用其 Router ID 表示, 而不是用其 IP interface address 表示. 将 Designated Router (或 Backup Designated Router) 通告为 0.0.0.0 表示尚未选择 Designated Router (或 Backup Designated Router).

  • Hello packet 中的 Options 字段位置发生了移动, 并且在此过程中变得更大. 现在可以有更多 Options bit. 在 Hello packet 中必须正确设置的 bit 如下. 当且仅当 interface 连接到 regular area, 即不是 stub 或 NSSA area 时, 设置 E-bit. 类似地, 当且仅当 interface 连接到 NSSA area (见 [NSSA]) 时, 设置 N-bit. 最后, 当且仅当路由器希望抑制以后在该 interface 上发送 Hello (见 [DEMAND]) 时, 设置 DC-bit. Hello packet 的 Options 字段中无法识别的 bit 应清零.

在 NBMA network 上发送 Hello packet 时, IPv6 的处理方式与 IPv4 完全相同, 如 [OSPFV2] Section 9.5.1 所记录.

4.2.1.2. 发送 Database Description 报文​

Database Description packet 的发送与 [OSPFV2] Section 10.8 的差异如下:

  • Database Description packet 中的 Options 字段位置发生了移动, 并且在此过程中变得更大. 现在可以有更多 Options bit. 在 Database Description packet 中必须正确设置的 bit 如下. 当且仅当路由器希望抑制在该 interface 上发送 Hello (见 [DEMAND]) 时, 设置 DC-bit. Database Description packet 的 Options 字段中无法识别的 bit 应清零.

4.2.2. 接收协议报文​

每当路由器接收到 OSPF protocol packet 时, 都会用接收它的 interface 对其进行标记. 对于配置了 virtual link 的路由器, 可能无法立即明确应将该 packet 与哪个 interface 关联. 例如, 考虑 [OSPFV2] Figure 6 中所示的 Router RT11. 如果 RT11 在其通往 Network N8 的 interface 上接收到 OSPF protocol packet, 它可能希望将该 packet 与通往 Area 2 的 interface 关联, 或者与通往 Router RT10 的 virtual link (它是 backbone 的一部分) 关联. 下文中, 我们假定该 packet 初始关联到 non-virtual link.

为了将该 packet 交给 OSPF 处理, 必须对封装 IPv6 header 执行以下检查:

  • packet 的 IP destination address 必须是与接收 interface 关联的某个 IPv6 unicast address (这包括 link-local address), IPv6 multicast address AllSPFRouters 或 AllDRouters 之一, 或者 IPv6 global address (用于 virtual link).

  • 直接封装它的 IPv6 header 的 Next Header 字段必须指定 OSPF protocol (89).

  • 任何封装的 IP Authentication Header (见 [IPAUTH]) 和 IP Encapsulating Security Payload (见 [IPESP]) 必须被处理和/或验证, 以确保 OSPF routing exchange 的完整性以及认证/机密性. 这在 [OSPFV3-AUTH] 中描述.

处理封装 IPv6 header 后, 将处理 OSPF packet header. header 中指定的字段必须与接收 OSPFv3 interface 的配置匹配. 如果不匹配, packet 应该被丢弃:

  • version number 字段必须指定 protocol version 3.

  • 必须验证 IPv6 Upper-Layer checksum (如 [IPV6] Section 8.1 所述), 它覆盖整个 OSPF packet 和前置的 IPv6 pseudo-header (见 Appendix A.3.1).

  • 必须验证 OSPF header 中的 Area ID 和 Instance ID. 如果以下两种情况都不成立, packet 应被丢弃. header 中指定的 Area ID 和 Instance ID 必须满足以下之一:

    1. 匹配接收 link 的某个 Area ID 和 Interface Instance ID. 与 IPv4 不同, IPv6 source address 不限制在与接收 link 相同的 IPv6 subnet 内. IPv6 OSPF 按 link 运行, 而不是按 IP subnet 运行.

    2. 匹配 backbone area 以及已配置 virtual link 的其他条件. 接收路由器必须是 ABR (Area Border Router), 且 packet 中指定的 Router ID (source router) 必须是某条已配置 virtual link 的另一端. 此外, 接收 link 必须有一个连接到该 virtual link 已配置 transit area 的 OSPFv3 interface, 并且 Instance ID 必须匹配该 virtual link 的 Instance ID. 如果所有这些检查都成功, packet 将被接受并与 virtual link (以及 backbone area) 关联.

  • 本地发起的 packet 不应该由 OSPF 处理, 除非是为了支持 Section 4.9 中描述的连接到同一 link 的多个 interface. 本地发起的 packet 的 source address 等于路由器的某个 local address.

  • IPv6 destination 为 AllDRouters 的 packet 只有在接收 OSPFv3 interface 的状态为 DR 或 Backup 时才应被接受 (见 Section 9.1 [OSPFV2]).

header 处理完成后, packet 会根据其 OSPF packet 类型进一步处理. OSPF packet 类型和功能在 IPv4 与 IPv6 中相同.

如果 packet 类型是 Hello, 则应按 Section 4.2.2.1 中描述的 Hello packet 处理继续处理. 所有其他 packet 类型只在 adjacency 上发送/接收. 这意味着该 packet 必须由路由器的某个 active neighbor 发送. neighbor 由接收到的 packet 的 OSPF header 中出现的 Router ID 标识. 不匹配任何 active neighbor 的 packet 将被丢弃.

Database Description packet, Link State Request packet 和 Link State Acknowledgment packet 的接收处理分别与 [OSPFV2] Sections 10.6, 10.7 和 13.7 中记录的 IPv4 过程几乎相同, 但有以下例外.

  • Database Description packet 中具有未知 LS type 且具有可接受 flooding scope 的 LSA, 按与已知 LS type 的 LSA 相同的方式处理. 在 OSPFv2 [OSPFV2] 中, 这些 LSA 会导致 adjacency 因 SequenceMismatch event 而被关闭.

Hello packet 的接收记录在 Section 4.2.2.1 中, Link State Update packet 的接收记录在 Section 4.5.1 中.

4.2.2.1. 接收 Hello 报文​

Hello packet 的接收处理与 [OSPFV2] Section 10.5 的差异如下:

  • 在所有 link 类型上 (例如 broadcast, NBMA, point-to-point 等), neighbor 仅由其 OSPF Router ID 标识. 对于除 virtual link 之外的所有 link 类型, Neighbor IP address 设置为接收到的 OSPF Hello packet 的 IPv6 header 中的 IPv6 source address.

  • Hello packet 中不再有 Network Mask 字段.

  • neighbor 选择的 Designated Router 和 Backup Designated Router 现在编码为 OSPF Router ID, 而不是 IP interface address.

最后于 更新