RFC 1247 OSPF Version 2 July 1991
Security Considerations
All OSPF protocol exchanges are authenticated. This is accomplished through authentication fields contained in the
OSPF packet header. For more information, see Sections 8.1, 8.2, and Appendix E.
Author’s Address
John Moy
Proteon, Inc.
2 Technology Drive
Westborough, MA 01581
Phone: (508) 898-2800
EMail: jmoy@proteon.com
[J. Moy] [Page 124]
RFC 1247 OSPF Version 2 July 1991
F.3.2 Packet simplification
To simplify the format of Database Description packets and Link State Acknowledgment packets, their description of
link state advertisements has been modified. Each advertisement is now be described by its 20-byte link state header
(see Section A.4). This does not consume any additional space in the packets. The one additional piece of information
that will be present is the LS length. However, this field need not be used when processing the Database Description
and Link State Acknowledgment packets.
F.3.3 Adding forwarding addresses to AS external advertisements
As discussed in Section F.1.3, a forwarding address field has been added to the AS external advertisement.
F.3.4 Labelling of virtual links
Virtual links will be labelled as such in router links advertisements. This separates virtual links from unnumbered
point-to-point links, allowing all backbone routers to discover whether any virtual links are in use. See Section 12.4.1
for more details.
F.3.5 TOS costs ordered
When a link state advertisement specifies a separate cost depending on TOS, these costs must be ordered by increasing
TOS value. In other words, the cost for TOS 16 must always follow the cost for TOS 8.
F.3.6 OSPF’s TOS encoding redefined
The way that OSPF encodes TOS in its link state advertisements has been redefined in version 2. OSPF’s encoding of
the Delay (D), Throughput (T), and Reliability (R) TOS flags defined by [RFC 791] is described in Section 12.3.
F.4 Backward-compatibility provisions
Additional functionality will probably be added to OSPF in the future. One example of this is a multicast routing
capability, which is currently under development. In order to be able to add such features in a backward-compatible
manner, the following provisions have been made in the OSPF specification.
New capabilities will probably involve the introduction of new link state advertisements. If a router receives a link
state advertisement of unknown type during the flooding procedure, the advertisement is simply ignored (Section 13.
The router should not attempt to further flood the advertisement, nor acknowledge it. The advertisement should not
be installed into the link state database. If the router receives an advertisement of unknown type during the Database
Description process, this is an error (see Sections 10.6 and 10.3). The Database Description process is then restarted.
There is also an Options field in both the Hello packets, Database Description packets and the link state advertise-
ment headers. Unrecognized capabilities found in these places should be ignored, and should not affect the normal
processing of protocol packets/link state advertisements (see Sections 10.5 and 10.6). Routers will originate their
Hello packets, Database Description packets and link state advertisements with unrecognized capabilities set to 0 (see
Sections 9.5, 10.8 and 12.1.2).
[J. Moy] [Page 123]
RFC 1247 OSPF Version 2 July 1991
appears on any neighbor Link State Retransmission lists and b) none of the router’sneighbors are in states Exchange
or Loading. See Sections 13 (step 4c) and 14.1 for more details.
In addition, a new step has been added to the flooding procedure (Section 13) in order to make the Database Descrip-
tion process more robust. This step detects when a neighbor lists one instance of an advertisement in its Database
Description packets, but responds to Link State Request packets by sending another (earlier) instance. This behavior
now causes the event BadLSReq to be generated, which restarts the Database Description process with the neighbor.
In OSPF version 1, the neighbor event BadLSReq erroneously did not restart the Database Description process.
F.2.7 Receiving OSPF Hello packets
The section detailing the receive processing of OSPF Hello packets (Section 10.5) has been modified to include the
generation of the neighbor Backup Seen event. In addition, the section detailing the Designated Router election
algorithm (Section 9.4) has been modified to include the algorithm’s initial state.
F.2.8 Network mask defined for default route
The network mask for the default route, when it appears as the destination in either an AS external link advertisement
or in a summary link advertisement, has been set to 0.0.0.0. See Sections A.4.4 and A.4.5 for more details.
F.2.9 Rate limit imposed on flooding
When an advertisement is installed in the link state database, it is timestamped. The flooding procedure is then not
allowed to install a new instance of the advertisement until MinLSInterval seconds have elapsed. This enforces a rate
limit on the flooding procedure; a new instance can be flooded only once every MinLSInterval seconds. This guards
against routers that disregard the limit on self-originated advertisements (already present in OSPF version 1) of one
origination every MinLSInterval seconds. For more information, see Section 13.
F.3 Packet format changes
The following changes have been made to the format of OSPF packets and link state advertisements. Some of these
changes were required to support the added functionality listed above. Other changes were made to further simplify
the parsing of OSPF packets.
F.3.1 Adding a Capability bitfield
To support the new “stub area” and “optional TOS” features, a bitfield listing protocol capabilities has been added
to the Hello packet, Database Description packet and all link state advertisements. When used in Hello packets, this
allows a router to reject a neighbor because of a capability mismatch. Alternatively, when capabilities are exchanged in
Database Description packets a router can choose not to forward certain link state advertisements to a neighbor because
of its reduced functionality. Lastly, listing capabilities in link state advertisements allows routers to route traffic around
reduced functionality router, by excluding them from parts of the routing table calculation. See Section A.2 for more
details.
[J. Moy] [Page 122]
RFC 1247 OSPF Version 2 July 1991
of the advertisement must be originated (due either to topological change of the expiration of the LS refresh timer) the
current instance must first be “prematurely aged”.
There will be a new section discussing premature aging (Section 14.1). This is a method for flushing a link state
advertisement from the routing domain: the advertisement’s age is set to MaxAge and advertisement is reflooded just
as if it were a newly received advertisement. As soon as the new flooding is acknowledged by all of the router’s
adjacent neighbors, the advertisement is flushed from the database.
Premature aging can also be used when, for example, a previously advertised external route is no longer reachable. In
this circumstance, premature aging is preferable to the alternative, which is to originate a new advertisement for the
destination specifying a metric of LSInfinity.
A router may only prematurely age its own (self-originated) link state advertisements. These are the link state adver-
tisements having the router’s own OSPF router ID in the Advertising Router field.
F.2.2 Flooding of unexpected MaxAge advertisements
Version 1 of the OSPF omitted the handling of a special case in the flooding procedure: the reception of a MaxAge
advertisement that has no database instance. A paragraph has been added to Section 13 to deal with this occurrence.
Without this paragraph, retransmissions of MaxAge advertisements could possibly delay their being flushed from the
routing domain.
F.2.3 Virtual links and address ranges
When summarizing information into a virtual link’s transit area, version 2 of the OSPF specification prohibits the
collapsing of multiple backbone IP networks/subnets into a single summary link. This restriction has been added to
deal with certain anomalous OSPF area configurations. See Sections 15 and 12.4.3 for more information.
F.2.4 Routing table lookup explained
When forwarding an IP data packet, a router looks up the packet’s IP destination in the routing table. This determines
the packet’s next hop. A new section (Section 11.1) has been added describing the routing table lookup (instead of
just specifying a “best match”). This section clarifies OSPF’s four level routing hierarchy (i.e., intra-area, inter-area,
external type 1 and external type 2 routes). It also specifies the effect of TOS on routing.
F.2.5 Sending Link State Request packets
OSPF Version 2 eases the restrictions on the sending of Link State Request packets. Link State Request packets can
now be sent to a neighboring router before a complete set of Database Description packets have been exchanged. This
enables a more efficient use of a router’s memory resources; an OSPF version 2 implementation may limit the size of
the neighbor Link state request lists. See Sections 10.9, 10.7 and 10.3 for more details.
F.2.6 Changes to the Database description process
The specification has been modified to ensure that, when two routers are synchronizing their databases during the
Database Description process, none of the component link state advertisements can have their sequence numbers
decrease. A link state advertisement’s sequence number decreases when it is flushed from the routing domain via
premature-aging, and then reoriginated with the smallest sequence number 0x80000001 (see Section 14.1). So the
specification now dictates that an advertisement cannot be flushed from a router’s database until both a) it no longer
[J. Moy] [Page 121]
RFC 1247 OSPF Version 2 July 1991
X from the calculation. In effect, an attempt will be made to bypass router X when forwarding non-zero TOS traffic.
Summary link and AS external link advertisements can also indicate their non-availability for non-zero TOS traffic
(Sections 12.4.3 and 12.4.4).
The result may be that no route can be found for some non-zero value of TOS. When this happens, the packet is routed
along the TOS 0 route instead (Section 11.1).
It is still mandatory for all OSPF implementations to be able to construct separate routing tables for each TOS value,
if desired by the system administrator.
F.1.3 Preventing external extra-hops
In some cases, version 1 of the OSPF specification will introduce extra-hops when calculating routes to external
destinations. This is because it is implicit in the format of AS external advertisements that packets should be forwarded
through the advertising router. However, consider the situation where multiple OSPF routers share a LAN with an
external router (call it router Y) , and only one OSPF router (call it router X) exchanges routing information with Y.
The OSPF routers on the LAN other than X will forward packets destined for Y and beyond through X, generating an
extra hop (see Section 2.2).
To fix this, a new field has been added to AS external advertisements. This field (called the forwarding address)
will indicate the router address to which packets should be forwarded (Section 12.4.4). In the above example, router
X will put Y’s IP address into this field. If the field is 0, packets are (as before) forwarded to the originator of the
advertisement. A different forwarding address can be specified for each TOS value.
Whenever possible, this new field should be set to 0. This is because setting it to an actual router address incurs
additional cost during the routing table build process (Section 16.4).
Besides preventing extra-hops, there are two other applications for this field. The first is for use by “route servers”.
Using the forwarding address, a router in the middle of the Autonomous System can gather external routing infor-
mation and originate AS external advertisements that specify the correct exit route to use for each external destination
(Section 2.2).
The other application possibly enables the reduction of the number of AS external advertisements that need be im-
ported. Suppose in the example at the beginning of this section that there are two routers (X and Z) exchanging EGP
information with the non-OSPF router Y. It is then likely that both X and Z will originate the same set of external
routes. Two AS external advertisements that specify the same (non-zero) forwarding address, destination and cost
are obviously functionally equivalent, regardless of their originators (advertising routers). The OSPF specification
dictates that the advertisement originated by the router with the largest Router ID will always be used. This allows the
other router to flush its equivalent advertisement (Section 12.4.4).
F.2 Corrected problems
The following problems in OSPF version 1 have been corrected in version 2.
F.2.1 LS sequence number space changes
The LS sequence number space has been changed from version 1’s lollipop shape to a linear sequence space (Sec-
tion 12.1.6). Sequence numbers will now be compared as signed 32-bit integers. Link state advertisements having
larger sequence numbers will be considered more recent. The sequence number space will still begin at (-N+1) (where
N = 2**31). The value of -N remains reserved. The LS sequence number of successive instances of an advertisement
will continue to be incremented until it reaches the maximum possible value: N-1. At this point, when a new instance
[J. Moy] [Page 120]
