RFC 5340
OSPF for IPv6
Pages: 94
Proposed Standard
→ Errata
Obsoletes: 2740
Updated by: 6845 6860 7503 8362 9454
Proposed Standard
→ Errata
Obsoletes: 2740
Updated by: 6845 6860 7503 8362 9454
Part 3 of 4 – Pages 40 to 68
4.5. Flooding
Most of the flooding algorithm remains unchanged from the IPv4 flooding mechanisms described in Section 13 of [OSPFV2]. In particular, the protocol processes for determining which LSA instance is newer (Section 13.1 of [OSPFV2]), responding to updates of self- originated LSAs (Section 13.4 of [OSPFV2]), sending Link State Acknowledgment packets (Section 13.5 of [OSPFV2]), retransmitting LSAs (Section 13.6 of [OSPFV2]), and receiving Link State Acknowledgment packets (Section 13.7 of [OSPFV2]), are exactly the same for IPv6 and IPv4. However, the addition of flooding scope and unknown LSA type handling (see Appendix A.4.2.1) has caused some changes in the OSPF flooding algorithm: the reception of Link State Updates (Section 13 in [OSPFV2]) and the sending of Link State Updates (Section 13.3 of [OSPFV2]) must take into account the LSA's scope and U-bit setting. Also, installation of LSAs into the OSPF database (Section 13.2 of [OSPFV2]) causes different events in IPv6, due to the reorganization of LSA types and the IPv6 LSA contents. These changes are described in detail below.4.5.1. Receiving Link State Update Packets
The encoding of flooding scope in the LS type and the need to process unknown LS types cause modifications to the processing of received Link State Update packets. As in IPv4, each LSA in a received Link
State Update packet is examined. In IPv4, eight steps are executed for each LSA, as described in Section 13 of [OSPFV2]. For IPv6, all the steps are the same, except that Steps 2 and 3 are modified as follows: (2) Examine the LSA's LS type. Discard the LSA and get the next one from the Link State Update packet if the interface area has been configured as a stub or NSSA area and the LS type indicates "AS flooding scope". This generalizes the IPv4 behavior where AS-external-LSAs and AS-scoped opaque LSAs [OPAQUE] are not flooded throughout stub or NSSA areas. (3) Else if the flooding scope in the LSA's LS type is set to "reserved", discard the LSA and get the next one from the Link State Update packet. Steps 5b (sending Link State Update packets) and 5d (installing LSAs in the link-state database) in Section 13 of [OSPFV2] are also somewhat different for IPv6, as described in Sections 4.5.2 and 4.5.3 below.4.5.2. Sending Link State Update Packets
The sending of Link State Update packets is described in Section 13.3 of [OSPFV2]. For IPv4 and IPv6, the steps for sending a Link State Update packet are the same (steps 1 through 5 of Section 13.3 in [OSPFV2]). However, the list of eligible interfaces on which to flood the LSA is different. For IPv6, the eligible interfaces are selected based on the following factors: o The LSA's flooding scope. o For LSAs with area or link-local flooding scope, the particular area or interface with which the LSA is associated. o Whether the LSA has a recognized LS type. o The setting of the U-bit in the LS type. If the U-bit is set to 0, unrecognized LS types are treated as having link-local scope. If set to 1, unrecognized LS types are stored and flooded as if they were recognized.
Choosing the set of eligible interfaces then breaks into the
following cases:
Case 1
The LSA's LS type is recognized. In this case, the set of
eligible interfaces is set depending on the flooding scope encoded
in the LS type. If the flooding scope is "AS flooding scope", the
eligible interfaces are all router interfaces excepting virtual
links. In addition, AS-external-LSAs are not flooded on
interfaces connecting to stub or NSSA areas. If the flooding
scope is "area flooding scope", the eligible interfaces are those
interfaces connecting to the LSA's associated area. If the
flooding scope is "link-local flooding scope", then there is a
single eligible interface, the one connecting to the LSA's
associated link (which is also the interface on which the LSA was
received in a Link State Update packet).
Case 2
The LS type is unrecognized and the U-bit in the LS type is set to
0 (treat the LSA as if it had link-local flooding scope). In this
case, there is a single eligible interface, namely, the interface
on which the LSA was received.
Case 3
The LS type is unrecognized, and the U-bit in the LS type is set
to 1 (store and flood the LSA as if the type is understood). In
this case, select the eligible interfaces based on the encoded
flooding scope the same as in Case 1 above.
A further decision must sometimes be made before adding an LSA to a
given neighbor's link-state retransmission list (Step 1d in Section
13.3 of [OSPFV2]). If the LS type is recognized by the router but
not by the neighbor (as can be determined by examining the Options
field that the neighbor advertised in its Database Description
packet) and the LSA's U-bit is set to 0, then the LSA should be added
to the neighbor's link-state retransmission list if and only if that
neighbor is the Designated Router or Backup Designated Router for the
attached link. The LS types described in detail by this document,
namely, router-LSAs (LS type 0x2001), network-LSAs (0x2002), inter-
area-prefix-LSAs (0x2003), inter-area-router-LSAs (0x2004), NSSA-LSAs
(0x2007), AS-external-LSAs (0x4005), link-LSAs (0x0008), and Intra-
Area-Prefix-LSAs (0x2009), are assumed to be understood by all
routers. However, all LS types MAY not be understood by all routers.
For example, a new LSA type with its U-bit set to 0 MAY only be
understood by a subset of routers. This new LS type should only be
flooded to an OSPF neighbor that understands the LS type or when the
neighbor is the Designated Router or Backup Designated Router for the
attached link.
The previous paragraph solves a problem for IPv4 OSPF extensions, which require that the Designated Router support the extension in order to have the new LSA types flooded across broadcast and NBMA networks.4.5.3. Installing LSAs in the Database
There are three separate places to store LSAs, depending on their flooding scope. LSAs with AS flooding scope are stored in the global OSPF data structure (see Section 4.1) as long as their LS type is known or their U-bit is 1. LSAs with area flooding scope are stored in the appropriate area data structure (see Section 4.1.1) as long as their LS type is known or their U-bit is 1. LSAs with link-local flooding scope, and those LSAs with unknown LS type and U-bit set to 0 (treat the LSA as if it had link-local flooding scope), are stored in the appropriate interface data structure. When storing the LSA into the link-state database, a check must be made to see whether the LSA's contents have changed. Changes in contents are indicated exactly as in Section 13.2 of [OSPFV2]. When an LSA's contents have been changed, the following parts of the routing table must be recalculated, based on the LSA's LS type: Router-LSAs, Network-LSAs, Intra-Area-Prefix-LSAs, and Link-LSAs The entire routing table is recalculated, starting with the shortest-path calculation for each area (see Section 4.8). Inter-Area-Prefix-LSAs and Inter-Area-Router-LSAs The best route to the destination described by the LSA must be recalculated (see Section 16.5 in [OSPFV2]). If this destination is an AS boundary router, it may also be necessary to re-examine all the AS-external-LSAs. AS-external-LSAs and NSSA-LSAs The best route to the destination described by the AS-external-LSA or NSSA-LSA must be recalculated (see Section 16.6 in [OSPFV2] and Section 2.0 in [NSSA]). As in IPv4, any old instance of the LSA must be removed from the database when the new LSA is installed. This old instance must also be removed from all neighbors' link-state retransmission lists.4.6. Definition of Self-Originated LSAs
In IPv6, the definition of a self-originated LSA has been simplified from the IPv4 definition appearing in Sections 13.4 and 14.1 of [OSPFV2]. For IPv6, self-originated LSAs are those LSAs whose Advertising Router is equal to the router's own Router ID.
4.7. Virtual Links
OSPF virtual links for IPv4 are described in Section 15 of [OSPFV2]. Virtual links are the same in IPv6, with the following exceptions: o LSAs having AS flooding scope are never flooded over virtual adjacencies, nor are LSAs with AS flooding scope summarized over virtual adjacencies during the database exchange process. This is a generalization of the IPv4 treatment of AS-external-LSAs. o The IPv6 interface address of a virtual link MUST be an IPv6 address having global scope, instead of the link-local addresses used by other interface types. This address is used as the IPv6 source for OSPF protocol packets sent over the virtual link. Hence, a link-LSA SHOULD NOT be originated for a virtual link since the virtual link has no link-local address or associated prefixes. o Likewise, the virtual neighbor's IPv6 address is an IPv6 address with global scope. To enable the discovery of a virtual neighbor's IPv6 address during the routing calculation, the neighbor advertises its virtual link's IPv6 interface address in an intra-area-prefix-LSA originated for the virtual link's transit area (see Section 4.4.3.9 and Section 4.8.1). o Like all other IPv6 OSPF interfaces, virtual links are assigned unique (within the router) Interface IDs. These are advertised in Hellos sent over the virtual link and in the router's router-LSAs.4.8. Routing Table Calculation
The IPv6 OSPF routing calculation proceeds along the same lines as the IPv4 OSPF routing calculation, following the five steps specified by Section 16 of [OSPFV2]. High-level differences between the IPv6 and IPv4 calculations include: o Prefix information has been removed from router-LSAs and network- LSAs and is now advertised in intra-area-prefix-LSAs. Whenever [OSPFV2] specifies that stub networks within router-LSAs be examined, IPv6 will instead examine prefixes within intra-area- prefix-LSAs. o Type 3 and 4 summary-LSAs have been renamed inter-area-prefix-LSAs and inter-area-router-LSAs respectively.
o Addressing information is no longer encoded in Link State IDs and
is now only found within the body of LSAs.
o In IPv6, a router can originate multiple router-LSAs,
distinguished by Link State ID, within a single area. These
router-LSAs MUST be treated as a single aggregate by the area's
shortest-path calculation (see Section 4.8.1).
For each area, the shortest-path tree calculation creates routing
table entries for the area's routers and transit links (see
Section 4.8.1). These entries are then used when processing intra-
area-prefix-LSAs, inter-area-prefix-LSAs, and inter-area-router-LSAs,
as described in Section 4.8.3.
Events generated as a result of routing table changes (Section 16.7
of [OSPFV2]) and the equal-cost multipath logic (Section 16.8 of
[OSPFV2]) are identical for both IPv4 and IPv6.
4.8.1. Calculating the Shortest-Path Tree for an Area
The IPv4 shortest-path calculation is contained in Section 16.1 of
[OSPFV2]. The graph used by the shortest-path tree calculation is
identical for both IPv4 and IPv6. The graph's vertices are routers
and transit links, represented by router-LSAs and network-LSAs
respectively. A router is identified by its OSPF Router ID, while a
transit link is identified by its Designated Router's Interface ID
and OSPF Router ID. Both routers and transit links have associated
routing table entries within the area (see Section 4.3).
Section 16.1 of [OSPFV2] splits up the shortest-path calculations
into two stages. First, the Dijkstra calculation is performed, and
then the stub links are added onto the tree as leaves. The IPv6
calculation maintains this split.
The Dijkstra calculation for IPv6 is identical to that specified for
IPv4, with the following exceptions (referencing the steps from the
Dijkstra calculation as described in Section 16.1 of [OSPFV2]):
o The Vertex ID for a router is the OSPF Router ID. The Vertex ID
for a transit network is a combination of the Interface ID and
OSPF Router ID of the network's Designated Router.
o In Step 2, when a router Vertex V has just been added to the
shortest-path tree, there may be multiple LSAs associated with the
router. All router-LSAs with the Advertising Router set to V's
OSPF Router ID MUST be processed as an aggregate, treating them as
fragments of a single large router-LSA. The Options field and the
router type bits (bits Nt, V, E, and B) should always be taken
from the router-LSA with the smallest Link State ID.
o Step 2a is not needed in IPv6, as there are no longer stub network
links in router-LSAs.
o In Step 2b, if W is a router and the router-LSA V6-bit or R-bit is
not set in the LSA options, the transit link W is ignored and V's
next link is examined.
o In Step 2b, if W is a router, there may again be multiple LSAs
associated with the router. All router-LSAs with the Advertising
Router set to W's OSPF Router ID MUST be processed as an
aggregate, treating them as fragments of a single large router-
LSA.
o In Step 4, there are now per-area routing table entries for each
of an area's routers rather than just the area border routers.
These entries subsume all the functionality of IPv4's area border
router routing table entries, including the maintenance of virtual
links. When the router added to the area routing table in this
step is the other end of a virtual link, the virtual neighbor's IP
address is set as follows: The collection of intra-area-prefix-
LSAs originated by the virtual neighbor is examined, with the
virtual neighbor's IP address being set to the first prefix
encountered with the LA-bit set.
o Routing table entries for transit networks, which are no longer
associated with IP networks, are also calculated in Step 4 and
added to the per-area routing table.
The next stage of the shortest-path calculation proceeds similarly to
the two steps of the second stage of Section 16.1 in [OSPFV2].
However, instead of examining the stub links within router-LSAs, the
list of the area's intra-area-prefix-LSAs is examined. A prefix
advertisement whose NU-bit is set SHOULD NOT be included in the
routing calculation. The cost of any advertised prefix is the sum of
the prefix's advertised metric plus the cost to the transit vertex
(either router or transit network) identified by intra-area-prefix-
LSA's Referenced LS Type, Referenced Link State ID, and Referenced
Advertising Router fields. This latter cost is stored in the transit
vertex's routing table entry for the area.
This specification does not require that the above algorithm be used
to calculate the intra-area shortest-path tree. However, if another
algorithm or optimization is used, an identical shortest-path tree
must be produced. It is also important that any alternate algorithm
or optimization maintain the requirement that transit vertices must
be bidirectional for inclusion in the tree. Alternate algorithms and optimizations are beyond the scope of this specification.4.8.2. The Next-Hop Calculation
In IPv6, the calculation of the next-hop's IPv6 address (which will be a link-local address) proceeds along the same lines as the IPv4 next-hop calculation (see Section 16.1.1 of [OSPFV2]). However, there are some differences. When calculating the next-hop IPv6 address for a router (call it Router X) that shares a link with the calculating router, the calculating router assigns the next-hop IPv6 address to be the link-local interface address contained in Router X's link-LSA (see Appendix A.4.9) for the link. This procedure is necessary for some link types, for example NBMA, where the two routers need not be neighbors and might not be exchanging OSPF Hello packets. For other link types, the next-hop address may be determined via the IPv6 source address in the neighbor's Hello packet. Additionally, when calculating routes for the area's intra-area- prefix-LSAs, the parent vertex can be either a router-LSA or network- LSA. This is in contrast to the second stage of the OSPFv2 intra- area SPF (Section 16.1 in [OSPFV2]) where the parent vertex is always a router-LSA. In the case where the intra-area-prefix-LSA's referenced LSA is a directly connected network-LSA, the prefixes are also considered to be directly connected. In this case, the next hop is solely the outgoing link and no IPv6 next-hop address is selected.4.8.3. Calculating the Inter-Area Routes
Calculation of inter-area routes for IPv6 proceeds along the same lines as the IPv4 calculation in Section 16.2 of [OSPFV2], with the following modifications: o The names of the Type 3 summary-LSAs and Type 4 summary-LSAs have been changed to inter-area-prefix-LSAs and inter-area-router-LSAs respectively. o The Link State ID of the above LSA types no longer encodes the network or router described by the LSA. Instead, an address prefix is contained in the body of an inter-area-prefix-LSA and an advertised AS boundary router's OSPF Router ID is carried in the body of an inter-area-router-LSA. o Prefixes having the NU-bit set in their PrefixOptions field should be ignored by the inter-area route calculation.
When a single inter-area-prefix-LSA or inter-area-router-LSA has changed, the incremental calculations outlined in Section 16.5 of [OSPFV2] can be performed instead of recalculating the entire routing table.4.8.4. Examining Transit Areas' Summary-LSAs
Examination of transit areas' summary-LSAs in IPv6 proceeds along the same lines as the IPv4 calculation in Section 16.3 of [OSPFV2], modified in the same way as the IPv6 inter-area route calculation in Section 4.8.3.4.8.5. Calculating AS External and NSSA Routes
The IPv6 AS external route calculation proceeds along the same lines as the IPv4 calculation in Section 16.4 of [OSPFV2] and Section 2.5 of [NSSA], with the following exceptions: o The Link State ID of the AS-external-LSA and NSSA-LSA types no longer encodes the network described by the LSA. Instead, an address prefix is contained in the body of the LSA. o The default route in AS-external-LSAs or NSSA-LSAs is advertised by a zero-length prefix. o Instead of comparing the AS-external-LSA's or NSSA-LSA's Forwarding Address field to 0.0.0.0 to see whether a forwarding address has been used, the bit F in the respective LSA is examined. A forwarding address is in use if and only if bit F is set. o Prefixes having the NU-bit set in their PrefixOptions field should be ignored by the inter-area route calculation. o AS Boundary Router (ASBR) and forwarding address selection will proceed the same as if RFC1583Compatibility is disabled. Furthermore, RFC1583Compatibility is not an OSPF for IPv6 configuration parameter. Refer to Appendix C.1. When a single AS-external-LSA or NSSA-LSA has changed, the incremental calculations outlined in Section 16.6 of [OSPFV2] can be performed instead of recalculating the entire routing table.4.9. Multiple Interfaces to a Single Link
In OSPF for IPv6, a router may have multiple interfaces to a single link associated with the same OSPF instance and area. All interfaces
will be used for the reception and transmission of data traffic while
only a single interface sends and receives OSPF control traffic. In
more detail:
o Each of the multiple interfaces is assigned a different Interface
ID. A router will automatically detect that multiple interfaces
are attached to the same link when a Hello packet is received with
one of the router's link-local addresses as the source address and
an Interface ID other than the Interface ID of the receiving
interface.
o Each of the multiple interfaces MUST be configured with the same
Interface Instance ID to be considered on the same link. If an
interface has multiple Instance IDs, it will be grouped with other
interfaces based on matching Instance IDs. Each Instance ID will
be treated uniquely with respect to groupings of multiple
interfaces on the same link. For example, if interface A is
configured with Instance IDs 1 and 35, and interface B is
configured with Instance ID 35, interface B may be the Active
Interface for Instance ID 35 but interface A will be active for
Instance ID 1.
o The router will ignore OSPF packets other than Hello packets on
all but one of the interfaces attached to the link. It will only
send its OSPF control packets (including Hello packets) on a
single interface. This interface is designated the Active
Interface and other interfaces attached to the same link will be
designated Standby Interfaces. The choice of the Active Interface
is implementation dependent. For example, the interface with the
highest Interface ID could be chosen. If the router is elected
Designated Router, it will be the Active Interface's Interface ID
that will be used as the network-LSA's Link State ID.
o All of the interfaces to the link (Active and Standby) will appear
in the router-LSA. In addition, a link-LSA will be generated for
each of the interfaces. In this way, all interfaces will be
included in OSPF's routing calculations.
o Any link-local scope LSAs that are originated for a Standby
Interface will be flooded over the Active Interface.
If a Standby Interface goes down, then the link-local scope LSAs
originated for the Standby Interfaces MUST be flushed on the
Active Interface.
o Prefixes on Standby Interfaces will be processed the same way as
prefixes on the Active Interface. For example, if the router is
the DR for the link, the Active Interface's prefixes are included
in an intra-area-prefix-LSA which is associated with the Active
Interface's network-LSA; prefixes from Standby Interfaces on the
link will also be included in that intra-area-prefix LSA.
Similarly, if the link is a stub link, then the prefixes for the
Active and Standby Interfaces will all be included in the same
intra-area-prefix-LSA that is associated with the router-LSA.
o If the Active Interface fails, a new Active Interface will have to
take over. The new Active Interface SHOULD form all new neighbor
adjacencies with routers on the link. This failure can be
detected when the router's other interfaces to the Active
Interface's link cease to hear the router's Hellos or through
internal mechanisms, e.g., monitoring the Active Interface's
status.
o If the network becomes partitioned with different local interfaces
attaching to different network partitions, multiple interfaces
will become Active Interfaces and function independently.
o During the SPF calculation when a network-LSA for a network that
is directly connected to the root vertex is being examined, all of
the multiple interfaces to the link of adjacent router-LSAs must
be used in the next-hop calculation.
This can be accomplished during the back link check (see Section
16.1, Step 2 (B), in [OSPFV2]) by examining each link of the
router-LSA and making a list of the links that point to the
network-LSA. The Interface IDs for links in this list are then
used to find the corresponding link-LSAs and the link-local
addresses used as next hops when installing equal-cost paths in
the routing table.
o The interface state machine is modified to add the state Standby.
See Section 4.9.1 for a description of the Standby state.
4.9.1. Standby Interface State
In this state, the interface is one of multiple interfaces to a link
and this interface is designated Standby and is not sending or
receiving control packets. The interface will continue to receive
the Hello packets sent by the Active Interface. The interface will
maintain a timer, the Active Interface Timer, with the same interval
as the RouterDeadInterval. This timer will be reset whenever an OSPF
Hello packet is received from the Active Interface to the link.
Two new events are added to the list of events that cause interface
state changes: MultipleInterfacesToLink and ActiveInterfaceDead. The
descriptions of these events are as follows:
MultipleInterfacesToLink
An interfaces on the router has received a Hello packet from
another interface on the same router. One of the interfaces is
designated as the Active Interface and the other interface is
designated as a Standby Interface. The Standby Interface
transitions to the Standby state.
ActiveInterfaceDead
There has been an indication that a Standby Interface is no longer
on a link with an Active Interface. The firing of the Active
Interface Timer is one indication of this event, as it indicates
that the Standby Interface has not received an OSPF Hello packet
from the Active Interface for the RouterDeadInterval. Other
indications may come from internal notifications, such as the
Active Interface being disabled through a configuration change.
Any indication internal to the router, such that the router knows
the Active Interface is no longer active on the link, can trigger
the ActiveInterfaceDead event for a Standby Interface.
Interface state machine additions include:
State(s): Waiting, DR Other, Backup, or DR
Event: MultipleInterfacesToLink
New state: Standby
Action: All interface variables are reset and interface
timers disabled. Also, all neighbor connections
associated with the interface are destroyed. This
is done by generating the event KillNbr on all
associated neighbors. The Active Interface Timer is
started and the interface will listen for OSPF Hello
packets from the link's Active Interface.
State(s): Standby
Event: ActiveInterfaceDead
New state: Down
Action: The Active Interface Timer is first disabled. Then
the InterfaceUp event is invoked.
Standby Interface State Machine Additions
5. Security Considerations
When running over IPv6, OSPFv3 relies on the IP Authentication Header (see [IPAUTH]) and the IP Encapsulating Security Payload (see [IPESP]) to ensure integrity and authentication/confidentiality of protocol packets. This is described in [OSPFV3-AUTH]. Most OSPFv3 implementations will be running on systems that support multiple protocols with their own independent security assumptions and domains. When IPsec is used to protect OSPFv3 packets, it is important for the implementation to check the IPsec Security Association (SA) and local SA database to ensure the OSPF packet originated from a source that is trusted for OSPFv3. This is required to eliminate the possibility that the packet was authenticated using an SA defined for another protocol running on the same system. The mechanisms in [OSPFV3-AUTH] do not provide protection against compromised, malfunctioning, or misconfigured routers. Such routers can, either accidentally or deliberately, cause malfunctions affecting the whole routing domain. The reader is encouraged to consult [GENERIC-THREATS] for a more comprehensive description of threats to routing protocols.6. Manageability Considerations
The Management Information Base (MIB) for OSPFv3 is defined in [OSPFV3-MIB].7. IANA Considerations
Most OSPF for IPv6 IANA considerations are documented in [OSPF-IANA]. IANA has updated the reference for RFC 2740 to this document. Additionally, this document introduces the following IANA requirements that were not present in [OSPFV3]: o Reserves the options with the values 0x000040 and 0x000080 for migrated OSPFv2 options in the OSPFv3 Options registry defined in [OSPF-IANA]. For information on the OSPFv3 Options field, refer to Appendix A.2. o Adds the prefix option P-bit with value 0x08 to the OSPFv3 Prefix Options registry defined in [OSPF-IANA]. For information on OSPFv3 Prefix Options, refer to Appendix A.4.1.1.
o Adds the prefix option DN-bit with value 0x10 to the OSPFv3 Prefix
Options registry defined in [OSPF-IANA]. For information on
OSPFv3 Prefix Options, refer to Appendix A.4.1.1.
7.1. MOSPF for OSPFv3 Deprecation IANA Considerations
With the deprecation of MOSPF for OSPFv3, the following code points
are available for reassignment. Refer to [OSPF-IANA] for information
on the respective registries. This document:
o Deprecates the MC-bit with value 0x000004 in the OSPFv3 Options
registry.
o Deprecates Group-membership-LSA with value 6 in OSPFv3 LSA
Function Code registry.
o Deprecates MC-bit with value 0x04 in the OSPFv3 Prefix Options
registry.
The W-bit in the OSPFv3 Router Properties has also been deprecated.
This requires a new registry for OSPFv3 router properties since it
will diverge from the OSPFv2 Router Properties.
Registry Name: OSPFv3 Router Properties Registry
Reference: RFC 5340
Registration Procedures: Standards Action
Registry:
Value Description Reference
------ ------------- ---------
0x01 B-bit RFC 5340
0x02 E-bit RFC 5340
0x04 V-bit RFC 5340
0x08 Deprecated RFC 5340
0x10 Nt-bit RFC 5340
OSPFv3 Router Properties Registry
8. Acknowledgments
The RFC text was produced using Marshall Rose's xml2rfc tool.
The following individuals contributed comments that were incorporated
into this document:
o Harold Rabbie for his description of protocol details that needed
to be clarified for OSPFv3 NSSA support.
o Nic Neate for his pointing out that there needed to be changes for
unknown LSA types handling in the processing of Database
Description packets.
o Jacek Kwiatkowski for being the first to point out that the V6-
and R-bits are not taken into account in the OSPFv3 intra-area SPF
calculation.
o Michael Barnes recognized that the support for multiple interfaces
to a single link was broken (see Section 4.9) and provided the
description of the current protocol mechanisms. Abhay Roy
reviewed and suggested improvements to the mechanisms.
o Alan Davey reviewed and commented on document revisions.
o Vivek Dubey reviewed and commented on document revisions.
o Manoj Goyal and Vivek Dubey complained enough about link-LSAs
being unnecessary to compel introduction of the LinkLSASuppression
interface configuration parameter.
o Manoj Goyal for pointing out that the next-hop calculation for
intra-area-prefix-LSAs corresponding to network vertices was
unclear.
o Ramana Koppula reviewed and commented on document revisions.
o Paul Wells reviewed and commented on document revisions.
o Amir Khan reviewed and commented on document revisions.
o Dow Street and Wayne Wheeler commented on the addition of the DN-
bit to OSPFv3.
o Mitchell Erblichs provided numerous editorial comments.
o Russ White provided numerous editorial comments.
o Kashima Hiroaki provided editorial comments.
o Sina Mirtorabi suggested that OSPFv3 should be aligned with OSPFv2
with respect to precedence and should map it to IPv6 traffic class
as specified in RFC 2474. Steve Blake helped with the text.
o Faraz Shamin reviewed a late version of the document and provided
editorial comments.
o Christian Vogt performed the General Area Review Team (Gen-ART)
review and provided comments.
o Dave Ward, Dan Romascanu, Tim Polk, Ron Bonica, Pasi Eronen, and
Lars Eggert provided comments during the IESG review. Also,
thanks to Pasi for the text in Section 5 relating to routing
threats.
9. References
9.1. Normative References
[DEMAND] Moy, J., "Extending OSPF to Support Demand
Circuits", RFC 1793, April 1995.
[DIFF-SERV] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field
(DS Field) in the IPv4 and IPv6 Headers",
RFC 2474, December 1998.
[DN-BIT] Rosen, E., Peter, P., and P. Pillay-Esnault,
"Using a Link State Advertisement (LSA) Options
Bit to Prevent Looping in BGP/MPLS IP Virtual
Private Networks (VPNs)", RFC 4576, June 2006.
[INTFMIB] McCloghrie, K. and F. Kastenholz, "The Interfaces
Group MIB", RFC 2863, June 2000.
[IP6ADDR] Hinden, R. and S. Deering, "IP Version 6
Addressing Architecture", RFC 4291, February 2006.
[IPAUTH] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[IPESP] Kent, S., "IP Encapsulating Security Payload
(ESP)", RFC 4303, December 2005.
[IPV4] Postal, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[IPV6] Deering, S. and R. Hinden, "Internet Protocol,
Version 6 (IPv6) Specification", RFC 2460,
December 1998.
[NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA)
Option", RFC 3101, January 2003.
[OSPF-IANA] Kompella, K. and B. Fenner, "IANA Considerations for OSPF", BCP 130, RFC 4940, July 2007. [OSPFV2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [OSPFV3-AUTH] Gupta, M. and N. Melam, "Authentication/ Confidentiality for OSPFv3", RFC 4552, June 2006. [RFC-KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.9.2. Informative References
[GENERIC-THREATS] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006. [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994. [MTUDISC] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990. [OPAQUE] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998. [OSPFV3] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999. [OSPFV3-MIB] Joyal, D. and V. Manral, "Management Information Base for OSPFv3", Work in Progress, September 2007. [SERV-CLASS] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006.
Appendix A. OSPF Data Formats
This appendix describes the format of OSPF protocol packets and OSPF LSAs. The OSPF protocol runs directly over the IPv6 network layer. Before any data formats are described, the details of the OSPF encapsulation are explained. Next, the OSPF Options field is described. This field describes various capabilities that may or may not be supported by pieces of the OSPF routing domain. The OSPF Options field is contained in OSPF Hello packets, Database Description packets, and OSPF LSAs. OSPF packet formats are detailed in Section A.3. A description of OSPF LSAs appears in Section A.4. This section describes how IPv6 address prefixes are represented within LSAs, details the standard LSA header, and then provides formats for each of the specific LSA types.A.1. Encapsulation of OSPF Packets
OSPF runs directly over the IPv6's network layer. OSPF packets are therefore encapsulated solely by IPv6 and local data-link headers. OSPF does not define a way to fragment its protocol packets, and depends on IPv6 fragmentation when transmitting packets larger than the link MTU. If necessary, the length of OSPF packets can be up to 65,535 bytes. The OSPF packet types that are likely to be large (Database Description, Link State Request, Link State Update, and Link State Acknowledgment packets) can usually be split into multiple protocol packets without loss of functionality. This is recommended; IPv6 fragmentation should be avoided whenever possible. Using this reasoning, an attempt should be made to limit the size of OSPF packets sent over virtual links to 1280 bytes unless Path MTU Discovery is being performed [MTUDISC]. The other important features of OSPF's IPv6 encapsulation are: o Use of IPv6 multicast. Some OSPF messages are multicast when sent over broadcast networks. Two distinct IP multicast addresses are used. Packets sent to these multicast addresses should never be forwarded; they are meant to travel a single hop only. As such, the multicast addresses have been chosen with link-local scope and packets sent to these addresses should have their IPv6 Hop Limit set to 1. b
AllSPFRouters
This multicast address has been assigned the value FF02::5.
All routers running OSPF should be prepared to receive packets
sent to this address. Hello packets are always sent to this
destination. Also, certain OSPF protocol packets are sent to
this address during the flooding procedure.
AllDRouters
This multicast address has been assigned the value FF02::6.
Both the Designated Router and Backup Designated Router must be
prepared to receive packets destined to this address. Certain
OSPF protocol packets are sent to this address during the
flooding procedure.
o OSPF is IP protocol 89. This number SHOULD be inserted in the
Next Header field of the encapsulating IPv6 header.
o The OSPFv2 specification (Appendix A.1 in [OSPFV2]) indicates that
OSPF protocol packets are sent with IP precedence set to
Internetwork Control (B'110') [IPV4]. If routers in the OSPF
routing domain map their IPv6 Traffic Class octet to the
Differentiated Services Code Point (DSCP) as specified in
[DIFF-SERV], then OSPFv3 packets SHOULD be sent with their DSCP
set to CS6 (B'110000'), as specified in [SERV-CLASS]. In networks
supporting this mapping, OSPF packets will be given precedence
over IPv6 data traffic.
A.2. The Options Field
The 24-bit OSPF Options field is present in OSPF Hello packets,
Database Description packets, and certain LSAs (router-LSAs, network-
LSAs, inter-area-router-LSAs, and link-LSAs). The Options field
enables OSPF routers to support (or not support) optional
capabilities, and to communicate their capability level to other OSPF
routers. Through this mechanism, routers of differing capabilities
can be mixed within an OSPF routing domain.
An option mismatch between routers can cause a variety of behaviors,
depending on the particular option. Some option mismatches prevent
neighbor relationships from forming (e.g., the E-bit below); these
mismatches are discovered through the sending and receiving of Hello
packets. Some option mismatches prevent particular LSA types from
being flooded across adjacencies; these are discovered through the
sending and receiving of Database Description packets. Some option
mismatches prevent routers from being included in one or more of the
various routing calculations because of their reduced functionality;
these mismatches are discovered by examining LSAs.
Seven bits of the OSPF Options field have been assigned. Each bit is
described briefly below. Routers should reset (i.e., clear)
unrecognized bits in the Options field when sending Hello packets or
Database Description packets and when originating LSAs. Conversely,
routers encountering unrecognized Options bits in received Hello
packets, Database Description packets, or LSAs should ignore the
unrecognized bits and process the packet or LSA normally.
1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+--+
| | | | | | | | | | | | | | | | |*|*|DC|R|N|x| E|V6|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+--+
The Options field
The Options field
V6-bit
If this bit is clear, the router/link should be excluded from IPv6
routing calculations. See Section 4.8 for details.
E-bit
This bit describes the way AS-external-LSAs are flooded, as
described in Sections 3.6, 9.5, 10.8, and 12.1.2 of [OSPFV2].
x-Bit
This bit was previously used by MOSPF (see [MOSPF]), which has
been deprecated for OSPFv3. The bit should be set to 0 and
ignored when received. It may be reassigned in the future.
N-bit
This bit indicates whether or not the router is attached to an
NSSA as specified in [NSSA].
R-bit
This bit (the `Router' bit) indicates whether the originator is an
active router. If the router bit is clear, then routes that
transit the advertising node cannot be computed. Clearing the
router 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.
DC-bit
This bit describes the router's handling of demand circuits, as
specified in [DEMAND].
*-bit
These bits are reserved for migration of OSPFv2 protocol
extensions.
A.3. OSPF Packet Formats
There are five distinct OSPF packet types. All OSPF packet types
begin with a standard 16-byte header. This header is described
first. Each packet type is then described in a succeeding section.
In these sections, each packet's format is displayed and the packet's
component fields are defined.
All OSPF packet types (other than the OSPF Hello packets) deal with
lists of LSAs. For example, Link State Update packets implement the
flooding of LSAs throughout the OSPF routing domain. The format of
LSAs is described in Section A.4.
The receive processing of OSPF packets is detailed in Section 4.2.2.
The sending of OSPF packets is explained in Section 4.2.1.
A.3.1. The OSPF Packet Header
Every OSPF packet starts with a standard 16-byte header. Together
with the encapsulating IPv6 headers, the OSPF header contains all the
information necessary to determine whether the packet should be
accepted for further processing. This determination is described in
Section 4.2.2.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | Type | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The OSPF Packet Header
Version #
The OSPF version number. This specification documents version 3
of the OSPF protocol.
Type
The OSPF packet types are as follows. See Appendix A.3.2 through
Appendix A.3.6 for details.
Type Description
---------------------------------
1 Hello
2 Database Description
3 Link State Request
4 Link State Update
5 Link State Acknowledgment
Packet length
The length of the OSPF protocol packet in bytes. This length
includes the standard OSPF header.
Router ID
The Router ID of the packet's source.
Area ID
A 32-bit number identifying the area to which this packet belongs.
All OSPF packets are associated with a single area. Most travel a
single hop only. Packets traversing a virtual link are labeled
with the backbone Area ID of 0.
Checksum
OSPF uses the standard checksum calculation for IPv6 applications:
The 16-bit one's complement of the one's complement sum of the
entire contents of the packet, starting with the OSPF packet
header, and prepending a "pseudo-header" of IPv6 header fields, as
specified in Section 8.1 of [IPV6]. The "Upper-Layer Packet
Length" in the pseudo-header is set to the value of the OSPF
packet header's length field. The Next Header value used in the
pseudo-header is 89. If the packet's length is not an integral
number of 16-bit words, the packet is padded with a byte of zero
before checksumming. Before computing the checksum, the checksum
field in the OSPF packet header is set to 0.
Instance ID
Enables multiple instances of OSPF to be run over a single link.
Each protocol instance would be assigned a separate Instance ID;
the Instance ID has link-local significance only. Received
packets whose Instance ID is not equal to the receiving
interface's Instance ID are discarded.
0
These fields are reserved. They SHOULD be set to 0 when sending
protocol packets and MUST be ignored when receiving protocol
packets.
A.3.2. The Hello Packet
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.
All routers connected to a common link must agree on certain
parameters (HelloInterval and RouterDeadInterval). These parameters
are included in Hello packets allowing differences to inhibit the
forming of neighbor relationships. The Hello packet also contains
fields used in Designated Router election (Designated Router ID and
Backup Designated Router ID), and fields used to detect bidirectional
communication (the Router IDs of all neighbors whose Hellos have been
recently received).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 1 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rtr Priority | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | RouterDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Designated Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Designated Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
The OSPF Hello Packet
Interface ID
32-bit number uniquely identifying this interface among the
collection of this router's interfaces. For example, in some
implementations it may be possible to use the MIB-II IfIndex
([INTFMIB]).
Rtr Priority
This router's Router Priority. Used in (Backup) Designated Router
election. If set to 0, the router will be ineligible to become
(Backup) Designated Router.
Options
The optional capabilities supported by the router, as documented
in Section A.2.
HelloInterval
The number of seconds between this router's Hello packets.
RouterDeadInterval
The number of seconds before declaring a silent router down.
Designated Router ID
The sending router's view of the identity of the Designated Router
for this network. The Designated Router is identified by its
Router ID. It is set to 0.0.0.0 if there is no Designated Router.
Backup Designated Router ID
The sending router's view of the identity of the Backup Designated
Router for this network. The Backup Designated Router is
identified by its IP Router ID. It is set to 0.0.0.0 if there is
no Backup Designated Router.
Neighbor ID
The Router IDs of each router on the network with neighbor state
1-Way or greater.
A.3.3. The Database Description Packet
Database Description packets are OSPF packet type 2. 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.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| 3 | 2 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| Interface MTU | 0 |0|0|0|0|0|I|M|MS|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| DD sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| ... |
The OSPF Database Description Packet
The format of the Database Description packet is very similar to both
the Link State Request packet and the Link State Acknowledgment
packet. The main part of all three is a list of items, each item
describing a piece of the link-state database. The sending of
Database Description packets is documented in Section 10.8 of
[OSPFV2]. The reception of Database Description packets is
documented in Section 10.6 of [OSPFV2].
Options
The optional capabilities supported by the router, as documented
in Section A.2.
Interface MTU
The size in bytes of the largest IPv6 datagram that can be sent
out the associated interface without fragmentation. The MTUs of
common Internet link types can be found in Table 7-1 of [MTUDISC].
Interface MTU should be set to 0 in Database Description packets
sent over virtual links.
I-bit
The Init bit. When set to 1, this packet is the first in the
sequence of Database Description packets.
M-bit
The More bit. When set to 1, it indicates that more Database
Description packets are to follow.
MS-bit
The Master/Slave bit. When set to 1, it indicates that the router
is the master during the Database Exchange process. Otherwise,
the router is the slave.
DD sequence number
Used to sequence the collection of Database Description packets.
The initial value (indicated by the Init bit being set) should be
unique. The DD sequence number then increments until the complete
database for both the master and slave routers have been
exchanged.
The rest of the packet consists of a (possibly partial) list of the
link-state database's pieces. Each LSA in the database is described
by its LSA header. The LSA header is documented in Appendix A.4.2.
It contains all the information required to uniquely identify both
the LSA and the LSA's current instance.
A.3.4. The Link State Request Packet
Link State Request packets are OSPF packet type 3. 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.
A router that sends a Link State Request packet has in mind the
precise instance of the database pieces it is requesting. Each
instance is defined by its LS sequence number, LS checksum, and LS
age, although these fields are not specified in the Link State
Request packet itself. The router may receive even more recent LSA
instances in response.
The sending of Link State Request packets is documented in Section
10.9 of [OSPFV2]. The reception of Link State Request packets is
documented in Section 10.7 of [OSPFV2].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 3 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
The OSPF Link State Request Packet
Each LSA requested is specified by its LS type, Link State ID, and
Advertising Router. This uniquely identifies the LSA without
specifying its instance. Link State Request packets are understood
to be requests for the most recent instance of the specified LSAs.
A.3.5. The Link State Update Packet
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.
Link State Update packets are multicast on those physical networks
that support multicast/broadcast. In order to make the flooding
procedure reliable, flooded LSAs are acknowledged in Link State
Acknowledgment packets. If retransmission of certain LSAs is
necessary, the retransmitted LSAs are always carried by unicast Link
State Update packets. For more information on the reliable flooding
of LSAs, consult Section 4.5.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 4 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # LSAs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- +-+
| LSAs |
+- +-+
| ... |
The OSPF Link State Update Packet
# LSAs
The number of LSAs included in this update.
The body of the Link State Update packet consists of a list of LSAs.
Each LSA begins with a common 20-byte header, described in
Appendix A.4.2. Detailed formats of the different types of LSAs are
described Appendix A.4.
A.3.6. The Link State Acknowledgment Packet
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. The sending of Link State Acknowledgment packets is
documented in Section 13.5 of [OSPFV2]. The reception of Link State
Acknowledgment packets is documented in Section 13.7 of [OSPFV2].
Multiple LSAs MAY be acknowledged in a single Link State
Acknowledgment packet. Depending on the state of the sending
interface and the sender of the corresponding Link State Update
packet, a Link State Acknowledgment packet is sent to the multicast
address AllSPFRouters, the multicast address AllDRouters, or to a
neighbor's unicast address (see Section 13.5 of [OSPFV2] for
details).
The format of this packet is similar to that of the Data Description
packet. The body of both packets is simply a list of LSA headers.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 5 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
The OSPF Link State Acknowledgment Packet
Each acknowledged LSA is described by its LSA header. The LSA header
is documented in Appendix A.4.2. It contains all the information
required to uniquely identify both the LSA and the LSA's current
instance.
(page 68 continued on part 4)