OSPFv3 Address Families: How They’re Used and Why

OSPFv3AddressFamilies99661160Open Shortest Path First version 3 (OSPFv3) was introduced in 1993 via RFC 2740 as “OSPF for IPv6.” It was later updated with RFC 5340. In general, OSPFv3 looks a lot like OSPFv2 in that the area types, router types and most of the Link State Advertisements (LSAs) area identical in description and function. OSPFv3 renames some of the LSAs to be more descriptive and others changed in function, so if you know OSPFv2, you already know at least 80 percent of OSPFv3. Some of what is happening “under the hood” of the protocols are different but as far as those that have to configure and support the protocols, they seem very similar.

One addition in OSPFv3 that OSPFv2 does not have is an instance number. OSPFv3 can support more than one instance per process. The original intent for the instance ID was to support multiple instances of OSPFv3 to run on the same interface. You could use an instance number of 0 (zero) through 255 to distinguish between the different OSPFv3 instances. In RFC 5838, the instance ID was re-purposed to be used to support address families with OSPFv3. The default instance is 0 if no other is defined. Instances 1 through 31 are still used to associate multiple OSPFv3 instances to an interface, 32 and above have been redefined. 32 is the base IPv6 multicast address family; 64 is the base IPv4 unicast address family; and 96 is the base IPv4 multicast address family. In addition to a modification to the interpretation of the instance field, the option field within the OSPF hello was also modified to include an address family (AF) bit to indicate the support for multiple address families. Let me be clear, OSPFv3 runs on top of IPv6 and uses IPv6 link local address to form OSPFv3 adjacencies, but can now advertise IPv4 routes as well. The Cisco routers do NOT support multicast OSPF (MOSPF), so the only supported address families for OSPFv3 on a Cisco router are IPv6 and IPv4 unicast.

Why Use Address Families for OSPFv3?

Well, if your protocol of choice is OSPF, then you most likely have been using it for IPv4. Now that we are moving towards IPv6, the logical move would be to also run OSPF for that protocol suite, which makes sense and reduces the learning curve for implementation and support. But, that would mean that you have to run two OSPF processes — one for IPv4 unicast and one for IPv6 unicast. That means two sets of policies have to be applied, including security for OSPF itself. Running OSPFv3 for both IPv4 and IPv6 reduces the number routing protocols and the configuration that goes with that.

It makes it easier to implement policy in a consistent way for both protocol suites. The way the protocol is handled within the router will save on CPU cycles for any of the protocol independent processes. The other benefit is the security of OSPFv3; it is better than OSPFv2 since OSPFv3 utilizes IPv6 native security features. This opens the door to use any of the IPsec features within the version of code to help lock down OSPFv3, including authentication and encryption, for both IPv6 and IPv4 routing information. This means that IPv6 has to be configured on all interfaces that you want to run OSPFv3 across, but if that’s the goal for you IPv6 deployment, that’s not that much of a concern.

Configuration Example

This figure is an example of the configuration using OSPFv3 to support IPv4. The show output shows that OSPFv3 is passing IPv4 routing information and that the adjacency is protected with SHA-1:

Configuration-Using-OSPFv3-to-Support-IPv4
R1#sh run
interface Loopback0
ip address 1.1.1.1 255.255.255.0
ipv6 address 2005:DEAD:BEEF:1::1/96
ospfv3 1 ipv6 area 1
ospfv3 1 ipv4 area 1
!
interface Serial1/1
ip address 192.168.12.1 255.255.255.0
ipv6 address 2005:DEAD:BEEF:12::1/80
ospfv3 authentication ipsec spi 256 sha1 ABABABABABABABABABABABABABABABABABABABAB
ospfv3 1 ipv4 area 0
ospfv3 1 ipv6 area 0
!
router ospfv3 1
router-id 1.1.1.1
!
address-family ipv4 unicast
exit-address-family
!
address-family ipv6 unicast
exit-address-family
!
R2# sh run
interface Loopback0
ip address 2.2.2.2 255.255.255.0
ipv6 address 2005:DEAD:BEEF:2::2/96
ospfv3 1 ipv6 area 2
ospfv3 1 ipv4 area 2
!
interface Serial1/1
ip address 192.168.12.2 255.255.255.0
ipv6 address 2005:DEAD:BEEF:12::2/80

ospfv3 1 ipv4 area 0
ospfv3 1 ipv6 area 0
!
router ospfv3 1
router-id 2.2.2.2
!
address-family ipv4 unicast
exit-address-family
!
address-family ipv6 unicast
exit-address-family
!
R2#sh ipv6 route ospf
IPv6 Routing Table - default - 6 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
         B - BGP, R - RIP, H - NHRP, I1 - ISIS L1
         I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary, D - EIGRP
         EX - EIGRP external, ND - ND Default, NDp - ND Prefix, DCE - Destination
         NDr - Redirect, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
         OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, l - LISP
OI   2005:DEAD:BEEF:1::1/128 [110/64]
       via FE80::C800:22FF:FEA8:8, Serial1/1
R2#sh ip route ospfv3
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
         D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
         N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
         E1 - OSPF external type 1, E2 - OSPF external type 2
         i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
         ia - IS-IS inter area, * - candidate default, U - per-user static route
         o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
         + - replicated route, % - next hop override

Gateway of last resort is not set

       1.0.0.0/32 is subnetted, 1 subnets
O IA     1.1.1.1 [110/64] via 192.168.12.1, 00:10:46, Serial1/1
R2#sh ospfv3 database inter-area prefix

         OSPFv3 1 address-family ipv4 (router-id 2.2.2.2)

               Inter Area Prefix Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 762
  LS Type: Inter Area Prefix Links
  Link State ID: 0
  Advertising Router: 1.1.1.1
  LS Seq Number: 80000001
  Checksum: 0xA46E
  Length: 32
  Metric: 0
  Prefix Address: 1.1.1.1

 

  Prefix Length: 32, Options: None
- output omitted -
R2#sh ospfv3 neighbor 1.1.1.1 detail

         OSPFv3 1 address-family ipv4 (router-id 2.2.2.2)

Neighbor 1.1.1.1, interface address 192.168.12.1
    In the area 0 via interface Serial1/1
    Neighbor: interface-id 5, link-local address FE80::C800:22FF:FEA8:8

 

    Neighbor priority is 0, State is FULL, 24 state changes
    Options is 0x000112 in Hello (E-Bit, R-bit, AF-Bit)
    Options is 0x000112 in DBD (E-Bit, R-bit, AF-Bit)
    Dead timer due in 00:00:33
    Neighbor is up for 00:14:19
    Index 1/1/1, retransmission queue length 0, number of retransmission 3
    First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0)
    Last retransmission scan length is 4, maximum is 4
    Last retransmission scan time is 4 msec, maximum is 4 msec
- output omitted -
R2#sh ospfv3 interface ser1/1
Serial1/1 is up, line protocol is up
  Link Local Address FE80::C801:22FF:FEA8:8, Interface ID 5
  Internet Address 192.168.12.2/24
  Area 0, Process ID 1, Instance ID 64, Router ID 2.2.2.2
  Network Type POINT_TO_POINT, Cost: 64
  SHA-1 authentication SPI 256, secure socket UP (errors: 0)

 

  Transmit Delay is 1 sec, State POINT_TO_POINT
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 00:00:01
  Graceful restart helper support enabled
  Index 1/1/2, flood queue length 0
  Next 0x0(0)/0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 1
  Last flood scan time is 4 msec, maximum is 4 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 1.1.1.1
  Suppress hello for 0 neighbor(s)
- output omitted -

 
Since OSPFv3 uses instance numbers to allow us to have multiple instances of the routing protocol for a single process, it seemed a natural progression that it may support IPv4, even though the original RFC states “OSPF for IPv6.” It make sense moving forward — as we look to replace IPv4 with IPv6 and start phase IPv4 out — that we would start phasing out IPv4 only routing protocols as well. OSPFv3 (as well as ISIS, EIGRP and BGP) are well positioned for that. With the addition of address families, it has made OSPFv3 a more attractive protocol and most likely will continue as the most popular Interior Gateway Protocol (IGP) out there.

Related Resource
Cisco White Papers

Related Courses
IP6FD – IPv6 Fundamentals, Design, and Deployment v3.0
ROUTE – Implementing Cisco IP Routing v2.0

In this article

Join the Conversation