rfc-visual
GitHub

RFC 5340 · July 2008 · R. Coltun, D. Ferguson, J. Moy, A. Lindem

OSPF for IPv6

PROPOSED STANDARDIETF stream
5 verified errata2 held for document update

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

100%

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. 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.2 Hello 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. 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.2 Hello 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. 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.3 These 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. 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.3 These 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. 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.4 After 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. 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.5 Link 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. 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.6 Link 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

Text

Loading the RFC text…