Similarities:
Network types and interface types
Interface state machines and neighbor state machines
LSDB
Flooding mechanism
Five types of packets: Hello, DD, LSR, LSU, and LSAck packets
Route calculation
Differences:
In OSPFv3, only LSAs in LSU packets contain address information.
OSPFv3 is based on links rather than network segments.
OSPFv3 runs over IPv6, which is based on links instead of network segments.
As such, the interfaces on which OSPFv3 is to be configured must be on the same link, rather than on the same network segment. In addition, the interfaces can establish OSPFv3 connections without IPv6 global addresses.
OSPFv3 does not depend on IP addresses.
OSPFv3 separates topology calculation from IP addresses. OSPFv3 can calculate the OSPFv3 topology without knowing IPv6 global addresses, which are used only for Vlink interfaces and packet forwarding.
OSPFv3 packets and the LSA format change.
OSPFv3 packets do not contain IP addresses.
OSPFv3 router LSAs and network LSAs do not contain IP addresses, which are advertised through link LSAs and intra-area prefix LSAs.
In OSPFv3, router IDs, area IDs, and LSA link state IDs no longer indicate IP addresses, but the IPv4 address format is still reserved.
Neighbors are identified by router IDs instead of IP addresses on broadcast, NBMA, or P2MP networks.
Information about the flooding scope is added to OSPFv3 LSAs.
Information about the flooding scope is added to the LSA Type field of OSPFv3 LSAs. Therefore, OSPFv3 routers can process LSAs of unidentified types.
OSPFv3 can store or flood unidentified packets, whereas OSPF discards unidentified packets.
In OSPFv3, unknown LSAs with the U flag set to 1 can be flooded, and the flooding scope of such LSAs is specified by the LSAs.
For example, DeviceA and DeviceB can identify LSAs of a certain type. DeviceA and DeviceB are connected through DeviceC which, however, cannot identify these LSAs. If DeviceA floods such LSA to DeviceC, DeviceC can still flood the received LSAs to DeviceB although DeviceC does not identify these LSAs. DeviceB then processes these LSAs.
If OSPFv2 is run, DeviceC discards the unidentified LSAs. As a result, these LSAs cannot reach DeviceB.
OSPFv3 supports multi-process on a link.
In OSPFv2, one physical interface can be bound to only one multi-instance. In OSPFv3, one physical interface can be bound to multiple multi-instances that are identified by different instance IDs. In these OSPFv3 multi-instances running on one physical interface, neighbor relationships are established separately, sharing resources on the same link.
OSPFv3 uses IPv6 link-local addresses.
IPv6 implements neighbor discovery and automatic configuration based on link-local addresses. Routers running IPv6 do not forward IPv6 packets whose destination address is a link-local address, and those packets can only be exchanged on the same link. The unicast link-local address starts from FE80/10.
As a routing protocol running on IPv6, OSPFv3 also uses link-local addresses to maintain neighbor relationships and update LSDBs. Except Vlink interfaces, all OSPFv3 interfaces use link-local addresses as the source address and the next hop to transmit OSPFv3 packets.
OSPFv3 can calculate the topology without global IPv6 addresses.
The packets flooded on a link are not transmitted to other links, which prevents unnecessary flooding and saves bandwidth.
OSPFv3 supports two new LSAs.
Link LSA: A device floods a link LSA on the link where it resides to advertise its link-local address and the configured global IPv6 address.
Intra-area prefix LSA: A device advertises an intra-area prefix LSA in the local area to inform the other devices in the area or the network (either a broadcast network or an NBMA network) of its IPv6 global address.
OSPFv3 identifies neighbors based on Router IDs only.
On broadcast, NBMA, and P2MP networks, OSPFv2 identifies neighbors based on IPv4 addresses of interfaces.
OSPFv3 identifies neighbors based on Router IDs only.