RFC 5340 · July 2008 · R. Coltun, D. Ferguson, J. Moy, A. Lindem
OSPF for IPv6
Index fetched 2026-10-19 from rfc-editor.org
How it works
Machine-generated by minimax/minimax-m3.1-flash:free on 2026-10-19, not reviewed by anyone. Every arrow, step and field cites an RFC 5340 sentence that an automated check confirmed exists. Treat it as a draft. Help verify this visual
RFC 5340 §4 Initial synchronization is performed through the Database Exchange process, which includes the exchange of Database Description, Link State Request, and Link State Update packets. Thereafter, database synchronization is maintained via flooding, utilizing Link State Update and Link State Acknowledgment packets.
1. Router A → Router B: Hello packet
Router A sends a Hello on the link. The packet supports neighbor discovery and the maintenance of neighbor relationships.
RFC 5340 §A.3.2Hello packets are OSPF packet type 1. These packets are sent periodically on all interfaces (including virtual links) in order to establish and maintain neighbor relationships. In addition, Hello packets are multicast on those links having a multicast or broadcast capability, enabling dynamic discovery of neighboring routers.
2. Router B → Router A: Hello packet
Router B also sends periodic Hellos so that the routers can discover and maintain each other.
RFC 5340 §A.3.2Hello packets are OSPF packet type 1. These packets are sent periodically on all interfaces (including virtual links) in order to establish and maintain neighbor relationships. In addition, Hello packets are multicast on those links having a multicast or broadcast capability, enabling dynamic discovery of neighboring routers.
3. Router A → Router B: Database Description packet
In this example, Router A is the master and sends a Database Description poll while the adjacency is being initialized.
RFC 5340 §A.3.3These packets are exchanged when an adjacency is being initialized. They describe the contents of the link-state database. Multiple packets may be used to describe the database. For this purpose, a poll-response procedure is used. One of the routers is designated to be the master and the other is the slave. The master sends Database Description packets (polls) that are acknowledged by Database Description packets sent by the slave (responses). The responses are linked to the polls via the packets' DD sequence numbers.
4. Router B → Router A: Database Description packet
Router B acts as the slave and responds to the poll with its own Database Description packet.
RFC 5340 §A.3.3These packets are exchanged when an adjacency is being initialized. They describe the contents of the link-state database. Multiple packets may be used to describe the database. For this purpose, a poll-response procedure is used. One of the routers is designated to be the master and the other is the slave. The master sends Database Description packets (polls) that are acknowledged by Database Description packets sent by the slave (responses). The responses are linked to the polls via the packets' DD sequence numbers.
5. Router A → Router B: Link State Request packet
Router A requests newer pieces of Router B's link-state database after discovering that its own database is out of date.
RFC 5340 §A.3.4After exchanging Database Description packets with a neighboring router, a router may find that parts of its link-state database are out-of-date. The Link State Request packet is used to request the pieces of the neighbor's database that are more up-to-date. Multiple Link State Request packets may need to be used.
6. Router B → Router A: Link State Update packet
Router B sends an update containing the link-state information needed by Router A. A single update can carry several LSAs.
RFC 5340 §A.3.5Link State Update packets are OSPF packet type 4. These packets implement the flooding of LSAs. Each Link State Update packet carries a collection of LSAs one hop further from their origin. Several LSAs may be included in a single packet.
7. Router A → Router B: Link State Acknowledgment packet
Router A explicitly acknowledges the flooded LSA. Such acknowledgments make LSA flooding reliable.
RFC 5340 §A.3.6Link State Acknowledgment packets are OSPF packet type 5. To make the flooding of LSAs reliable, flooded LSAs are explicitly or implicitly acknowledged. Explicit acknowledgment is accomplished through the sending and receiving of Link State Acknowledgment packets.
Quoted text consists of unmodified excerpts from RFC 5340, published by the IETF (line breaks reflowed). Copyright in the RFC text belongs to the IETF Trust and the persons identified as the document authors, as stated in the RFC. The diagrams and plain-English explanations are rfc-visual's own and do not replace the RFC.
Not shown: The full OSPF interface and neighbor state machines inherited from RFC 2328, and the separate Standby interface-state addition specified in RFC 5340; Detailed layouts of Hello, Database Description, Link State Request, Link State Update, and Link State Acknowledgment packets beyond the common packet header; Detailed LSA bodies for the eight LSA types beyond the common LSA header and link-LSA behavior; SPF, next-hop, inter-area, AS-external, and NSSA route calculations; Virtual links, demand-circuit behavior, and configurable parameters.
Lineage
Updated by (5)
Obsoletes (1)
Text
Loading the RFC text…