OSPFv3 is the updated version of OSPFv2 that has support for IPv6 addressing as well as IPv4. OSPFv3 is defined in RFC 5340. OSPFv3 differs to OSPFv2 in the following ways:
- Support for multiple address families: OSPFv3 supports both IPv4 and IPv6 configuration.
- New LSA Types: Type 8 and 9 LSA's are used in OSPFv3 to support IPv6 prefixes.
- Removal of addressing semantics: IP Prefix information is no longer carried in the header but in the LSA itself making the protocol essentially address family independent.
- LSA Flooding: OSPFv3 includes a new Link-state Type field that is used to determine the flooding scope of the LSA and how unknown LSA's are handled.
- Packet Format: OSPFv3 runs directly over IPv6 and the number of fields in the packet have been reduced.
- Router ID: The router ID is ised to identify neighbours regardless of address family used. OSPFv3 must have a router ID set.
- Authentication: Neighbour authentication has been removed, instead relying on IPv6 IPSec extension headers for authentication.
- Neighbour Adjacencies: Neighbour communication is handled by IPv6 Link Local addresses. Neighbours on NBMA networks are not auto discovered. OSPFv3 also allows for neighbour adjacency even when two routers do not share the same common subnet.
- Multiple Instances: OSPFv3 packets include an instance ID field to manipulate which routers on a segment are allowed to form adjacencies.
There are some other changes in OSPFv3 regarding the LSA Types and Names.
- The structure of the Type 1 Router LSA has been modified
- The Network LSA is now called the Inter-Area Prefix LSA
- The ASBR Summary LSA is now the Inter-Area Router LSA
The main difference with the Type 1 LSA is that it now only advertises the interface parameters such as interface type and metric. The IP address information is advertised independently by using the Two new LSA types, The Type 9 Intra-Area Prefix LSA, and The Type 8 Link Local LSA. Below is a list of the LSA Types in OSPFv3. Note they are not Type 1 Type 2 any more, they are referred to as 0x2001, 0x2001 etc.
|0x2001||Router||Generated by every router to describe the state and cost of each interface in the area.|
|0x2002||Network||Generated by DR's, to advertise all of the routers attached to the link including itself.|
|0x2003||Interarea Prefix||ABR's generate these LSAs to describe routes to IPv6 prefixes in other areas.|
|0x2004||Interarea Router||ABR's generate these to announce the addresses of ASBR's in other areas.|
|ox2005||AS External||ASBR routers generate these to advertise default routes or routes learned through route redistribution.|
|0x2007||NSSA||ABR routers that are in a NSSA area advertise these LSAs for routes redistributed into the area.|
|0x2008||Link||This LSA is used to advertise All the Global unicast adress prefixes associated with an interface to the link local address and cannot be flooded beyond the local link.|
|0x2009||Intra-Area Prefix||These are used to advertise one or more IPv6 prefixes that are associated with a router, stub, or transit network segment.|
OSPFv3 uses IPv6 for it's transport still using protocol ID 89. With OSPFv2, the AllSPFRouters address is the IPv4 multicast address 188.8.131.52 and the AllDRouters address is 184.108.40.206. Because OSPFv3 runs on IPv6, these addresses have changed. The OSPFv3 AllSPFRouters address is the IPv6 multicast address FF02::5 and the AllDRouters address is FF02::6. Packets in OSPFv3, depending on the type of OSPF packet being set, are also sent and received, to the routers link local addresses. The blow table lists the packet types and the addressing used.
OSPFv3 supports the same network types as OSPFv2 including the DR requirements for Broadcast and NBMA networks. You can change the interface network type by using the interface configuration subcommand ospfv3 network <network-type>. This needs to be done on Loopback interfaces if you want them to not be advertised as host routes /32 or /128 for IPv6 which is the default behaviour.
Summarisation in OSPFv3 is just as important as with OSPFv2 if not more so given the number of possible prefixes in an IPv6 network. Summarisation works just the same in OSPFv3 as it does in OSPFv2 with it only being configured on an ABR. Summarising IPv6 addresses might seem a little daunting at first given they're in hex and are 128 bits long but once you get the hang of it, it will only take a few minutes to work out the hex values and math for it. For example, let's say we have 4 IPv6 prefixes
From the above, we can see that the 4th "Hextet" (There's no actual name for it like octet in IPv4), is the common hextet so let's break down the binary of that hextet only
The reason I have separated these into 4 binary bits for each hex value, is because there are 16 hex values, and in order to make 16 binary values, we need 4 bits. So let's assign the binary values to each of the above IPv6 addresses.
- 2001:0:0:1:: = 2001:0:0:0000.0000.0000.0001::
- 2001:0:0:2:: = 2001:0:0:0000.0000.0000.0010::
- 2001:0:0:3:: = 2001:0:0:0000.0000.0000.0011::
- 2001:0:0:a2:: = 2001:0:0:0000.0000.1010.0010::
Now remember that each value between the : in an IPv6 address is equal to 16 bits so we know that in the above, at least the first 3 hextets are the same so we know the first 48 bits are the same. Calculating the last hextet we can see the first 8 bits of the 4th hextet are the same so we can summarise with a mask of 48+8 = 56. The summary of these addresses becomes 2001::/56. this includes everything from 2001::/56 through to 2001:0:0:ff::/56. To summarise this in OSPFv3, use the ospfv3 router configuration address family subcommand area <id> range <prefix/length> where the Area ID is the area that the prefixes reside in. Let's take a look at the below topology and the route table of R4 prior to summarisation.
Now let's configure the summary command on the ABRs R2 and R3. I will only show the configuration on R2 here as it's exactly the same on R3.
And again, now let's take a look at the route table on R4.
OSPFv3 IPv4 Support
OSPFv3 now supports the advertisment of both IPv4 and IPv6 routes. When sending IPv4 route updates using OSPFv3, all packets are still sent using IPv6 as the transport to the IPv6 multicast address ff02::5 and ff02::6 for the OSPFv3 AllSPFRouters and AllDRouters or using the link local addresses on networks without a DR/BDR requirement. When you look at the OSPFv3 header information however, under the address prefix, you will see the IPv4 address, converted to hex. For example, our 10.1.123.0/24 subnet in IPv6 hex is a01:7b00::.
To configure OSPFv3 to advertise IPv4 address information as well as IPv6, use the interface configuration subcommand ospfv3 <process> ipv4 area <id>.
To verify that an interface is enabled for OSPFv3 IPv4, use the show command show ospfv3 interface brief. This will display both the IPv4 and IPv6 interfaces.
OSPFv3 doesn't actually include its own authentication mechanism like with OSPFv2 and its ability to use plain text or MD5 authentication. Instead, OSPFv3 relies on the built in authentication extension of the IPv6 packet itself and IPSec. Currently Cisco IOS does not support the configuration of IPSec payload encryption using ESP but this can be configured as null, instead IOS only supports the use of IPSec Authentication HEader (AH) protocol for OSPFv3 authentication to preserve packet integrity.
When configuring OSPFv3 IPSec AH authentication, you can either configure it on a per interface basis, or a per area basis. To configure Authentication on a per interface bases, use the interface configuration subcommand ospfv3 authentication ipsec spi <spi> [sha1|md5] <hex-password>. When configuring the authentication as SHA1, you must specify a 40 hex digit (160bit) password, and a 32 hex digit (128bit) password when using MD5. SPI stands for Security Policy Identifier, and is similar to a key number when using key chains for authentication. The number can be anything from 256 to 4294967295 but must match on all routers that are to be using authentication.
To configure OSPFv3 IPSec authentication for an entire Area, use the OSPFv3 router configuration subcommand area <id> authentication ipsec spi <spi> [sha1|md5] <hex-password>. This configures Authentication for all neighbours in the specified area.
For this example, I will configure authentication on R1, R2, and R3 for Area 10. On R1, I will use interface specific authentication, and on R2 and R3, I will use the global area authentication configuration.
And here is the configuration for the Area 10 on R2.
Notice that once I had configured authentication on R1, the neighbour relationship between R2 and R3 expired after the dead timer. As soon as I enabled Authentication on R2, the neighbour relationship came back up. To verify the OSPFv3 authentication, you can use the show command show ospfv3 interface <interface>.