Keywords: OSPF, OSPFv3, IPv4, IPv6
Abstract: OSPFv3 is a link-state routing protocol developed from OSPFv2 and used for IPv6 networks. This document describes the OSPFv3 implementation, differences between OSPFv3 and OSPFv2, and OSPFv3 configuration example.
Open Shortest Path First
Open Shortest Path First version 3
Interior Gateway Protocol
Area Border Router
Autonomous System Border Router
Link Statement Advertisement
Link State Data Base
Backup Designated Router
Link State Request
Link State Update
Link State Acknowledgment
Table of Contents
OSPFv2 is a link state Interior Gateway Protocol (IGP) developed by the IETF. Featuring a wide application scope, fast convergence, loop-free capability, and facilitating hierarchical network design, OSPFv2 is widely used in IPv4 networks.
OSPFv3 works basically the same way as OSPFv2 but has some differences from OSPFv2 to support IPv6 address format. This following describes OSPFv2 briefly before detailing how different OSPFv3 and OSPFv2 are.
1. DR and BDR
For broadcast and NBMA networks, DR and BDR are defined in OSPF. BDR is a backup DR.
A DR and BDR form an adjacency and exchange routing information with all the DROthers (routers other than DR or BDR) on the same network. DROthers do not form any adjacencies with each other. This reduces the number of adjacencies in broadcast and NBMA networks, thus reducing network traffic and saving bandwidth resources.
If a large number of routers in a network run OSPF, the following problems will arise:
l Large numbers of LSAs generated by the routers will occupy much storage space.
l The calculation of the shortest path tree will take much longer, causing high CPU utilization.
l Network topological changes will be more frequent, causing large numbers of OSPF packets to be transmitted in the network and wasting bandwidth resources. Each topology change makes all the routers perform a route recalculation.
To address these issues, OSPF divides an AS into multiple areas.
An area consists of a logical group of networks and routers and is assigned an area ID.
The following describes two specific types of areas:
(1) (Totally) Stub area
The ABR in a stub area does not inject Type-5 LSAs into the area. This reduces the link-state database size, and therefore the memory requirements for routers in the stub area .
To further reduce the routing table size in a stub area, a stub area can be configured as a totally stub area, which does not allow routes other than intra-area and the default route to be propagated within the area.
Stub area configuration is optional, and not every area is qualified to be a stub area. In general, a stub area resides on the border of the AS.
(2) NSSA area
A Not-So-Stubby Area (NSSA) retains the stub characteristics. Type-7 LSAs, rather than Type-5 LSAs, can be injected into an NSSA area. Type-7 LSAs are generated by an NSSA ASBR and propagated within the NSSA area. The NSSA ABR translates the Type-7 LSAs into Type-5 LSAs, which get propagated into the OSPF domain.
3. OSPF Network Types
OSPF networks fall into four types by link layer protocol:
l Broadcast: If Ethernet or FDDI is adopted, OSPF defaults the network type to broadcast. In such a network, OSPF packets are multicast (using the IP addresses 184.108.40.206 and 220.127.116.11) by default.
l Non-Broadcast Multi-access (NBMA): If Frame Relay, ATM, or X.25 is adopted, OSPF defaults the network type to NBMA. In an NBMA network, OSPF packets are unicast.
l Point-to-Multipoint (P2MP): OSPF does not default the network type for any link layer protocol to P2MP. P2MP is always a change from another network type. A common practice is to change an NBMA network into a P2MP network. In a P2P network, OSPF packets are multicast (using the IP address 18.104.22.168) by default. Unicasting OSPF packets can be configured when needed.
l Point-to-point (P2P): If PPP or HDLC is adopted, OSPF defaults the network type to P2P. In a P2P network, OSPF packets are multicast (by using the IP address 22.214.171.124).
4. OSPF packets
OSPF uses five types of protocol packets:
l Hello packets: Hello packets are periodically sent to establish and maintain neighbor relationships. The Hello packet contains timer values, the router's current choice for Designated Router (DR), Backup Designated Router (BDR), and the list of all routers on the network from which Hello packets have been seen recently.
l DD packet (Database Description Packet): DD packets are exchanged after an adjacency is initialized and describe the contents of the link-state database.
l LSR packet: After exchanging DD packets with a neighboring router, a router may find some LSAs are missing. To get these LSAs, it sends LSR packets that carry the digest of those LSAs to the neighbor. <
l LSU packet: Each Link State Update packet carries a collection of LSAs.
l LSAck packet: LSAck packets are sent to acknowledge the received LSAs. An LSAck contains the headers of the LSAs to be acknowledged (one LSAck packet can acknowledge multiple LSAs).
The route calculation process of the OSPF protocol is as follows:
l Based on the network topology around itself, each OSPF router generates LSAs and sends them to other routers in update packets.
l Each OSPF router collects LSAs from other routers to compose an LSDB (Link State Database). An LSA describes the network topology around a router, so the LSDB describes the entire network topology of the AS.
l Each router transforms the LSDB to a weighted directed graph, which actually reflects the topology architecture of the entire network.
OSPFv3 and OSPFv2 have the following common aspects:
l Packet types: Hello, DD, LSR, LSU, and LSAck
l Area partition
l LSA flooding and synchronization mechanisms: Reliable flooding and synchronization to ensure correct LSDB contents.
l Routing calculation method: SPF algorithm
l Network types: broadcast, NBMA, P2MP, and P2P.
l Neighbor discovery and adjacency establishment mechanisms: When a router starts, it sends a hello packet via an OSPF interface, and the peer that receives the hello packet checks parameters carried in the packet. If parameters of the two routers match, they become neighbors. Not every pair of neighboring routers become adjacent, which depends on network types. Only by synchronizing the LSDB via exchanging DD packets and LSAs can two routers become adjacent.
l DR election: It is required to elect the DR and BDR on NBMA and broadcast networks.
Some necessary modifications are made to OSPFv2 so that OSPFv3 can support IPv6. This allows OSPFv3 to run independent of network layer protocols and to adapt to different protocols.
Differences between OSPFv3 and OSPFv2 are as follows:
l Protocol running per-link, not per-subnet
l Use of link-local addresses
l Support for multiple instances per link
l Identifying neighbors by Router ID
l Authentication changes
l Stub area support
l OSPFv3 packet formats
l The Options field
OSPFv2 runs on a per-IP-subnet basis. With OSPFv2 enabled, two routers must be attached to the same subnet to establish a neighbor relationship.
OSPFv3 runs on a per-link basis. Multiple IPv6 subnets (IPv6 prefixes) can be assigned to a single link, and two nodes can talk directly over a single link, even if they do not share a common IPv6 prefix.
An OSPFv3 router sends packets using the interface's associated link-local unicast address as source. A router learns the link-local addresses of all other routers attached to its links, and uses these addresses as next hop information during packet forwarding. On virtual links, global scope or site-local IP addresses must be used as the source for OSPFv3 protocol packets.
Link-local addresses have only local significance and can be flooded on the local link only. Therefore, link-local addresses can appear in Link-LSAs only.
Multiple OSPFv3 instances can run on a single link, thus cutting costs, as shown in Figure 1 .
Connected to the same broadcast network, Router A, Router B, Router C, and Router D share the same link and can establish neighbor relationships with each other. After instance 1 is configured on Eth1/0 of Router A, Eth1/1 of Router B, and Eth1/3 of Router D and instance 2 on Eth1/0 of Router A, Eth1/1 of Router B, and Eth1/2 of Router C, neighbor relationships of instance 1 are established between A, Router B, and Router D, and neighbor relationships of instance 2 are established between A, Router B, and Router C.
Support for multiple instances on a link is accomplished through an instance ID contained in the OSPF packet header. If the instance ID configured on the interface and that of a received OSPF packets do not match, the interface discards the packet and no neighbor relationship can be established.
In OSPFv2, neighbors on broadcast or NBMA links are identified by their interfaces’ IPv4 addresses, and neighbors on point-to-point networks or connected through virtual links are identified by their Router IDs.
OSPFv3 supports the flooding of unknown LSAs. To prevent uncontrolled flooding of unknown LSAs within a Stub area, the following rule regarding stub areas has been established: an LSA whose LS type is unrecognized can be flooded throughout a stub area only if both a) the LSA has area or link-local flooding scope and b) the LSA has U-bit set to 0.
OSPFv3 packets are encapsulated in IPv6 headers. All OSPF packet types begin with a standard 16-byte header.
Like OSPFv2, OSPFv3 also has five types of packets: hello, DD, LSR, LSU, and LSAck, which share the same header format.
OSPFv3 has the same LSU and LSAck packet formats as OSPFv2 but different packet headers, Hello, DD, and LSR packet formats:
l Version: For OSPFv3, this field is 3.
l Packet header: An OSPFv3 packet header is only 16 bytes long, with no authentication field but an additional Instance ID field, which is used to support multiple instances on a link. The Instance ID has local link significance only. Received packets whose Instance ID is not equal to the receiving interface's Instance ID are discarded. In that case, no neighbor relationship can be established.
l Hello packet: Compared with the OSPFv2 hello packet, the OSPFv3 hello packet has no network mask field but has Interface ID field, which uniquely identifies this interface among the collection of this router's interfaces.
In OSPFv2, each Hello packet, DD packet, and LSA has the Options field.
In OSPFv3, the Options field is available in only Hello packets, DD packets, Router LSAs, Network LSAs, Inter-Area-Router LSAs, and Link LSAs.
The following figure shows the OSPFv2 Options field format:
Figure 2 OSPFv2 Options field format
The following figure shows the OSPFv3 Options field format:
Figure 3 OSPFv3 Options field format
Compared with OSPFv2, OSPFv3 has the additional R and V bits in the Options field:
l R bit: This bit indicates whether the originator is an active router. If the R bit is clear, routes which transit the advertising node cannot be computed. Clearing the R bit would be appropriate for a multi-homed host that wants to participate in routing, but does not want to forward non-locally addressed packets.
l V bit: If this bit is clear, the router/link should be excluded from IPv6 routing calculation.
1. OSPFv3 LSA Types
OSPFv3 uses seven types of LSAs. The following table compares OSPFv3 and OSPFv2 LSAs.
Table 1 Comparisons between OSPFv3 and OSPFv2 LSAs
OSPFv3 Router LSAs and Network LSAs are used to describe the routing domain topology, rather than address information.
Network Summary LSA
Inter Area Prefix LSA
They perform similar functions.
ASBR Summary LSA
Inter Area Router LSA
AS External LSA
AS External LSA
Exactly the same.
Available in OSPFv3 only
Intra Area Prefix LSA
Available in OSPFv3 only
2. Two New LSA Types
OSPFv3 has two new LSA types: Link LSA and Intra Area Prefix LSA
l In OSPFv3, Router LSAs contain no address information. An OSPFv3 router originates a separate Link-LSA for each link it is attached to. A Link-LSA provides the router's link-local address and other addresses on this link to all other routers attached to the link.
l Router-LSAs and Network-LSAs do not carry route information, which is carried by Intra-Area-Prefix-LSAs. An Intra-Area-Prefix-LSA can advertise one or more IPv6 address prefixes.
The flooding scope of an LSA is defined in its LS Type field. There are three flooding scopes:
l Link-local scope: The LSA is flooded only on the local link. It is used for new Link-LSAs.
l Area scope: The LSA is flooded throughout the single OSPF area only. It is used for Router-LSAs, Network-LSAs, Inter-Area-Prefix-LSAs, Inter-Area-Router-LSAs, and Intra-Area-Prefix-LSAs.
l AS scope. The LSA is flooded throughout the routing domain. It is used for AS-external-LSAs.
An OSPFv2 interface directly discards any unknown LSAs received.
OSPFv3 uses the U bit in the LS Type field of LSAs to indicate the mode of processing an unknown LSA:
l If the U bit is set to 1, the unknown LSA will be flooded within the range specified in its LS Type field.
l If the U bit is set to 0, the unknown LSA will be flooded on the link.
Each OSPFv3 LSA begins with an LSA header. The following discusses the LSA header and content differences between OSPFv3 and OSPFv2.
1. LSA headers
As shown in the figure above, the Options field available in OSPFv2 is removed from the OSPFv3 LSA header. In addition, the Link State ID field in OSPFv3 has a random value and identifies an LSA together with the Advertising Router and LS Sequence Number fields.
OSPFv2 has an 8-bit LS Type field, while OSPFv3 has a 16-bit LS Type field, as shown in the following figure.
l U bit: The U bit indicates how the LSA should be handled by a receiving router which does not recognize the LSA's function code. If the U-bit is set to 0, the LSA has link-local scope. If the U-bit is set to 1, the LSA has the flooding scope specified by the S2/S1 bits.
l S2/S1 bits: The S1 and S2 bits jointly indicate the flooding scope of the LSA. A value of 00 means the LSA will be flooded only on the local link. A value of 01 means the LSA will be flooded to all routers in the originating area. A value of 10 means the LSA will be flooded to all routers in the AS. A value of 11 is reserved.
l LSA Function Code: This field indicates the LS type. The following table lists the possible code values and the corresponding LS types:
Table 2 LSA function codes and LS types
LSA function code
Inter Area Prefix LSA
Inter Area Router LSA
AS External LSA
Group Membership LSA
Intra Area Prefix LSA
The following figure shows the OSPFv2 Router-LSA format:
Figure 6 OSPFv2 Router-LSA format
The following figure shows the OSPFv3 Router-LSA format:
See Figure 7 In the OSPFv3 Router LSA:
l An Options field is added.
l The #Links field, which indicates the number of connected routers, is no long available.
l Links are described in a way different from OSPFv2. The Interface ID, Neighbor Interface ID, and Neighbor Router ID fields jointly describe the link.
Different fields in OSPFv3 Router-LSA are described as follows:
l W: Wild card, used for MOSPF. Currently, this bit is not supported by H3C.
l Interface ID: Local interface ID assigned to the interface being described.
l Neighbor Interface ID: Interface ID of the neighbor router.
l Neighbor Router: Router ID of the neighbor router.
As shown in the figure above, the OSPFv3 Network-LSA has an additional Options field but without the Network Mask field.
A Network-LSA is originated for a broadcast or NBMA link by the link's Designated Router. The LSA describes all routers attached to the link, including the Designated Router itself. Without the Network Mask field, an OSPFv3 Network-LSA describes the topology, rather than routing information.
The LS type of Inter-Area-Prefix-LSAs is 3. They are the IPv6 equivalent of OSPFv2 summary-LSAs. Through PrefixLength, PrefixOption, and Address Prefix fields, Inter-Area-Prefix-LSAs describe IPv6 prefixes that belong to other areas. An Inter-Area-Prefix-LSA is originated for each IPv6 prefix.
For stub areas, Inter-Area-Prefix-LSAs can be used to describe a default route. When describing a default route, the Inter-Area-Prefix-LSA's PrefixLength is set to 0.
The following figure shows the OSPFv2 Network Summary LSA format:
The following figure shows the OSPFv3 Inter-Area-Prefix-LSA format:
Figure 10 OSPFv3 Inter-Area-Prefix-LSA format
Compared with OSPFv2 Network-Summary-LSA, OSPFv3 Inter-Area-Prefix-LSA has the following different fields:
l PrefixLength: IPv6 prefix length.
l PrefixOption: IPv6 prefix options, describing that, for example, the prefix should be ignored, or cannot be re-advertised.
l Address Prefix: IPv6 address prefix.
The PrefixOptions field is one byte long, as shown in the following figure.
l P: The "propagate" bit, which is set to 1 for an NSSA prefix, indicating that the prefix should be re-advertised at the NSSA area border.
l MC: The "multicast" capability bit. If set, the prefix should be included in IPv6 multicast routing calculation.
l LA: The "local address" capability bit. If set, the prefix is actually the egress interface’s IPv6 address of the advertising router.
l NU: The "no unicast" capability bit. If set, the prefix should be excluded from IPv6 unicast calculation.
The LS type of an Inter-Area-Router-LSA is set to 4. Inter-Area-Router-LSAs are similar to ASBR Summary-LSAs in OSPFv2, which have the same format as the OSPFv2 Network Summary LSA format, as shown in Figure 9 .
The following figure shows the OSPFv3 Inter-Area-Router-LSA format:
Significant fields are described as follows:
l Metric: The cost of using this router interface, for outbound traffic.
l Destination Router ID: Router ID of a destination router outside the area.
The LS type of an AS-external-LSA is set to 5. The purposes of AS-External-LSAs are the same as those of AS-External-LSAs in OSPFv2.
The following figure shows the OSPFv2 AS-External-LSA format:
Figure 13 OSPFv2 AS-External-LSA format
The following figure shows the OSPFv3 AS-External-LSA format:
Figure 14 OSPFv3 AS-External-LSA format
Compared with OSPFv2 AS-External-LSAs, OSPFv3 AS-External-LSAs have the following different fields:
l The Address Prefix, PrefixLength, and PrefixOptions fields jointly identify an IPv6 address prefix outside the AS.
l Referenced LS Type: If it set to a non-zero value, a referenced LSA with this LS type is associated with the LSA.
l Referenced Link State ID: Link state ID of the LSA referenced. Currently, H3C does not support this field.
The LS type of Link-LSAs is 8. A router originates a separate Link-LSA for each link it is attached to.
Link-LSAs have three purposes:
l They provide the router's link-local address to all other routers attached to the link.
l They inform other routers attached to the link of a list of IPv6 prefixes to associate with the link.
l They allow the router to assert a collection of Options bits to associate with the Network-LSA that will be originated for the link.
The following figure shows the Link-LSA format:
Significant fields are described as follows:
l Router Priority: Router Priority of the interface attached to the link.
l Options: Optional capabilities supported by the router; the set of Options bits that the router would like set in the Network-LSA that will be originated for the link.
l Link Local Interface Address: The originating router's link-local interface address on the link.
l # prefixes: Number of IPv6 address prefixes contained in the LSA.
The LS type of an Intra-Area-Prefix-LSA is 9. OSPFv3 is designed to separate topology information from routing information. In OSPFv3, all addressing information has been removed from router-LSAs and network-LSAs, and the Intra-Area-Prefix-LSA was introduced to carry such addressing information.
A router uses Intra-Area-Prefix-LSAs to advertise one or more IPv6 address prefixes that are associated with:
l The router itself
l An attached stub network segment
l An attached transit network segment.
The following figure shows the OSPFv3 Intra-Area-Prefix-LSA format:
Intra-Area-Prefix-LSAs describe the routing information carried by the Router-LSAs and Network-LSAs. Therefore, the Intra-Area-Prefix-LSA should indicate the referenced Router-LSA or Network-LSA, which is jointly identified by the Referenced LS Type, Referenced Link State ID, and Referenced Advertising Router fields.
The significant fields are described as follows:
l # Prefixes: Number of IPv6 address prefixes contained in the LSA.
l Referenced LS Type: If the Referenced LS type is 1, the prefixes are associated with a router-LSA. If Referenced LS type is 2, the prefixes are associated with a network-LSA.
l Referenced Link State ID: If the prefixes are associated with a router-LSA, the Referenced Link State ID should be 0. If the prefixes are associated with a network-LSA, the Referenced Link State ID should be the Interface ID of the link's Designated Router.
l Referenced Advertising Router: If the prefixes are associated with a router-LSA, the Referenced Advertising Router should be the originating router's Router ID. If the prefixes are associated with a network-LSA, Referenced Advertising Router should be the Designated Router's Router ID.
3 OSPFv3 Configuration Example
Figure 17 Network diagram for OSPFv3 configuration
l All the routers in the network run OSPFv3. The AS is divided into three areas. Router B works as the ABR between Area 0 and Area 1. Router C works as the ABR between Area 0 and Area 2.
l RFC2328: OSPF Version 2
l RFC2740: OSPF for IPv6
Copyright © 2008 Hangzhou H3C Technologies Co., Ltd. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of H3C Technologies Co., Ltd.
This document is subject to change without notice.