OSPFv3 differences from OSPFv2.

OSPFv3 is specified in RFC 5340. The RFC starts out by saying that, even though the protocol is updated, most of the fundamental mechanics (flooding, DR/BDR, area’s, SPF, etc.) remain unaltered. In chapter 2 of the RFC, you can find a list of things that have been altered.

Instead of regurgitating this list, I wanted to highlight its items by briefly go through the OSPFv3 packet, Hello and LSA types.

The packets.



scenario


There are no authentication or authentication type fields present in the OSPFv3 packet. OSPFv3 will rely on IPv6 extension headers to provide for authentication.

The OSPFv3 packet has an Instance ID field. Each OSPFv3 instance will be assigned a locally significant separate Instance ID. Through this field, explicit support for multiple instances per link is provided.

0 is simply a field reserved for future purposes.

Packets of both versions of the OSPF protocol are carried directly in IP/IPv6. The IP protocol number is 89 in both of the OSPF versions. The IPv4 OSPF packets are send to 224.0.0.5 (all SPF-routers) or 224.0.0.6 (all DR-routers). In IPv6, the packets are send to FF02::5 (all SPF-routers) or FF02::6 (all DR-routers). In both cases, the scope is link local.

Both of the OSPF versions use the same messages. The 5 OSPF packet types (for both OSPFv2 and v3) are the following:

OSPF packet type Description
1 Hello
2 Database Description
3 Link State Request
4 Link State Update
5 Link State Acknowlegdement

Moving on to the Hellos.



scenario


The OSPFv3 and OSPFv2 Hellos are very similar. In OSPFv3, the network mask field from the OSPFv2 Hello is replaced with an Interface ID field. The Interface ID is a 32-bit number that uniquely identifies an interface amongst the collection of the interfaces a router has.

The network mask field is not needed as the IPv6 adjacencies are build using the IPv6 link-local addresses.

Moving on to the LSAs.

Below is an overview on how the OSPFv3 and OSPFv2 LSAs relate to each other. For the OSPFv3 LSAs, I also included the flooding scope of the different LSAs;

OSPFv3 LSA type - function code: OSPFv3 LSA name: OSPFv2 LSA type: OSPFv2 LSa name:
0x2001 - 1 (Area scope) Router-LSA 1 Router-LSA
0x2002 - 2 (Area scope) Network-LSA 2 Network-LSA
0x2003 - 3 (Area scope) Inter-Area-Prefix-LSA 3 Summary-LSA
0x2004 - 4 (Area scope) Inter-Area-Router-LSA 4 ASBR-Summary-LSA
0x4005 - 5 (AS scope) AS-External-LSA 5 AS-External-LSA
0x2006 - 6 (Area scope) Deprecated
0x2007 - 7 (Area scope) NSSA-LSA 7 NSSA External LSA
0x0008 - 8 (link-local) Link-LSA
0x2009 - 9 (Area scope) Intra-Area-Prefix-LSA

The Link-LSA and Intra-Area-Prefix-LSA do not have a counterpart in the list above so I wanted to briefly go over those two LSAs.

The Link-LSA is originated by all OSPFv3 routers. The LSA is originated with a link-local flooding scope on every physical link. The Link-LSA provide the router’s link-local IPv6 address to the other routers attached on the link. It also informs the other routers of the list of IPv6 prefixes associated with the link.

Besides this, the Link-LSA is also used by the DR to advertise a collection of Option bits on multiaccess segments.

The Intra-Area-Prefix-LSA is the other LSA that does not have a real counterpart either. OSPFv2 uses the Router-LSA and the Network-LSA to advertise a local router address and the connected segments. In OSPFv3, addressing information is moved from Router-LSA and Network-LSA to Intra-Area-Prefix-LSA.




In closing, I briefly wanted to mention two more worthwhile items from the chapter 2 list that is presented in RFC 5340. First, in OSPFv3, link-local addresses are used to establish adjacencies. OSPFv2 used the interface IP addresses for this. The link-local addresses are not use on a virtual-link.

Second is the removal of addressing semantics. This effectively makes OSPFv3 capable of carrying routing information for other protocols (say IPv4 for instance) as well.

16-10-2014.