The OSPFv3 address families feature enables both IPv4 and IPv6 unicast traffic to be supported. With this feature, users
may have two processes per interface, but only one process per AF. If the IPv4 AF is used, an IPv4 address must first be configured
on the interface, but IPv6 must be enabled on the interface. A single IPv4 or IPv6 OSPFv3 process running multiple instances
on the same interface is not supported.
Users with an IPv6 network that uses OSPFv3 as its IGP may want to use the same IGP to help carry and install IPv4 routes.
All devices on this network have an IPv6 forwarding stack. Some (or all) of the links on this network may be allowed to do
IPv4 forwarding and be configured with IPv4 addresses. Pockets of IPv4-only devices exist around the edges running an IPv4
static or dynamic routing protocol. In this scenario, users need the ability to forward IPv4 traffic between these pockets
without tunneling overhead, which means that any IPv4 transit device has both IPv4 and IPv6 forwarding stacks (e.g., is dual
stack).
This feature allows a separate (possibly incongruent) topology to be constructed for the IPv4 AF. It installs IPv4 routes
in IPv4 RIB, and then the forwarding occurs natively. The OSPFv3 process fully supports an IPv4 AF topology and can redistribute
routes from and into any other IPv4 routing protocol.
An OSPFv3 process can be configured to be either IPv4 or IPv6. The
address-family command is used to determine which AF will run in the OSPFv3 process, and only one address family can be configured per instance.
Once the AF is selected, users can enable multiple instances on a link and enable address-family-specific commands.
Different instance ID ranges are used for each AF. Each AF establishes different adjacencies, has a different link state
database, and computes a different shortest path tree. The AF then installs the routes in AF-specific RIB. LSAs that carry
IPv6 unicast prefixes are used without any modification in different instances to carry each AFs’ prefixes.
The IPv4 subnets configured on OSPFv3-enabled interfaces are advertised through intra-area prefix LSAs, just as any IPv6
prefixes. External LSAs are used to advertise IPv4 routes redistributed from any IPv4 routing protocol, including connected
and static. The IPv4 OSPFv3 process runs the SPF calculations and finds the shortest path to those IPv4 destinations. These
computed routes are then inserted in the IPv4 RIB (computed routes are inserted into an IPv6 RIB for an IPv6 AF).
Because the IPv4 OSPFv3 process allocates a unique pdbindex in the IPv4 RIB, all other IPv4 routing protocols can redistribute
routes from it. The parse chain for all protocols is same, so the
ospfv3 keyword added to the list of IPv4 routing protocols causes OSPFv3 to appear in the
redistribute command from any IPv4 routing protocol. With the
ospfv3 keyword, IPv4 OSPFv3 routes can be redistributed into any other IPv4 routing protocol as defined in the
redistribute
ospfv3 command.
Third-party devices will not neighbor with devices running the AF feature for the IPv4 AF because they do not set the AF
bit. Therefore, those devices will not participate in the IPv4 AF SPF calculations and will not install the IPv4 OSPFv3 routes
in the IPv6 RIB.