RFC 2740
OSPF for IPv6
A. OSPF data formats
This appendix describes the format of OSPF protocol packets and OSPF LSAs. The OSPF protocol runs directly over the IPv6 network layer. Before any data formats are described, the details of the OSPF encapsulation are explained. Next the OSPF Options field is described. This field describes various capabilities that may or may not be supported by pieces of the OSPF routing domain. The OSPF Options field is contained in OSPF Hello packets, Database Description packets and in OSPF LSAs. OSPF packet formats are detailed in Section A.3. A description of OSPF LSAs appears in Section A.4. This section describes how IPv6 address prefixes are represented within LSAs, details the standard LSA header, and then provides formats for each of the specific LSA types.A.1 Encapsulation of OSPF packets
OSPF runs directly over the IPv6's network layer. OSPF packets are therefore encapsulated solely by IPv6 and local data-link headers. OSPF does not define a way to fragment its protocol packets, and depends on IPv6 fragmentation when transmitting packets larger than the link MTU. If necessary, the length of OSPF packets can be up to 65,535 bytes. The OSPF packet types that are likely to be large (Database Description Packets, Link State Request, Link State Update, and Link State Acknowledgment packets) can usually be split into several separate protocol packets, without loss of functionality. This is recommended; IPv6 fragmentation should be avoided whenever possible. Using this reasoning, an attempt should be made to limit the sizes of OSPF packets sent over virtual links to 1280 bytes unless Path MTU Discovery is being performed [Ref14]. The other important features of OSPF's IPv6 encapsulation are: o Use of IPv6 multicast. Some OSPF messages are multicast, when sent over broadcast networks. Two distinct IP multicast addresses are used. Packets sent to these multicast addresses should never be forwarded; they are meant to travel a single hop only. As such, the multicast addresses have been chosen with link-local scope, and packets sent to these addresses should have their IPv6 Hop Limit set to 1.
AllSPFRouters
This multicast address has been assigned the value FF02::5. All
routers running OSPF should be prepared to receive packets sent to
this address. Hello packets are always sent to this destination.
Also, certain OSPF protocol packets are sent to this address
during the flooding procedure.
AllDRouters
This multicast address has been assigned the value FF02::6. Both
the Designated Router and Backup Designated Router must be
prepared to receive packets destined to this address. Certain
OSPF protocol packets are sent to this address during the flooding
procedure.
o OSPF is IP protocol 89. This number should be inserted in the
Next Header field of the encapsulating IPv6 header.
A.2 The Options field
The 24-bit OSPF Options field is present in OSPF Hello packets,
Database Description packets and certain LSAs (router-LSAs, network-
LSAs, inter-area-router-LSAs and link-LSAs). The Options field
enables OSPF routers to support (or not support) optional
capabilities, and to communicate their capability level to other OSPF
routers. Through this mechanism routers of differing capabilities
can be mixed within an OSPF routing domain.
An option mismatch between routers can cause a variety of behaviors,
depending on the particular option. Some option mismatches prevent
neighbor relationships from forming (e.g., the E-bit below); these
mismatches are discovered through the sending and receiving of Hello
packets. Some option mismatches prevent particular LSA types from
being flooded across adjacencies (e.g., the MC-bit below); these are
discovered through the sending and receiving of Database Description
packets. Some option mismatches prevent routers from being included
in one or more of the various routing calculations because of their
reduced functionality (again the MC-bit is an example); these
mismatches are discovered by examining LSAs.
Six bits of the OSPF Options field have been assigned. Each bit is
described briefly below. Routers should reset (i.e. clear)
unrecognized bits in the Options field when sending Hello packets or
Database Description packets and when originating LSAs. Conversely,
routers encountering unrecognized Option bits in received Hello
Packets, Database Description packets or LSAs should ignore the
capability and process the packet/LSA normally.
1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+
| | | | | | | | | | | | | | | | | |DC| R| N|MC| E|V6|
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+
The Options field
V6-bit
If this bit is clear, the router/link should be excluded from IPv6
routing calculations. See Section 3.8 of this memo.
E-bit
This bit describes the way AS-external-LSAs are flooded, as
described in Sections 3.6, 9.5, 10.8 and 12.1.2 of [Ref1].
MC-bit
This bit describes whether IP multicast datagrams are forwarded
according to the specifications in [Ref7].
N-bit
This bit describes the handling of Type-7 LSAs, as specified in
[Ref8].
R-bit
This bit (the `Router' bit) indicates whether the originator is an
active router. If the router bit is clear routes which transit the
advertising node cannot be computed. Clearing the router bit would
be appropriate for a multi-homed host that wants to participate in
routing, but does not want to forward non-locally addressed
packets.
DC-bit
This bit describes the router's handling of demand circuits, as
specified in [Ref10].
A.3 OSPF Packet Formats
There are five distinct OSPF packet types. All OSPF packet types
begin with a standard 16 byte header. This header is described
first. Each packet type is then described in a succeeding section.
In these sections each packet's division into fields is displayed,
and then the field definitions are enumerated.
All OSPF packet types (other than the OSPF Hello packets) deal with
lists of LSAs. For example, Link State Update packets implement the
flooding of LSAs throughout the OSPF routing domain. The format of
LSAs is described in Section A.4.
The receive processing of OSPF packets is detailed in Section 3.2.2. The sending of OSPF packets is explained in Section 3.2.1.A.3.1 The OSPF packet header
Every OSPF packet starts with a standard 16 byte header. Together with the encapsulating IPv6 headers, the OSPF header contains all the information necessary to determine whether the packet should be accepted for further processing. This determination is described in Section 3.2.2 of this memo. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version # | Type | Packet length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Instance ID | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version # The OSPF version number. This specification documents version 3 of the OSPF protocol. Type The OSPF packet types are as follows. See Sections A.3.2 through A.3.6 for details. Type Description --------------------------------- 1 Hello 2 Database Description 3 Link State Request 4 Link State Update 5 Link State Acknowledgment Packet length The length of the OSPF protocol packet in bytes. This length includes the standard OSPF header. Router ID The Router ID of the packet's source.
Area ID
A 32 bit number identifying the area that this packet belongs to.
All OSPF packets are associated with a single area. Most travel
a single hop only. Packets travelling over a virtual link are
labelled with the backbone Area ID of 0.
Checksum
OSPF uses the standard checksum calculation for IPv6
applications: The 16-bit one's complement of the one's complement
sum of the entire contents of the packet, starting with the OSPF
packet header, and prepending a "pseudo-header" of IPv6 header
fields, as specified in [Ref14, section 8.1]. The "Upper-Layer
Packet Length" in the pseudo-header is set to value of the OSPF
packet header's length field. The Next Header value used in the
pseudo-header is 89. If the packet's length is not an integral
number of 16-bit words, the packet is padded with a byte of zero
before checksumming. Before computing the checksum, the checksum
field in the OSPF packet header is set to 0.
Instance ID
Enables multiple instances of OSPF to be run over a single link.
Each protocol instance would be assigned a separate Instance ID;
the Instance ID has local link significance only. Received
packets whose Instance ID is not equal to the receiving
interface's Instance ID are discarded.
0 These fields are reserved. They must be 0.
A.3.2 The Hello packet
Hello packets are OSPF packet type 1. These packets are sent
periodically on all interfaces (including virtual links) in order to
establish and maintain neighbor relationships. In addition, Hello
Packets are multicast on those links having a multicast or broadcast
capability, enabling dynamic discovery of neighboring routers.
All routers connected to a common link must agree on certain
parameters (HelloInterval and RouterDeadInterval). These parameters
are included in Hello packets, so that differences can inhibit the
forming of neighbor relationships. The Hello packet also contains
fields used in Designated Router election (Designated Router ID and
Backup Designated Router ID), and fields used to detect bi-
directionality (the Router IDs of all neighbors whose Hellos have
been recently received).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 1 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rtr Pri | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | RouterDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Designated Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Designated Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Interface ID
32-bit number uniquely identifying this interface among the
collection of this router's interfaces. For example, in some
implementations it may be possible to use the MIB-II IfIndex
([Ref3]).
Rtr Pri
This router's Router Priority. Used in (Backup) Designated
Router election. If set to 0, the router will be ineligible to
become (Backup) Designated Router.
Options
The optional capabilities supported by the router, as documented
in Section A.2.
HelloInterval
The number of seconds between this router's Hello packets.
RouterDeadInterval
The number of seconds before declaring a silent router down.
Designated Router ID
The identity of the Designated Router for this network, in the
view of the sending router. The Designated Router is identified
by its Router ID. Set to 0.0.0.0 if there is no Designated
Router.
Backup Designated Router ID
The identity of the Backup Designated Router for this network, in
the view of the sending router. The Backup Designated Router is
identified by its IP Router ID. Set to 0.0.0.0 if there is no
Backup Designated Router.
Neighbor ID
The Router IDs of each router from whom valid Hello packets have
been seen recently on the network. Recently means in the last
RouterDeadInterval seconds.
A.3.3 The Database Description packet
Database Description packets are OSPF packet type 2. These packets
are exchanged when an adjacency is being initialized. They describe
the contents of the link-state database. Multiple packets may be
used to describe the database. For this purpose a poll-response
procedure is used. One of the routers is designated to be the
master, the other the slave. The master sends Database Description
packets (polls) which are acknowledged by Database Description
packets sent by the slave (responses). The responses are linked to
the polls via the packets' DD sequence numbers.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 2 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface MTU | 0 |0|0|0|0|0|I|M|MS
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DD sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
The format of the Database Description packet is very similar to both
the Link State Request and Link State Acknowledgment packets. The
main part of all three is a list of items, each item describing a
piece of the link-state database. The sending of Database
Description Packets is documented in Section 10.8 of [Ref1]. The
reception of Database Description packets is documented in Section
10.6 of [Ref1].
Options
The optional capabilities supported by the router, as documented
in Section A.2.
Interface MTU
The size in bytes of the largest IPv6 datagram that can be sent
out the associated interface, without fragmentation. The MTUs
of common Internet link types can be found in Table 7-1 of
[Ref12]. Interface MTU should be set to 0 in Database Description
packets sent over virtual links.
I-bit
The Init bit. When set to 1, this packet is the first in the
sequence of Database Description Packets.
M-bit
The More bit. When set to 1, it indicates that more Database
Description Packets are to follow.
MS-bit
The Master/Slave bit. When set to 1, it indicates that the router
is the master during the Database Exchange process. Otherwise,
the router is the slave.
DD sequence number
Used to sequence the collection of Database Description Packets.
The initial value (indicated by the Init bit being set) should be
unique. The DD sequence number then increments until the complete
database description has been sent.
The rest of the packet consists of a (possibly partial) list of the
link-state database's pieces. Each LSA in the database is described
by its LSA header. The LSA header is documented in Section
A.4.1. It contains all the information required to uniquely identify
both the LSA and the LSA's current instance.
A.3.4 The Link State Request packet
Link State Request packets are OSPF packet type 3. After exchanging
Database Description packets with a neighboring router, a router may
find that parts of its link-state database are out-of-date. The Link
State Request packet is used to request the pieces of the neighbor's
database that are more up-to-date. Multiple Link State Request
packets may need to be used.
A router that sends a Link State Request packet has in mind the
precise instance of the database pieces it is requesting. Each
instance is defined by its LS sequence number, LS checksum, and LS
age, although these fields are not specified in the Link State
Request Packet itself. The router may receive even more recent
instances in response.
The sending of Link State Request packets is documented in Section
10.9 of [Ref1]. The reception of Link State Request packets is
documented in Section 10.7 of [Ref1].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 3 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Each LSA requested is specified by its LS type, Link State ID, and
Advertising Router. This uniquely identifies the LSA, but not its
instance. Link State Request packets are understood to be requests
for the most recent instance (whatever that might be).
A.3.5 The Link State Update packet
Link State Update packets are OSPF packet type 4. These packets
implement the flooding of LSAs. Each Link State Update packet
carries a collection of LSAs one hop further from their origin.
Several LSAs may be included in a single packet.
Link State Update packets are multicast on those physical networks
that support multicast/broadcast. In order to make the flooding
procedure reliable, flooded LSAs are acknowledged in Link State
Acknowledgment packets. If retransmission of certain LSAs is
necessary, the retransmitted LSAs are always carried by unicast Link
State Update packets. For more information on the reliable flooding
of LSAs, consult Section 3.5.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 4 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # LSAs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- +-+
| LSAs |
+- +-+
| ... |
# LSAs
The number of LSAs included in this update.
The body of the Link State Update packet consists of a list of LSAs.
Each LSA begins with a common 20 byte header, described in Section
A.4.2. Detailed formats of the different types of LSAs are described
in Section A.4.
A.3.6 The Link State Acknowledgment packet
Link State Acknowledgment Packets are OSPF packet type 5. To make
the flooding of LSAs reliable, flooded LSAs are explicitly
acknowledged. This acknowledgment is accomplished through the
sending and receiving of Link State Acknowledgment packets. The
sending of Link State Acknowledgement packets is documented in
Section 13.5 of [Ref1]. The reception of Link State Acknowledgement
packets is documented in Section 13.7 of [Ref1].
Multiple LSAs can be acknowledged in a single Link State
Acknowledgment packet. Depending on the state of the sending
interface and the sender of the corresponding Link State Update
packet, a Link State Acknowledgment packet is sent either to the
multicast address AllSPFRouters, to the multicast address
AllDRouters, or as a unicast (see Section 13.5 of [Ref1] for
details).
The format of this packet is similar to that of the Data Description
packet. The body of both packets is simply a list of LSA headers.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 5 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Each acknowledged LSA is described by its LSA header. The LSA header
is documented in Section A.4.2. It contains all the information
required to uniquely identify both the LSA and the LSA's current
instance.
A.4 LSA formats
This memo defines seven distinct types of LSAs. Each LSA begins with
a standard 20 byte LSA header. This header is explained in Section
A.4.2. Succeeding sections then diagram the separate LSA types.
Each LSA describes a piece of the OSPF routing domain. Every router
originates a router-LSA. A network-LSA is advertised for each link by
its Designated Router. A router's link-local addresses are advertised
to its neighbors in link-LSAs. IPv6 prefixes are advertised in
intra-area-prefix-LSAs, inter-area-prefix-LSAs and AS-external-LSAs.
Location of specific routers can be advertised across area boundaries
in inter-area-router-LSAs. 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 3.5
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 of [Ref1]). For the details of the routing table build process, see Section 3.8.A.4.1 IPv6 Prefix Representation
IPv6 addresses are bit strings of length 128. IPv6 routing algorithms, and OSPF for IPv6 in particular, advertise IPv6 address prefixes. IPv6 address prefixes are bit strings whose length ranges between 0 and 128 bits (inclusive). Within OSPF, IPv6 address prefixes are always represented by a combination of three fields: PrefixLength, PrefixOptions, and Address Prefix. PrefixLength is the length in bits of the prefix. PrefixOptions is an 8-bit field describing various capabilities associated with the prefix (see Section A.4.2). Address Prefix is an encoding of the prefix itself as an even multiple of 32-bit words, padding with zero bits as necessary; this encoding consumes (PrefixLength + 31) / 32) 32-bit words. The default route is represented by a prefix of length 0. Examples of IPv6 Prefix representation in OSPF can be found in Sections A.4.5, A.4.7, A.4.8 and A.4.9.A.4.1.1 Prefix Options
Each prefix is advertised along with an 8-bit field of capabilities. These serve as input to the various routing calculations, allowing, for example, certain prefixes to be ignored in some cases, or to be marked as not readvertisable in others. 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+ | | | | | P|MC|LA|NU| +--+--+--+--+--+--+--+--+ The Prefix Options field NU-bit The "no unicast" capability bit. If set, the prefix should be excluded from IPv6 unicast calculations, otherwise it should be included.
LA-bit
The "local address" capability bit. If set, the prefix is actually
an IPv6 interface address of the advertising router.
MC-bit
The "multicast" capability bit. If set, the prefix should be
included in IPv6 multicast routing calculations, otherwise it
should be excluded.
P-bit
The "propagate" bit. Set on NSSA area prefixes that should be
readvertised at the NSSA area border.
A.4.2 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 | LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LS age
The time in seconds since the LSA was originated.
LS type
The LS type field indicates the function performed by the LSA.
The high-order three bits of LS type encode generic properties of
the LSA, while the remainder (called LSA function code) indicate
the LSA's specific functionality. See Section A.4.2.1 for a
detailed description of LS type.
Link State ID
Together with LS type and Advertising Router, uniquely identifies
the LSA in the link-state database.
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 in
[Ref1] 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 in [Ref1] for more details.
length
The length in bytes of the LSA. This includes the 20 byte LSA
header.
A.4.2.1 LS type
The LS type field indicates the function performed by the LSA. The
high-order three bits of LS type encode generic properties of the
LSA, while the remainder (called LSA function code) indicate the
LSA's specific functionality. The format of the LS type is as
follows:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|U |S2|S1| LSA Function Code |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The U bit indicates how the LSA should be handled by a router which
does not recognize the LSA's function code. Its values are:
U-bit LSA Handling
-------------------------------------------------------------
0 Treat the LSA as if it had link-local flooding scope
1 Store and flood the LSA, as if type understood
The S1 and S2 bits indicate the flooding scope of the LSA. The values are: S2 S1 Flooding Scope --------------------------------------------------------------------- 0 0 Link-Local Scoping. Flooded only on link it is originated on. 0 1 Area Scoping. Flooded to all routers in the originating area 1 0 AS Scoping. Flooded to all routers in the AS 1 1 Reserved The LSA function codes are defined as follows. The origination and processing of these LSA function codes are defined elsewhere in this memo, except for the group-membership-LSA (see [Ref7]) and the Type- 7-LSA (see [Ref8]). Each LSA function code also implies a specific setting for the U, S1 and S2 bits, as shown below. LSA function code LS Type Description ---------------------------------------------------- 1 0x2001 Router-LSA 2 0x2002 Network-LSA 3 0x2003 Inter-Area-Prefix-LSA 4 0x2004 Inter-Area-Router-LSA 5 0x4005 AS-External-LSA 6 0x2006 Group-membership-LSA 7 0x2007 Type-7-LSA 8 0x0008 Link-LSA 9 0x2009 Intra-Area-Prefix-LSAA.4.3 Router-LSAs
Router-LSAs have LS type equal to 0x2001. Each router in an area originates one or more router-LSAs. The complete collection of router-LSAs originated by the router describe the state and cost of the router's interfaces to the area. For details concerning the construction of router-LSAs, see Section 3.4.3.1. Router-LSAs are flooded throughout a single area only.
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 |0|0|1| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |W|V|E|B| Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
A single router may originate one or more Router LSAs, distinguished
by their Link-State IDs (which are chosen arbitrarily by the
originating router). The Options field and V, E and B bits should be
the same in all Router LSAs from a single originator. However, in
the case of a mismatch the values in the LSA with the lowest Link
State ID take precedence. When more than one Router LSA is received
from a single router, the links are processed as if concatenated into
a single LSA.
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).
bit W
When set, the router is a wild-card multicast receiver. When
running MOSPF, these routers receive all multicast datagrams,
regardless of destination. See Sections 3, 4 and A.2 of [Ref8] for
details.
Options
The optional capabilities supported by the router, as documented
in Section A.2.
The following fields are used to describe each router interface. The
Type field indicates the kind of interface being described. It may
be an interface to a transit network, a point-to-point connection to
another router or a virtual link. The values of all the other fields
describing a router interface depend on the interface's Type field.
Type
The kind of interface being described. One of the following:
Type Description
---------------------------------------------------
1 Point-to-point connection to another router
2 Connection to a transit network
3 Reserved
4 Virtual link
Metric
The cost of using this router interface, for outbound traffic.
Interface ID
The Interface ID assigned to the interface being described. See
Sections 3.1.2 and C.3.
Neighbor Interface ID
The Interface ID the neighbor router (or the attached link's
Designated Router, for Type 2 interfaces) has been advertising
in hello packets sent on the attached link.
Neighbor Router ID
The Router ID the neighbor router (or the attached link's
Designated Router, for Type 2 interfaces).
For Type 2 links, the combination of Neighbor Interface ID and
Neighbor Router ID allows the network-LSA for the attached link
to be found in the link-state database.
A.4.4 Network-LSAs
Network-LSAs have LS type equal to 0x2002. A network-LSA is
originated for each broadcast and NBMA link in the area which
supports two or more routers. The network-LSA is originated by the
link's Designated Router. The LSA describes all routers attached to
the link, including the Designated Router itself. The LSA's Link
State ID field is set to the Interface ID that the Designated Router
has been advertising in Hello packets on the link.
The distance from the network to all attached routers is zero. This
is why the metric fields need not be specified in the network-LSA.
For details concerning the construction of network-LSAs, see Section
3.4.3.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 |0|0|1| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attached Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Attached Router
The Router IDs of each of the routers attached to the link.
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.5 Inter-Area-Prefix-LSAs
Inter-Area-Prefix-LSAs have LS type equal to 0x2003. These LSAs are are the IPv6 equivalent of OSPF for IPv4's type 3 summary-LSAs (see Section 12.4.3 of [Ref1]). Originated by area border routers, they describe routes to IPv6 address prefixes that belong to other areas. A separate Inter-Area-Prefix-LSA is originated for each IPv6 address prefix. For details concerning the construction of Inter-Area- Prefix-LSAs, see Section 3.4.3.3. For stub areas, Inter-Area-Prefix-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 Inter-Area-Prefix-LSA's PrefixLength is set to 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 |0|0|1| 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixLength | PrefixOptions | (0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Prefix | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Metric The cost of this route. Expressed in the same units as the interface costs in the router-LSAs. When the Inter-Area-Prefix-LSA is describing a route to a range of addresses (see Section C.2) the cost is set to the maximum cost to any reachable component of the address range. PrefixLength, PrefixOptions and Address Prefix Representation of the IPv6 address prefix, as described in Section A.4.1.
A.4.6 Inter-Area-Router-LSAs
Inter-Area-Router-LSAs have LS type equal to 0x2004. These LSAs are are the IPv6 equivalent of OSPF for IPv4's type 4 summary-LSAs (see Section 12.4.3 of [Ref1]). Originated by area border routers, they describe routes to routers in other areas. (To see why it is necessary to advertise the location of each ASBR, consult Section 16.4 in [Ref1].) Each LSA describes a route to a single router. For details concerning the construction of Inter-Area-Router-LSAs, see Section 3.4.3.4. 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 |0|0|1| 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Options The optional capabilities supported by the router, as documented in Section A.2. Metric The cost of this route. Expressed in the same units as the interface costs in the router-LSAs. Destination Router ID The Router ID of the router being described by the LSA.
A.4.7 AS-external-LSAs
AS-external-LSAs have LS type equal to 0x4005. These LSAs are originated by AS boundary routers, and describe destinations external to the AS. Each LSA describes a route to a single IPv6 address prefix. For details concerning the construction of AS-external-LSAs, see Section 3.4.3.5. AS-external-LSAs can be used to describe a default route. Default routes are used when no specific route exists to the destination. When describing a default route, the AS-external-LSA's PrefixLength is set to 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 |0|1|0| 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |E|F|T| Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixLength | PrefixOptions | Referenced LS Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Prefix | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- -+ | | +- Forwarding Address (Optional) -+ | | +- -+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | External Route Tag (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Referenced Link State ID (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 intra-AS 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).
bit F
If set, a Forwarding Address has been included in the LSA.
bit T
If set, an External Route Tag has been included in the LSA.
Metric
The cost of this route. Interpretation depends on the external
type indication (bit E above).
PrefixLength, PrefixOptions and Address Prefix
Representation of the IPv6 address prefix, as described in Section
A.4.1.
Referenced LS type
If non-zero, an LSA with this LS type is to be associated with
this LSA (see Referenced Link State ID below).
Forwarding address
A fully qualified IPv6 address (128 bits). Included in the LSA if
and only if bit F has been set. If included, Data traffic for the
advertised destination will be forwarded to this address. Must not
be set to the IPv6 Unspecified Address (0:0:0:0:0:0:0:0).
External Route Tag
A 32-bit field which may be used to communicate additional
information between AS boundary routers; see [Ref5] for example
usage. Included in the LSA if and only if bit T has been set.
Referenced Link State ID Included if and only if Reference LS Type is
non-zero. If included, additional information concerning the
advertised external route can be found in the LSA having LS type
equal to "Referenced LS Type", Link State ID equal to "Referenced
Link State ID" and Advertising Router the same as that specified
in the AS-external-LSA's link state header. This additional
information 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.
All, none or some of the fields labeled Forwarding address, External Route Tag and Referenced Link State ID may be present in the AS- external-LSA (as indicated by the setting of bit F, bit T and Referenced LS type respectively). However, when present Forwarding Address always comes first, with External Route Tag always preceding Referenced Link State ID.A.4.8 Link-LSAs
Link-LSAs have LS type equal to 0x0008. A router originates a separate Link-LSA for each link it is attached to. These LSAs have local-link flooding scope; they are never flooded beyond the link that they are associated with. Link-LSAs have three purposes: 1) they provide the router's link-local address to all other routers attached to the link and 2) they inform other routers attached to the link of a list of IPv6 prefixes to associate with the link and 3) they allow the router to assert a collection of Options bits to associate with the Network-LSA that will be originated for the link. A link-LSA's Link State ID is set equal to the originating router's Interface ID on the link.
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 |0|0|0| 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rtr Pri | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- Link-local Interface Address -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # prefixes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rtr Pri
The Router Priority of the interface attaching the originating
router to the link.
Options
The set of Options bits that the router would like set in the
Network-LSA that will be originated for the link.
Link-local Interface Address
The originating router's link-local interface address on the
link.
# prefixes
The number of IPv6 address prefixes contained in the LSA.
The rest of the link-LSA contains a list of IPv6 prefixes to be
associated with the link.
PrefixLength, PrefixOptions and Address Prefix
Representation of an IPv6 address prefix, as described in
Section A.4.1.
A.4.9 Intra-Area-Prefix-LSAs
Intra-Area-Prefix-LSAs have LS type equal to 0x2009. A router uses
Intra-Area-Prefix-LSAs to advertise one or more IPv6 address
prefixes that are associated with a) the router itself, b) an
attached stub network segment or c) an attached transit network
segment. In IPv4, a) and b) were accomplished via the router's
router-LSA, and c) via a network-LSA. However, in OSPF for IPv6 all
addressing information has been removed from router-LSAs and
network-LSAs, leading to the introduction of the Intra-Area-Prefix-LSA.
A router can originate multiple Intra-Area-Prefix-LSAs for each
router or transit network; each such LSA is distinguished by its
Link State ID.
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 |0|0|1| 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # prefixes | Referenced LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Referenced Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Referenced Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
# prefixes
The number of IPv6 address prefixes contained in the LSA.
Router
Referenced LS type, Referenced Link State ID and Referenced
Advertising
Identifies the router-LSA or network-LSA with which the IPv6
address prefixes should be associated. If Referenced LS type is 1,
the prefixes are associated with a router-LSA, Referenced Link
State ID should be 0 and Referenced Advertising Router should be
the originating router's Router ID. If Referenced LS type is 2,
the prefixes are associated with a network-LSA, Referenced Link
State ID should be the Interface ID of the link's Designated
Router and Referenced Advertising Router should be the Designated
Router's Router ID.
The rest of the Intra-Area-Prefix-LSA contains a list of IPv6
prefixes to be associated with the router or transit link, together
with the cost of each prefix.
PrefixLength, PrefixOptions and Address Prefix
Representation of an IPv6 address prefix, as described in Section
A.4.1.
Metric
The cost of this prefix. Expressed in the same units as the
interface costs in the router-LSAs.
B. Architectural Constants
Architectural constants for the OSPF protocol are defined in Appendix
B of [Ref1]. The only difference for OSPF for IPv6 is that
DefaultDestination is encoded as a prefix of length 0 (see Section
A.4.1).
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 HelloInterval and RouterDeadInterval.
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. 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 of [Ref1]), or they will persist
for up to MaxAge minutes.
Because the size of the Router ID is smaller than an IPv6 address,
it cannot be set to one of the router's IPv6 addresses (as is
commonly done for IPv4). Possible Router ID assignment procedures
for IPv6 include: a) assign the IPv6 Router ID as one of the
router's IPv4 addresses or b) assign IPv6 Router IDs through some
local administrative procedure (similar to procedures used by
manufacturers to assign product serial numbers).
The Router ID of 0.0.0.0 is reserved, and should not be used.
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 is reserved for the backbone.
List of address ranges
Address ranges control the advertisement of routes across
area boundaries. Each address range consists of the
following items:
[IPv6 prefix, prefix length]
Describes the collection of IPv6 addresses contained in
the address range.
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
inter-area-prefix-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.
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 inter-area 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 of [Ref1].
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 inter-area-prefix-LSA that the
router should advertise into the area. See Section 12.4.3.1 of
[Ref1] for more information.
C.3 Router interface parameters
Some of the configurable router interface parameters (such as Area
ID, HelloInterval and RouterDeadInterval) actually imply properties
of the attached links, and therefore must be consistent across all
the routers attached to that link. The parameters that must be
configured for a router interface are:
IPv6 link-local address
The IPv6 link-local address associated with this interface. May
be learned through auto-configuration.
Area ID
The OSPF area to which the attached link belongs.
Instance ID
The OSPF protocol instance associated with this OSPF interface.
Defaults to 0.
Interface ID
32-bit number uniquely identifying this interface among the
collection of this router's interfaces. For example, in some
implementations it may be possible to use the MIB-II IfIndex
([Ref3]).
IPv6 prefixes
The list of IPv6 prefixes to associate with the link. These will
be advertised in intra-area-prefix-LSAs.
Interface output cost(s)
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 link. 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 link. 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 link. 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:
30 seconds. Sample value for a local area network (LAN): 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 link.
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
most of the parameters associated with a router interface (see
Section C.3). Virtual links do not have link-local addresses, but
instead use one of the router's global-scope or site-local IPv6
addresses as the IP source in OSPF protocol packets it sends along
the virtual link. Router Priority is not used on virtual links.
Interface output cost is not configured on virtual links, but is
dynamically set to be the cost of the intra-area path between the two
endpoint 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.
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 configured with its Router ID and IPv6 link-local
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 configured with its Router ID
and IPv6 link-local address on the network. Designated Routers are
not elected on Point-to-MultiPoint networks, so the Designated Router
eligibility of configured neighbors is undefined.
C.7 Host route parameters
Host prefixes are advertised in intra-area-prefix-LSAs. They
indicate either internal router addresses, router interfaces to
point-to-point networks, looped router interfaces, or IPv6 hosts that
are directly connected to the router (e.g., via a PPP connection).
For each host directly connected to the router, the following items
must be configured:
Host IPv6 prefix
The IPv6 prefix belonging to 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(s) in many
cases is unimportant (i.e., will have no effect on routing).
Area ID
The OSPF area to which the host's prefix belongs.
Security Considerations
When running over IPv6, OSPF relies on the IP Authentication Header (see [Ref19]) and the IP Encapsulating Security Payload (see [Ref20]) to ensure integrity and authentication/confidentiality of routing exchanges. Most OSPF implementations will be running on systems that support multiple protocols, many of them having independent security assumptions and domains. When IPSEC is used to protect OSPF packets, it is important for the implementation to check the IPSEC SA, and local SA database to make sure that the packet originates from a source THAT IS TRUSTED FOR OSPF PURPOSES.Authors' Addresses
Rob Coltun Siara Systems 300 Ferguson Drive Mountain View, CA 94043 Phone: (650) 390-9030 EMail: rcoltun@siara.com Dennis Ferguson Juniper Networks 385 Ravendale Drive Mountain View, CA 94043 Phone: +1 650 526 8004 EMail: dennis@juniper.com John Moy Sycamore Networks, Inc. 10 Elizabeth Drive Chelmsford, MA 01824 Phone: (978) 367-2161 Fax: (978) 250-3350 EMail: jmoy@sycamorenet.com
Full Copyright Statement Copyright (C) The Internet Society (1999). 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.