OSPFv2 versus OSPFv3

By stretch | Tuesday, March 2, 2010 at 4:27 a.m. UTC

OSPFv3 is to IPv6 what OSPFv2 is to IPv4. The two versions of OSPF naturally have much in common, however there are several important differences in the way the two protocols operate. This article seeks to highlight some of the more noteworthy deviations. (For a more thorough discussion, see section 2 of RFC 5340.) For illustration, both OSPFv2 and OSPFv3 have been configured on the example topology below.

OSPFv2-OSPFv3.png

For some IOS OSPFv3 configuration fundamentals, see IPv6 and OSPFv3.

New LSA Types

OSPFv3 carries over the seven basic LSA types we're familiar with from OSPFv2. However, the type 1 and 2 LSAs have been re-purposed, as will be discussed in a bit. OSPFv3 also introduces two new LSA types: Link and Intra-area Prefix.

OSPFv3OSPFv2
0x2001Router LSA1Router LSA
0x2002Network LSA2Network LSA
0x2003Inter-area Prefix LSA3Network Summary LSA
0x2004Inter-area Router LSA4ASBR Summary LSA
0x4005AS-External LSA5AS-External LSA
0x2006Group Membership LSA6Group Membership LSA
0x2007Type-7 LSA7NSSA External LSA
0x0008Link LSA
0x2009Intra-area Prefix LSA

Separation of Addressing from the SPF Tree

One of the biggest advantages of OSPFv3 over its predecessor is the separation of IP addressing from the calculation of the SPF tree. One of OSPFv3's new LSAs, the Intra-area Prefix LSA (type 9), handles intra-area network information that was previously included in OSPFv2 type 2 LSAs. Because IP addressing is communicated independent of the LSAs used for SPF tree calculation, adding or modifying IP subnets within the OSPF domain will not affect the integrity of the SPF tree (which is concerned only with nodes and the links between them) and avoid forcing an SPF recalculation.

For illustration, following are the two OSPF databases from R2 in our example topology:

R2# show ip ospf database

            OSPF Router with ID (2.2.2.2) (Process ID 1)

        Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         1697        0x80000001 0x00264B 2
4.4.4.4         4.4.4.4         1693        0x80000002 0x005216 2

        Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
10.0.123.0      2.2.2.2         1683        0x80000002 0x00DEC5

        Router Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         1656        0x80000003 0x00BB55 1
2.2.2.2         2.2.2.2         1655        0x80000003 0x008086 1
3.3.3.3         3.3.3.3         1656        0x80000003 0x003FBF 1

        Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
10.0.123.3      3.3.3.3         1656        0x80000001 0x007B0E

        Summary Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
10.0.0.0        2.2.2.2         1694        0x80000001 0x003BB2
R2# show ipv6 ospf database

            OSPFv3 Router with ID (2.2.2.2) (Process ID 1)

        Router Link States (Area 0)

ADV Router      Age         Seq#        Fragment ID  Link count  Bits
2.2.2.2         1694        0x80000002  0            1           B
4.4.4.4         1695        0x80000002  0            1           None

        Inter Area Prefix Link States (Area 0)

ADV Router      Age         Seq#        Prefix
2.2.2.2         1692        0x80000001  2001:DB8:0:123::/64

        Link (Type-8) Link States (Area 0)

ADV Router      Age         Seq#        Link ID    Interface
2.2.2.2         1696        0x80000002  6          Se1/0
4.4.4.4         1699        0x80000002  6          Se1/0

        Intra Area Prefix Link States (Area 0)

ADV Router      Age         Seq#        Link ID    Ref-lstype  Ref-LSID
2.2.2.2         1696        0x80000001  0          0x2001      0
4.4.4.4         1699        0x80000001  0          0x2001      0

        Router Link States (Area 1)

ADV Router      Age         Seq#        Fragment ID  Link count  Bits
1.1.1.1         1652        0x80000005  0            1           None
2.2.2.2         1652        0x80000005  0            1           B
3.3.3.3         1649        0x80000005  0            1           None

        Net Link States (Area 1)

ADV Router      Age         Seq#        Link ID    Rtr count
3.3.3.3         1661        0x80000001  4          3

        Inter Area Prefix Link States (Area 1)

ADV Router      Age         Seq#        Prefix
2.2.2.2         1693        0x80000001  2001:DB8::/64

        Link (Type-8) Link States (Area 1)

ADV Router      Age         Seq#        Link ID    Interface
1.1.1.1         1697        0x80000002  4          Fa0/0
2.2.2.2         1698        0x80000002  4          Fa0/0
3.3.3.3         1696        0x80000002  4          Fa0/0

        Intra Area Prefix Link States (Area 1)

ADV Router      Age         Seq#        Link ID    Ref-lstype  Ref-LSID
3.3.3.3         1662        0x80000001  4096       0x2002      4

Note that the OSPFv3 database appears larger, because network addressing is now stored separately in the new Link and Intra-area LSAs.

LSA Flooding Scope

Looking again at the above table of LSA types, one might note that OSPFv3 LSA numbers begin with differing numbers (for example, 0x2001 versus 0x4005). The second and third most-significant bits in an LSA number (referenced as bits S2 and S1, respectively) indicate its flooding scope:

S2S1Flooding Scope
00Link-local
01Area
10AS (OSPF domain)
11Reserved

Most LSAs begin with 0x2, indicating that they are flooded within an area. Two LSAs of note are the AS-External LSA (which advertises external routes) with a domain-wide scope, and the Link LSA with a scope appropriately restricted to the local link.

Link-local Addressing

An OSPFv2 router forms adjacencies using its configured IPv4 interface address:

R1# show ip ospf neighbor detail
 Neighbor 2.2.2.2, interface address 10.0.123.2
    In the area 1 via interface FastEthernet0/0
    Neighbor priority is 1, State is FULL, 6 state changes
    DR is 10.0.123.3 BDR is 10.0.123.2
    Options is 0x52
    LLS Options is 0x1 (LR)
    Dead timer due in 00:00:37
    Neighbor is up for 00:15:32
    Index 2/2, retransmission queue length 0, number of retransmission 0
    First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
    Last retransmission scan length is 0, maximum is 0
    Last retransmission scan time is 0 msec, maximum is 0 msec
...

OSPFv3, however, makes use of IPv6's link-local address scope (FE80::/10). All OSPFv3 adjacencies are formed using link-local addresses:

R1# show ipv6 ospf neighbor detail
 Neighbor 3.3.3.3
    In the area 1 via interface FastEthernet0/0 
    Neighbor: interface-id 4, link-local address FE80::C003:7DFF:FE07:0
    Neighbor priority is 1, State is FULL, 6 state changes
    DR is 3.3.3.3 BDR is 2.2.2.2
    Options is 0x6670B96D
    Dead timer due in 00:00:32
    Neighbor is up for 00:16:48
    Index 1/1/1, retransmission queue length 0, number of retransmission 0
    First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0)
    Last retransmission scan length is 0, maximum is 0
    Last retransmission scan time is 0 msec, maximum is 0 msec

Also note in the second output that neighboring routers are referred to not by IP address, but by OSPF ID, demonstrating OSPFv3's fundamental separation of the SPF tree and IP addressing. It is worth pointing out that OSPFv3 router IDs are not IPv4 addresses; they are merely unique 32-bit identifiers expressed in the familiar dotted-decimal notation.

Support for Multiple Instances Per Link

OSPFv3 includes support for multiple instances of OSPF running in parallel across a common link. This is especially handy for shared network segments such as those found in Internet exchange points. On Cisco IOS, OSPFv3 instances are configured by appending the instance argument to the ipv6 ospf statement:

Router(config-if)# ipv6 ospf 100 area 0 instance 1

Removal of OSPF-specific Authentication

OSPFv2 authentication is achieved by implementing a shared secret and MD5 HMAC supported as part of the OSPFv2 protocol. OSPFv3 does away its own support for authentication entirely, instead relying on the more flexible IPsec framework offered by IPv6. For more detail on how OSPFv3 authentication is configured, see OSPFv3 authentication.

Improved Handling of Unknown LSA Types

OSPFv2 routers simple discard LSAs of an unknown type. OSPFv3 LSAs may be discarded, or optionally stored and flooded as though they were understood. Which action is taken is determined by the most-significant bit (the U bit) in the LSA type number. This option allows for the introduction of new LSA types across OSPF networks where only some routers support the new types.

Cisco IOS Configuration Differences

Cisco notes some differences in the way OSPFv2 and OSPFv3 are configured here. A brief summary:

  • Enabling OSPF on an IPv6 interface automatically enables OSPFv3; an explicit OSPFv3 routing process does not need to be administratively created (though it likely still will be for other purposes).
  • OSPFv3 interfaces must be designated under interface configuration; there is no option to designate interfaces using the network command under router configuration.
  • NBMA neighbors must be identified by link-local IPv6 address.
  • Like OSPFv2, OSPFv3 will take its router ID from the highest-numbered IPv4 loopback interface; however, as this IPv4 address is likely irrelevant your IPv6 network, it is recommended to manually specify a router ID with the router-id command under OSPFv3 router configuration.

About the Author

Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.

Posted in Routing

Comments


nainashujal
March 2, 2010 at 6:31 a.m. UTC

Excellent work..


Rob (guest)
March 2, 2010 at 1:38 p.m. UTC

Thanks a lot! I can get more out of your blog in 20 minutes than reading CP for two hours.


bashkhid
March 3, 2010 at 9:39 a.m. UTC

Nice one. Thanks


Dre (guest)
March 5, 2010 at 6:45 p.m. UTC

I'm currently in the process of introducing IPv6 in our network. We currently use OSPFv2 for our IPv4 network.

I was wondering if OSPV3 is exclusively used for IPv6 networks, maybe in conjunction with OSPFv2 for IPv4. Or if one could just use OSPFv3 for both IPv4 as well as IPv6.

If OSPFv3 uses ipv6 link local addresses, this probably means that all parts of the network need to support IPv6. Correct?

In our case I was wondering if we could migrate everything to OSPFv3 (ipv4 only) and then introduce IPv6. This would have the benefit of only one IP routing protocol. However doing it in this order would imply we need IPv6 support everywhere before deploying IPv6 (because of the link local requirement)?

Thanks!


stretch
March 5, 2010 at 7:58 p.m. UTC

@Dre: Currently, OSPFv3 only supports IPv6, however this is an Internet draft in the works to port IPv4 to the protocol as well to take advantage of its higher efficiency. The draft suggests the assignments of OSPFv3 instance ID ranges to specific address families (IPv6 unicast, IPv6 multicast, IPv4 unicast, and IPv4 multicast) not unlike MP-BGP.

For now I would suggest simply rolling out OSPFv3 in parallel to your OSPFv2 topology, but keep the draft's supposed instance ID allocations if you implement multiple instances of OSPFv3.


Didzis Ozolins (guest)
May 3, 2010 at 4:00 p.m. UTC

Really nice article, Stretch. However, i've spotted some little mistakes. You said that

One of OSPFv3's new LSAs, the Intra-area Prefix LSA (type 9), handles intra-area network information that was previously included in OSPFv2 type 2 LSAs.

Actually Intra-area Prefix LSA handles prefix information that is included in the OSPFv2 Router and Network LSA's. And also, about NBMA networks, you identify neighbor by it's link-local address not RID.


yamini priya (guest)
November 15, 2010 at 12:33 p.m. UTC

Hi, Whats exact usage of Instance ID in OSPFv3?? can a link can be given two different instance id in the same area .. or it is mandatory that it should in different area?


yamini
December 8, 2010 at 4:12 a.m. UTC

Hi, Whats exact usage of Instance ID in OSPFv3? Will there be separate routing table for each instance? if yes, then how data packets ll access that particluar Routing Table? I mean whether data packets can too support instance id.. ?

Thanks


Vijay (guest)
November 17, 2011 at 10:51 a.m. UTC

Rob: "Thanks a lot! I can get more out of your blog in 20 minutes than reading CP for two hours." - Second that!! Thanks.
Challenge question: How many bytes in length a UDP header? Another search on Google!!


shanu (guest)
February 20, 2013 at 7:49 p.m. UTC

really nice blog...can you explain the use of fragment id??


Ivan (guest)
May 15, 2014 at 9:41 a.m. UTC

Informative, thanks a lot stretch.


Roma (guest)
March 23, 2016 at 2:29 a.m. UTC

"cisco multiple instances of OSPFv3 can be run on a link" Please advise I'm trying to create multiple instances under interface using ospfv3 with 2 pocess ID's, but as soon I add a new instance the old one -config disappears.

Comments have closed for this article due to its age.