OSPFv3 instance ID

One of the advancements of OSPFv3 over OSPFv2 is the use of the instance ID. This instance ID is an 8 bit field within the OSPFv3 header.

The original intent for the instance ID was to support multiple instances of OSPFv3 to run on the same interface. In this way, you can manipulate which routers on a particular segment are allowed to form adjacencies. You could use an instance number of 0 through 255 to distinguish between the different OSPFv3 instances.

However, within RFC 5838, the instance ID was re-purposed to be used to support address families (AFs) with OSPFv3. The default instance of 0 is used if no other instance is defined. However, specific ranges of the instance ID map to specific AFs. According to the RFC, these ranges are:

Instance ID # 0 - # 31 IPv6 unicast AF Instance ID # 32 - # 63 IPv6 multicast AF Instance ID # 64 - # 95 IPv4 unicast AF Instance ID # 96 - # 127 IPv4 multicast AF Instance ID # 128 - # 255 Unassigned

If you go into the command line of a Cisco IOS device, you will see that only specific instance ID values are allowed for each address family you use:

R1-Hub(config-if)#ospfv3 1 ipv6 area 0 instance ? <0-31> Instance ID R1-Hub(config-if)#ospfv3 1 ipv4 area 0 instance ? <64-95> Instance ID

As you can see, 0-31 matches with the available values for the command using IPv6 unicast, while the same is true for IPv4 unicast. Note here that OSPFv3 runs on top of IPv6 and uses IPv6 IPv6 link-local address addresses to form OSPFv3 adjacencies. However, OSPFv3, using these instance IDs can now advertise IPv4 routes too. Note also that Cisco routers do not support multicast OSPF, so you don’t see those instance ID values at all in any of the Cisco configuration options.

Links:

https://forum.networklessons.com/t/ospfv2-vs-ospfv3/2073/14?u=lagapides

https://datatracker.ietf.org/doc/html/rfc5838