OSPFv3 is the version of OSPF that is used over IPv6 networks, and in terms of communication, assumes that each router has been assigned link-local unicast addresses on each of the router's attached physical links. OSPF packets are sent using the associated link-local unicast address of a given physical interface as the source address. A router learns the link-local addresses of all other routers attached to its links and uses these addresses as next-hop information during packet forwarding. This operation is true for all physical links with the exception of virtual links which are outside the scope of this material.
A reserved “AllSPFRouters” multicast address has been assigned the value FF02::5, reflecting the multicast address 224.0.0.5 used in OSPFv2, for which it should be noted that the two versions are not compatible. All routers running OSPFv3 should be prepared to receive packets sent to this address. Hello packets are always sent to this destination, as well as certain OSPF protocol packets during the flooding procedure.
The router ID plays a prominent role in OSPFv3 and is now always used to identify neighboring routers. Previously, they had been identified by an IPv4 address on broadcast, NBMA (Non-Broadcast Multi-Access), and point-to-multipoint links. Each router ID (as well as the area ID) is maintained as a 32 bit dotted decimal value and cannot be configured using an IPv6 address.
The router ID also continues to actively act as a tie breaker in the event that the priority associated with each OSPFv3 enabled router is equal. In such cases the Designated Router (DR) is identified as the router possessing the highest router ID. Hello messages sent will contain a router ID set to 0.0.0.0 if there is no Designated Router. The same principle applies for the Backup Designated Router, identified by the next highest router ID. A priority of 0 set on a router interface participating in OSPFv3 will deem the router as ineligible to participate in DR/BDR elections. Router Priority is only configured for interfaces associated with broadcast and NBMA networks.
The multicast address “AllDRouters” has been assigned the value FF02::6, the equivalent of the 224.0.0.6 multicast address used in OSPFv2 for IPv4. The Designated Router and Backup Designated Router are both required to be prepared to receive packets destined to this address.
IPv6 refers to the concept of links to mean a medium between nodes over which communication at the link layer is facilitated. Interfaces therefore connect to links and multiple IPv6 subnets can be associated with a single link, to allow two nodes to communicate directly over a single link, even when they do not share a common IPv6 subnet (IPv6 prefix). OSPFv3 as a result operates on a per-link basis instead of per-IP-subnet as is found within IPv4. The term link therefore is used to replace the terms network and subnet which are understood within OSPFv2. OSPF interfaces are now understood to connect to a link instead of an IP subnet. This change affects the receiving of OSPF protocol packets, the contents of Hello packets, and the contents of network-LSAs.
The impact of links can be understood from OSPFv3 capability to now support multiple OSPF protocol instances on a single link. Where separate OSPF routing domains that wish to remain separate but operate over one or more physical network segments (links) that are common to the different domains. IPv4 required isolation of the domains through authentication which did not provide a practical solution to this design requirement.
The per-link operation also means the Hello packet no longer contains any address information, and instead it now includes an Interface ID that the originating router assigns to uniquely identify (among its own interfaces) its interface to the link.
Authentication in OSPFv3 is no longer supported, and as such the authentication type and authentication (value) fields from the OSPF packet header no longer exist. As of IPv6, changes to the IP header have allowed for the utilization of security protocols that were only present in IPv4 as part of the IPsec suite, since initial TCP/IP development in the late 1960’s was never designed with security in mind, since security of TCP/IP at the time was not foreseen as a future requirement.
With the security improvements made to IPv6 and the utilization of IP extension headers in the protocol suite, OSPFv3 is capable of relying on the IP Authentication Header and the IP Encapsulating Security Payload to ensure integrity as well as authentication & confidentiality, during the exchange of OSPFv3 routing information.
Implementing OSPFv3 between peers requires, as with RIPng, that the router firstly be capable of supporting IPv6. Additionally the router must also enable the OSPFv3 protocol globally in the system view. Each interface should be assigned an IPv6 address. During the configuration of RIPng it was demonstrated how the interface can be automatically configured to assign a link local address. In this example an alternative and recommended method of link local address assignment is demonstrated. The link local IPv6 address is manually assigned and designated as a link local address using the ipv6 <link local address> link-local command. If the address associated with the physical interface is a global IPv6 unicast address, the interface will also automatically generate a link local address.
In order to generate an OSPFv3 route, the example demonstrates assigning global unicast addresses to the logical loopback interface of each router. The physical and logical interfaces both should be associated with the OSPFv3 process and be assigned a process ID (typically the same ID unless they are to operate as separate instances of OSPFv3) and also be assigned to an area, which in this case is confined to area 0.
As a reminder, OSPFv3 nodes rely on identification by neighboring routers through the use of the router ID, and therefore a unique router ID should be assigned for each router under the OSPFv3 protocol view following the configuration of the ospfv3 command.
Following the configuration of neighboring routers participating in OSPFv3, the display ospfv3 command is used to verify the operation and parameters associated with OSPFv3. Each router will show a running OSPFv3 process and a unique router ID. If the adjacency between neighbors is established, the number of FULL (state) neighbors will show a value greater than zero.
A 32-bit router ID is used to uniquely distinguish each node running OSPFv3.