RFC 2328
OSPF Version 2
Pages: 244
Internet Standard: 54
→ Errata
Obsoletes: 2178
Updated by: 5709 6549 6845 6860 7474 8042 9355 9454
Internet Standard: 54
→ Errata
Obsoletes: 2178
Updated by: 5709 6549 6845 6860 7474 8042 9355 9454
Part 8 of 8 – Pages 203 to 244
A.4 LSA formats This memo defines five distinct types of LSAs. Each LSA begins with a standard 20 byte LSA header. This header is explained in Section A.4.1. Succeeding sections then diagram the separate LSA types. Each LSA describes a piece of the OSPF routing domain. Every router originates a router-LSA. In addition, whenever the router is elected Designated Router, it originates a network-LSA. Other types of LSAs may also be originated (see Section 12.4). All LSAs are then flooded throughout the OSPF routing domain. The flooding algorithm is reliable, ensuring that all routers have the same collection of LSAs. (See Section 13 for more information concerning the flooding algorithm). This collection of LSAs is called the link-state database. From the link state database, each router constructs a shortest path tree with itself as root. This yields a routing table (see Section 11). For the details of the routing table build process, see Section 16.
A.4.1 The LSA header All LSAs begin with a common 20 byte header. This header contains enough information to uniquely identify the LSA (LS type, Link State ID, and Advertising Router). Multiple instances of the LSA may exist in the routing domain at the same time. It is then necessary to determine which instance is more recent. This is accomplished by examining the LS age, LS sequence number and LS checksum fields that are also contained in the LSA header. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | LS type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ LS age The time in seconds since the LSA was originated. Options The optional capabilities supported by the described portion of the routing domain. OSPF's optional capabilities are documented in Section A.2. LS type The type of the LSA. Each LSA type has a separate advertisement format. The LSA types defined in this memo are as follows (see Section 12.1.3 for further explanation):
LS Type Description
___________________________________
1 Router-LSAs
2 Network-LSAs
3 Summary-LSAs (IP network)
4 Summary-LSAs (ASBR)
5 AS-external-LSAs
Link State ID
This field identifies the portion of the internet environment
that is being described by the LSA. The contents of this field
depend on the LSA's LS type. For example, in network-LSAs the
Link State ID is set to the IP interface address of the
network's Designated Router (from which the network's IP address
can be derived). The Link State ID is further discussed in
Section 12.1.4.
Advertising Router
The Router ID of the router that originated the LSA. For
example, in network-LSAs this field is equal to the Router ID of
the network's Designated Router.
LS sequence number
Detects old or duplicate LSAs. Successive instances of an LSA
are given successive LS sequence numbers. See Section 12.1.6
for more details.
LS checksum
The Fletcher checksum of the complete contents of the LSA,
including the LSA header but excluding the LS age field. See
Section 12.1.7 for more details.
length
The length in bytes of the LSA. This includes the 20 byte LSA
header.
A.4.2 Router-LSAs Router-LSAs are the Type 1 LSAs. Each router in an area originates a router-LSA. The LSA describes the state and cost of the router's links (i.e., interfaces) to the area. All of the router's links to the area must be described in a single router-LSA. For details concerning the construction of router-LSAs, see Section 12.4.1. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |V|E|B| 0 | # links | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | # TOS | metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOS | 0 | TOS metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
In router-LSAs, the Link State ID field is set to the router's OSPF
Router ID. Router-LSAs are flooded throughout a single area only.
bit V
When set, the router is an endpoint of one or more fully
adjacent virtual links having the described area as Transit area
(V is for virtual link endpoint).
bit E
When set, the router is an AS boundary router (E is for
external).
bit B
When set, the router is an area border router (B is for border).
# links
The number of router links described in this LSA. This must be
the total collection of router links (i.e., interfaces) to the
area.
The following fields are used to describe each router link (i.e.,
interface). Each router link is typed (see the below Type field).
The Type field indicates the kind of link being described. It may
be a link to a transit network, to another router or to a stub
network. The values of all the other fields describing a router
link depend on the link's Type. For example, each link has an
associated 32-bit Link Data field. For links to stub networks this
field specifies the network's IP address mask. For other link types
the Link Data field specifies the router interface's IP address.
Type
A quick description of the router link. One of the following.
Note that host routes are classified as links to stub networks
with network mask of 0xffffffff.
Type Description
__________________________________________________
1 Point-to-point connection to another router
2 Connection to a transit network
3 Connection to a stub network
4 Virtual link
Link ID
Identifies the object that this router link connects to. Value
depends on the link's Type. When connecting to an object that
also originates an LSA (i.e., another router or a transit
network) the Link ID is equal to the neighboring LSA's Link
State ID. This provides the key for looking up the neighboring
LSA in the link state database during the routing table
calculation. See Section 12.2 for more details.
Type Link ID
______________________________________
1 Neighboring router's Router ID
2 IP address of Designated Router
3 IP network/subnet number
4 Neighboring router's Router ID
Link Data
Value again depends on the link's Type field. For connections to
stub networks, Link Data specifies the network's IP address
mask. For unnumbered point-to-point connections, it specifies
the interface's MIB-II [Ref8] ifIndex value. For the other link
types it specifies the router interface's IP address. This
latter piece of information is needed during the routing table
build process, when calculating the IP address of the next hop.
See Section 16.1.1 for more details.
# TOS
The number of different TOS metrics given for this link, not
counting the required link metric (referred to as the TOS 0
metric in [Ref9]). For example, if no additional TOS metrics
are given, this field is set to 0.
metric
The cost of using this router link.
Additional TOS-specific information may also be included, for
backward compatibility with previous versions of the OSPF
specification ([Ref9]). Within each link, and for each desired TOS,
TOS TOS-specific link information may be encoded as follows:
TOS IP Type of Service that this metric refers to. The encoding of
TOS in OSPF LSAs is described in Section 12.3.
TOS metric
TOS-specific metric information.
A.4.3 Network-LSAs Network-LSAs are the Type 2 LSAs. A network-LSA is originated for each broadcast and NBMA network in the area which supports two or more routers. The network-LSA is originated by the network's Designated Router. The LSA describes all routers attached to the network, including the Designated Router itself. The LSA's Link State ID field lists the IP interface address of the Designated Router. The distance from the network to all attached routers is zero. This is why metric fields need not be specified in the network-LSA. For details concerning the construction of network-LSAs, see Section 12.4.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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attached Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Network Mask The IP address mask for the network. For example, a class A network would have the mask 0xff000000.
Attached Router
The Router IDs of each of the routers attached to the network.
Actually, only those routers that are fully adjacent to the
Designated Router are listed. The Designated Router includes
itself in this list. The number of routers included can be
deduced from the LSA header's length field.
A.4.4 Summary-LSAs Summary-LSAs are the Type 3 and 4 LSAs. These LSAs are originated by area border routers. Summary-LSAs describe inter-area destinations. For details concerning the construction of summary- LSAs, see Section 12.4.3. Type 3 summary-LSAs are used when the destination is an IP network. In this case the LSA's Link State ID field is an IP network number (if necessary, the Link State ID can also have one or more of the network's "host" bits set; see Appendix E for details). When the destination is an AS boundary router, a Type 4 summary-LSA is used, and the Link State ID field is the AS boundary router's OSPF Router ID. (To see why it is necessary to advertise the location of each ASBR, consult Section 16.4.) Other than the difference in the Link State ID field, the format of Type 3 and 4 summary-LSAs is identical. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 3 or 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOS | TOS metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
For stub areas, Type 3 summary-LSAs can also be used to describe a
(per-area) default route. Default summary routes are used in stub
areas instead of flooding a complete set of external routes. When
describing a default summary route, the summary-LSA's Link State ID
is always set to DefaultDestination (0.0.0.0) and the Network Mask
is set to 0.0.0.0.
Network Mask
For Type 3 summary-LSAs, this indicates the destination
network's IP address mask. For example, when advertising the
location of a class A network the value 0xff000000 would be
used. This field is not meaningful and must be zero for Type 4
summary-LSAs.
metric
The cost of this route. Expressed in the same units as the
interface costs in the router-LSAs.
Additional TOS-specific information may also be included, for
backward compatibility with previous versions of the OSPF
specification ([Ref9]). For each desired TOS, TOS-specific
information is encoded as follows:
TOS IP Type of Service that this metric refers to. The encoding of
TOS in OSPF LSAs is described in Section 12.3.
TOS metric
TOS-specific metric information.
A.4.5 AS-external-LSAs AS-external-LSAs are the Type 5 LSAs. These LSAs are originated by AS boundary routers, and describe destinations external to the AS. For details concerning the construction of AS-external-LSAs, see Section 12.4.3. AS-external-LSAs usually describe a particular external destination. For these LSAs the Link State ID field specifies an IP network number (if necessary, the Link State ID can also have one or more of the network's "host" bits set; see Appendix E for details). AS- external-LSAs are also used to describe a default route. Default routes are used when no specific route exists to the destination. When describing a default route, the Link State ID is always set to DefaultDestination (0.0.0.0) and the Network Mask is set to 0.0.0.0. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| 0 | metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Forwarding address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | External Route Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| TOS | TOS metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Forwarding address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Route Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Network Mask
The IP address mask for the advertised destination. For
example, when advertising a class A network the mask 0xff000000
would be used.
bit E
The type of external metric. If bit E is set, the metric
specified is a Type 2 external metric. This means the metric is
considered larger than any link state path. If bit E is zero,
the specified metric is a Type 1 external metric. This means
that it is expressed in the same units as the link state metric
(i.e., the same units as interface cost).
metric
The cost of this route. Interpretation depends on the external
type indication (bit E above).
Forwarding address
Data traffic for the advertised destination will be forwarded to
this address. If the Forwarding address is set to 0.0.0.0, data
traffic will be forwarded instead to the LSA's originator (i.e.,
the responsible AS boundary router).
External Route Tag
A 32-bit field attached to each external route. This is not
used by the OSPF protocol itself. It may be used to communicate
information between AS boundary routers; the precise nature of
such information is outside the scope of this specification.
Additional TOS-specific information may also be included, for
backward compatibility with previous versions of the OSPF
specification ([Ref9]). For each desired TOS, TOS-specific
information is encoded as follows:
TOS The Type of Service that the following fields concern. The
encoding of TOS in OSPF LSAs is described in Section 12.3.
B. Architectural Constants Several OSPF protocol parameters have fixed architectural values. These parameters have been referred to in the text by names such as LSRefreshTime. The same naming convention is used for the configurable protocol parameters. They are defined in Appendix C. The name of each architectural constant follows, together with its value and a short description of its function. LSRefreshTime The maximum time between distinct originations of any particular LSA. If the LS age field of one of the router's self-originated LSAs reaches the value LSRefreshTime, a new instance of the LSA is originated, even though the contents of the LSA (apart from the LSA header) will be the same. The value of LSRefreshTime is set to 30 minutes. MinLSInterval The minimum time between distinct originations of any particular LSA. The value of MinLSInterval is set to 5 seconds. MinLSArrival For any particular LSA, the minimum time that must elapse between reception of new LSA instances during flooding. LSA instances received at higher frequencies are discarded. The value of MinLSArrival is set to 1 second. MaxAge The maximum age that an LSA can attain. When an LSA's LS age field reaches MaxAge, it is reflooded in an attempt to flush the LSA from the routing domain (See Section 14). LSAs of age MaxAge are not used in the routing table calculation. The value of MaxAge is set to 1 hour. CheckAge When the age of an LSA in the link state database hits a multiple of CheckAge, the LSA's checksum is verified. An incorrect checksum at this time indicates a serious error. The value of CheckAge is set to 5 minutes.
MaxAgeDiff
The maximum time dispersion that can occur, as an LSA is flooded
throughout the AS. Most of this time is accounted for by the
LSAs sitting on router output queues (and therefore not aging)
during the flooding process. The value of MaxAgeDiff is set to
15 minutes.
LSInfinity
The metric value indicating that the destination described by an
LSA is unreachable. Used in summary-LSAs and AS-external-LSAs as
an alternative to premature aging (see Section 14.1). It is
defined to be the 24-bit binary value of all ones: 0xffffff.
DefaultDestination
The Destination ID that indicates the default route. This route
is used when no other matching routing table entry can be found.
The default destination can only be advertised in AS-external-
LSAs and in stub areas' type 3 summary-LSAs. Its value is the
IP address 0.0.0.0. Its associated Network Mask is also always
0.0.0.0.
InitialSequenceNumber
The value used for LS Sequence Number when originating the first
instance of any LSA. Its value is the signed 32-bit integer
0x80000001.
MaxSequenceNumber
The maximum value that LS Sequence Number can attain. Its value
is the signed 32-bit integer 0x7fffffff.
C. Configurable Constants The OSPF protocol has quite a few configurable parameters. These parameters are listed below. They are grouped into general functional categories (area parameters, interface parameters, etc.). Sample values are given for some of the parameters. Some parameter settings need to be consistent among groups of routers. For example, all routers in an area must agree on that area's parameters, and all routers attached to a network must agree on that network's IP network number and mask. Some parameters may be determined by router algorithms outside of this specification (e.g., the address of a host connected to the router via a SLIP line). From OSPF's point of view, these items are still configurable. C.1 Global parameters In general, a separate copy of the OSPF protocol is run for each area. Because of this, most configuration parameters are defined on a per-area basis. The few global configuration parameters are listed below. Router ID This is a 32-bit number that uniquely identifies the router in the Autonomous System. One algorithm for Router ID assignment is to choose the largest or smallest IP address assigned to the router. If a router's OSPF Router ID is changed, the router's OSPF software should be restarted before the new Router ID takes effect. Before restarting in order to change its Router ID, the router should flush its self-originated LSAs from the routing domain (see Section 14.1), or they will persist for up to MaxAge minutes. RFC1583Compatibility Controls the preference rules used in Section 16.4 when choosing among multiple AS-external-LSAs advertising the same destination. When set to "enabled", the preference rules remain those specified by RFC 1583 ([Ref9]). When set to "disabled", the preference rules are those stated in
Section 16.4.1, which prevent routing loops when AS-
external-LSAs for the same destination have been originated
from different areas. Set to "enabled" by default.
In order to minimize the chance of routing loops, all OSPF
routers in an OSPF routing domain should have
RFC1583Compatibility set identically. When there are routers
present that have not been updated with the functionality
specified in Section 16.4.1 of this memo, all routers should
have RFC1583Compatibility set to "enabled". Otherwise, all
routers should have RFC1583Compatibility set to "disabled",
preventing all routing loops.
C.2 Area parameters
All routers belonging to an area must agree on that area's
configuration. Disagreements between two routers will lead to
an inability for adjacencies to form between them, with a
resulting hindrance to the flow of routing protocol and data
traffic. The following items must be configured for an area:
Area ID
This is a 32-bit number that identifies the area. The Area
ID of 0.0.0.0 is reserved for the backbone. If the area
represents a subnetted network, the IP network number of the
subnetted network may be used for the Area ID.
List of address ranges
An OSPF area is defined as a list of address ranges. Each
address range consists of the following items:
[IP address, mask]
Describes the collection of IP addresses contained
in the address range. Networks and hosts are
assigned to an area depending on whether their
addresses fall into one of the area's defining
address ranges. Routers are viewed as belonging to
multiple areas, depending on their attached
networks' area membership.
Status Set to either Advertise or DoNotAdvertise. Routing
information is condensed at area boundaries.
External to the area, at most a single route is
advertised (via a summary-LSA) for each address
range. The route is advertised if and only if the
address range's Status is set to Advertise.
Unadvertised ranges allow the existence of certain
networks to be intentionally hidden from other
areas. Status is set to Advertise by default.
As an example, suppose an IP subnetted network is to be its
own OSPF area. The area would be configured as a single
address range, whose IP address is the address of the
subnetted network, and whose mask is the natural class A, B,
or C address mask. A single route would be advertised
external to the area, describing the entire subnetted
network.
ExternalRoutingCapability
Whether AS-external-LSAs will be flooded into/throughout the
area. If AS-external-LSAs are excluded from the area, the
area is called a "stub". Internal to stub areas, routing to
external destinations will be based solely on a default
summary route. The backbone cannot be configured as a stub
area. Also, virtual links cannot be configured through stub
areas. For more information, see Section 3.6.
StubDefaultCost
If the area has been configured as a stub area, and the
router itself is an area border router, then the
StubDefaultCost indicates the cost of the default summary-
LSA that the router should advertise into the area.
C.3 Router interface parameters
Some of the configurable router interface parameters (such as IP
interface address and subnet mask) actually imply properties of
the attached networks, and therefore must be consistent across
all the routers attached to that network. The parameters that
must be configured for a router interface are:
IP interface address
The IP protocol address for this interface. This uniquely
identifies the router over the entire internet. An IP
address is not required on point-to-point networks. Such a
point-to-point network is called "unnumbered".
IP interface mask
Also referred to as the subnet/network mask, this indicates
the portion of the IP interface address that identifies the
attached network. Masking the IP interface address with the
IP interface mask yields the IP network number of the
attached network. On point-to-point networks and virtual
links, the IP interface mask is not defined. On these
networks, the link itself is not assigned an IP network
number, and so the addresses of each side of the link are
assigned independently, if they are assigned at all.
Area ID
The OSPF area to which the attached network belongs.
Interface output cost
The cost of sending a packet on the interface, expressed in
the link state metric. This is advertised as the link cost
for this interface in the router's router-LSA. The interface
output cost must always be greater than 0.
RxmtInterval
The number of seconds between LSA retransmissions, for
adjacencies belonging to this interface. Also used when
retransmitting Database Description and Link State Request
Packets. This should be well over the expected round-trip
delay between any two routers on the attached network. The
setting of this value should be conservative or needless
retransmissions will result. Sample value for a local area
network: 5 seconds.
InfTransDelay
The estimated number of seconds it takes to transmit a Link
State Update Packet over this interface. LSAs contained in
the update packet must have their age incremented by this
amount before transmission. This value should take into
account the transmission and propagation delays of the
interface. It must be greater than 0. Sample value for a
local area network: 1 second.
Router Priority
An 8-bit unsigned integer. When two routers attached to a
network both attempt to become Designated Router, the one
with the highest Router Priority takes precedence. If there
is still a tie, the router with the highest Router ID takes
precedence. A router whose Router Priority is set to 0 is
ineligible to become Designated Router on the attached
network. Router Priority is only configured for interfaces
to broadcast and NBMA networks.
HelloInterval
The length of time, in seconds, between the Hello Packets
that the router sends on the interface. This value is
advertised in the router's Hello Packets. It must be the
same for all routers attached to a common network. The
smaller the HelloInterval, the faster topological changes
will be detected; however, more OSPF routing protocol
traffic will ensue. Sample value for a X.25 PDN network: 30
seconds. Sample value for a local area network: 10 seconds.
RouterDeadInterval
After ceasing to hear a router's Hello Packets, the number
of seconds before its neighbors declare the router down.
This is also advertised in the router's Hello Packets in
their RouterDeadInterval field. This should be some
multiple of the HelloInterval (say 4). This value again
must be the same for all routers attached to a common
network.
AuType
Identifies the authentication procedure to be used on the
attached network. This value must be the same for all
routers attached to the network. See Appendix D for a
discussion of the defined authentication types.
Authentication key
This configured data allows the authentication procedure to
verify OSPF protocol packets received over the interface.
For example, if the AuType indicates simple password, the
Authentication key would be a clear 64-bit password.
Authentication keys associated with the other OSPF
authentication types are discussed in Appendix D.
C.4 Virtual link parameters
Virtual links are used to restore/increase connectivity of the
backbone. Virtual links may be configured between any pair of
area border routers having interfaces to a common (non-backbone)
area. The virtual link appears as an unnumbered point-to-point
link in the graph for the backbone. The virtual link must be
configured in both of the area border routers.
A virtual link appears in router-LSAs (for the backbone) as if
it were a separate router interface to the backbone. As such,
it has all of the parameters associated with a router interface
(see Section C.3). Although a virtual link acts like an
unnumbered point-to-point link, it does have an associated IP
interface address. This address is used as the IP source in
OSPF protocol packets it sends along the virtual link, and is
set dynamically during the routing table build process.
Interface output cost is also set dynamically on virtual links
to be the cost of the intra-area path between the two routers.
The parameter RxmtInterval must be configured, and should be
well over the expected round-trip delay between the two routers.
This may be hard to estimate for a virtual link; it is better to
err on the side of making it too large. Router Priority is not
used on virtual links.
A virtual link is defined by the following two configurable
parameters: the Router ID of the virtual link's other endpoint,
and the (non-backbone) area through which the virtual link runs
(referred to as the virtual link's Transit area). Virtual links
cannot be configured through stub areas.
C.5 NBMA network parameters
OSPF treats an NBMA network much like it treats a broadcast
network. Since there may be many routers attached to the
network, a Designated Router is selected for the network. This
Designated Router then originates a network-LSA, which lists all
routers attached to the NBMA network.
However, due to the lack of broadcast capabilities, it may be
necessary to use configuration parameters in the Designated
Router selection. These parameters will only need to be
configured in those routers that are themselves eligible to
become Designated Router (i.e., those router's whose Router
Priority for the network is non-zero), and then only if no
automatic procedure for discovering neighbors exists:
List of all other attached routers
The list of all other routers attached to the NBMA network.
Each router is listed by its IP interface address on the
network. Also, for each router listed, that router's
eligibility to become Designated Router must be defined.
When an interface to a NBMA network comes up, the router
sends Hello Packets only to those neighbors eligible to
become Designated Router, until the identity of the
Designated Router is discovered.
PollInterval
If a neighboring router has become inactive (Hello Packets
have not been seen for RouterDeadInterval seconds), it may
still be necessary to send Hello Packets to the dead
neighbor. These Hello Packets will be sent at the reduced
rate PollInterval, which should be much larger than
HelloInterval. Sample value for a PDN X.25 network: 2
minutes.
C.6 Point-to-MultiPoint network parameters
On Point-to-MultiPoint networks, it may be necessary to
configure the set of neighbors that are directly reachable over
the Point-to-MultiPoint network. Each neighbor is identified by
its IP address on the Point-to-MultiPoint network. Designated
Routers are not elected on Point-to-MultiPoint networks, so the
Designated Router eligibility of configured neighbors is
undefined.
Alternatively, neighbors on Point-to-MultiPoint networks may be
dynamically discovered by lower-level protocols such as Inverse
ARP ([Ref14]).
C.7 Host route parameters Host routes are advertised in router-LSAs as stub networks with mask 0xffffffff. They indicate either router interfaces to point-to-point networks, looped router interfaces, or IP hosts that are directly connected to the router (e.g., via a SLIP line). For each host directly connected to the router, the following items must be configured: Host IP address The IP address of the host. Cost of link to host The cost of sending a packet to the host, in terms of the link state metric. However, since the host probably has only a single connection to the internet, the actual configured cost in many cases is unimportant (i.e., will have no effect on routing). Area ID The OSPF area to which the host belongs.
D. Authentication All OSPF protocol exchanges are authenticated. The OSPF packet header (see Section A.3.1) includes an authentication type field, and 64-bits of data for use by the appropriate authentication scheme (determined by the type field). The authentication type is configurable on a per-interface (or equivalently, on a per-network/subnet) basis. Additional authentication data is also configurable on a per-interface basis. Authentication types 0, 1 and 2 are defined by this specification. All other authentication types are reserved for definition by the IANA (iana@ISI.EDU). The current list of authentication types is described below in Table 20. AuType Description ___________________________________________ 0 Null authentication 1 Simple password 2 Cryptographic authentication All others Reserved for assignment by the IANA (iana@ISI.EDU) Table 20: OSPF authentication types. D.1 Null authentication Use of this authentication type means that routing exchanges over the network/subnet are not authenticated. The 64-bit authentication field in the OSPF header can contain anything; it is not examined on packet reception. When employing Null authentication, the entire contents of each OSPF packet (other than the 64-bit authentication field) are checksummed in order to detect data corruption.
D.2 Simple password authentication Using this authentication type, a 64-bit field is configured on a per-network basis. All packets sent on a particular network must have this configured value in their OSPF header 64-bit authentication field. This essentially serves as a "clear" 64- bit password. In addition, the entire contents of each OSPF packet (other than the 64-bit authentication field) are checksummed in order to detect data corruption. Simple password authentication guards against routers inadvertently joining the routing domain; each router must first be configured with its attached networks' passwords before it can participate in routing. However, simple password authentication is vulnerable to passive attacks currently widespread in the Internet (see [Ref16]). Anyone with physical access to the network can learn the password and compromise the security of the OSPF routing domain. D.3 Cryptographic authentication Using this authentication type, a shared secret key is configured in all routers attached to a common network/subnet. For each OSPF protocol packet, the key is used to generate/verify a "message digest" that is appended to the end of the OSPF packet. The message digest is a one-way function of the OSPF protocol packet and the secret key. Since the secret key is never sent over the network in the clear, protection is provided against passive attacks. The algorithms used to generate and verify the message digest are specified implicitly by the secret key. This specification completely defines the use of OSPF Cryptographic authentication when the MD5 algorithm is used. In addition, a non-decreasing sequence number is included in each OSPF protocol packet to protect against replay attacks. This provides long term protection; however, it is still possible to replay an OSPF packet until the sequence number changes. To implement this feature, each neighbor data structure contains a new field called the "cryptographic sequence number". This field is initialized to zero, and is also set to zero
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Key ID | Auth Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cryptographic sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 18: Usage of the Authentication field in the OSPF packet header when Cryptographic Authentication is employed whenever the neighbor's state transitions to "Down". Whenever an OSPF packet is accepted as authentic, the cryptographic sequence number is set to the received packet's sequence number. This specification does not provide a rollover procedure for the cryptographic sequence number. When the cryptographic sequence number that the router is sending hits the maximum value, the router should reset the cryptographic sequence number that it is sending back to 0. After this is done, the router's neighbors will reject the router's OSPF packets for a period of RouterDeadInterval, and then the router will be forced to reestablish all adjacencies over the interface. However, it is expected that many implementations will use "seconds since reboot" (or "seconds since 1960", etc.) as the cryptographic sequence number. Such a choice will essentially prevent rollover, since the cryptographic sequence number field is 32 bits in length. The OSPF Cryptographic authentication option does not provide confidentiality. When cryptographic authentication is used, the 64-bit Authentication field in the standard OSPF packet header is redefined as shown in Figure 18. The new field definitions are as follows:
Key ID
This field identifies the algorithm and secret key used to
create the message digest appended to the OSPF packet. Key
Identifiers are unique per-interface (or equivalently, per-
subnet).
Auth Data Len
The length in bytes of the message digest appended to the
OSPF packet.
Cryptographic sequence number
An unsigned 32-bit non-decreasing sequence number. Used to
guard against replay attacks.
The message digest appended to the OSPF packet is not actually
considered part of the OSPF protocol packet: the message digest
is not included in the OSPF header's packet length, although it
is included in the packet's IP header length field.
Each key is identified by the combination of interface and Key
ID. An interface may have multiple keys active at any one time.
This enables smooth transition from one key to another. Each key
has four time constants associated with it. These time constants
can be expressed in terms of a time-of-day clock, or in terms of
a router's local clock (e.g., number of seconds since last
reboot):
KeyStartAccept
The time that the router will start accepting packets that
have been created with the given key.
KeyStartGenerate
The time that the router will start using the key for packet
generation.
KeyStopGenerate
The time that the router will stop using the key for packet
generation.
KeyStopAccept
The time that the router will stop accepting packets that
have been created with the given key.
In order to achieve smooth key transition, KeyStartAccept should
be less than KeyStartGenerate and KeyStopGenerate should be less
than KeyStopAccept. If KeyStopGenerate and KeyStopAccept are
left unspecified, the key's lifetime is infinite. When a new key
replaces an old, the KeyStartGenerate time for the new key must
be less than or equal to the KeyStopGenerate time of the old
key.
Key storage should persist across a system restart, warm or
cold, to avoid operational issues. In the event that the last
key associated with an interface expires, it is unacceptable to
revert to an unauthenticated condition, and not advisable to
disrupt routing. Therefore, the router should send a "last
authentication key expiration" notification to the network
manager and treat the key as having an infinite lifetime until
the lifetime is extended, the key is deleted by network
management, or a new key is configured.
D.4 Message generation
After building the contents of an OSPF packet, the
authentication procedure indicated by the sending interface's
Autype value is called before the packet is sent. The
authentication procedure modifies the OSPF packet as follows.
D.4.1 Generating Null authentication
When using Null authentication, the packet is modified as
follows:
(1) The Autype field in the standard OSPF header is set to
0.
(2) The checksum field in the standard OSPF header is set to
the standard IP checksum of the entire contents of the
packet, starting with the OSPF packet header but
excluding the 64-bit authentication field. This
checksum is calculated as the 16-bit one's complement of
the one's complement sum of all the 16-bit words in the
packet, excepting the authentication field. 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.
D.4.2 Generating Simple password authentication
When using Simple password authentication, the packet is
modified as follows:
(1) The Autype field in the standard OSPF header is set to
1.
(2) The checksum field in the standard OSPF header is set to
the standard IP checksum of the entire contents of the
packet, starting with the OSPF packet header but
excluding the 64-bit authentication field. This
checksum is calculated as the 16-bit one's complement of
the one's complement sum of all the 16-bit words in the
packet, excepting the authentication field. 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.
(3) The 64-bit authentication field in the OSPF packet
header is set to the 64-bit password (i.e.,
authentication key) that has been configured for the
interface.
D.4.3 Generating Cryptographic authentication
When using Cryptographic authentication, there may be
multiple keys configured for the interface. In this case,
among the keys that are valid for message generation (i.e,
that have KeyStartGenerate <= current time <
KeyStopGenerate) choose the one with the most recent
KeyStartGenerate time. Using this key, modify the packet as
follows:
(1) The Autype field in the standard OSPF header is set to
2.
(2) The checksum field in the standard OSPF header is not
calculated, but is instead set to 0.
(3) The Key ID (see Figure 18) is set to the chosen key's
Key ID.
(4) The Auth Data Len field is set to the length in bytes of
the message digest that will be appended to the OSPF
packet. When using MD5 as the authentication algorithm,
Auth Data Len will be 16.
(5) The 32-bit Cryptographic sequence number (see Figure 18)
is set to a non-decreasing value (i.e., a value at least
as large as the last value sent out the interface). The
precise values to use in the cryptographic sequence
number field are implementation-specific. For example,
it may be based on a simple counter, or be based on the
system's clock.
(6) The message digest is then calculated and appended to
the OSPF packet. The authentication algorithm to be
used in calculating the digest is indicated by the key
itself. Input to the authentication algorithm consists
of the OSPF packet and the secret key. When using MD5 as
the authentication algorithm, the message digest
calculation proceeds as follows:
(a) The 16 byte MD5 key is appended to the OSPF packet.
(b) Trailing pad and length fields are added, as
specified in [Ref17].
(c) The MD5 authentication algorithm is run over the
concatenation of the OSPF packet, secret key, pad
and length fields, producing a 16 byte message
digest (see [Ref17]).
(d) The MD5 digest is written over the OSPF key (i.e.,
appended to the original OSPF packet). The digest is
not counted in the OSPF packet's length field, but
is included in the packet's IP length field. Any
trailing pad or length fields beyond the digest are
not counted or transmitted.
D.5 Message verification
When an OSPF packet has been received on an interface, it must
be authenticated. The authentication procedure is indicated by
the setting of Autype in the standard OSPF packet header, which
matches the setting of Autype for the receiving OSPF interface.
If an OSPF protocol packet is accepted as authentic, processing
of the packet continues as specified in Section 8.2. Packets
which fail authentication are discarded.
D.5.1 Verifying Null authentication
When using Null authentication, the checksum field in the
OSPF header must be verified. It must be set to the 16-bit
one's complement of the one's complement sum of all the 16-
bit words in the packet, excepting the authentication field.
(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.)
D.5.2 Verifying Simple password authentication
When using Simple password authentication, the received OSPF
packet is authenticated as follows:
(1) The checksum field in the OSPF header must be verified.
It must be set to the 16-bit one's complement of the
one's complement sum of all the 16-bit words in the
packet, excepting the authentication field. (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.)
(2) The 64-bit authentication field in the OSPF packet
header must be equal to the 64-bit password (i.e.,
authentication key) that has been configured for the
interface.
D.5.3 Verifying Cryptographic authentication When using Cryptographic authentication, the received OSPF packet is authenticated as follows: (1) Locate the receiving interface's configured key having Key ID equal to that specified in the received OSPF packet (see Figure 18). If the key is not found, or if the key is not valid for reception (i.e., current time < KeyStartAccept or current time >= KeyStopAccept), the OSPF packet is discarded. (2) If the cryptographic sequence number found in the OSPF header (see Figure 18) is less than the cryptographic sequence number recorded in the sending neighbor's data structure, the OSPF packet is discarded. (3) Verify the appended message digest in the following steps: (a) The received digest is set aside. (b) A new digest is calculated, as specified in Step 6 of Section D.4.3. (c) The calculated and received digests are compared. If they do not match, the OSPF packet is discarded. If they do match, the OSPF protocol packet is accepted as authentic, and the "cryptographic sequence number" in the neighbor's data structure is set to the sequence number found in the packet's OSPF header.
E. An algorithm for assigning Link State IDs The Link State ID in AS-external-LSAs and summary-LSAs is usually set to the described network's IP address. However, if necessary one or more of the network's host bits may be set in the Link State ID. This allows the router to originate separate LSAs for networks having the same address, yet different masks. Such networks can occur in the presence of supernetting and subnet 0s (see [Ref10]). This appendix gives one possible algorithm for setting the host bits in Link State IDs. The choice of such an algorithm is a local decision. Separate routers are free to use different algorithms, since the only LSAs affected are the ones that the router itself originates. The only requirement on the algorithms used is that the network's IP address should be used as the Link State ID whenever possible; this maximizes interoperability with OSPF implementations predating RFC 1583. The algorithm below is stated for AS-external-LSAs. This is only for clarity; the exact same algorithm can be used for summary-LSAs. Suppose that the router wishes to originate an AS-external-LSA for a network having address NA and mask NM1. The following steps are then used to determine the LSA's Link State ID: (1) Determine whether the router is already originating an AS- external-LSA with Link State ID equal to NA (in such an LSA the router itself will be listed as the LSA's Advertising Router). If not, the Link State ID is set equal to NA and the algorithm terminates. Otherwise, (2) Obtain the network mask from the body of the already existing AS-external-LSA. Call this mask NM2. There are then two cases: o NM1 is longer (i.e., more specific) than NM2. In this case, set the Link State ID in the new LSA to be the network [NA,NM1] with all the host bits set (i.e., equal to NA or'ed together with all the bits that are not set in NM1, which is network [NA,NM1]'s broadcast address). o NM2 is longer than NM1. In this case, change the existing LSA (having Link State ID of NA) to reference the new network [NA,NM1] by incrementing the sequence number,
changing the mask in the body to NM1 and inserting the cost
of the new network. Then originate a new LSA for the old
network [NA,NM2], with Link State ID equal to NA or'ed
together with the bits that are not set in NM2 (i.e.,
network [NA,NM2]'s broadcast address).
The above algorithm assumes that all masks are contiguous; this
ensures that when two networks have the same address, one mask is
more specific than the other. The algorithm also assumes that no
network exists having an address equal to another network's
broadcast address. Given these two assumptions, the above algorithm
always produces unique Link State IDs. The above algorithm can also
be reworded as follows: When originating an AS-external-LSA, try to
use the network number as the Link State ID. If that produces a
conflict, examine the two networks in conflict. One will be a subset
of the other. For the less specific network, use the network number
as the Link State ID and for the more specific use the network's
broadcast address instead (i.e., flip all the "host" bits to 1). If
the most specific network was originated first, this will cause you
to originate two LSAs at once.
As an example of the algorithm, consider its operation when the
following sequence of events occurs in a single router (Router A).
(1) Router A wants to originate an AS-external-LSA for
[10.0.0.0,255.255.255.0]:
(a) A Link State ID of 10.0.0.0 is used.
(2) Router A then wants to originate an AS-external-LSA for
[10.0.0.0,255.255.0.0]:
(a) The LSA for [10.0.0,0,255.255.255.0] is reoriginated using a
new Link State ID of 10.0.0.255.
(b) A Link State ID of 10.0.0.0 is used for
[10.0.0.0,255.255.0.0].
(3) Router A then wants to originate an AS-external-LSA for
[10.0.0.0,255.0.0.0]:
(a) The LSA for [10.0.0.0,255.255.0.0] is reoriginated using a
new Link State ID of 10.0.255.255.
(b) A Link State ID of 10.0.0.0 is used for
[10.0.0.0,255.0.0.0].
(c) The network [10.0.0.0,255.255.255.0] keeps its Link State ID
of 10.0.0.255.
F. Multiple interfaces to the same network/subnet There are at least two ways to support multiple physical interfaces to the same IP subnet. Both methods will interoperate with implementations of RFC 1583 (and of course this memo). The two methods are sketched briefly below. An assumption has been made that each interface has been assigned a separate IP address (otherwise, support for multiple interfaces is more of a link-level or ARP issue than an OSPF issue). Method 1: Run the entire OSPF functionality over both interfaces, sending and receiving hellos, flooding, supporting separate interface and neighbor FSMs for each interface, etc. When doing this all other routers on the subnet will treat the two interfaces as separate neighbors, since neighbors are identified (on broadcast and NBMA networks) by their IP address. Method 1 has the following disadvantages: (1) You increase the total number of neighbors and adjacencies. (2) You lose the bidirectionality test on both interfaces, since bidirectionality is based on Router ID. (3) You have to consider both interfaces together during the Designated Router election, since if you declare both to be DR simultaneously you can confuse the tie-breaker (which is Router ID). Method 2: Run OSPF over only one interface (call it the primary interface), but include both the primary and secondary interfaces in your Router-LSA. Method 2 has the following disadvantages: (1) You lose the bidirectionality test on the secondary interface. (2) When the primary interface fails, you need to promote the secondary interface to primary status.
G. Differences from RFC 2178 This section documents the differences between this memo and RFC 2178. All differences are backward-compatible. Implementations of this memo and of RFCs 2178, 1583, and 1247 will interoperate. G.1 Flooding modifications Three changes have been made to the flooding procedure in Section 13. The first change is to step 4 in Section 13. Now MaxAge LSAs are acknowledged and then discarded only when both a) there is no database copy of the LSA and b) none of router's neighbors are in states Exchange or Loading. In all other cases, the MaxAge LSA is processed like any other LSA, installing the LSA in the database and flooding it out the appropriate interfaces when the LSA is more recent than the database copy (Step 5 of Section 13). This change also affects the contents of Table 19. The second change is to step 5a in Section 13. The MinLSArrival check is meant only for LSAs received during flooding, and should not be performed on those LSAs that the router itself originates. The third change is to step 8 in Section 13. Confusion between routers as to which LSA instance is more recent can cause a disastrous amount of flooding in a link-state protocol (see [Ref26]). OSPF guards against this problem in two ways: a) the LS age field is used like a TTL field in flooding, to eventually remove looping LSAs from the network (see Section 13.3), and b) routers refuse to accept LSA updates more frequently than once every MinLSArrival seconds (see Section 13). However, there is still one case in RFC 2178 where disagreements regarding which LSA is more recent can cause a lot of flooding traffic: responding to old LSAs by reflooding the database copy. For this reason, Step 8 of Section 13 has been amended to only respond with the database copy when that copy has not been sent in any Link State Update within the last MinLSArrival seconds.
G.2 Changes to external path preferences There is still the possibility of a routing loop in RFC 2178 when both a) virtual links are in use and b) the same external route is being imported by multiple ASBRs, each of which is in a separate area. To fix this problem, Section 16.4.1 has been revised. To choose the correct ASBR/forwarding address, intra- area paths through non-backbone areas are always preferred. However, intra-area paths through the backbone area (Area 0) and inter-area paths are now of equal preference, and must be compared solely based on cost. The reasoning behind this change is as follows. When virtual links are in use, an intra-area backbone path for one router can turn into an inter-area path in a router several hops closer to the destination. Hence, intra-area backbone paths and inter-area paths must be of equal preference. We can safely compare their costs, preferring the path with the smallest cost, due to the calculations in Section 16.3. Thanks to Michael Briggs and Jeremy McCooey of the UNH InterOperability Lab for pointing out this problem. G.3 Incomplete resolution of virtual next hops One of the functions of the calculation in Section 16.3 is to determine the actual next hop(s) for those destinations whose next hop was calculated as a virtual link in Sections 16.1 and 16.2. After completion of the calculation in Section 16.3, any paths calculated in Sections 16.1 and 16.2 that still have unresolved virtual next hops should be discarded. G.4 Routing table lookup The routing table lookup algorithm in Section 11.1 has been modified to reflect current practice. The "best match" routing table entry is now always selected to be the one providing the most specific (longest) match. Suppose for example a router is forwarding packets to the destination 192.9.1.1. A routing table entry for 192.9.1/24 will always be a better match than the routing table entry for 192.9/16, regardless of the routing table entries' path-types. Note however that when multiple paths
are available for a given routing table entry, the calculations
in Sections 16.1, 16.2, and 16.4 always yield the paths having
the most preferential path-type. (Intra-area paths are the most
preferred, followed in order by inter-area, type 1 external and
type 2 external paths; see Section 11).
Security Considerations All OSPF protocol exchanges are authenticated. OSPF supports multiple types of authentication; the type of authentication in use can be configured on a per network segment basis. One of OSPF's authentication types, namely the Cryptographic authentication option, is believed to be secure against passive attacks and provide significant protection against active attacks. When using the Cryptographic authentication option, each router appends a "message digest" to its transmitted OSPF packets. Receivers then use the shared secret key and received digest to verify that each received OSPF packet is authentic. The quality of the security provided by the Cryptographic authentication option depends completely on the strength of the message digest algorithm (MD5 is currently the only message digest algorithm specified), the strength of the key being used, and the correct implementation of the security mechanism in all communicating OSPF implementations. It also requires that all parties maintain the secrecy of the shared secret key. None of the OSPF authentication types provide confidentiality. Nor do they protect against traffic analysis. Key management is also not addressed by this memo. For more information, see Sections 8.1, 8.2, and Appendix D. Author's Address John Moy Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886 Phone: 978-952-1367 Fax: 978-392-2075 EMail: jmoy@casc.com
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.