ietf-corpus

rfc-1247

OSPF Version 2

J. Moy
date1991-07 streamIETF areartg wgospf statusDRAFT STANDARD pages189 canonicalhttps://www.rfc-editor.org/rfc/rfc1247 doi10.17487/RFC1247
This memo documents version 2 of the OSPF protocol. OSPF is a link- state based routing protocol. [STANDARDS-TRACK]

obsoleted by

obsoletes

updated by

Extracted elements (29)

design-rationale §4.4

Interval timers must be implemented to avoid drift. When multiple routers on the same network synchronize their Hello transmissions, routing packet collisions result. Where drift-free timers are not feasible, small random jitter should be added at each timer firing.

routing

design-rationale §3

OSPF areas hide topology to reduce routing traffic and protect intra-area routing from bad external data. Intra-area routing uses only the area's own topology; inter-area routing forces a star (hub-and-spoke) topology through the backbone.

routing

design-rationale §3.7

OSPF does not actively repair area partitions. When an area partitions, each component becomes a separate area and the backbone performs inter-area routing between them. This simplifies the protocol at the cost of some paths becoming inter-area instead of intra-area.

routing

design-rationale §7.4

The BDR does not generate a network links advertisement even though it could speed failover. This is an explicit tradeoff: omitting the pre-generated advertisement keeps database size smaller at the cost of slightly slower convergence when the DR fails.

routing

design-rationale §1.2

The Designated Router concept reduces the number of adjacencies on a multi-access network from O(n²) to O(n) by requiring only the DR (and BDR) to be adjacent to all other routers. This reduces routing protocol traffic and topological database size.

routing

interoperability-note §4.5

Optional OSPF capabilities are advertised in Hello packets, Database Description packets, and LSAs. Mismatch in area-wide capabilities (e.g., E-bit for external routing in stub areas) prevents neighbor relationships from forming; mismatch in negotiable capabilities reduces the set of LSAs exchanged.

routing

interoperability-note §4.5

TOS-capable and TOS-0-only routers can coexist in the same AS. TOS-capable routers will attempt to avoid TOS-0-only routers when computing non-zero TOS paths. The T-bit in the OSPF options field advertises TOS capability.

routing

normative-requirement §3.5 MUST

A packet is always forwarded to the network that is the best (longest or most specific) match for the packet's destination IP address. Subnet masks must be assigned so that the best match for any IP destination is unambiguous.

routing, ip

normative-requirement §2.4 MUST

All OSPF implementations must be capable of calculating separate routes based on IP Type of Service. Routers can optionally be configured to route all packets on the TOS 0 path only, eliminating non-zero TOS path calculations to conserve resources.

routing

normative-requirement §1.1 MUST

All OSPF protocol exchanges are authenticated. A single authentication scheme is configured per area, enabling different areas to use different authentication strictness. Only trusted routers can participate in the AS's routing.

routing, security

normative-requirement §3.6 MUST

All routers belonging to an area must agree on whether the area is configured as a stub. Virtual links cannot be configured through stub areas, and AS boundary routers cannot be placed internal to stub areas. The backbone cannot be a stub area.

routing

normative-requirement §4.3 SHOULD

OSPF large protocol packets should generally be split into several smaller protocol packets rather than relying on IP fragmentation. IP fragmentation should be avoided whenever possible.

routing, ip

normative-requirement §4.3 MUST

OSPF runs directly over IP using IP protocol number 89. OSPF does not provide explicit fragmentation/reassembly support; when fragmentation is necessary, IP fragmentation/reassembly is used, though it should be avoided whenever possible.

routing, ip

normative-requirement §4.3 SHOULD

Routing protocol packets should always be sent with the IP TOS field set to 0 and their IP precedence field set to Internetwork Control (per RFC 791). Routing packets should receive preferential treatment over data packets when being sent and received.

routing, ip

normative-requirement §3.1 MUST

The OSPF backbone must be contiguous. If backbone connectivity is broken by area configuration, the system administrator must restore it by configuring virtual links between backbone routers that share a common non-backbone area.

routing

protocol-element §6

An OSPF area is a collection of contiguous networks defined by a list of [address, mask] address ranges. Each area runs an independent SPF algorithm with its own topological database. Area ID 0 is reserved for the backbone.

routing

protocol-element §2.2

AS external link advertisements may specify a forwarding address field. When set, packets for the external destination are routed directly to that address rather than to the advertising AS boundary router, enabling AS boundary routers to function as route servers.

routing

protocol-element §4.3

OSPF defines five LSA types: Router links advertisements (type 1, area-scoped, all routers), Network links advertisements (type 2, area-scoped, originated by DR), Summary links for networks (type 3) and AS boundary routers (type 4) originated by ABRs, and AS external link advertisements (type 5, AS-wide scope, originated by ASBRs).

routing

protocol-element §4.3

OSPF defines five packet types: Hello (type 1) for neighbor discovery and maintenance, Database Description (type 2) for database summarization, Link State Request (type 3) for database download, Link State Update (type 4) for database updates, and Link State Acknowledgment (type 5) for flooding acknowledgment.

routing

protocol-element §3.3

OSPF routers are classified into four overlapping categories: internal routers (all interfaces in one area), area border routers (ABRs, interfaces in multiple areas), backbone routers (interface to backbone), and AS boundary routers (ASBRs, exchange routing info with other ASes).

routing

protocol-element §2.2

OSPF supports two types of external metrics. Type 1 external metrics are comparable to internal link state metrics (total cost = internal + external). Type 2 external metrics are always greater than any internal path cost. When both types are present, Type 1 always takes precedence.

routing

protocol-element §3.6

Stub areas exclude AS external link advertisements from flooding, reducing database size and memory requirements for internal routers. Routing to AS external destinations within stub areas is based on a default summary route advertised by area border routers.

routing

protocol-element §7.4

The Backup Designated Router (BDR) is also elected by Hello Protocol and remains adjacent to all routers on a multi-access network. When the DR fails, the BDR immediately assumes DR responsibilities without needing to form new adjacencies, reducing traffic disruption.

routing

protocol-element §7.3

The Designated Router (DR) is elected per multi-access network by the Hello Protocol using configurable per-interface Router Priority. The DR originates a network links advertisement and becomes adjacent to all other attached routers, centralizing database synchronization.

routing

protocol-element §3.1

Virtual links are configured between two backbone routers sharing a common non-backbone transit area. They behave as unnumbered point-to-point backbone links; their costs equal the intra-area distance between endpoints and use intra-area routing of the transit area to forward packets.

routing

security-consideration §6

All OSPF routing protocol exchanges are authenticated, ensuring only trusted routers participate in AS routing. Authentication type is configured per area (schemes defined in Appendix E), allowing stricter authentication in some areas than others. The 64-bit authentication field is excluded from the packet checksum.

routing, security

state-machine §7.2

Adjacency formation uses the Database Exchange Process: two routers establish a master/slave relationship and exchange Database Description packets (each with sequence number and M-bit); master retransmits at RxmtInterval. Followed by Link State Request/Update exchanges; full adjacency declared when all requests are satisfied.

routing

wire-format §8.1

All OSPF packets share a common header containing: Version # (set to 2), Packet type (1 octet), Packet length (total bytes including header), Router ID (32-bit), Area ID (32-bit), Checksum (16-bit one's complement of entire packet excluding 64-bit authentication field), Autype, and Authentication data.

routing

wire-format §5

The Router ID is a 32-bit number that uniquely identifies each OSPF router within the AS. Network mask is a 32-bit number displayed in hexadecimal (e.g., 0xffffff00 for class C). Host routes use a mask of 0xffffffff.

routing