Open Shortest Path First version 3 (OSPFv3) was introduced in 1993 via RFC 2740 as “OSPF for IPv6.” It was later updated with RFC 5340. In general, OSPFv3 looks a lot like OSPFv2 in that the area types, router types and most of the Link State Advertisements (LSAs) area identical in description and function. OSPFv3 renames some of the LSAs to be more descriptive and others changed in function, so if you know OSPFv2, you already know at least 80 percent of OSPFv3. Some of what is happening “under the hood” of the protocols are different but as far as those that have to configure and support the protocols, they seem very similar.
One addition in OSPFv3 that OSPFv2 does not have is an instance number. OSPFv3 can support more than one instance per process. The original intent for the instance ID was to support multiple instances of OSPFv3 to run on the same interface. You could use an instance number of 0 (zero) through 255 to distinguish between the different OSPFv3 instances. In RFC 5838, the instance ID was re-purposed to be used to support address families with OSPFv3. The default instance is 0 if no other is defined. Instances 1 through 31 are still used to associate multiple OSPFv3 instances to an interface, 32 and above have been redefined. 32 is the base IPv6 multicast address family; 64 is the base IPv4 unicast address family; and 96 is the base IPv4 multicast address family. In addition to a modification to the interpretation of the instance field, the option field within the OSPF hello was also modified to include an address family (AF) bit to indicate the support for multiple address families. Let me be clear, OSPFv3 runs on top of IPv6 and uses IPv6 link local address to form OSPFv3 adjacencies, but can now advertise IPv4 routes as well. The Cisco routers do NOT support multicast OSPF (MOSPF), so the only supported address families for OSPFv3 on a Cisco router are IPv6 and IPv4 unicast.
Why Use Address Families for OSPFv3?
Well, if your protocol of choice is OSPF, then you most likely have been using it for IPv4. Now that we are moving towards IPv6, the logical move would be to also run OSPF for that protocol suite, which makes sense and reduces the learning curve for implementation and support. But, that would mean that you have to run two OSPF processes — one for IPv4 unicast and one for IPv6 unicast. That means two sets of policies have to be applied, including security for OSPF itself. Running OSPFv3 for both IPv4 and IPv6 reduces the number routing protocols and the configuration that goes with that.
It makes it easier to implement policy in a consistent way for both protocol suites. The way the protocol is handled within the router will save on CPU cycles for any of the protocol independent processes. The other benefit is the security of OSPFv3; it is better than OSPFv2 since OSPFv3 utilizes IPv6 native security features. This opens the door to use any of the IPsec features within the version of code to help lock down OSPFv3, including authentication and encryption, for both IPv6 and IPv4 routing information. This means that IPv6 has to be configured on all interfaces that you want to run OSPFv3 across, but if that’s the goal for you IPv6 deployment, that’s not that much of a concern.
This figure is an example of the configuration using OSPFv3 to support IPv4. The show output shows that OSPFv3 is passing IPv4 routing information and that the adjacency is protected with SHA-1:
Since OSPFv3 uses instance numbers to allow us to have multiple instances of the routing protocol for a single process, it seemed a natural progression that it may support IPv4, even though the original RFC states “OSPF for IPv6.” It make sense moving forward — as we look to replace IPv4 with IPv6 and start phase IPv4 out — that we would start phasing out IPv4 only routing protocols as well. OSPFv3 (as well as ISIS, EIGRP and BGP) are well positioned for that. With the addition of address families, it has made OSPFv3 a more attractive protocol and most likely will continue as the most popular Interior Gateway Protocol (IGP) out there.
Cisco White Papers