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-LSA
A.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