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 126.96.36.199. 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
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: email@example.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.