diff options
Diffstat (limited to 'doc/rfc/rfc2740.txt')
| -rw-r--r-- | doc/rfc/rfc2740.txt | 4483 |
1 files changed, 4483 insertions, 0 deletions
diff --git a/doc/rfc/rfc2740.txt b/doc/rfc/rfc2740.txt new file mode 100644 index 0000000..bb70f46 --- /dev/null +++ b/doc/rfc/rfc2740.txt @@ -0,0 +1,4483 @@ + + + + + + +Network Working Group R. Coltun +Requests for Comments: 2740 Siara Systems +Category: Standards Track D. Ferguson + Juniper Networks + J. Moy + Sycamore Networks + December 1999 + + + OSPF for IPv6 + +Status of this Memo + + 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 Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +Abstract + + 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. + + + + + + +Coltun, et al. Standards Track [Page 1] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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. + +Table of Contents + + 1 Introduction ........................................... 4 + 1.1 Terminology ............................................ 4 + 2 Differences from OSPF for IPv4 ......................... 4 + 2.1 Protocol processing per-link, not per-subnet ........... 5 + 2.2 Removal of addressing semantics ........................ 5 + 2.3 Addition of Flooding scope ............................. 5 + 2.4 Explicit support for multiple instances per link ....... 6 + 2.5 Use of link-local addresses ............................ 6 + 2.6 Authentication changes ................................. 7 + 2.7 Packet format changes .................................. 7 + 2.8 LSA format changes ..................................... 8 + 2.9 Handling unknown LSA types ............................ 10 + 2.10 Stub area support ..................................... 10 + 2.11 Identifying neighbors by Router ID .................... 11 + 3 Implementation details ................................ 11 + 3.1 Protocol data structures .............................. 12 + 3.1.1 The Area Data structure ............................... 13 + 3.1.2 The Interface Data structure .......................... 13 + 3.1.3 The Neighbor Data Structure ........................... 14 + 3.2 Protocol Packet Processing ............................ 15 + 3.2.1 Sending protocol packets .............................. 15 + 3.2.1.1 Sending Hello packets ................................. 16 + 3.2.1.2 Sending Database Description Packets .................. 17 + 3.2.2 Receiving protocol packets ............................ 17 + 3.2.2.1 Receiving Hello Packets ............................... 19 + 3.3 The Routing table Structure ........................... 19 + 3.3.1 Routing table lookup .................................. 20 + 3.4 Link State Advertisements ............................. 20 + 3.4.1 The LSA Header ........................................ 21 + 3.4.2 The link-state database ............................... 22 + 3.4.3 Originating LSAs ...................................... 22 + 3.4.3.1 Router-LSAs ........................................... 25 + 3.4.3.2 Network-LSAs .......................................... 27 + 3.4.3.3 Inter-Area-Prefix-LSAs ................................ 28 + 3.4.3.4 Inter-Area-Router-LSAs ................................ 29 + 3.4.3.5 AS-external-LSAs ...................................... 29 + 3.4.3.6 Link-LSAs ............................................. 31 + 3.4.3.7 Intra-Area-Prefix-LSAs ................................ 32 + 3.5 Flooding .............................................. 35 + 3.5.1 Receiving Link State Update packets ................... 36 + 3.5.2 Sending Link State Update packets ..................... 36 + 3.5.3 Installing LSAs in the database ....................... 38 + + + +Coltun, et al. Standards Track [Page 2] + +RFC 2740 OSPF for IPv6 December 1999 + + + 3.6 Definition of self-originated LSAs .................... 39 + 3.7 Virtual links ......................................... 39 + 3.8 Routing table calculation ............................. 39 + 3.8.1 Calculating the shortest path tree for an area ........ 40 + 3.8.1.1 The next hop calculation .............................. 41 + 3.8.2 Calculating the inter-area routes ..................... 42 + 3.8.3 Examining transit areas' summary-LSAs ................. 42 + 3.8.4 Calculating AS external routes ........................ 42 + 3.9 Multiple interfaces to a single link .................. 43 + References ............................................ 44 + A OSPF data formats ..................................... 46 + A.1 Encapsulation of OSPF packets ......................... 46 + A.2 The Options field ..................................... 47 + A.3 OSPF Packet Formats ................................... 48 + A.3.1 The OSPF packet header ................................ 49 + A.3.2 The Hello packet ...................................... 50 + A.3.3 The Database Description packet ....................... 52 + A.3.4 The Link State Request packet ......................... 54 + A.3.5 The Link State Update packet .......................... 55 + A.3.6 The Link State Acknowledgment packet .................. 56 + A.4 LSA formats ........................................... 57 + A.4.1 IPv6 Prefix Representation ............................ 58 + A.4.1.1 Prefix Options ........................................ 58 + A.4.2 The LSA header ........................................ 59 + A.4.2.1 LS type ............................................... 60 + A.4.3 Router-LSAs ........................................... 61 + A.4.4 Network-LSAs .......................................... 64 + A.4.5 Inter-Area-Prefix-LSAs ................................ 65 + A.4.6 Inter-Area-Router-LSAs ................................ 66 + A.4.7 AS-external-LSAs ...................................... 67 + A.4.8 Link-LSAs ............................................. 69 + A.4.9 Intra-Area-Prefix-LSAs ................................ 71 + B Architectural Constants ............................... 73 + C Configurable Constants ................................ 73 + C.1 Global parameters ..................................... 73 + C.2 Area parameters ....................................... 74 + C.3 Router interface parameters ........................... 75 + C.4 Virtual link parameters ............................... 77 + C.5 NBMA network parameters ............................... 77 + C.6 Point-to-MultiPoint network parameters ................ 78 + C.7 Host route parameters ................................. 78 + Security Considerations ............................... 79 + Authors' Addresses .................................... 79 + Full Copyright Statement .............................. 80 + + + + + + + +Coltun, et al. Standards Track [Page 3] + +RFC 2740 OSPF for IPv6 December 1999 + + +1. Introduction + + 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. + +1.1. Terminology + + 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. + +2. Differences from OSPF for IPv4 + + 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]. + + + + + + + + + + +Coltun, et al. Standards Track [Page 4] + +RFC 2740 OSPF for IPv6 December 1999 + + +2.1. Protocol processing per-link, not per-subnet + + 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. + +2.2. Removal of addressing semantics + + 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: + + o IPv6 Addresses are not present in OSPF packets, except in + LSA payloads carried by the Link State Update Packets. See + Section 2.7 for details. + + o Router-LSAs and Network-LSAs no longer contain network + addresses, but simply express topology information. See + Section 2.8 for details. + + o OSPF Router IDs, Area IDs and LSA Link State IDs remain at + the IPv4 size of 32-bits. They can no longer be assigned as + (IPv6) addresses. + + o Neighboring routers are now always identified by Router ID, + where previously they had been identified by IP address on + broadcast and NBMA "networks". + +2.3. Addition of Flooding scope + + 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: + + + + + + + +Coltun, et al. Standards Track [Page 5] + +RFC 2740 OSPF for IPv6 December 1999 + + + o Link-local scope. LSA is flooded only on the local link, and + no further. Used for the new Link-LSA (see Section A.4.8). + + o Area scope. LSA is flooded throughout a single OSPF area + only. Used for Router-LSAs, Network-LSAs, Inter-Area-Prefix- + LSAs, Inter-Area-Router-LSAs and Intra-Area-Prefix-LSAs. + + o AS scope. LSA is flooded throughout the routing domain. Used + for AS-external-LSAs. + +2.4. Explicit support for multiple instances per link + + 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. + +2.5. Use of link-local addresses + + 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. + + + + +Coltun, et al. Standards Track [Page 6] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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). + +2.6. Authentication changes + + 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). + +2.7. Packet format changes + + 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: + + o The OSPF version number has been increased from 2 to 3. + + o The Options field in Hello Packets and Database description Packet + has been expanded to 24-bits. + + o The Authentication and AuType fields have been removed from the + OSPF packet header (see Section 2.6). + + o The Hello packet now contains no address information at all, and + includes an Interface ID which the originating router has assigned + to uniquely identify (among its own interfaces) its interface to + the link. This Interface ID becomes the Netowrk-LSA's Link State + ID, should the router become Designated-Router on the link. + + + + + + +Coltun, et al. Standards Track [Page 7] + +RFC 2740 OSPF for IPv6 December 1999 + + + o Two option bits, the "R-bit" and the "V6-bit", have been added to + the Options field for processing Router-LSAs during the SPF + calculation (see Section A.2). If the "R-bit" is clear an OSPF + speaker can participate in OSPF topology distribution without + being used to forward transit traffic; this can be used in multi- + homed hosts that want to participate in the routing protocol. The + V6-bit specializes the R-bit; if the V6-bit is clear an OSPF + speaker can participate in OSPF topology distribution without + being used to forward IPv6 datagrams. If the R-bit is set and the + V6-bit is clear, IPv6 datagrams are not forwarded but diagrams + belonging to another protocol family may be forwarded. + + o TheOSPF packet header now includes an "Instance ID" which allows + multiple OSPF protocol instances to be run on a single link (see + Section 2.4). + +2.8. LSA format changes + + 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: + + o The Options field has been removed from the LSA header, expanded + to 24 bits, and moved into the body of Router-LSAs, Network-LSAs, + Inter-Area-Router-LSAs and Link-LSAs. See Section A.2 for details. + + o The LSA Type field has been expanded (into the former Options + space) to 16 bits, with the upper three bits encoding flooding + scope and the handling of unknown LSA types (see Section 2.9). + + o Addresses in LSAs are now expressed as [prefix, prefix length] + instead of [address, mask] (see Section A.4.1). The default route + is expressed as a prefix with length 0. + + o The Router and Network LSAs now have no address information, and + are network-protocol-independent. + + o Router interface information may be spread across multiple Router + LSAs. Receivers must concatenate all the Router-LSAs originated by + a given router when running the SPF calculation. + + + + + + +Coltun, et al. Standards Track [Page 8] + +RFC 2740 OSPF for IPv6 December 1999 + + + o A new LSA called the Link-LSA has been introduced. The 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, 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. See Section A.4.8 for details. + + 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. + + o The Options field in the Network LSA is set to the logical OR of + the Options that each router on the link advertises in its Link- + LSA. + + o Type-3 summary-LSAs have been renamed "Inter-Area-Prefix-LSAs". + Type-4 summary LSAs have been renamed "Inter-Area-Router-LSAs". + + o The Link State ID in Inter-Area-Prefix-LSAs, Inter-Area-Router- + LSAs and AS-external-LSAs has lost its addressing semantics, and + now serves solely to identify individual pieces of the Link State + Database. All addresses or Router IDs that were formerly expressed + by the Link State ID are now carried in the LSA bodies. + + o Network-LSAs and Link-LSAs are the only LSAs whose Link State ID + carries additional meaning. For these LSAs, the Link State ID is + always the Interface ID of the originating router on the link + being described. For this reason, Network-LSAs and Link-LSAs are + now the only LSAs whose size cannot be limited: a Network-LSA must + list all routers connected to the link, and a Link-LSA must list + all of a router's addresses on the link. + + o A new LSA called the Intra-Area-Prefix-LSA has been introduced. + This LSA carries all IPv6 prefix information that in IPv4 is + included in Router-LSAs and Network-LSAs. See Section A.4.9 for + details. + + + + + +Coltun, et al. Standards Track [Page 9] + +RFC 2740 OSPF for IPv6 December 1999 + + + o Inclusion of a forwarding address in AS-external-LSAs is now + optional, as is the inclusion of an external route tag (see + [Ref5]). In addition, AS-external-LSAs can now reference another + LSA, for inclusion of additional route attributes that are outside + the scope of the OSPF protocol itself. For example, this can be + used to attach BGP path attributes to external routes as proposed + in [Ref10]. + +2.9. Handling unknown LSA types + + 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. + +2.10. Stub area support + + 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. + + + + +Coltun, et al. Standards Track [Page 10] + +RFC 2740 OSPF for IPv6 December 1999 + + +2.11. Identifying neighbors by Router ID + + 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. + +3. Implementation details + + 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: + + o Both IPv4 and IPv6 use OSPF packet types described in Section 4.3 + of [Ref1], namely: Hello, Database Description, Link State + Request, Link State Update and Link State Acknowledgment packets. + While in some cases (e.g., Hello packets) their format has changed + somewhat, the functions of the various packet types remains the + same. + + o The system requirements for an OSPF implementation remain + unchanged, although OSPF for IPv6 requires an IPv6 protocol stack + (from the network layer on down) since it runs directly over the + IPv6 network layer. + + + +Coltun, et al. Standards Track [Page 11] + +RFC 2740 OSPF for IPv6 December 1999 + + + o The discovery and maintenance of neighbor relationships, and the + selection and establishment of adjacencies remain the same. This + includes election of the Designated Router and Backup Designated + Router on broadcast and NBMA links. These mechanisms are described + in Sections 7, 7.1, 7.2, 7.3, 7.4 and 7.5 of [Ref1]. + + o The link types (or equivalently, interface types) supported by + OSPF remain unchanged, namely: point-to-point, broadcast, NBMA, + Point-to-MultiPoint and virtual links. + + o The interface state machine, including the list of OSPF interface + states and events, and the Designated Router and Backup Designated + Router election algorithm, remain unchanged. These are described + in Sections 9.1, 9.2, 9.3 and 9.4 of [Ref1]. + + o The neighbor state machine, including the list of OSPF neighbor + states and events, remain unchanged. These are described in + Sections 10.1, 10.2, 10.3 and 10.4 of [Ref1]. + + o Aging of the link-state database, as well as flushing LSAs from + the routing domain through the premature aging process, remains + unchanged from the description in Sections 14 and 14.1 of [Ref1]. + + 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. + +3.1. Protocol data structures + + 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: + + o All LSAs with known LS type and AS flooding scope appear in the + top-level data structure, instead of belonging to a specific area + or link. AS-external-LSAs are the only LSAs defined by this + specification which have AS flooding scope. LSAs with unknown LS + type, U-bit set to 1 (flood even when unrecognized) and AS + flooding scope also appear in the top-level data structure. + + + + + + + +Coltun, et al. Standards Track [Page 12] + +RFC 2740 OSPF for IPv6 December 1999 + + +3.1.1. The Area Data structure + + 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. + +3.1.2. The Interface 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. + + + + +Coltun, et al. Standards Track [Page 13] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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]. + +3.1.3. The Neighbor Data Structure + + 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. + + + +Coltun, et al. Standards Track [Page 14] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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]. + +3.2. Protocol Packet Processing + + 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. + +3.2.1. Sending protocol packets + + 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. + + + +Coltun, et al. Standards Track [Page 15] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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. + +3.2.1.1. Sending Hello packets + + IPv6 changes the way OSPF Hello packets are sent in the following + ways (compare to Section 9.5 of [Ref1]): + + o Before the Hello Packet is sent out an interface, the interface's + Interface ID must be copied into the Hello Packet. + + o The Hello Packet no longer contains an IP network mask, as OSPF + for IPv6 runs per-link instead of per-subnet. + + o The choice of Designated Router and Backup Designated Router are + now indicated within Hellos by their Router IDs, instead of by + 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. + + + + +Coltun, et al. Standards Track [Page 16] + +RFC 2740 OSPF for IPv6 December 1999 + + + o The Options field within Hello packets has moved around, getting + larger in the process. More options bits are now possible. Those + that must be set correctly in Hello packets are: The E-bit is set + if and only if the interface attaches to a non-stub area, the N- + bit is set if and only if the interface attaches to an NSSA area + (see [Ref9]), and the DC- bit is set if and only if the router + wishes to suppress the sending of future Hellos over the interface + (see [Ref11]). Unrecognized bits in the Hello Packet's Options + field should be cleared. + + 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]. + +3.2.1.2. Sending Database Description Packets + + The sending of Database Description packets differs from Section 10.8 + of [Ref1] in the following ways: + + o The Options field within Database Description packets has moved + around, getting larger in the process. More options bits are now + possible. Those that must be set correctly in Database Description + packets are: The MC-bit is set if and only if the router is + forwarding multicast datagrams according to the MOSPF + specification in [Ref7], and the DC-bit is set if and only if the + router wishes to suppress the sending of Hellos over the interface + (see [Ref11]). Unrecognized bits in the Database Description + Packet's Options field should be cleared. + +3.2.2. Receiving protocol packets + + 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: + + o The packet's IP destination address must be one of the IPv6 + unicast addresses associated with the receiving interface (this + includes link-local addresses), or one of the IP multicast + addresses AllSPFRouters or AllDRouters. + + + +Coltun, et al. Standards Track [Page 17] + +RFC 2740 OSPF for IPv6 December 1999 + + + o The Next Header field of the immediately encapsulating IPv6 header + must specify the OSPF protocol (89). + + o Any encapsulating IP Authentication Headers (see [Ref19]) and the + IP Encapsulating Security Payloads (see [Ref20]) must be processed + and/or verified to ensure integrity and + authentication/confidentiality of OSPF routing exchanges. + + o Locally originated packets should not be passed on to OSPF. That + is, the source IPv6 address should be examined to make sure this + is not a multicast packet that the router itself generated. + + 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: + + o The version number field must specify protocol version 3. + + o The standard IPv6 16-bit one's complement checksum, covering the + entire OSPF packet and prepended IPv6 pseudo-header, must be + verified (see Section A.3.1). + + o The Area ID found in the OSPF header must be verified. If both of + the following cases fail, the packet should be discarded. The + Area ID specified in the header must either: + + (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). + + o The Instance ID specified in the OSPF header must match the + receiving interface's Instance ID. + + + + + +Coltun, et al. Standards Track [Page 18] + +RFC 2740 OSPF for IPv6 December 1999 + + + o Packets whose IP destination is AllDRouters should only be + accepted if the state of the receiving interface is DR or Backup + (see Section 9.1). + + 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. + +3.2.2.1. Receiving Hello Packets + + The receive processing of Hello Packets differs from Section 10.5 of + [Ref1] in the following ways: + + o On all link types (e.g., broadcast, NBMA, point-to- point, etc), + neighbors are identified solely by their OSPF Router ID. For all + link types except virtual links, the Neighbor IP address is set to + the IPv6 source address in the IPv6 header of the received OSPF + Hello packet. + + o There is no longer a Network Mask field in the Hello Packet. + + o The neighbor's choice of Designated Router and Backup Designated + Router is now encoded as an OSPF Router ID instead of an IP + interface address. + +3.3. The Routing table Structure + + 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). + + + + +Coltun, et al. Standards Track [Page 19] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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: + + o An entry for each router in the area. Routers are identified by + their OSPF router ID. These routing table entries hold the set of + shortest paths through a given area to a given router, which in + turn allows calculation of paths to the IPv6 prefixes advertised + by that router in Intra-area-prefix-LSAs. If the router is also an + area-border router, these entries are also used to calculate paths + for inter-area address prefixes. If in addition the router is the + other endpoint of a virtual link, the routing table entry + describes the cost and viability of the virtual link. + + o An entry for each transit link in the area. Transit links have + associated network-LSAs. Both the transit link and the network-LSA + are identified by a combination of the Designated Router's + Interface ID on the link and the Designated Router's OSPF Router + ID. These routing table entries allow later calculation of paths + to IP prefixes advertised for the transit link in intra-area- + prefix-LSAs. + + 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). + +3.3.1. Routing table lookup + + Routing table lookup (i.e., determining the best matching routing + table entry during IP forwarding) is the same for IPv6 as for IPv4. + +3.4. Link State Advertisements + + 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- + + + +Coltun, et al. Standards Track [Page 20] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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. + +3.4.1. The LSA Header + + 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. + + + +Coltun, et al. Standards Track [Page 21] + +RFC 2740 OSPF for IPv6 December 1999 + + +3.4.2. The link-state database + + 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. + +3.4.3. Originating LSAs + + 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: + + o The state of one of the router's interfaces changes. The router + may need to (re)originate or flush its Link-LSA and one or more + router-LSAs and/or intra-area-prefix-LSAs. + + o The identity of a link's Designated Router changes. The router may + need to (re)originate or flush the link's network-LSA and one or + more router-LSAs and/or intra-area-prefix-LSAs. + + + + + + +Coltun, et al. Standards Track [Page 22] + +RFC 2740 OSPF for IPv6 December 1999 + + + o A neighbor transitions to/from "Full" state. The router may need + to (re)originate or flush the link's network-LSA and one or more + router-LSAs and/or intra-area-prefix-LSAs. + + o The Interface ID of a neighbor changes. This may cause a new + instance of a router-LSA to be originated for the associated area, + and the reorigination of one or more intra-area-prefix-LSAs. + + o A new prefix is added to an attached link, or a prefix is deleted + (both through configuration). This causes the router to + reoriginate its link-LSA for the link, or, if it is the only + router attached to the link, causes the router to reoriginate an + intra-area-prefix-LSA. + + o A new link-LSA is received, causing the link's collection of + prefixes to change. If the router is Designated Router for the + link, it originates a new intra-area-prefix-LSA. + + 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. + + + + + + + + + + + + + + + + + + + + + + + +Coltun, et al. Standards Track [Page 23] + +RFC 2740 OSPF for IPv6 December 1999 + + + .......................................... + . 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 + + + + +Coltun, et al. Standards Track [Page 24] + +RFC 2740 OSPF for IPv6 December 1999 + + +3.4.3.1. Router-LSAs + + 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. + + + + + + + + +Coltun, et al. Standards Track [Page 25] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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 + + + +Coltun, et al. Standards Track [Page 26] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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. + +3.4.3.2. Network-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: + + o An IPv6 network-LSA's Link State ID is set to the Interface ID of + the Designated Router on the link. + + o IPv6 network-LSAs do not contain a Network Mask. All addressing + information formerly contained in the IPv4 network-LSA has now + been consigned to intra-Area-Prefix-LSAs. + + o The Options field in the network-LSA is set to the logical OR of + the Options fields contained within the link's associated link- + LSAs. In this way, the network link exhibits a capability when at + least one of the link's routers requests that the capability be + asserted. + + 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 + + + + + +Coltun, et al. Standards Track [Page 27] + +RFC 2740 OSPF for IPv6 December 1999 + + +3.4.3.3. Inter-Area-Prefix-LSAs + + 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: + + o The Link State ID of an inter-area-prefix-LSA has lost all of its + addressing semantics, and instead simply serves to distinguish + multiple inter-area-prefix-LSAs that are originated by the same + router. + + o The prefix is described by the PrefixLength, PrefixOptions and + Address Prefix fields embedded within the LSA body. Network Mask + is no longer specified. + + o The NU-bit in the PrefixOptions field should be clear. The coding + of the MC-bit depends upon whether, and if so how, MOSPF is + operating in the routing domain (see [Ref8]). + + o Link-local addresses must never be advertised in inter-area- + prefix-LSAs. + + 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 + + + + + +Coltun, et al. Standards Track [Page 28] + +RFC 2740 OSPF for IPv6 December 1999 + + +3.4.3.4. Inter-Area-Router-LSAs + + 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: + + o The Link State ID of an inter-area-router-LSA is no longer the + destination router's OSPF Router ID, but instead simply serves to + distinguish multiple inter-area-router-LSAs that are originated by + the same router. The destination router's Router ID is now found + in the body of the LSA. + + o The Options field in an inter-area-router-LSA should be set equal + to the Options field contained in the destination router's own + router-LSA. The Options field thus describes the capabilities + supported by the destination router. + + 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 + +3.4.3.5. AS-external-LSAs + + 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: + + + + +Coltun, et al. Standards Track [Page 29] + +RFC 2740 OSPF for IPv6 December 1999 + + + o The Link State ID of an AS-external-LSA has lost all of its + addressing semantics, and instead simply serves to distinguish + multiple AS-external-LSAs that are originated by the same router. + + o The prefix is described by the PrefixLength, PrefixOptions and + Address Prefix fields embedded within the LSA body. Network Mask + is no longer specified. + + o The NU-bit in the PrefixOptions field should be clear. The coding + of the MC-bit depends upon whether, and if so how, MOSPF is + operating in the routing domain (see [Ref8]). + + o Link-local addresses can never be advertised in AS-external-LSAs. + + o The forwarding address is present in the AS-external-LSA if and + only if the AS-external-LSA's bit F is set. + + o The external route tag is present in the AS-external-LSA if and + only if the AS-external-LSA's bit T is set. + + o The capability for an AS-external-LSA to reference another LSA has + been included, by inclusion of the Referenced LS Type field and + the optional Referenced Link State ID field (the latter present if + and only if Referenced LS Type is non-zero). This capability is + for future use; for now Referenced LS Type should be set to 0 and + received non-zero values for this field should be ignored. + + 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 + + + +Coltun, et al. Standards Track [Page 30] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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 + +3.4.3.6. Link-LSAs + + 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: + + o The Link State ID is set to the router's Interface ID on Link L. + + o The Router Priority of the router's interface to Link L is + inserted into the Link-LSA. + + o The Link-LSA's Options field is set to those bits that the router + wishes set in Link L's Network LSA. + + o The router inserts its link-local address on Link L into the + Link-LSA. This information will be used when the other routers on + Link L do their next hop calculations (see Section 3.8.1.1). + + o Each IPv6 address prefix that has been configured into the router + for Link L is added to the Link-LSA, by specifying values for + PrefixLength, PrefixOptions, and Address Prefix fields. + + 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. + + + + +Coltun, et al. Standards Track [Page 31] + +RFC 2740 OSPF for IPv6 December 1999 + + + ; 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 + +3.4.3.7. Intra-Area-Prefix-LSAs + + 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: + + o In order to indicate that the prefixes are to be associated with + the Link L, the fields Referenced LS type, Referenced Link State + ID, and Referenced + + 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. + + o Each Link-LSA associated with Link L is examined (these are in the + Designated Router's interface structure for Link L). If the Link- + LSA's Advertising Router is fully adjacent to the Designated + Router, the list of prefixes in the Link-LSA is copied into the + + + +Coltun, et al. Standards Track [Page 32] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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. + + o The "# prefixes" field is set to the number of prefixes that the + router has copied into the LSA. If necessary, the list of prefixes + can be spread across multiple intra-area-prefix-LSAs in order to + keep the LSA size small. + + 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: + + o In order to indicate that the prefixes are to be associated with + the Router RTX itself, RTX sets Referenced LS type to 0x2001, + Referenced Link State ID to 0, and Referenced Advertising Router + to RTX's own Router ID. + + o Router RTX examines its list of interfaces to the area. If the + interface is in state Down, its prefixes are not included. If the + interface has been reported in RTX's router-LSA as a Type 2 link + description (link to transit network), its prefixes are not + included (they will be included in the intra-area-prefix-LSA for + the link instead). If the interface type is Point-to-MultiPoint, + or the interface is in state Loopback, or the interface connects + to a point-to-point link which has not been assigned a prefix, + then the site-local and global scope IPv6 addresses associated + with the interface (if any) are copied into the intra-area- + prefix-LSA, setting the LA-bit in the PrefixOptions field, and + setting the PrefixLength to 128 and the Metric to 0. Otherwise, + the list of site-local and global prefixes configured in RTX for + the link are copied into the intra-area-prefix-LSA by specifying + the PrefixLength, PrefixOptions, and Address Prefix fields. The + Metric field for each of these prefixes is set to the interface's + output cost. + + o RTX adds the IPv6 prefixes for any directly attached hosts + belonging to the area (see Section C.7) to the intra-area-prefix- + LSA. + + + + + +Coltun, et al. Standards Track [Page 33] + +RFC 2740 OSPF for IPv6 December 1999 + + + o If RTX has one or more virtual links configured through the area, + it includes one of its site-local or global scope IPv6 interface + addresses in the LSA (if it hasn't already), setting the LA-bit in + the PrefixOptions field, and setting the PrefixLength to 128 and + the Metric to 0. This information will be used later in the + routing calculation so that the two ends of the virtual link can + discover each other's IPv6 addresses. + + o The "# prefixes" field is set to the number of prefixes that the + router has copied into the LSA. If necessary, the list of prefixes + can be spread across multiple intra-area-prefix-LSAs in order to + keep the LSA size small. + + 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 + + + + + +Coltun, et al. Standards Track [Page 34] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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. + +3.5. Flooding + + 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. + + + + + + +Coltun, et al. Standards Track [Page 35] + +RFC 2740 OSPF for IPv6 December 1999 + + +3.5.1. Receiving Link State Update packets + + 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. + +3.5.2. Sending Link State Update packets + + 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: + + o The LSA's flooding scope. + + o For LSAs with area or link-local flooding scoping, the particular + area or interface that the LSA is associated with. + + o Whether the LSA has a recognized LS type. + + o The setting of the U-bit in the LS type. If the U-bit is set to 0, + unrecognized LS types are treated as having link-local scope. If + set to 1, unrecognized LS types are stored and flooded as if they + were recognized. + + + +Coltun, et al. Standards Track [Page 36] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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 + + + +Coltun, et al. Standards Track [Page 37] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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]). + +3.5.3. Installing LSAs in the database + + 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. + + + + + + + + + +Coltun, et al. Standards Track [Page 38] + +RFC 2740 OSPF for IPv6 December 1999 + + +3.6. Definition of self-originated LSAs + + 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. + +3.7. Virtual links + + OSPF virtual links for IPv4 are described in Section 15 of [Ref1]. + Virtual links are the same in IPv6, with the following exceptions: + + o LSAs having AS flooding scope are never flooded over virtual + adjacencies, nor are LSAs with AS flooding scope summarized over + virtual adjacencies during the Database Exchange process. This is + a generalization of the IPv4 treatment of AS-external-LSAs. + + o The IPv6 interface address of a virtual link must be an IPv6 + address having site-local or global scope, instead of the link- + local addresses used by other interface types. This address is + used as the IPv6 source for OSPF protocol packets sent over the + virtual link. + + o Likewise, the virtual neighbor's IPv6 address is an IPv6 address + with site-local or global scope. To enable the discovery of a + virtual neighbor's IPv6 address during the routing calculation, + the neighbor advertises its virtual link's IPv6 interface address + in an Intra-Area-Prefix-LSA originated for the virtual link's + transit area (see Sections 3.4.3.7 and 3.8.1). + + o Like all other IPv6 OSPF interfaces, virtual links are assigned + unique (within the router) Interface IDs. These are advertised in + Hellos sent over the virtual link, and in the router's router- + LSAs. + +3.8. Routing table calculation + + 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: + + o Prefix information has been removed from router-LSAs, and now is + advertised in intra-area-prefix-LSAs. Whenever [Ref1] specifies + that stub networks within router-LSAs be examined, IPv6 will + instead examine prefixes within intra-area-prefix-LSAs. + + + + + +Coltun, et al. Standards Track [Page 39] + +RFC 2740 OSPF for IPv6 December 1999 + + + o Type 3 and 4 summary-LSAs have been renamed inter-area-prefix-LSAs + and inter-area-router-LSAs (respectively). + + o Addressing information is no longer encoded in Link State IDs, and + must instead be found within the body of LSAs. + + o In IPv6, a router can originate multiple router-LSAs within a + single area, distinguished by Link State ID. These router-LSAs + must be treated as a single aggregate by the area's shortest path + calculation (see Section 3.8.1). + + 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. + +3.8.1. Calculating the shortest path tree for an area + + 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]): + + o The Vertex ID for a router is the OSPF Router ID. The Vertex ID + for a transit network is a combination of the Interface ID and + OSPF Router ID of the network's Designated Router. + + + + + + +Coltun, et al. Standards Track [Page 40] + +RFC 2740 OSPF for IPv6 December 1999 + + + o In Step 2, when a router Vertex V has just been added to the + shortest path tree, there may be multiple LSAs associated with the + router. All Router-LSAs with Advertising Router set to V's OSPF + Router ID must processed as an aggregate, treating them as + fragments of a single large router-LSA. The Options field and the + router type bits (bits W, V, E and B) should always be taken from + "fragment" with the smallest Link State ID. + + o Step 2a is not needed in IPv6, as there are no longer stub network + links in router-LSAs. + + o In Step 2b, if W is a router, there may again be multiple LSAs + associated with the router. All Router-LSAs with Advertising + Router set to W's OSPF Router ID must processed as an aggregate, + treating them as fragments of a single large router-LSA. + + o In Step 4, there are now per-area routing table entries for each + of an area's routers, instead of just the area border routers. + These entries subsume all the functionality of IPv4's area border + router routing table entries, including the maintenance of virtual + links. When the router added to the area routing table in this + step is the other end of a virtual link, the virtual neighbor's IP + address is set as follows: The collection of intra-area-prefix- + LSAs originated by the virtual neighbor is examined, with the + virtual neighbor's IP address being set to the first prefix + encountered having the "LA-bit" set. + + o Routing table entries for transit networks, which are no longer + associated with IP networks, are also modified in Step 4. + + 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. + +3.8.1.1. The next hop calculation + + 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 + + + +Coltun, et al. Standards Track [Page 41] + +RFC 2740 OSPF for IPv6 December 1999 + + + (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. + +3.8.2. Calculating the inter-area routes + + 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: + + o The names of the Type 3 summary-LSAs and Type 4 summary-LSAs have + been changed to inter-area-prefix-LSAs and inter-area-router-LSAs + respectively. + + o The Link State ID of the above LSA types no longer encodes the + network or router described by the LSA. Instead, an address + prefix is contained in the body of an inter-area-prefix-LSA, and a + described router's OSPF Router ID is carried in the body of an + inter-area- router-LSA. + + o Prefixes having the "NU-bit" set in their Prefix Options field + should be ignored by the inter-area route calculation. + + 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. + +3.8.3. Examining transit areas' summary-LSAs + + 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. + +3.8.4. Calculating AS external routes + + 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: + + o The Link State ID of the AS-external-LSA types no longer encodes + the network described by the LSA. Instead, an address prefix is + contained in the body of an AS- external-LSA. + + + + +Coltun, et al. Standards Track [Page 42] + +RFC 2740 OSPF for IPv6 December 1999 + + + o The default route is described by AS-external-LSAs which advertise + zero length prefixes. + + o Instead of comparing the AS-external-LSA's Forwarding address + field to 0.0.0.0 to see whether a forwarding address has been + used, bit F of the external-LSA is examined. A forwarding address + is in use if and only if bit F is set. + + o Prefixes having the "NU-bit" set in their Prefix Options field + should be ignored by the inter-area route calculation. + + 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. + +3.9. Multiple interfaces to a single link + + 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: + + o Each of the multiple interfaces are assigned different Interface + IDs. In this way the router can automatically detect when + multiple interfaces attach to the same link, when receiving Hellos + from its own Router ID but with an Interface ID other than the + receiving interface's. + + o The router turns off the sending and receiving of OSPF packets + (that is, control traffic) on all but one of the interfaces to the + link. The choice of interface to send and receive control traffic + is implementation dependent; as one example, the interface with + the highest Interface ID could be chosen. If the router is + elected DR, it will be this interface's Interface ID that will be + used as the network-LSA's Link State ID. + + o All the multiple interfaces to the link will however appear in the + router-LSA. In addition, a Link-LSA will be generated for each of + the multiple interfaces. In this way, all interfaces will be + included in OSPF's routing calculations. + + o If the interface which is responsible for sending and receiving + control traffic fails, another will have to take over, reforming + all neighbor adjacencies from scratch. This failure can be + detected by the router itself, when the other interfaces to the + same link cease to hear the router's own Hellos. + + + + + +Coltun, et al. Standards Track [Page 43] + +RFC 2740 OSPF for IPv6 December 1999 + + +References + + [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. + + + + + +Coltun, et al. Standards Track [Page 44] + +RFC 2740 OSPF for IPv6 December 1999 + + + [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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Coltun, et al. Standards Track [Page 45] + +RFC 2740 OSPF for IPv6 December 1999 + + +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. + + + + + + +Coltun, et al. Standards Track [Page 46] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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. + + + + + +Coltun, et al. Standards Track [Page 47] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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. + + + +Coltun, et al. Standards Track [Page 48] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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. + + + + + + +Coltun, et al. Standards Track [Page 49] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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). + + + + + + + +Coltun, et al. Standards Track [Page 50] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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. + + + + + +Coltun, et al. Standards Track [Page 51] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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. + + + + + + + + + + + + + + + + + + + + + + + +Coltun, et al. Standards Track [Page 52] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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. + + + + +Coltun, et al. Standards Track [Page 53] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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]. + + + + + + + +Coltun, et al. Standards Track [Page 54] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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. + + + + + + + + + + + + + +Coltun, et al. Standards Track [Page 55] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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. + + + + +Coltun, et al. Standards Track [Page 56] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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. + + + + + + +Coltun, et al. Standards Track [Page 57] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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. + + + + + + + +Coltun, et al. Standards Track [Page 58] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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. + + + + + +Coltun, et al. Standards Track [Page 59] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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 + + + + + + + + +Coltun, et al. Standards Track [Page 60] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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. + + + + + + + + + + + + + + + +Coltun, et al. Standards Track [Page 61] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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). + + + +Coltun, et al. Standards Track [Page 62] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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). + + + + +Coltun, et al. Standards Track [Page 63] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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. + + + + + + + +Coltun, et al. Standards Track [Page 64] + +RFC 2740 OSPF for IPv6 December 1999 + + +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. + + + + +Coltun, et al. Standards Track [Page 65] + +RFC 2740 OSPF for IPv6 December 1999 + + +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. + + + + + + + + + + +Coltun, et al. Standards Track [Page 66] + +RFC 2740 OSPF for IPv6 December 1999 + + +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) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + +Coltun, et al. Standards Track [Page 67] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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. + + + + +Coltun, et al. Standards Track [Page 68] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Coltun, et al. Standards Track [Page 69] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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. + + + + + + +Coltun, et al. Standards Track [Page 70] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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. + + + + + + + + + + + + + + + + + + + + + + + +Coltun, et al. Standards Track [Page 71] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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. + + + + +Coltun, et al. Standards Track [Page 72] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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 + + + +Coltun, et al. Standards Track [Page 73] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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. + + + + + + + + +Coltun, et al. Standards Track [Page 74] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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. + + + + + + + +Coltun, et al. Standards Track [Page 75] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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 + + + + + +Coltun, et al. Standards Track [Page 76] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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: + + + +Coltun, et al. Standards Track [Page 77] + +RFC 2740 OSPF for IPv6 December 1999 + + + 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. + + + + + +Coltun, et al. Standards Track [Page 78] + +RFC 2740 OSPF for IPv6 December 1999 + + +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 + + + + + + + + + +Coltun, et al. Standards Track [Page 79] + +RFC 2740 OSPF for IPv6 December 1999 + + +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. + + + + + + + + + + + + + + + + + + + +Coltun, et al. Standards Track [Page 80] + |