4.1. Protocol Data Structures

The major OSPF data structures are the same for both IPv4 and IPv6: areas, interfaces, neighbors, the link-state database, and the routing table. The top-level data structures for IPv6 remain those listed in Section 5 of [OSPFV2], with the following modifications:

• All LSAs with known LS type and AS flooding scope appear in the top-level data structure, instead of belonging to a specific area or link. AS-external-LSAs are the only LSAs defined by this specification that have AS flooding scope. LSAs with unknown LS type, U-bit set to 1 (flood even when unrecognized), and AS flooding scope also appear in the top-level data structure.

4.1.1. The Area Data Structure

The IPv6 area data structure contains all elements defined for IPv4 areas in Section 6 of [OSPFV2]. In addition, all LSAs of known type that have area flooding scope are contained in the IPv6 area data structure. This always includes the following LSA types: router-LSAs, network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs, and intra-area-prefix-LSAs. LSAs with unknown LS type, U-bit set to 1 (flood even when unrecognized), and area scope also appear in the area data structure. NSSA-LSAs are also included in an NSSA area's data structure.

4.1.2. The Interface Data Structure

In OSPF for IPv6, an interface connects a router to a link. The IPv6 interface structure modifies the IPv4 interface structure (as defined in Section 9 of [OSPFV2]) as follows:

Interface ID

Every interface is assigned an Interface ID, which uniquely identifies the interface with the router. For example, some implementations MAY be able to use the MIB-II IfIndex ([INTFMIB]) as the Interface ID. The Interface ID appears in Hello packets sent out the interface, the link-local-LSA originated by the router for the attached link, and the router-LSA originated by the router-LSA for the associated area. It will also serve as the Link State ID for the network-LSA that the router will originate for the link if the router is elected Designated Router.

The Interface ID for a virtual link is independent of the Interface ID of the outgoing interface it traverses in the transit area.

Instance ID

Every interface is assigned an Instance ID. This should default to 0. It is only necessary to assign a value other than 0 on those links that will contain multiple separate communities of OSPF routers. For example, suppose that there are two communities of routers on a given ethernet segment that you wish to keep separate.

The first community is assigned an Instance ID of 0 and all the routers in the first community will be assigned 0 as the Instance ID for interfaces connected to the ethernet segment. An Instance ID of 1 is assigned to the other routers' interfaces connected to the ethernet segment. The OSPF transmit and receive processing (see Section 4.2) will then keep the two communities separate.

List of LSAs with link-local scope

All LSAs with link-local scope and that were originated/flooded on the link belong to the interface structure that connects to the link. This includes the collection of the link's link-LSAs.

IP interface address

For IPv6, the IPv6 address appearing in the source of OSPF packets sent on the interface is almost always a link-local address. The one exception is for virtual links that MUST use one of the router's own global IPv6 addresses as IP interface address.

List of link prefixes

A list of IPv6 prefixes can be configured for the attached link. These will be advertised by the router in link-LSAs, so that they can be advertised by the link's Designated Router in intra-area-prefix-LSAs.

In OSPF for IPv6, each router interface has a single metric representing the cost of sending packets on the interface. In addition, OSPF for IPv6 relies on the IP Authentication Header (see [IPAUTH]) and the IP Encapsulating Security Payload (see [IPESP]) as described in [OSPFV3-AUTH] to ensure integrity and authentication/confidentiality of routing exchanges. For this reason, AuType and Authentication key are not associated with IPv6 OSPF interfaces.

Interface states, events, and the interface state machine remain unchanged from IPv4 as documented in Sections 9.1, 9.2, and 9.3 of [OSPFV2] respectively. The Designated Router and Backup Designated Router election algorithm also remains unchanged from the IPv4 election in Section 9.4 of [OSPFV2].

4.1.3. The Neighbor Data Structure

The neighbor structure performs the same function in both IPv6 and IPv4. Namely, it collects all information required to form an adjacency between two routers when such an adjacency becomes necessary. Each neighbor structure is bound to a single OSPF interface. The differences between the IPv6 neighbor structure and the neighbor structure defined for IPv4 in Section 10 of [OSPFV2] are:

Neighbor's Interface ID

The Interface ID that the neighbor advertises in its Hello packets must be recorded in the neighbor structure. The router will include the neighbor's Interface ID in the router's router-LSA when either a) advertising a point-to-point or point-to-multipoint link to the neighbor or b) advertising a link to a network where the neighbor has become the Designated Router.

Neighbor IP address

The neighbor's IPv6 address contained as the source address in OSPF for IPv6 packets. This will be an IPv6 link-local address for all link types except virtual links.

Neighbor's Designated Router

The neighbor's choice of Designated Router is now encoded as a Router ID instead of as an IP address.

Neighbor's Backup Designated Router

The neighbor's choice of Backup Designated Router is now encoded as a Router ID instead of as an IP address.

Neighbor states, events, and the neighbor state machine remain unchanged from IPv4 as documented in Sections 10.1, 10.2, and 10.3 of [OSPFV2] respectively. The decision as to which adjacencies to form also remains unchanged from the IPv4 logic documented in Section 10.4 of [OSPFV2].

---