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 Host route parameters
Host routes are advertised in router links advertisements 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. There may be multiple costs configured,
one for each IP TOS. However, since the host probably has
only a single connection to the internet, the actual
configured cost(s) in many cases is unimportant (i.e., will
have no effect on routing).
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-area basis.
Additional authentication data is configurable on a per-interface
basis. For example, if an area uses a simple password scheme for
authentication, a separate password may be configured for each
network contained in the area.
Authentication types 0 and 1 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 No authentication
1 Simple password
All others Reserved for assignment by the
IANA (iana@ISI.EDU)
Table 20: OSPF authentication types.
D.1 AuType 0 -- No authentication
Use of this authentication type means that routing exchanges in
the area are not authenticated. The 64-bit field in the OSPF
header can contain anything; it is not examined on packet
reception.
D.2 AuType 1 -- Simple password
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.
This guards against routers inadvertently joining the area.
They must first be configured with their attached networks'
passwords before they can participate in the routing domain.
E. Differences from RFC1247
This section documents the differences between this memo and RFC
1247. These differences include a fix for a problem involving OSPF
virtual links, together with minor enhancements and clarifications
to the protocol. All differences are backward-compatible.
Implementations of this memo and of RFC1247 will interoperate.
E.1 A fix for a problem with OSPF Virtual links
In RFC1247, certain configurations of OSPF virtual links can
cause routing loops. The root of the problem is that while there
is an information mismatch at the boundary of any virtual link's
Transit area, a backbone path can still cross the boundary. RFC
1247 attempted to compensate for this information mismatch by
adjusting any backbone path as it enters the transit area (see
Section 16.3 in RFC1247). However, this proved not to be
enough. This memo fixes the problem by having all area border
routers determine, by looking at summary links, whether better
backbone paths can be found through the transit areas.
This fix simplifies the OSPF virtual link logic, and consists of
the following components:
o A new bit has been defined in the router links
advertisement, called bit V. Bit V is set in a router's
router links advertisement for Area A if and only if the
router is an endpoint of an active virtual link that uses
Area A as its Transit area (see Sections 12.4.1 and A.4.2).
This enables the other routers attached to Area A to
discover whether the area supports any virtual links (i.e.,
is a transit area). This discovery is done during the
calculation of Area A's shortest-path tree (see Section
16.1).
o To aid in the description of the algorithm, a new parameter
has been added to the OSPF area structure:
TransitCapability. This parameter indicates whether the area
supports any active virtual links. Equivalently, it
indicates whether the area can carry traffic that neither
originates nor terminates in the area itself.
o The calculation in Section 16.3 of RFC1247 has been
replaced. The new calculation, performed by area border
routers only, examines the summary links belonging to all
attached transit areas to see whether the transit areas can
provide better paths than those already found in Sections
16.1 and 16.2.
o The incremental calculations in Section 16.5 have been
updated as a result of the new calculations in Section 16.3.
E.2 Supporting supernetting and subnet 0
In RFC1247, an OSPF router cannot originate separate AS
external link advertisements (or separate summary link
advertisements) for two networks that have the same address but
different masks. This situation can arise when subnet 0 of a
network has been assigned (a practice that is generally
discouraged), or when using supernetting as described in [RFC
1519] (a practice that is generally encouraged to reduce the
size of routing tables), or even when in transition from one
mask to another on a subnet. Using supernetting as an example,
you might want to aggregate the four class C networks
192.9.4.0-192.9.7.0, advertising one route for the aggregation
and another for the single class C network 192.9.4.0.
The reason behind this limitation is that in RFC1247, the Link
State ID of AS external link advertisements and summary link
advertisements is set equal to the described network's IP
address. In the above example, RFC1247 would assign both
advertisements the Link State ID of 192.9.4.0, making them in
essence the same advertisement. This memo fixes the problem by
relaxing the setting of the Link State ID so that any of the
"host" bits of the network address can also be set. This allows
you to disambiguate advertisements for networks having the same
address but different masks. Given an AS external link
advertisement (or a summary link advertisement), the described
network's address can now be obtained by masking the Link State
ID with the network mask carried in the body of the
advertisement. Again using the above example, the aggregate can
now be advertised using a Link State ID of 192.9.4.0 and the
single class C network advertised simultaneously using the Link
State ID of 192.9.4.255.
Appendix F gives one possible algorithm for setting one or more
"host" bits in the Link State ID in order to disambiguate
advertisements. It should be noted that this is a local
decision. Each router in an OSPF system is free to use its own
algorithm, since only those advertisements originated by the
router itself are affected.
It is believed that this change will be more or less compatible
with implementations of RFC1247. Implementations of RFC1247
will probably either a) install routing table entries that won't
be used or b) do the correct processing as outlined in this memo
or c) mark the advertisement as unusable when presented with a
Link State ID that has one or more of the host bits set.
However, in the interest of interoperability, implementations of
this memo should only set the host bits in Link State IDs when
absolutely necessary.
The change affects Sections 12.1.4, 12.4.3, 12.4.5, 16.2, 16.3,
16.4, 16.5, 16.6, A.4.4 and A.4.5.
E.3 Obsoleting LSInfinity in router links advertisements
The metric of LSInfinity can no longer be used in router links
advertisements to indicate unusable links. This is being done
for several reasons:
o It removes any possible confusion in an OSPF area as to just
which routers/networks are reachable in the area. For
example, the above virtual link fix relies on detecting the
existence of virtual links when running the Dijkstra.
However, when one-directional links (i.e., cost of
LSInfinity in one direction, but not the other) are
possible, some routers may detect the existence of virtual
links while others may not. This may defeat the fix for the
virtual link problem.
o It also helps OSPF's Multicast routing extensions (MOSPF),
because one-way reachability can lead to places that are
reachable via unicast but not multicast, or vice versa.
The two prior justifications for using LSInfinity in router
links advertisements were 1) it was a way to not support TOS
before TOS was optional and 2) it went along with strong TOS
interpretations. These justifications are no longer valid.
However, LSInfinity will continue to mean "unreachable" in
summary link advertisements and AS external link advertisements,
as some implementations use this as an alternative to the
premature aging procedure specified in Section 14.1.
This change has one other side effect. When two routers are
connected via a virtual link whose underlying path is non-TOS-
capable, they must now revert to being non-TOS-capable routers
themselves, instead of the previous behavior of advertising the
non-zero TOS costs of the virtual link as LSInfinity. See
Section 15 for details.
E.4 TOS encoding updated
The encoding of TOS in OSPF link state advertisements has been
updated to reflect the new TOS value (minimize monetary cost)
defined by [RFC1349]. The OSPF encoding is defined in Section
12.3, which is identical in content to Section A.5 of [RFC
1349].
E.5 Summarizing routes into transit areas
RFC1247 mandated that routes associated with Area A are never
summarized back into Area A. However, this memo further reduces
the number of summary links originated by refusing to summarize
into Area A those routes having next hops belonging to Area A.
This is an optimization over RFC1247 behavior when virtual
links are present. For example, in the area configuration of
Figure 6, Router RT11 need only originate a single summary link
having the (collapsed) destination N9-N11,H1 into its connected
transit area Area 2, since all of its other eligible routes have
next hops belonging to Area 2 (and as such only need be
advertised by other area border routers; in this case, Routers
RT10 and RT7). This is the logical equivalent of a Distance
Vector protocol's split horizon logic.
This change appears in Section 12.4.3.
E.6 Summarizing routes into stub areas
RFC1247 mandated that area border routers attached to stub
areas must summarize all inter-area routes into the stub areas.
However, while area border routers connected to OSPF stub areas
must originate default summary links into the stub area, they
need not summarize other routes into the stub area. The amount
of summarization done into stub areas can instead be put under
configuration control. The network administrator can then make
the trade-off between optimal routing and database size.
This change appears in Sections 12.4.3 and 12.4.4.
E.7 Flushing anomalous network links advertisements
Text was added indicating that a network links advertisement
whose Link State ID is equal to one of the router's own IP
interface addresses should be considered to be self-originated,
regardless of the setting of the advertisement's Advertising
Router. If the Advertising Router of such an advertisement is
not equal to the router's own Router ID, the advertisement
should be flushed from the routing domain using the premature
aging procedure specified in Section 14.1. This case should be
rare, and it indicates that the router's Router ID has changed
since originating the advertisement.
Failure to flush these anomalous advertisements could lead to
multiple network links advertisements having the same Link State
ID. This in turn could cause the Dijkstra calculation in Section
16.1 to fail, since it would be impossible to tell which network
links advertisement is valid (i.e., more recent).
This change appears in Sections 13.4 and 14.1.
E.8 Required Statistics appendix deleted
Appendix D of RFC1247, which specified a list of required
statistics for an OSPF implementation, has been deleted. That
appendix has been superseded by the two documents: the OSPF
Version 2 Management Information Base and the OSPF Version 2
Traps.
E.9 Other changes
The following small changes were also made to RFC1247:
o When representing unnumbered point-to-point networks in
router links advertisements, the corresponding Link Data
field should be set to the unnumbered interface's MIB-II
[RFC1213] ifIndex value.
o A comment was added to Step 3 of the Dijkstra algorithm in
Section 16.1. When removing vertices from the candidate
list, and when there is a choice of vertices closest to the
root, network vertices must be chosen before router vertices
in order to necessarily find all equal-cost paths.
o A comment was added to Section 12.4.3 noting that a summary
link advertisement cannot express a reachable destination
whose path cost equals or exceeds LSInfinity.
o A comment was added to Section 15 noting that a virtual link
whose underlying path has cost greater than hexadecimal
0xffff (the maximum size of an interface cost in a router
links advertisement) should be considered inoperational.
o An option was added to the definition of area address
ranges, allowing the network administrator to specify that a
particular range should not be advertised to other OSPF
areas. This enables the existence of certain networks to be
hidden from other areas. This change appears in Sections
12.4.3 and C.2.
o A note was added reminding implementors that bit E (the AS
boundary router indication) should never be set in a router
links advertisement for a stub area, since stub areas cannot
contain AS boundary routers. This change appears in Section
12.4.1.
F. An algorithm for assigning Link State IDs
In RFC1247, the Link State ID in AS external link advertisements
and summary link advertisements is set to the described network's IP
address. This memo relaxes that requirement, allowing one or more of
the network's host bits to be set in the Link State ID. This allows
the router to originate separate advertisements for networks having
the same addresses, yet different masks. Such networks can occur in
the presence of supernetting and subnet 0s (see Section E.2 for more
information).
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 advertisements 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
(the RFC1247 behavior) whenever possible.
The algorithm below is stated for AS external link advertisements.
This is only for clarity; the exact same algorithm can be used for
summary link advertisements. Suppose that the router wishes to
originate an AS external link advertisement for a network having
address NA and mask NM1. The following steps are then used to
determine the advertisement's Link State ID:
(1) Determine whether the router is already originating an AS
external link advertisement with Link State ID equal to NA (in
such an advertisement the router itself will be listed as the
advertisement's Advertising Router). If not, set the Link State
ID equal to NA (the RFC1247 behavior) and the algorithm
terminates. Otherwise,
(2) Obtain the network mask from the body of the already existing AS
external link advertisement. 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 advertisement 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
advertisement (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 using the cost for
the new network. Then originate a new advertisement 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 link state
advertisement, 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 link state
advertisements 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 link advertisement
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 link
advertisement for [10.0.0.0,255.255.0.0]:
(a) The advertisement 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 link
advertisement for [10.0.0.0,255.0.0.0]:
(a) The advertisement 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.
Security Considerations
All OSPF protocol exchanges are authenticated. This is accomplished
through authentication fields contained in the OSPF packet header.
For more information, see Sections 8.1, 8.2, and Appendix D.
Author's Address
John Moy
Proteon, Inc.
9 Technology Drive
Westborough, MA 01581
Phone: 508-898-2800
Fax: 508-898-3176
Email: jmoy@proteon.com