Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2740

OSPF for IPv6

Pages: 80
Obsoleted by:  5340
Part 3 of 3 – Pages 46 to 80
First   Prev   None

ToP   noToC   RFC2740 - Page 46   prevText

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.
ToP   noToC   RFC2740 - Page 47
   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.
ToP   noToC   RFC2740 - Page 48
                             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.
ToP   noToC   RFC2740 - Page 49
   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.
ToP   noToC   RFC2740 - Page 50
   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).
ToP   noToC   RFC2740 - Page 51
    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.
ToP   noToC   RFC2740 - Page 52
   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.
ToP   noToC   RFC2740 - Page 53
    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.
ToP   noToC   RFC2740 - Page 54
   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].
ToP   noToC   RFC2740 - Page 55
    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.
ToP   noToC   RFC2740 - Page 56
    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.
ToP   noToC   RFC2740 - Page 57
    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.
ToP   noToC   RFC2740 - Page 58
   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.
ToP   noToC   RFC2740 - Page 59
   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.
ToP   noToC   RFC2740 - Page 60
   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
ToP   noToC   RFC2740 - Page 61
   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.
ToP   noToC   RFC2740 - Page 62
    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).
ToP   noToC   RFC2740 - Page 63
   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).
ToP   noToC   RFC2740 - Page 64
      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.
ToP   noToC   RFC2740 - Page 65

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.
ToP   noToC   RFC2740 - Page 66

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.
ToP   noToC   RFC2740 - Page 67

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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ToP   noToC   RFC2740 - Page 68
   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.
ToP   noToC   RFC2740 - Page 69
   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.
ToP   noToC   RFC2740 - Page 70
    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.
ToP   noToC   RFC2740 - Page 71
   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.
ToP   noToC   RFC2740 - Page 72
    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.
ToP   noToC   RFC2740 - Page 73
   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
ToP   noToC   RFC2740 - Page 74
      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.
ToP   noToC   RFC2740 - Page 75
   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.
ToP   noToC   RFC2740 - Page 76
   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
ToP   noToC   RFC2740 - Page 77
      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:
ToP   noToC   RFC2740 - Page 78
   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.
ToP   noToC   RFC2740 - Page 79

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
ToP   noToC   RFC2740 - Page 80
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.