Skip to main content

4.2. Protocol Packet Processing

OSPF for IPv6 runs directly over IPv6's network layer. As such, it is encapsulated in one or more IPv6 headers with the Next Header field of the immediately encapsulating IPv6 header set to the value 89.

As for OSPF for IPv4, OSPF for IPv6 OSPF routing protocol packets are sent along adjacencies only (with the exception of Hello packets, which are used to discover the adjacencies). OSPF packet types and functions are the same in both IPv4 and IPv6, encoded by the Type field of the standard OSPF packet header.

4.2.1. Sending Protocol Packets​

When an IPv6 router sends an OSPF routing protocol packet, it fills in the fields of the standard OSPF for IPv6 packet header (see Appendix A.3.1) as follows:

Version #

Set to 3, the version number of the protocol as documented in this specification.

Type

The type of OSPF packet, such as Link State Update or Hello packet.

Packet length

The length of the entire OSPF packet in bytes, including the standard OSPF packet header.

Router ID

The identity of the router itself (who is originating the packet).

Area ID

The OSPF area for the interface on which the packet is being sent.

Instance ID

The OSPF Instance ID associated with the interface out of which the packet is being sent.

Checksum

The standard IPv6 Upper-Layer checksum (as described in Section 8.1 of [IPV6]) covering the entire OSPF packet and prepended IPv6 pseudo-header (see Appendix A.3.1).

Selection of OSPF routing protocol packets' IPv6 source and destination addresses is performed identically to the IPv4 logic in Section 8.1 of [OSPFV2]. The IPv6 destination address is chosen from among the addresses AllSPFRouters, AllDRouters, and the Neighbor IP address associated with the other end of the adjacency (which in IPv6, for all links except virtual links, is an IPv6 link-local address).

The sending of Link State Request packets and Link State Acknowledgment packets remains unchanged from the IPv4 procedures documented in Sections 10.9 and 13.5 of [OSPFV2] respectively. Sending Hello packets is documented in Section 4.2.1.1, and the sending of Database Description packets in Section 4.2.1.2. The sending of Link State Update packets is documented in Section 4.5.2.

4.2.1.1. Sending Hello Packets​

IPv6 changes the way OSPF Hello packets are sent in the following ways (compare to Section 9.5 of [OSPFV2]):

  • Before the Hello packet is sent on an interface, the interface's Interface ID MUST be copied into the Hello packet.

  • The Hello packet no longer contains an IP network mask since OSPF for IPv6 runs per-link instead of per-subnet.

  • The choice of Designated Router and Backup Designated Router is now indicated within Hellos by their Router IDs instead of by their IP interface addresses. Advertising the Designated Router (or Backup Designated Router) as 0.0.0.0 indicates that the Designated Router (or Backup Designated Router) has not yet been chosen.

  • The Options field within Hello packets has moved around, getting larger in the process. More Options bits are now possible. Those that MUST be set correctly in Hello packets are as follows. The E-bit is set if and only if the interface attaches to a regular area, i.e., not a stub or NSSA area. Similarly, the N-bit is set if and only if the interface attaches to an NSSA area (see [NSSA]). Finally, the DC-bit is set if and only if the router wishes to suppress the sending of future Hellos over the interface (see [DEMAND]). Unrecognized bits in the Hello packet's Options field should be cleared.

Sending Hello packets on NBMA networks proceeds for IPv6 in exactly the same way as for IPv4, as documented in Section 9.5.1 of [OSPFV2].

4.2.1.2. Sending Database Description Packets​

The sending of Database Description packets differs from Section 10.8 of [OSPFV2] in the following ways:

  • The Options field within Database Description packets has moved around, getting larger in the process. More Options bits are now possible. Those that MUST be set correctly in Database Description packets are as follows. The DC-bit is set if and only if the router wishes to suppress the sending of Hellos over the interface (see [DEMAND]). Unrecognized bits in the Database Description packet's Options field should be cleared.

4.2.2. Receiving Protocol Packets​

Whenever a router receives an OSPF protocol packet, it is marked with the interface on which it was received. For routers that have virtual links configured, it may not be immediately obvious with which interface to associate the packet. For example, consider the Router RT11 depicted in Figure 6 of [OSPFV2]. If RT11 receives an OSPF protocol packet on its interface to Network N8, it may want to associate the packet with the interface to Area 2, or with the virtual link to Router RT10 (which is part of the backbone). In the following, we assume that the packet is initially associated with the non-virtual link.

In order for the packet to be passed to OSPF for processing, the following tests must be performed on the encapsulating IPv6 headers:

  • The packet's IP destination address MUST be one of the IPv6 unicast addresses associated with the receiving interface (this includes link-local addresses), one of the IPv6 multicast addresses AllSPFRouters or AllDRouters, or an IPv6 global address (for virtual links).

  • The Next Header field of the immediately encapsulating IPv6 header MUST specify the OSPF protocol (89).

  • Any encapsulating IP Authentication Headers (see [IPAUTH]) and the IP Encapsulating Security Payloads (see [IPESP]) MUST be processed and/or verified to ensure integrity and authentication/confidentiality of OSPF routing exchanges. This is described in [OSPFV3-AUTH].

After processing the encapsulating IPv6 headers, the OSPF packet header is processed. The fields specified in the header must match those configured for the receiving OSPFv3 interface. If they do not, the packet SHOULD be discarded:

  • The version number field MUST specify protocol version 3.

  • The IPv6 Upper-Layer checksum (as described in Section 8.1 of [IPV6]), covering the entire OSPF packet and prepended IPv6 pseudo-header, must be verified (see Appendix A.3.1).

  • The Area ID and Instance ID found in the OSPF header must be verified. If both of the following cases fail, the packet should be discarded. The Area ID and Instance ID specified in the header must either:

    1. Match one of the Area ID(s) and Interface Instance ID(s) for the receiving link. Unlike IPv4, the IPv6 source address is not restricted to lie within the same IPv6 subnet as the receiving link. IPv6 OSPF runs per-link instead of per-IP-subnet.

    2. Match the backbone area and other criteria for a configured virtual link. The receiving router must be an ABR (Area Border Router) and the Router ID specified in the packet (the source router) must be the other end of a configured virtual link. Additionally, the receiving link must have an OSPFv3 interface that attaches to the virtual link's configured transit area and the Instance ID must match the virtual link's Instance ID. If all of these checks succeed, the packet is accepted and is associated with the virtual link (and the backbone area).

  • Locally originated packets SHOULD NOT be processed by OSPF except for support of multiple interfaces attached to the same link as described in Section 4.9. Locally originated packets have a source address equal to one of the router's local addresses.

  • Packets whose IPv6 destination is AllDRouters should only be accepted if the state of the receiving OSPFv3 interface is DR or Backup (see Section 9.1 [OSPFV2]).

After header processing, the packet is further processed according to its OSPF packet type. OSPF packet types and functions are the same for both IPv4 and IPv6.

If the packet type is Hello, it should then be further processed by the Hello packet processing as described in Section 4.2.2.1. All other packet types are sent/received only on adjacencies. This means that the packet must have been sent by one of the router's active neighbors. The neighbor is identified by the Router ID appearing in the received packet's OSPF header. Packets not matching any active neighbor are discarded.

The receive processing of Database Description packets, Link State Request packets, and Link State Acknowledgment packets is almost identical to the IPv4 procedures documented in Sections 10.6, 10.7, and 13.7 of [OSPFV2] respectively with the exceptions noted below.

  • LSAs with unknown LS types in Database Description packets that have an acceptable flooding scope are processed the same as LSAs with known LS types. In OSPFv2 [OSPFV2], these would result in the adjacency being brought down with a SequenceMismatch event.

The receiving of Hello packets is documented in Section 4.2.2.1 and the receiving of Link State Update packets is documented in Section 4.5.1.

4.2.2.1. Receiving Hello Packets​

The receive processing of Hello packets differs from Section 10.5 of [OSPFV2] in the following ways:

  • On all link types (e.g., broadcast, NBMA, point-to-point, etc.), neighbors are identified solely by their OSPF Router ID. For all link types except virtual links, the Neighbor IP address is set to the IPv6 source address in the IPv6 header of the received OSPF Hello packet.

  • There is no longer a Network Mask field in the Hello packet.

  • The neighbor's choice of Designated Router and Backup Designated Router is now encoded as an OSPF Router ID instead of an IP interface address.

Last updated on