OSPFv3 and OSPFv2 Differences

OSPFv3 differs from OSPFv2 in a number of respects:

• OSPFv3 processing is per link. OSPFv3 is link rather than subnet centric. An OSPFv3 interface connects to a link, not a subnet. This change has both functional and efficiency advantages. Multiple IP subnets can be assigned to a single link. Two nodes can talk directly over a single link. In OSPFv3, terms such as network and subnet should generally be replaced with the term link in order to understand OSPFv3 processing.
• With the exception of the new link LSA, OSPFv3 LSAs do not carry IPv6 addresses. The removal of addressing from the LSAs has scaling advantages. Router and network LSAs now only contain topology information necessary for SPF processing and no longer contain network addresses. OSPFv3 LSAs do maintain 32-bit RIDs and LSA IDs. Because OSPFv3 IDs are still expressed in dotted-quad notation, OSPFv3 networks can be easily overlayed on an OSPFv2 network.
• All OSPFv3 neighbors are identified by the neighbor router ID. The OSPFv2 behavior of identifying neighbors on broadcast and Non-Broadcast-Multi-Access (NBMA) links by their interface address has been removed.
• OSPFv3 uses link-local addresses, which begin with FF80::/10, as source and next-hop addresses. Link-local addresses are for use on a single link for purposes including neighbor discovery and auto-configuration. On all interfaces, except virtual, OSPF packets are sent using the interface‘s link-local unicast address as the source. Because all OSPF traffic transits the network on a link basis, IPv6 does not forward (route) IPv6 datagrams having link-local source addresses.
• OSPF specific authentication has been removed and replaced by optionally configuring IPsec for OSPFv3 as defined in RFC 4552. If IPsec for OSPFv3 is not enabled on the interface, OSPFv3 authentication does not take place for OSPF packets.
• RFC 1583 compatibility does not apply to OSPFv3.
• To take advantage of IPv6‘s link-local scope, OSPFv3 adds a link-local flooding scope to the domain and area flooding scopes present in OSPFv2. The link LSA, which has link-local flooding scope and can not be flooded beyond any attached router, has been added for neighbors on a single link.
• Two new LSAs have been introduced: the link LSA and the intra-area LSA. Point-to-point links are supported in order to enable operation over tunnels. OSPFv3 views IPv6‐over‐IPv4 tunnels as a point-to-point interface with a link-local address and possibly a global unicast address. OSPFv3 uses the reported MTU for tunnel interfaces.

  The prefix advertisement for OSPFv3 is now in the new intra-area prefix LSA. When information is only relevant to the connected neighbor, OSPFv3 puts it in the link LSA, not in the router or network LSA, in both cases avoiding flooding information beyond the relevant information scope.

OSPFv3 and OSPFv2 LSA Cross-Reference details the supported LSA types by LS ID and name for OSPFv3 and OSPF v2.

• Unlike for OSPFv2, the router and network LSAs for OSPFv3 do not advertise prefixes. In OSPFv3, the router and network LSAs only represent the router‘s node information for SPF and are only flooded if information relevant to the SPF algorithm changes. This behavior avoids the flooding of prefix changes that are not relevant to SPF.

  Inter-area prefix, inter-area router, and type-7 LSAs have the same function as their OSPFv2 counterparts listed in OSPFv3 and OSPFv2 LSA Cross-Reference.

• OSPFv3 specifies the processing of unsupported LSAs. Unsupported LSAs are maintained in the database and flooded according to scope. In OSPFv3, routers with 100 or more interfaces generate more than one router LSA. A new link LSA has been created. Addresses in LSAs are specified as [prefix, prefix length].
• OSPFv3 supports multiple OSPFv3 instances on an interface. Multiple OSPFv3 instances provide for the sharing of an interface when more than one physical network segment needs access to an interface. It also provides for the configuration of multiple areas on a single interface. Multiple OSPF instances on an interface is supported by OSPFv2. OSPFv2 does not support multiple areas on a single interface.
• The IPv6 all SPF routers multicast address is FF02::5; the all DRouters multicast address is FF02::6. Both have link-local scope.