|
Network Working Group Requests for Comments: 2740 Category: Standards Track |
R. Coltun Siara Systems D. Ferguson Juniper Networks J. Moy Sycamore Networks December 1999 |
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright © The Internet Society (1999). All Rights Reserved.
This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, DR election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6.
Changes between OSPF for IPv4 and this document include the following. Addressing semantics have been removed from OSPF packets and the basic LSAs. New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis, instead of on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol itself, instead relying on IPv6's Authentication Header and Encapsulating Security Payload.
Most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4, even with the larger IPv6 addresses. Most field-XSand packet-size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible.
All of OSPF for IPv4's optional capabilities, including on-demand circuit support, NSSA areas, and the multicast extensions to OSPF (MOSPF) are also supported in OSPF for IPv6.
1 Introduction
1.1 Terminology
2 Differences from OSPF for IPv4
2.1 Protocol processing per-link, not per-subnet
2.2 Removal of addressing semantics
2.3 Addition of Flooding scope
2.4 Explicit support for multiple instances per link
2.5 Use of link-local addresses
2.6 Authentication changes
2.7 Packet format changes
2.8 LSA format changes
2.9 Handling unknown LSA types
2.10 Stub area support
2.11 Identifying neighbors by Router ID
3 Implementation details
3.1 Protocol data structures
3.1.1 The Area Data structure
3.1.2 The Interface Data structure
3.1.3 The Neighbor Data Structure
3.2 Protocol Packet Processing
3.2.1 Sending protocol packets
3.2.1.1 Sending Hello packets
3.2.1.2 Sending Database Description Packets
3.2.2 Receiving protocol packets
3.2.2.1 Receiving Hello Packets
3.3 The Routing table Structure
3.3.1 Routing table lookup
3.4 Link State Advertisements
3.4.1 The LSA Header
3.4.2 The link-state database
3.4.3 Originating LSAs
3.4.3.1 Router-LSAs
3.4.3.2 Network-LSAs
3.4.3.3 Inter-Area-Prefix-LSAs
3.4.3.4 Inter-Area-Router-LSAs
3.4.3.5 AS-external-LSAs
3.4.3.6 Link-LSAs
3.4.3.7 Intra-Area-Prefix-LSAs
3.5 Flooding
3.5.1 Receiving Link State Update packets
3.5.2 Sending Link State Update packets
3.5.3 Installing LSAs in the database
3.6 Definition of self-originated LSAs
3.7 Virtual links
3.8 Routing table calculation
3.8.1 Calculating the shortest path tree for an area
3.8.1.1 The next hop calculation
3.8.2 Calculating the inter-area routes
3.8.3 Examining transit areas' summary-LSAs
3.8.4 Calculating AS external routes
3.9 Multiple interfaces to a single link
References
A OSPF data formats
A.1 Encapsulation of OSPF packets
A.2 The Options field
A.3 OSPF Packet Formats
A.3.1 The OSPF packet header
A.3.2 The Hello packet
A.3.3 The Database Description packet
A.3.4 The Link State Request packet
A.3.5 The Link State Update packet
A.3.6 The Link State Acknowledgment packet
A.4 LSA formats
A.4.1 IPv6 Prefix Representation
A.4.1.1 Prefix Options
A.4.2 The LSA header
A.4.2.1 LS type
A.4.3 Router-LSAs
A.4.4 Network-LSAs
A.4.5 Inter-Area-Prefix-LSAs
A.4.6 Inter-Area-Router-LSAs
A.4.7 AS-external-LSAs
A.4.8 Link-LSAs
A.4.9 Intra-Area-Prefix-LSAs
B Architectural Constants
C Configurable Constants
C.1 Global parameters
C.2 Area parameters
C.3 Router interface parameters
C.4 Virtual link parameters
C.5 NBMA network parameters
C.6 Point-to-MultiPoint network parameters
C.7 Host route parameters
Security Considerations
Authors' Addresses
Full Copyright Statement
This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, DR election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6.
This document is organized as follows. Section 2 describes the differences between OSPF for IPv4 and OSPF for IPv6 in detail. Section 3 provides implementation details for the changes. Appendix A gives the OSPF for IPv6 packet and LSA formats. Appendix B lists the OSPF architectural constants. Appendix C describes configuration parameters.
This document attempts to use terms from both the OSPF for IPv4 specification ([Ref1]) and the IPv6 protocol specifications ([Ref14]). This has produced a mixed result. Most of the terms used both by OSPF and IPv6 have roughly the same meaning (e.g., interfaces). However, there are a few conflicts. IPv6 uses "link" similarly to IPv4 OSPF's "subnet" or "network". In this case, we have chosen to use IPv6's "link" terminology. "Link" replaces OSPF's "subnet" and "network" in most places in this document, although OSPF's Network-LSA remains unchanged (and possibly unfortunately, a new Link-LSA has also been created).
The names of some of the OSPF LSAs have also changed. See Section 2.8 for details.
Most of the algorithms from OSPF for IPv4 [Ref1] have preserved in OSPF for IPv6. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6.
The following subsections describe the differences between this document and [Ref1].
IPv6 uses the term "link" to indicate "a communication facility or medium over which nodes can communicate at the link layer" ([Ref14]). "Interfaces" connect to links. Multiple IP subnets can be assigned to a single link, and two nodes can talk directly over a single link, even if they do not share a common IP subnet (IPv6 prefix).
For this reason, OSPF for IPv6 runs per-link instead of the IPv4 behavior of per-IP-subnet. The terms "network" and "subnet" used in the IPv4 OSPF specification ([Ref1]) should generally be relaced by link. Likewise, an OSPF interface now connects to a link instead of an IP subnet, etc.
This change affects the receiving of OSPF protocol packets, and the contents of Hello Packets and Network-LSAs.
In OSPF for IPv6, addressing semantics have been removed from the OSPF protocol packets and the main LSA types, leaving a network- protocol-independent core. In particular:
Flooding scope for LSAs has been generalized and is now explicitly coded in the LSA's LS type field. There are now three separate flooding scopes for LSAs:
OSPF now supports the ability to run multiple OSPF protocol instances on a single link. For example, this may be required on a NAP segment shared between several providers -- providers may be running separate OSPF routing domains that want to remain separate even though they have one or more physical network segments (i.e., links) in common. In OSPF for IPv4 this was supported in a haphazard fashion using the authentication fields in the OSPF for IPv4 header.
Another use for running multiple OSPF instances is if you want, for one reason or another, to have a single link belong to two or more OSPF areas.
Support for multiple protocol instances on a link is accomplished via an "Instance ID" contained in the OSPF packet header and OSPF interface structures. Instance ID solely affects the reception of OSPF packets.
IPv6 link-local addresses are for use on a single link, for purposes of neighbor discovery, auto-configuration, etc. IPv6 routers do not forward IPv6 datagrams having link-local source addresses [Ref15]. Link-local unicast addresses are assigned from the IPv6 address range FF80/10.
OSPF for IPv6 assumes that each router has been assigned link-local unicast addresses on each of the router's attached physical segments. On all OSPF interfaces except virtual links, OSPF packets are sent using the interface's associated link-local unicast address as source. A router learns the link-local addresses of all other routers attached to its links, and uses these addresses as next hop information during packet forwarding.
On virtual links, global scope or site-local IP addresses must be used as the source for OSPF protocol packets.
Link-local addresses appear in OSPF Link-LSAs (see Section 3.4.3.6). However, link-local addresses are not allowed in other OSPF LSA types. In particular, link-local addresses must not be advertised in inter-area-prefix-LSAs (Section 3.4.3.3), AS-external-LSAs (Section 3.4.3.5) or intra-area-prefix-LSAs (Section 3.4.3.7).
In OSPF for IPv6, authentication has been removed from OSPF itself. The "AuType" and "Authentication" fields have been removed from the OSPF packet header, and all authentication related fields have been removed from the OSPF area and interface structures.
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.
Protection of OSPF packet exchanges against accidental data corruption is provided by the standard IPv6 16-bit one's complement checksum, covering the entire OSPF packet and prepended IPv6 pseudo- header (see Section A.3.1).
OSPF for IPv6 runs directly over IPv6. Aside from this, all addressing semantics have been removed from the OSPF packet headers, making it essentially "network-protocol-independent". All addressing information is now contained in the various LSA types only.
In detail, changes in OSPF packet format consist of the following:
All addressing semantics have been removed from the LSA header, and from Router-LSAs and Network-LSAs. These two LSAs now describe the routing domain's topology in a network-protocol-independent manner. New LSAs have been added to distribute IPv6 address information, and data required for next hop resolution. The names of some of IPv4's LSAs have been changed to be more consistent with each other.
In detail, changes in LSA format consist of the following:
In IPv4, the router-LSA carries a router's IPv4 interface addresses, the IPv4 equivalent of link-local addresses. These are only used when calculating next hops during the OSPF routing calculation (see Section 16.1.1 of [Ref1]), so they do not need to be flooded past the local link; hence using link-LSAs to distribute these addresses is more efficient. Note that link-local addresses cannot be learned through the reception of Hellos in all cases: on NBMA links next hop routers do not necessarily exchange hellos, but rather learn of each other's existence by way of the Designated Router.
Handling of unknown LSA types has been made more flexible so that, based on LS type, unknown LSA types are either treated as having link-local flooding scope, or are stored and flooded as if they were understood (desirable for things like the proposed External- Attributes-LSA in [Ref10]). This behavior is explicitly coded in the LSA Handling bit of the link state header's LS type field (see Section A.4.2.1).
The IPv4 OSPF behavior of simply discarding unknown types is unsupported due to the desire to mix router capabilities on a single link. Discarding unknown types causes problems when the Designated Router supports fewer options than the other routers on the link.
In OSPF for IPv4, stub areas were designed to minimize link-state database and routing table sizes for the areas' internal routers. This allows routers with minimal resources to participate in even very large OSPF routing domains.
In OSPF for IPv6, the concept of stub areas is retained. In IPv6, of the mandatory LSA types, stub areas carry only router-LSAs, network- LSAs, Inter-Area-Prefix-LSAs, Link-LSAs, and Intra-Area-Prefix-LSAs. This is the IPv6 equivalent of the LSA types carried in IPv4 stub areas: router-LSAs, network-LSAs and type 3 summary-LSAs.
However, unlike in IPv4, IPv6 allows LSAs with unrecognized LS types to be labeled "Store and flood the LSA, as if type understood" (see the U-bit in Section A.4.2.1). Uncontrolled introduction of such LSAs could cause a stub area's link-state database to grow larger than its component routers' capacities.
To guard against this, the following rule regarding stub areas has been established: an LSA whose LS type is unrecognized may only be flooded into/throughout a stub area if both a) the LSA has area or link-local flooding scope and b) the LSA has U-bit set to 0. See Section 3.5 for details.
In OSPF for IPv6, neighboring routers on a given link are always identified by their OSPF Router ID. This contrasts with the IPv4 behavior where neighbors on point-to-point networks and virtual links are identified by their Router IDs, and neighbors on broadcast, NBMA and Point-to-MultiPoint links are identified by their IPv4 interface addresses.
This change affects the reception of OSPF packets (see Section 8.2 of [Ref1]), the lookup of neighbors (Section 10 of [Ref1]) and the reception of Hello Packets (Section 10.5 of [Ref1]).
The Router ID of 0.0.0.0 is reserved, and should not be used.
When going from IPv4 to IPv6, the basic OSPF mechanisms remain unchanged from those documented in [Ref1]. These mechanisms are briefly outlined in Section 4 of [Ref1]. Both IPv6 and IPv4 have a link-state database composed of LSAs and synchronized between adjacent routers. Initial synchronization is performed through the Database Exchange process, through the exchange of Database Description, Link State Request and Link State Update packets. Thereafter database synchronization is maintained via flooding, utilizing Link State Update and Link State Acknowledgment packets. Both IPv6 and IPv4 use OSPF Hello Packets to discover and maintain neighbor relationships, and to elect Designated Routers and Backup Designated Routers on broadcast and NBMA links. The decision as to which neighbor relationships become adjacencies, along with the basic ideas behind inter-area routing, importing external information in AS-external-LSAs and the various routing calculations are also the same.
In particular, the following IPv4 OSPF functionality described in [Ref1] remains completely unchanged for IPv6:
However, some OSPF protocol mechanisms have changed, as outlined in Section 2 above. These changes are explained in detail in the following subsections, making references to the appropriate sections of [Ref1].
The following subsections provide a recipe for turning an IPv4 OSPF implementation into an IPv6 OSPF implementation.
The major OSPF data structures are the same for both IPv4 and IPv6: areas, interfaces, neighbors, the link-state database and the routing table. The top-level data structures for IPv6 remain those listed in Section 5 of [Ref1], with the following modifications:
The IPv6 area data structure contains all elements defined for IPv4 areas in Section 6 of [Ref1]. In addition, all LSAs of known type which have area flooding scope are contained in the IPv6 area data structure. This always includes the following LSA types: router-LSAs, network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs and intra-area-prefix-LSAs. LSAs with unknown LS type, U-bit set to 1 (flood even when unrecognized) and area scope also appear in the area data structure. IPv6 routers implementing MOSPF add group- membership-LSAs to the area data structure. Type-7-LSAs belong to an NSSA area's data structure.
In OSPF for IPv6, an interface connects a router to a link. The IPv6 interface structure modifies the IPv4 interface structure (as defined in Section 9 of [Ref1]) as follows:
Interface ID
Every interface is assigned an Interface ID, which uniquely
identifies the interface with the router. For example, some
implementations may be able to use the MIB-II IfIndex ([Ref3]) as
Interface ID. The Interface ID appears in Hello packets sent out
the interface, the link-local-LSA originated by router for the
attached link, and the router-LSA originated by the router-LSA for
the associated area. It will also serve as the Link State ID for
the network-LSA that the router will originate for the link if the
router is elected Designated Router.
Instance ID
Every interface is assigned an Instance ID. This should default to
0, and is only necessary to assign differently on those links that
will contain multiple separate communities of OSPF Routers. For
example, suppose that there are two communities of routers on a
given ethernet segment that you wish to keep separate.
The first community is given an Instance ID of 0, by assigning 0 as the Instance ID of all its routers' interfaces to the ethernet. An Instance ID of 1 is assigned to the other routers' interfaces to the ethernet. The OSPF transmit and receive processing (see Section 3.2) will then keep the two communities separate.
List of LSAs with link-local scope
All LSAs with link-local scope and which were originated/flooded
on the link belong to the interface structure which connects to
the link. This includes the collection of the link's link-LSAs.
List of LSAs with unknown LS type
All LSAs with unknown LS type and U-bit set to 0 (if unrecognized,
treat the LSA as if it had link-local flooding scope) are kept in
the data structure for the interface that received the LSA.
IP interface address
For IPv6, the IPv6 address appearing in the source of OSPF packets
sent out the interface is almost always a link-local address. The
one exception is for virtual links, which must use one of the
router's own site-local or global IPv6 addresses as IP interface
address.
List of link prefixes
A list of IPv6 prefixes can be configured for the attached link.
These will be advertised by the router in link-LSAs, so that they
can be advertised by the link's Designated Router in intra-area-
prefix-LSAs.
In OSPF for IPv6, each router interface has a single metric, representing the cost of sending packets out the interface. In addition, OSPF for IPv6 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. For that reason, AuType and Authentication key are not associated with IPv6 OSPF interfaces.
Interface states, events, and the interface state machine remain unchanged from IPv4, and are documented in Sections 9.1, 9.2 and 9.3 of [Ref1] respectively. The Designated Router and Backup Designated Router election algorithm also remains unchanged from the IPv4 election in Section 9.4 of [Ref1].
The neighbor structure performs the same function in both IPv6 and IPv4. Namely, it collects all information required to form an adjacency between two routers, if an adjacency becomes necessary. Each neighbor structure is bound to a single OSPF interface. The differences between the IPv6 neighbor structure and the neighbor structure defined for IPv4 in Section 10 of [Ref1] are:
Neighbor's Interface ID
The Interface ID that the neighbor advertises in its Hello Packets
must be recorded in the neighbor structure. The router will
include the neighbor's Interface ID in the router's router-LSA
when either a) advertising a point-to-point link to the neighbor
or b) advertising a link to a network where the neighbor has
become Designated Router.
Neighbor IP address
Except on virtual links, the neighbor's IP address will be an IPv6
link-local address.
Neighbor's Designated Router
The neighbor's choice of Designated Router is now encoded as a
Router ID, instead of as an IP address.
Neighbor's Backup Designated Router
The neighbor's choice of Designated Router is now encoded as a
Router ID, instead of as an IP address.
Neighbor states, events, and the neighbor state machine remain unchanged from IPv4, and are documented in Sections 10.1, 10.2 and 10.3 of [Ref1] respectively. The decision as to which adjacencies to form also remains unchanged from the IPv4 logic documented in Section 10.4 of [Ref1].
OSPF for IPv6 runs directly over IPv6's network layer. As such, it is encapsulated in one or more IPv6 headers, with the Next Header field of the immediately encapsulating IPv6 header set to the value 89.
As for IPv4, in IPv6 OSPF routing protocol packets are sent along adjacencies only (with the exception of Hello packets, which are used to discover the adjacencies). OSPF packet types and functions are the same in both IPv4 and IPv4, encoded by the
Type field of the standard OSPF packet header.
When an IPv6 router sends an OSPF routing protocol packet, it fills in the fields of the standard OSPF for IPv6 packet header (see Section A.3.1) as follows:
Version #
Set to 3, the version number of the protocol as documented in this
specification.
Type
The type of OSPF packet, such as Link state Update or Hello
Packet.
Packet length
The length of the entire OSPF packet in bytes, including the
standard OSPF packet header.
Router ID
The identity of the router itself (who is originating the packet).
Area ID
The OSPF area that the packet is being sent into.
Instance ID
The OSPF Instance ID associated with the interface that the packet
is being sent out of.
Checksum
The standard IPv6 16-bit one's complement checksum, covering the
entire OSPF packet and prepended IPv6 pseudo-header (see Section
A.3.1).
Selection of OSPF routing protocol packets' IPv6 source and destination addresses is performed identically to the IPv4 logic in Section 8.1 of [Ref1]. The IPv6 destination address is chosen from among the addresses AllSPFRouters, AllDRouters and the Neighbor IP address associated with the other end of the adjacency (which in IPv6, for all links except virtual links, is an IPv6 link-local address).
The sending of Link State Request Packets and Link State
Acknowledgment Packets remains unchanged from the IPv4 procedures
documented in Sections 10.9 and 13.5 of [Ref1] respectively. Sending
Hello Packets is documented in Section 3.2.1.1, and the sending of
Database Description Packets in Section 3.2.1.2. The sending of Link
State Update Packets is documented in Section 3.5.2.
IPv6 changes the way OSPF Hello packets are sent in the following ways (compare to Section 9.5 of [Ref1]):
their IP interface addresses. Advertising the Designated
Router (or Backup Designated Router) as 0.0.0.0 indicates that the
Designated Router (or Backup Designated Router) has not yet been
chosen.
Sending Hello packets on NBMA networks proceeds for IPv6 in exactly the same way as for IPv4, as documented in Section 9.5.1 of [Ref1].
The sending of Database Description packets differs from Section 10.8 of [Ref1] in the following ways:
Whenever an OSPF protocol packet is received by the router it is marked with the interface it was received on. For routers that have virtual links configured, it may not be immediately obvious which interface to associate the packet with. For example, consider the Router RT11 depicted in Figure 6 of [Ref1]. If RT11 receives an OSPF protocol packet on its interface to Network N8, it may want to associate the packet with the interface to Area 2, or with the
virtual link to Router RT10 (which is part of the backbone). In the following, we assume that the packet is initially associated with the non-virtual link.
In order for the packet to be passed to OSPF for processing, the following tests must be performed on the encapsulating IPv6 headers:
After processing the encapsulating IPv6 headers, the OSPF packet header is processed. The fields specified in the header must match those configured for the receiving interface. If they do not, the packet should be discarded:
(1) Match the Area ID of the receiving interface. In
this case, unlike for IPv4, the IPv6 source
address is not restricted to lie on the same IP
subnet as the receiving interface. IPv6 OSPF runs
per-link, instead of per-IP-subnet.
(2) Indicate the backbone. In this case, the packet
has been sent over a virtual link. The receiving
router must be an area border router, and the
Router ID specified in the packet (the source
router) must be the other end of a configured
virtual link. The receiving interface must also
attach to the virtual link's configured Transit
area. If all of these checks succeed, the packet
is accepted and is from now on associated with
the virtual link (and the backbone area).
After header processing, the packet is further processed according to its OSPF packet type. OSPF packet types and functions are the same for both IPv4 and IPv6.
If the packet type is Hello, it should then be further processed by the Hello Protocol. All other packet types are sent/received only on adjacencies. This means that the packet must have been sent by one of the router's active neighbors. The neighbor is identified by the Router ID appearing the the received packet's OSPF header. Packets not matching any active neighbor are discarded.
The receive processing of Database Description Packets, Link State Request Packets and Link State Acknowledgment Packets remains unchanged from the IPv4 procedures documented in Sections 10.6, 10.7 and 13.7 of [Ref1] respectively. The receiving of Hello Packets is documented in Section 3.2.2.1, and the receiving of Link State Update Packets is documented in Section 3.5.1.
The receive processing of Hello Packets differs from Section 10.5 of [Ref1] in the following ways:
The routing table used by OSPF for IPv4 is defined in Section 11 of [Ref1]. For IPv6 there are analogous routing table entries: there are routing table entries for IPv6 address prefixes, and also for AS boundary routers. The latter routing table entries are only used to hold intermediate results during the routing table build process (see Section 3.8).
Also, to hold the intermediate results during the shortest-path calculation for each area, there is a separate routing table for each area holding the following entries:
The fields in the IPv4 OSPF routing table (see Section 11 of [Ref1]) remain valid for IPv6: Optional capabilities (routers only), path type, cost, type 2 cost, link state origin, and for each of the equal cost paths to the destination, the next hop and advertising router.
For IPv6, the link-state origin field in the routing table entry is the router-LSA or network-LSA that has directly or indirectly produced the routing table entry. For example, if the routing table entry describes a route to an IPv6 prefix, the link state origin is the router-LSA or network-LSA that is listed in the body of the intra-area-prefix-LSA that has produced the route (see Section A.4.9).
Routing table lookup (i.e., determining the best matching routing table entry during IP forwarding) is the same for IPv6 as for IPv4.
For IPv6, the OSPF LSA header has changed slightly, with the LS type field expanding and the Options field being moved into the body of appropriate LSAs. Also, the formats of some LSAs have changed somewhat (namely router-LSAs, network-LSAs and AS-external-LSAs), while the names of other LSAs have been changed (type 3 and 4 summary-LSAs are now inter-area-prefix-LSAs and inter-area-router-
LSAs respectively) and additional LSAs have been added (Link-LSAs and Intra-Area-Prefix-LSAs). Type of Service (TOS) has been removed from the OSPFv2 specification [Ref1], and is not encoded within OSPF for IPv6's LSAs.
These changes will be described in detail in the following subsections.
In both IPv4 and IPv6, all OSPF LSAs begin with a standard 20 byte LSA header. However, the contents of this 20 byte header have changed in IPv6. The LS age, Advertising Router, LS Sequence Number, LS checksum and length fields within the LSA header remain unchanged, as documented in Sections 12.1.1, 12.1.5, 12.1.6, 12.1.7 and A.4.1 of [Ref1] respectively. However, the following fields have changed for IPv6:
Options
The Options field has been removed from the standard 20 byte LSA
header, and into the body of router-LSAs, network-LSAs, inter-
area-router-LSAs and link-LSAs. The size of the Options field has
increased from 8 to 24 bits, and some of the bit definitions have
changed (see Section A.2). In addition a separate PrefixOptions
field, 8 bits in length, is attached to each prefix advertised
within the body of an LSA.
LS type
The size of the LS type field has increased from 8 to 16 bits,
with the top two bits encoding flooding scope and the next bit
encoding the handling of unknown LS types. See Section A.4.2.1
for the current coding of the LS type field.
Link State ID
Link State ID remains at 32 bits in length, but except for
network-LSAs and link-LSAs, Link State ID has shed any addressing
semantics. For example, an IPv6 router originating multiple AS-
external-LSAs could start by assigning the first a Link State ID
of 0.0.0.1, the second a Link State ID of 0.0.0.2, and so on.
Instead of the IPv4 behavior of encoding the network number within
the AS-external-LSA's Link State ID, the IPv6 Link State ID simply
serves as a way to differentiate multiple LSAs originated by the
same router.
For network-LSAs, the Link State ID is set to the Designated Router's Interface ID on the link. When a router originates a Link-LSA for a given link, its Link State ID is set equal to the router's Interface ID on the link.
In IPv6, as in IPv4, individual LSAs are identified by a combination of their LS type, Link State ID and Advertising Router fields. Given two instances of an LSA, the most recent instance is determined by examining the LSAs' LS Sequence Number, using LS checksum and LS age as tiebreakers (see Section 13.1 of [Ref1]).
In IPv6, the link-state database is split across three separate data structures. LSAs with AS flooding scope are contained within the top-level OSPF data structure (see Section 3.1) as long as either their LS type is known or their U-bit is 1 (flood even when unrecognized); this includes the AS-external-LSAs. LSAs with area flooding scope are contained within the appropriate area structure (see Section 3.1.1) as long as either their LS type is known or their U-bit is 1 (flood even when unrecognized); this includes router-LSAs, network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs, and intra-area-prefix-LSAs. LSAs with unknown LS type and U-bit set to 0 and/or link-local flooding scope are contained within the appropriate interface structure (see Section 3.1.2); this includes link-LSAs.
To lookup or install an LSA in the database, you first examine the LS type and the LSA's context (i.e., to which area or link does the LSA belong). This information allows you to find the correct list of LSAs, all of the same LS type, where you then search based on the LSA's Link State ID and Advertising Router.
The process of reoriginating an LSA in IPv6 is the same as in IPv4: the LSA's LS sequence number is incremented, its LS age is set to 0, its LS checksum is calculated, and the LSA is added to the link state database and flooded out the appropriate interfaces.
To the list of events causing LSAs to be reoriginated, which for IPv4 is given in Section 12.4 of [Ref1], the following events and/or actions are added for IPv6:
Detailed construction of the seven required IPv6 LSA types is supplied by the following subsections. In order to display example LSAs, the network map in Figure 15 of [Ref1] has been reworked to show IPv6 addressing, resulting in Figure 1. The OSPF cost of each interface is has been displayed in Figure 1. The assignment of IPv6 prefixes to network links is shown in Table 1. A single area address range has been configured for Area 1, so that outside of Area 1 all of its prefixes are covered by a single route to 5f00:0000:c001::/48. The OSPF interface IDs and the link-local addresses for the router interfaces in Figure 1 are given in Table 2.
. Area 1.
. + .
. | .
. | 3+---+1 .
. N1 |--|RT1|-----+ .
. | +---+ \ .
. | \ ______ .
. + \/ \ 1+---+
. * N3 *------|RT4|------
. + /\_______/ +---+
. | / | .
. | 3+---+1 / | .
. N2 |--|RT2|-----+ 1| .
. | +---+ +---+ .
. | |RT3|----------------
. + +---+ .
. |2 .
. | .
. +------------+ .
. N4 .
Figure 1: Area 1 with IP addresses shown
Network IPv6 prefix
-----------------------------------
N1 5f00:0000:c001:0200::/56
N2 5f00:0000:c001:0300::/56
N3 5f00:0000:c001:0100::/56
N4 5f00:0000:c001:0400::/56
Table 1: IPv6 link prefixes for sample network
Router interface Interface ID link-local address
-------------------------------------------------------
RT1 to N1 1 fe80:0001::RT1
to N3 2 fe80:0002::RT1
RT2 to N2 1 fe80:0001::RT2
to N3 2 fe80:0002::RT2
RT3 to N3 1 fe80:0001::RT3
to N4 2 fe80:0002::RT3
RT4 to N3 1 fe80:0001::RT4
Table 2: OSPF Interface IDs and link-local addresses
The LS type of a router-LSA is set to the value 0x2001. Router-LSAs have area flooding scope. A router may originate one or more router- LSAs for a given area. Each router-LSA contains an integral number of interface descriptions; taken together, the collection of router-LSAs originated by the router for an area describes the collected states of all the router's interfaces to the area. When multiple router-LSAs are used, they are distinguished by their Link State ID fields.
The Options field in the router-LSA should be coded as follows. The V6-bit should be set. The E-bit should be clear if and only if the attached area is an OSPF stub area. The MC-bit should be set if and only if the router is running MOSPF (see [Ref8]). The N-bit should be set if and only if the attached area is an OSPF NSSA area. The R-bit should be set. The DC-bit should be set if and only if the router can correctly process the DoNotAge bit when it appears in the LS age field of LSAs (see [Ref11]). All unrecognized bits in the Options field should be cleared
To the left of the Options field, the router capability bits V, E and B should be coded according to Section 12.4.1 of [Ref1]. Bit W should be coded according to [Ref8].
Each of the router's interfaces to the area are then described by appending "link descriptions" to the router-LSA. Each link description is 16 bytes long, consisting of 5 fields: (link) Type, Metric, Interface ID, Neighbor Interface ID and Neighbor Router ID (see Section A.4.3). Interfaces in state "Down" or "Loopback" are not described (although looped back interfaces can contribute prefixes to Intra-Area-Prefix-LSAs). Nor are interfaces without any full adjacencies described. All other interfaces to the area add zero, one or more link descriptions, the number and content of which depend on the interface type. Within each link description, the Metric field is always set the interface's output cost and the Interface ID field is set to the interface's OSPF Interface ID.
Point-to-point interfaces
If the neighboring router is fully adjacent, add a Type 1 link
description (point-to-point). The Neighbor Interface ID field is
set to the Interface ID advertised by the neighbor in its Hello
packets, and the Neighbor Router ID field is set to the neighbor's
Router ID.
Broadcast and NBMA interfaces
If the router is fully adjacent to the link's Designated Router,
or if the router itself is Designated Router and is fully adjacent
to at least one other router, add a single Type 2 link description
(transit network). The Neighbor Interface ID field is set to the
Interface ID advertised by the Designated Router in its Hello
packets, and the Neighbor Router ID field is set to the Designated
Router's Router ID.
Virtual links
If the neighboring router is fully adjacent, add a Type 4 link
description (virtual). The Neighbor Interface ID field is set to
the Interface ID advertised by the neighbor in its Hello packets,
and the Neighbor Router ID field is set to the neighbor's Router
ID. Note that the output cost of a virtual link is calculated
during the routing table calculation (see Section 3.7).
Point-to-MultiPoint interfaces
For each fully adjacent neighbor associated with the interface,
add a separate Type 1 link description (point-to-point) with
Neighbor Interface ID field set to the Interface ID advertised by
the neighbor in its Hello packets, and Neighbor Router ID field
set to the neighbor's Router ID.
As an example, consider the router-LSA that router RT3 would originate for Area 1 in Figure 1. Only a single interface must be described, namely that which connects to the transit network N3. It assumes that RT4 has been elected Designated Router of Network N3.
; RT3's router-LSA for Area 1
LS age = 0 ;newly (re)originated
LS type = 0x2001 ;router-LSA
Link State ID = 0 ;first fragment
Advertising Router = 192.1.1.3 ;RT3's Router ID
bit E = 0 ;not an AS boundary router
bit B = 1 ;area border router
Options = (V6-bit|E-bit|R-bit)
Type = 2 ;connects to N3
Metric = 1 ;cost to N3
Interface ID = 1 ;RT3's Interface ID on N3
Neighbor Interface ID = 1 ;RT4's Interface ID on N3
Neighbor Router ID = 192.1.1.4 ; RT4's Router ID
If for example another router was added to Network N4, RT3 would have to advertise a second link description for its connection to (the now transit) network N4. This could be accomplished by reoriginating the above router-LSA, this time with two link descriptions. Or, a
separate router-LSA could be originated with a separate Link State ID (e.g., using a Link State ID of 1) to describe the connection to N4.
Host routes no longer appear in the router-LSA, but are instead included in intra-area-prefix-LSAs.
The LS type of a network-LSA is set to the value 0x2002. Network- LSAs have area flooding scope. A network-LSA is originated for every broadcast or NBMA link having two or more attached routers, by the link's Designated Router. The network-LSA lists all routers attached to the link.
The procedure for originating network-LSAs in IPv6 is the same as the IPv4 procedure documented in Section 12.4.2 of [Ref1], with the following exceptions:
As an example, assuming that Router RT4 has been elected Designated Router of Network N3 in Figure 1, the following network-LSA is originated:
; Network-LSA for Network N3
LS age = 0 ;newly (re)originated
LS type = 0x2002 ;network-LSA
Link State ID = 1 ;RT4's Interface ID on N3
Advertising Router = 192.1.1.4 ;RT4's Router ID
Options = (V6-bit|E-bit|R-bit)
Attached Router = 192.1.1.4 ;Router ID
Attached Router = 192.1.1.1 ;Router ID
Attached Router = 192.1.1.2 ;Router ID
Attached Router = 192.1.1.3 ;Router ID
The LS type of an inter-area-prefix-LSA is set to the value 0x2003. Inter-area-prefix-LSAs have area flooding scope. In IPv4, inter- area-prefix-LSAs were called type 3 summary-LSAs. Each inter-area- prefix-LSA describes a prefix external to the area, yet internal to the Autonomous System.
The procedure for originating inter-area-prefix-LSAs in IPv6 is the same as the IPv4 procedure documented in Sections 12.4.3 and 12.4.3.1 of [Ref1], with the following exceptions:
As an example, the following shows the inter-area-prefix-LSA that Router RT4 originates into the OSPF backbone area, condensing all of Area 1's prefixes into the single prefix 5f00:0000:c001::/48. The cost is set to 4, which is the maximum cost to all of the prefix' individual components. The prefix is padded out to an even number of 32-bit words, so that it consumes 64-bits of space instead of 48 bits.
; Inter-area-prefix-LSA for Area 1 addresses
; originated by Router RT4 into the backbone
LS age = 0 ;newly (re)originated
LS type = 0x2003 ;inter-area-prefix-LSA
Advertising Router = 192.1.1.4 ;RT4's ID
Metric = 4 ;maximum to components
PrefixLength = 48
PrefixOptions = 0
Address Prefix = 5f00:0000:c001 ;padded to 64-bits
The LS type of an inter-area-router-LSA is set to the value 0x2004. Inter-area-router-LSAs have area flooding scope. In IPv4, inter-area-router-LSAs were called type 4 summary-LSAs. Each inter-area-router-LSA describes a path to a destination OSPF router (an ASBR) that is external to the area, yet internal to the Autonomous System.
The procedure for originating inter-area-router-LSAs in IPv6 is the same as the IPv4 procedure documented in Section 12.4.3 of [Ref1], with the following exceptions:
As an example, consider the OSPF Autonomous System depicted in Figure 6 of [Ref1]. Router RT4 would originate into Area 1 the following inter-area-router-LSA for destination router RT7.
; inter-area-router-LSA for AS boundary router RT7
; originated by Router RT4 into Area 1
LS age = 0 ;newly (re)originated
LS type = 0x2004 ;inter-area-router-LSA
Advertising Router = 192.1.1.4 ;RT4's ID
Options = (V6-bit|E-bit|R-bit) ;RT7's capabilities
Metric = 14 ;cost to RT7
Destination Router ID = Router RT7's ID
The LS type of an AS-external-LSA is set to the value 0x4005. AS- external-LSAs have AS flooding scope. Each AS-external-LSA describes a path to a prefix external to the Autonomous System.
The procedure for originating AS-external-LSAs in IPv6 is the same as the IPv4 procedure documented in Section 12.4.4 of [Ref1], with the following exceptions:
As an example, consider the OSPF Autonomous System depicted in Figure 6 of [Ref1]. Assume that RT7 has learned its route to N12 via BGP, and that it wishes to advertise a Type 2 metric into the AS. Further assume the the IPv6 prefix for N12 is the value 5f00:0000:0a00::/40. RT7 would then originate the following AS-external-LSA for the external network N12. Note that within the AS-external-LSA, N12's prefix occupies 64 bits of space, to maintain 32-bit alignment.
; AS-external-LSA for Network N12,
; originated by Router RT7
LS age = 0 ;newly (re)originated
LS type = 0x4005 ;AS-external-LSA
Link State ID = 123 ;or something else
Advertising Router = Router RT7's ID
bit E = 1 ;Type 2 metric
bit F = 0 ;no forwarding address
bit T = 1 ;external route tag included
Metric = 2
PrefixLength = 40
PrefixOptions = 0
Referenced LS Type = 0 ;no Referenced Link State ID
Address Prefix = 5f00:0000:0a00 ;padded to 64-bits
External Route Tag = as per BGP/OSPF interaction
The LS type of a Link-LSA is set to the value 0x0008. Link-LSAs have link-local flooding scope. A router originates a separate Link-LSA for each attached link that supports 2 or more (including the originating router itself) routers.
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 in the Network-LSA that will be originated for the link.
A Link-LSA for a given Link L is built in the following fashion:
After building a Link-LSA for a given link, the router installs the link-LSA into the associate interface data structure and floods the Link-LSA onto the link. All other routers on the link will receive the Link-LSA, but it will go no further.
As an example, consider the Link-LSA that RT3 will build for N3 in Figure 1. Suppose that the prefix 5f00:0000:c001:0100::/56 has been configured within RT3 for N3. This will give rise to the following Link-LSA, which RT3 will flood onto N3, but nowhere else. Note that not all routers on N3 need be configured with the prefix; those not configured will learn the prefix when receiving RT3's Link-LSA.
; RT3's Link-LSA for N3
LS age = 0 ;newly (re)originated
LS type = 0x0008 ;Link-LSA
Link State ID = 1 ;RT3's Interface ID on N3
Advertising Router = 192.1.1.3 ;RT3's Router ID
Rtr Pri = 1 ;RT3's N3 Router Priority
Options = (V6-bit|E-bit|R-bit)
Link-local Interface Address = fe80:0001::RT3
# prefixes = 1
PrefixLength = 56
PrefixOptions = 0
Address Prefix = 5f00:0000:c001:0100 ;pad to 64-bits
The LS type of an intra-area-prefix-LSA is set to the value 0x2009. Intra-area-prefix-LSAs have area flooding scope. An intra-area- prefix-LSA has one of two functions. It associates a list of IPv6 address prefixes with a transit network link by referencing a network- LSA, or associates a list of IPv6 address prefixes with a router by referencing a router-LSA. A stub link's prefixes are associated with its attached router.
A router may originate multiple intra-area-prefix-LSAs for a given area, distinguished by their Link State ID fields. Each intra-area- prefix-LSA contains an integral number of prefix descriptions.
A link's Designated Router originates one or more intra-area-prefix- LSAs to advertise the link's prefixes throughout the area. For a link L, L's Designated Router builds an intra-area-prefix-LSA in the following fashion:
Advertising Router are set to the corresponding fields in Link L's network-LSA (namely LS type, Link State ID, and Advertising Router respectively). This means that Referenced LS Type is set to 0x2002, Referenced Link State ID is set to the Designated Router's Interface ID on Link L, and Referenced Advertising Router is set to the Designated Router's Router ID.
intra-area-prefix-LSA that is being built. Prefixes having the NU-bit and/or LA-bit set in their Options field should not be copied, nor should link-local addresses be copied. Each prefix is described by the PrefixLength, PrefixOptions, and Address Prefix fields. Multiple prefixes having the same PrefixLength and Address Prefix are considered to be duplicates; in this case their Prefix Options fields should be merged by logically OR'ing the fields together, and a single resulting prefix should be copied into the intra-area-prefix-LSA. The Metric field for all prefixes is set to 0.
A router builds an intra-area-prefix-LSA to advertise its own prefixes, and those of its attached stub links. A Router RTX would build its intra-area-prefix-LSA in the following fashion:
For example, the intra-area-prefix-LSA originated by RT4 for Network N3 (assuming that RT4 is N3's Designated Router), and the intra- area-prefix-LSA originated into Area 1 by Router RT3 for its own prefixes, are pictured below.
; Intra-area-prefix-LSA
; for network link N3
LS age = 0 ;newly (re)originated
LS type = 0x2009 ;Intra-area-prefix-LSA
Link State ID = 5 ;or something
Advertising Router = 192.1.1.4 ;RT4's Router ID
# prefixes = 1
Referenced LS type = 0x2002 ;network-LSA reference
Referenced Link State ID = 1
Referenced Advertising Router = 192.1.1.4
PrefixLength = 56 ;N3's prefix
PrefixOptions = 0
Metric = 0
Address Prefix = 5f00:0000:c001:0100 ;pad
; RT3's Intra-area-prefix-LSA
; for its own prefixes
LS age = 0 ;newly (re)originated
LS type = 0x2009 ;Intra-area-prefix-LSA
Link State ID = 177 ;or something
Advertising Router = 192.1.1.3 ;RT3's Router ID
# prefixes = 1
Referenced LS type = 0x2001 ;router-LSA reference
Referenced Link State ID = 0
Referenced Advertising Router = 192.1.1.3
PrefixLength = 56 ;N4's prefix
PrefixOptions = 0
Metric = 2 ;N4 interface cost
Address Prefix = 5f00:0000:c001:0400 ;pad
When network conditions change, it may be necessary for a router to move prefixes from one intra-area-prefix-LSA to another. For example, if the router is Designated Router for a link but the link has no other attached routers, the link's prefixes are advertised in an intra-area-prefix-LSA referring to the Designated Router's router- LSA. When additional routers appear on the link, a network-LSA is originated for the link and the link's prefixes are moved to an intra-area-prefix-LSA referring to the network-LSA.
Note that in the intra-area-prefix-LSA, the "Referenced Advertising Router" is always equal to the router that is originating the intra- area-prefix-LSA (i.e., the LSA's Advertising Router). The reason that the Referenced Advertising Router field appears is that, even though it is currently redundant, it may not be in the future. We may sometime want to use the same LSA format to advertise address prefixes for other protocol suites. In that event, the Designated Router may not be running the other protocol suite, and so another of the link's routers may need to send out the prefix-LSA. In that case, "Referenced Advertising Router" and "Advertising Router" would be different.
Most of the flooding algorithm remains unchanged from the IPv4 flooding mechanisms described in Section 13 of [Ref1]. In particular, the processes for determining which LSA instance is newer (Section 13.1 of [Ref1]), responding to updates of self-originated LSAs (Section 13.4 of [Ref1]), sending Link State Acknowledgment packets (Section 13.5 of [Ref1]), retransmitting LSAs (Section 13.6 of [Ref1]) and receiving Link State Acknowledgment packets (Section 13.7 of [Ref1]) are exactly the same for IPv6 and IPv4.
However, the addition of flooding scope and handling options for unrecognized LSA types (see Section A.4.2.1) has caused some changes in the OSPF flooding algorithm: the reception of Link State Updates (Section 13 in [Ref1]) and the sending of Link State Updates (Section 13.3 of [Ref1]) must take into account the LSA's scope and U-bit setting. Also, installation of LSAs into the OSPF database (Section 13.2 of [Ref1]) causes different events in IPv6, due to the reorganization of LSA types and contents in IPv6. These changes are described in detail below.
The encoding of flooding scope in the LS type and the need to process unknown LS types causes modifications to the processing of received Link State Update packets. As in IPv4, each LSA in a received Link State Update packet is examined. In IPv4, eight steps are executed for each LSA, as described in Section 13 of [Ref1]. For IPv6, all the steps are the same, except that Steps 2 and 3 are modified as follows:
(2) Examine the LSA's LS type. If the LS type is
unknown, the area has been configured as a stub area,
and either the LSA's flooding scope is set to "AS
flooding scope" or the U-bit of the LS type is set to
1 (flood even when unrecognized), then discard the
LSA and get the next one from the Link State Update
Packet. This generalizes the IPv4 behavior where AS-
external-LSAs are not flooded into/throughout stub
areas.
(3) Else if the flooding scope of the LSA is set to
"reserved", discard the LSA and get the next one from
the Link State Update Packet.
Steps 5b (sending Link State Update packets) and 5d (installing LSAs in the link state database) in Section 13 of [Ref1] are also somewhat different for IPv6, as described in Sections 3.5.2 and 3.5.3 below.
The sending of Link State Update packets is described in Section 13.3 of [Ref1]. For IPv4 and IPv6, the steps for sending a Link State Update packet are the same (steps 1 through 5 of Section 13.3 in [Ref1]). However, the list of eligible interfaces out which to flood the LSA is different. For IPv6, the eligible interfaces are selected based on the following factors:
Choosing the set of eligible interfaces then breaks into the following cases:
Case 1
The LSA's LS type is recognized. In this case, the set of eligible
interfaces is set depending on the flooding scope encoded in the
LS type. If the flooding scope is "AS flooding scope", the
eligible interfaces are all router interfaces excepting virtual
links. In addition, AS-external-LSAs are not flooded out
interfaces connecting to stub areas. If the flooding scope is
"area flooding scope", the set of eligible interfaces are those
interfaces connecting to the LSA's associated area. If the
flooding scope is "link-local flooding scope", then there is a
single eligible interface, the one connecting to the LSA's
associated link (which, when the LSA is received in a Link State
Update packet, is also the interface the LSA was received on).
Case 2
The LS type is unrecognized, and the U-bit in the LS Type is set
to 0 (treat the LSA as if it had link-local flooding scope). In
this case there is a single eligible interface, namely, the
interface on which the LSA was received.
Case 3
The LS type is unrecognized, and the U-bit in the LS Type is set
to 1 (store and flood the LSA, as if type understood). In this
case, select the eligible interfaces based on the encoded flooding
scope as in Case 1 above. However, in this case interfaces
attached to stub areas are always excluded.
A further decision must sometimes be made before adding an LSA to a given neighbor's link-state retransmission list (Step 1d in Section 13.3 of [Ref1]). If the LS type is recognized by the router, but not by the neighbor (as can be determined by examining the Options field that the neighbor advertised in its Database Description packet) and the LSA's U-bit is set to 0, then the LSA should be added to the neighbor's link-state retransmission list if and only if that neighbor is the Designated Router or Backup Designated Router for the attached link. The LS types described in detail by this memo, namely router-LSAs (LS type 0x2001), network-LSAs (0x2002), Inter-Area- Prefix-LSAs (0x2003), Inter-Area-Router-LSAs (0x2004), AS-External- LSAs (0x4005), Link-LSAs (0x0008) and Intra-Area-Prefix-LSAs (0x2009) are assumed to be understood by all routers. However, as an example the group-membership-LSA (0x2006) is understood only by MOSPF routers and since it has its U-bit set to 0, it should only be forwarded to a non-MOSPF neighbor (determined by examining the MC-bit in the neighbor's Database Description packets' Options field) when the neighbor is Designated Router or Backup Designated Router for the
attached link.
The previous paragraph solves a problem in IPv4 OSPF extensions such as MOSPF, which require that the Designated Router support the extension in order to have the new LSA types flooded across broadcast and NBMA networks (see Section 10.2 of [Ref8]).
There are three separate places to store LSAs, depending on their flooding scope. LSAs with AS flooding scope are stored in the global OSPF data structure (see Section 3.1) as long as their LS type is known or their U-bit is 1. LSAs with area flooding scope are stored in the appropriate area data structure (see Section 3.1.1) as long as their LS type is known or their U-bit is 1. LSAs with link-local flooding scope, and those LSAs with unknown LS type and U-bit set to 0 (treat the LSA as if it had link-local flooding scope) are stored in the appropriate interface structure.
When storing the LSA into the link-state database, a check must be made to see whether the LSA's contents have changed. Changes in contents are indicated exactly as in Section 13.2 of [Ref1]. When an LSA's contents have been changed, the following parts of the routing table must be recalculated, based on the LSA's LS type:
Router-LSAs, Network-LSAs, Intra-Area-Prefix-LSAs and Link-LSAs The entire routing table is recalculated, starting with the shortest path calculation for each area (see Section 3.8).
Inter-Area-Prefix-LSAs and Inter-Area-Router-LSAs
The best route to the destination described by the LSA must be
recalculated (see Section 16.5 in [Ref1]). If this destination is
an AS boundary router, it may also be necessary to re-examine all
the AS-external-LSAs.
AS-external-LSAs
The best route to the destination described by the AS-external-LSA
must be recalculated (see Section 16.6 in [Ref1]).
As in IPv4, any old instance of the LSA must be removed from the database when the new LSA is installed. This old instance must also be removed from all neighbors' Link state retransmission lists.
In IPv6 the definition of a self-originated LSA has been simplified from the IPv4 definition appearing in Sections 13.4 and 14.1 of [Ref1]. For IPv6, self-originated LSAs are those LSAs whose Advertising Router is equal to the router's own Router ID.
OSPF virtual links for IPv4 are described in Section 15 of [Ref1]. Virtual links are the same in IPv6, with the following exceptions:
The IPv6 OSPF routing calculation proceeds along the same lines as the IPv4 OSPF routing calculation, following the five steps specified by Section 16 of [Ref1]. High level differences between the IPv6 and IPv4 calculations include:
For each area, routing table entries have been created for the area's routers and transit links, in order to store the results of the area's shortest-path tree calculation (see Section 3.8.1). These entries are then used when processing intra-area-prefix-LSAs, inter- area-prefix-LSAs and inter-area-router-LSAs, as described in Section 3.8.2.
Events generated as a result of routing table changes (Section 16.7 of [Ref1]), and the equal-cost multipath logic (Section 16.8 of [Ref1]) are identical for both IPv4 and IPv6.
The IPv4 shortest path calculation is contained in Section 16.1 of [Ref1]. The graph used by the shortest-path tree calculation is identical for both IPv4 and IPv6. The graph's vertices are routers and transit links, represented by router-LSAs and network-LSAs respectively. A router is identified by its OSPF Router ID, while a transit link is identified by its Designated Router's Interface ID and OSPF Router ID. Both routers and transit links have associated routing table entries within the area (see Section 3.3).
Section 16.1 of [Ref1] splits up the shortest path calculations into two stages. First the Dijkstra calculation is performed, and then the stub links are added onto the tree as leaves. The IPv6 calculation maintains this split.
The Dijkstra calculation for IPv6 is identical to that specified for IPv4, with the following exceptions (referencing the steps from the Dijkstra calculation as described in Section 16.1 of [Ref1]):
The next stage of the shortest path calculation proceeds similarly to the two steps of the second stage of Section 16.1 in [Ref1]. However, instead of examining the stub links within router-LSAs, the list of the area's intra-area-prefix-LSAs is examined. A prefix advertisement whose "NU-bit" is set should not be included in the routing calculation. The cost of any advertised prefix is the sum of the prefix' advertised metric plus the cost to the transit vertex (either router or transit network) identified by intra-area-prefix-LSA's Referenced LS type, Referenced Link State ID and Referenced Advertising Router fields. This latter cost is stored in the transit vertex' routing table entry for the area.
In IPv6, the calculation of the next hop's IPv6 address (which will be a link-local address) proceeds along the same lines as the IPv4 next hop calculation (see Section 16.1.1 of [Ref1]). The only difference is in calculating the next hop IPv6 address for a router
(call it Router X) which shares a link with the calculating router. In this case the calculating router assigns the next hop IPv6 address to be the link-local interface address contained in Router X's Link- LSA (see Section A.4.8) for the link. This procedure is necessary since on some links, such as NBMA links, the two routers need not be neighbors, and therefore might not be exchanging OSPF Hellos.
Calculation of inter-area routes for IPv6 proceeds along the same lines as the IPv4 calculation in Section 16.2 of [Ref1], with the following modifications:
When a single inter-area-prefix-LSA or inter-area-router-LSA has changed, the incremental calculations outlined in Section 16.5 of [Ref1] can be performed instead of recalculating the entire routing table.
Examination of transit areas' summary-LSAs in IPv6 proceeds along the same lines as the IPv4 calculation in Section 16.3 of [Ref1], modified in the same way as the IPv6 inter-area route calculation in Section 3.8.2.
The IPv6 AS external route calculation proceeds along the same lines as the IPv4 calculation in Section 16.4 of [Ref1], with the following exceptions:
When a single AS-external-LSA has changed, the incremental calculations outlined in Section 16.6 of [Ref1] can be performed instead of recalculating the entire routing table.
In OSPF for IPv6, a router may have multiple interfaces to a single link. All interfaces are involved in the reception and transmission of data traffic, however only a single interface sends and receives OSPF control traffic. In more detail:
[Ref1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[Ref2] McKenzie, A., "ISO Transport Protocol specification ISO DP 8073", RFC 905, April 1984.
[Ref3] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB using SMIv2", RFC 2233, November 1997.
[Ref4] Fuller, V., Li, T, Yu, J. and K. Varadhan, "Classless Inter- Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
[Ref5] Varadhan, K., Hares, S. and Y. Rekhter, "BGP4/IDRP for IP--- OSPF Interaction", RFC 1745, December 1994
[Ref6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[Ref7] deSouza, O. and M. Rodrigues, "Guidelines for Running OSPF Over Frame Relay Networks", RFC 1586, March 1994.
[Ref8] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[Ref9] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587, March 1994.
[Ref10] Ferguson, D., "The OSPF External Attributes LSA", unpublished.
[Ref11] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995.
[Ref12] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[Ref13] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[Ref14] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[Ref15] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[Ref16] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification" RFC 2463, December 1998.
[Ref17] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[Ref18] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[Ref19] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[Ref20] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
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.
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:
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.
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].
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.
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.
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.
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.
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