diff options
Diffstat (limited to 'doc/rfc/rfc5340.txt')
| -rw-r--r-- | doc/rfc/rfc5340.txt | 5267 |
1 files changed, 5267 insertions, 0 deletions
diff --git a/doc/rfc/rfc5340.txt b/doc/rfc/rfc5340.txt new file mode 100644 index 0000000..87ad681 --- /dev/null +++ b/doc/rfc/rfc5340.txt @@ -0,0 +1,5267 @@ + + + + + + +Network Working Group R. Coltun +Request for Comments: 5340 Acoustra Productions +Obsoletes: 2740 D. Ferguson +Category: Standards Track Juniper Networks + J. Moy + Sycamore Networks, Inc + A. Lindem, Ed. + Redback Networks + July 2008 + + + 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. + +Abstract + + This document describes the modifications to OSPF to support version + 6 of the Internet Protocol (IPv6). The fundamental mechanisms of + OSPF (flooding, Designated Router (DR) election, area support, Short + Path First (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. These modifications will necessitate + incrementing the protocol version from version 2 to version 3. OSPF + for IPv6 is also referred to as OSPF version 3 (OSPFv3). + + Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as + described herein include the following. Addressing semantics have + been removed from OSPF packets and the basic Link State + Advertisements (LSAs). New LSAs have been created to carry IPv6 + addresses and prefixes. OSPF now runs on a per-link basis rather + than on a per-IP-subnet basis. Flooding scope for LSAs has been + generalized. Authentication has been removed from the OSPF protocol + and instead relies on IPv6's Authentication Header and Encapsulating + Security Payload (ESP). + + Even with larger IPv6 addresses, most packets in OSPF for IPv6 are + almost as compact as those in OSPF for IPv4. Most fields and 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 5340 OSPF for IPv6 July 2008 + + + All of OSPF for IPv4's optional capabilities, including demand + circuit support and Not-So-Stubby Areas (NSSAs), are also supported + in OSPF for IPv6. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 + 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Differences from OSPF for IPv4 . . . . . . . . . . . . . . . . 5 + 2.1. Protocol Processing Per-Link, Not Per-Subnet . . . . . . . 5 + 2.2. Removal of Addressing Semantics . . . . . . . . . . . . . 5 + 2.3. Addition of Flooding Scope . . . . . . . . . . . . . . . . 6 + 2.4. Explicit Support for Multiple Instances per Link . . . . . 6 + 2.5. Use of Link-Local Addresses . . . . . . . . . . . . . . . 7 + 2.6. Authentication Changes . . . . . . . . . . . . . . . . . . 7 + 2.7. Packet Format Changes . . . . . . . . . . . . . . . . . . 8 + 2.8. LSA Format Changes . . . . . . . . . . . . . . . . . . . . 9 + 2.9. Handling Unknown LSA Types . . . . . . . . . . . . . . . . 10 + 2.10. Stub/NSSA Area Support . . . . . . . . . . . . . . . . . . 11 + 2.11. Identifying Neighbors by Router ID . . . . . . . . . . . . 11 + 3. Differences with RFC 2740 . . . . . . . . . . . . . . . . . . 11 + 3.1. Support for Multiple Interfaces on the Same Link . . . . . 11 + 3.2. Deprecation of MOSPF for IPv6 . . . . . . . . . . . . . . 12 + 3.3. NSSA Specification . . . . . . . . . . . . . . . . . . . . 12 + 3.4. Stub Area Unknown LSA Flooding Restriction Deprecated . . 12 + 3.5. Link LSA Suppression . . . . . . . . . . . . . . . . . . . 12 + 3.6. LSA Options and Prefix Options Updates . . . . . . . . . . 13 + 3.7. IPv6 Site-Local Addresses . . . . . . . . . . . . . . . . 13 + 4. Implementation Details . . . . . . . . . . . . . . . . . . . . 13 + 4.1. Protocol Data Structures . . . . . . . . . . . . . . . . . 14 + 4.1.1. The Area Data Structure . . . . . . . . . . . . . . . 15 + 4.1.2. The Interface Data Structure . . . . . . . . . . . . . 15 + 4.1.3. The Neighbor Data Structure . . . . . . . . . . . . . 16 + 4.2. Protocol Packet Processing . . . . . . . . . . . . . . . . 17 + 4.2.1. Sending Protocol Packets . . . . . . . . . . . . . . . 17 + 4.2.1.1. Sending Hello Packets . . . . . . . . . . . . . . 18 + 4.2.1.2. Sending Database Description Packets . . . . . . . 19 + 4.2.2. Receiving Protocol Packets . . . . . . . . . . . . . . 19 + 4.2.2.1. Receiving Hello Packets . . . . . . . . . . . . . 21 + 4.3. The Routing table Structure . . . . . . . . . . . . . . . 22 + 4.3.1. Routing Table Lookup . . . . . . . . . . . . . . . . . 23 + 4.4. Link State Advertisements . . . . . . . . . . . . . . . . 23 + 4.4.1. The LSA Header . . . . . . . . . . . . . . . . . . . . 23 + 4.4.2. The Link-State Database . . . . . . . . . . . . . . . 24 + 4.4.3. Originating LSAs . . . . . . . . . . . . . . . . . . . 25 + 4.4.3.1. LSA Options . . . . . . . . . . . . . . . . . . . 27 + 4.4.3.2. Router-LSAs . . . . . . . . . . . . . . . . . . . 27 + + + +Coltun, et al. Standards Track [Page 2] + +RFC 5340 OSPF for IPv6 July 2008 + + + 4.4.3.3. Network-LSAs . . . . . . . . . . . . . . . . . . . 29 + 4.4.3.4. Inter-Area-Prefix-LSAs . . . . . . . . . . . . . . 30 + 4.4.3.5. Inter-Area-Router-LSAs . . . . . . . . . . . . . . 31 + 4.4.3.6. AS-External-LSAs . . . . . . . . . . . . . . . . . 32 + 4.4.3.7. NSSA-LSAs . . . . . . . . . . . . . . . . . . . . 33 + 4.4.3.8. Link-LSAs . . . . . . . . . . . . . . . . . . . . 34 + 4.4.3.9. Intra-Area-Prefix-LSAs . . . . . . . . . . . . . . 36 + 4.4.4. Future LSA Validation . . . . . . . . . . . . . . . . 40 + 4.5. Flooding . . . . . . . . . . . . . . . . . . . . . . . . . 40 + 4.5.1. Receiving Link State Update Packets . . . . . . . . . 40 + 4.5.2. Sending Link State Update Packets . . . . . . . . . . 41 + 4.5.3. Installing LSAs in the Database . . . . . . . . . . . 43 + 4.6. Definition of Self-Originated LSAs . . . . . . . . . . . . 43 + 4.7. Virtual Links . . . . . . . . . . . . . . . . . . . . . . 44 + 4.8. Routing Table Calculation . . . . . . . . . . . . . . . . 44 + 4.8.1. Calculating the Shortest-Path Tree for an Area . . . . 45 + 4.8.2. The Next-Hop Calculation . . . . . . . . . . . . . . . 44 + 4.8.3. Calculating the Inter-Area Routes . . . . . . . . . . 47 + 4.8.4. Examining Transit Areas' Summary-LSAs . . . . . . . . 48 + 4.8.5. Calculating AS External and NSSA Routes . . . . . . . 48 + 4.9. Multiple Interfaces to a Single Link . . . . . . . . . . . 48 + 4.9.1. Standby Interface State . . . . . . . . . . . . . . . 50 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 52 + 6. Manageability Considerations . . . . . . . . . . . . . . . . . 52 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 + 7.1. MOSPF for OSPFv3 Deprecation IANA Considerations . . . . . 53 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 55 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 56 + Appendix A. OSPF Data Formats . . . . . . . . . . . . . . . . . . 57 + A.1. Encapsulation of OSPF Packets . . . . . . . . . . . . . . 57 + A.2. The Options Field . . . . . . . . . . . . . . . . . . . . 58 + A.3. OSPF Packet Formats . . . . . . . . . . . . . . . . . . . 60 + A.3.1. The OSPF Packet Header . . . . . . . . . . . . . . . . 60 + A.3.2. The Hello Packet . . . . . . . . . . . . . . . . . . . 62 + A.3.3. The Database Description Packet . . . . . . . . . . . 63 + A.3.4. The Link State Request Packet . . . . . . . . . . . . 65 + A.3.5. The Link State Update Packet . . . . . . . . . . . . . 66 + A.3.6. The Link State Acknowledgment Packet . . . . . . . . . 67 + A.4. LSA Formats . . . . . . . . . . . . . . . . . . . . . . . 68 + A.4.1. IPv6 Prefix Representation . . . . . . . . . . . . . . 69 + A.4.1.1. Prefix Options . . . . . . . . . . . . . . . . . . 69 + A.4.2. The LSA Header . . . . . . . . . . . . . . . . . . . . 70 + A.4.2.1. LSA Type . . . . . . . . . . . . . . . . . . . . . 72 + A.4.3. Router-LSAs . . . . . . . . . . . . . . . . . . . . . 73 + A.4.4. Network-LSAs . . . . . . . . . . . . . . . . . . . . . 76 + A.4.5. Inter-Area-Prefix-LSAs . . . . . . . . . . . . . . . . 77 + + + +Coltun, et al. Standards Track [Page 3] + +RFC 5340 OSPF for IPv6 July 2008 + + + A.4.6. Inter-Area-Router-LSAs . . . . . . . . . . . . . . . . 78 + A.4.7. AS-External-LSAs . . . . . . . . . . . . . . . . . . . 79 + A.4.8. NSSA-LSAs . . . . . . . . . . . . . . . . . . . . . . 82 + A.4.9. Link-LSAs . . . . . . . . . . . . . . . . . . . . . . 82 + A.4.10. Intra-Area-Prefix-LSAs . . . . . . . . . . . . . . . . 84 + Appendix B. Architectural Constants . . . . . . . . . . . . . . . 86 + Appendix C. Configurable Constants . . . . . . . . . . . . . . . 86 + C.1. Global Parameters . . . . . . . . . . . . . . . . . . . . 86 + C.2. Area Parameters . . . . . . . . . . . . . . . . . . . . . 87 + C.3. Router Interface Parameters . . . . . . . . . . . . . . . 88 + C.4. Virtual Link Parameters . . . . . . . . . . . . . . . . . 90 + C.5. NBMA Network Parameters . . . . . . . . . . . . . . . . . 91 + C.6. Point-to-Multipoint Network Parameters . . . . . . . . . . 92 + C.7. Host Route Parameters . . . . . . . . . . . . . . . . . . 92 + +1. Introduction + + This document describes the modifications to OSPF to support version + 6 of the Internet Protocol (IPv6). The fundamental mechanisms of + OSPF (flooding, Designated Router (DR) election, area support, + (Shortest Path First) 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. These modifications will necessitate + incrementing the protocol version from version 2 to version 3. OSPF + for IPv6 is also referred to as OSPF version 3 (OSPFv3). + + This document is organized as follows. Section 2 describes the + differences between OSPF for IPv4 (OSPF version 2) and OSPF for IPv6 + (OSPF version 3) in detail. Section 3 describes the difference + between RFC 2740 and this document. Section 4 provides + implementation details for the changes. Appendix A gives the OSPF + for IPv6 packet and Link State Advertisement (LSA) formats. Appendix + B lists the OSPF architectural constants. Appendix C describes + configuration parameters. + +1.1. Requirements Notation + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC-KEYWORDS]. + +1.2. Terminology + + This document attempts to use terms from both the OSPF for IPv4 + specification ([OSPFV2]) and the IPv6 protocol specifications + ([IPV6]). This has produced a mixed result. Most of the terms used + both by OSPF and IPv6 have roughly the same meaning (e.g., + + + +Coltun, et al. Standards Track [Page 4] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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. + + In the context of this document, an OSPF instance is a separate + protocol instance complete with its own protocol data structures + (e.g., areas, interfaces, neighbors), link-state database, protocol + state machines, and protocol processing (e.g., SPF calculation). + +2. Differences from OSPF for IPv4 + + Most of the algorithms from OSPF for IPv4 [OSPFV2] have been + 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 [OSPFV2]. + +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" ([IPV6]). + "Interfaces" connect to links. Multiple IPv6 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 IPv6 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 ([OSPFV2]) should generally be replaced + by link. Likewise, an OSPF interface now connects to a link instead + of an IP subnet. + + This change affects the receiving of OSPF protocol packets, the + contents of Hello packets, and the contents of 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: + + + + +Coltun, et al. Standards Track [Page 5] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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. + Previously, they had been identified by an IPv4 address on + broadcast, NBMA (Non-Broadcast Multi-Access), and point-to- + multipoint links. + +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: + + o Link-local scope. LSA is only flooded on the local link and no + further. Used for the new link-LSA. See Section 4.4.3.8 for + details. + + o Area scope. LSA is only flooded throughout a single OSPF area. + 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. A router that originates AS scoped LSAs is + considered an AS Boundary Router (ASBR) and will set its E-bit in + router-LSAs for regular areas. + +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 supporting + separate OSPF routing domains that wish 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. + + + + + + +Coltun, et al. Standards Track [Page 6] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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 data structures. Instance ID solely affects the reception + of OSPF packets and applies to normal OSPF interfaces and virtual + links. + +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 [IP6ADDR]. + Link-local unicast addresses are assigned from the IPv6 address range + FE80/10. + + OSPF for IPv6 assumes that each router has been assigned link-local + unicast addresses on each of the router's attached physical links + [IP6ADDR]. On all OSPF interfaces except virtual links, OSPF packets + are sent using the interface's associated link-local unicast address + as the source address. 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, a global scope IPv6 address MUST be used as the + source address for OSPF protocol packets. + + Link-local addresses appear in OSPF link-LSAs (see Section 4.4.3.8). + 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 4.4.3.4), AS-external-LSAs + (Section 4.4.3.6), NSSA-LSAs (Section 4.4.3.7), or intra-area-prefix- + LSAs (Section 4.4.3.9). + +2.6. Authentication Changes + + In OSPF for IPv6, authentication has been removed from the OSPF + protocol. 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 data structures. + + When running over IPv6, OSPF relies on the IP Authentication Header + (see [IPAUTH]) and the IP Encapsulating Security Payload (see + [IPESP]) as described in [OSPFV3-AUTH] to ensure integrity and + authentication/confidentiality of routing exchanges. + + + + +Coltun, et al. Standards Track [Page 7] + +RFC 5340 OSPF for IPv6 July 2008 + + + Protection of OSPF packet exchanges against accidental data + corruption is provided by the standard IPv6 Upper-Layer checksum (as + described in Section 8.1 of [IPV6]), covering the entire OSPF packet + and prepended IPv6 pseudo-header (see Appendix 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 incremented from 2 to 3. + + o The Options field in Hello packets and Database Description + packets 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. + Rather, it now includes an Interface ID that the originating + router has assigned to uniquely identify (among its own + interfaces) its interface to the link. This Interface ID will be + used as the network-LSA's Link State ID if the router becomes the + Designated Router on the link. + + o Two Options bits, the "R-bit" and the "V6-bit", have been added to + the Options field for processing router-LSAs during the SPF + calculation (see Appendix 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 datagrams + belonging to another protocol family may be forwarded. + + o The OSPF packet header now includes an "Instance ID" that allows + multiple OSPF protocol instances to be run on a single link (see + Section 2.4). + + + + + + + +Coltun, et al. Standards Track [Page 8] + +RFC 5340 OSPF for IPv6 July 2008 + + +2.8. LSA Format Changes + + All addressing semantics have been removed from the LSA header, + 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 Appendix 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 Appendix A.4.1). The default + route is expressed as a prefix with length 0. + + o Router-LSAs 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. + + o A new LSA called the link-LSA has been introduced. Link-LSAs have + link-local flooding scope; they are never flooded beyond the link + with which they are associated. 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 advertise a collection of Options bits to + associate with the network-LSA that will be originated for the + link. See Section 4.4.3.8 for details. + + o 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 [OSPFV2]), 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 + + + +Coltun, et al. Standards Track [Page 9] + +RFC 5340 OSPF for IPv6 July 2008 + + + in all cases. On NBMA links, next-hop routers do not necessarily + exchange Hellos. Rather, these routers learn of each other's + existence by way of the Designated Router (DR). + + 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, NSSA-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 4.4.3.9 for + details. + + o Inclusion of a forwarding address or external route tag in AS- + external-LSAs is now optional. 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. For + example, this reference could be used to attach BGP path + attributes to external routes. + +2.9. Handling Unknown LSA Types + + Handling of unknown LSA types has been made more flexible so that, + based on the LS type, unknown LSA types are either treated as having + link-local flooding scope, or are stored and flooded as if they were + understood. This behavior is explicitly coded in the LSA Handling + bit of the link state header's LS type field (see the U-bit in + Appendix A.4.2.1). + + + + + +Coltun, et al. Standards Track [Page 10] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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/NSSA Area Support + + In OSPF for IPv4, stub and NSSA 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 and NSSA 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. NSSA areas are restricted to these types and, of + course, NSSA-LSAs. This is the IPv6 equivalent of the LSA types + carried in IPv4 stub areas: router-LSAs, network-LSAs, type 3 + summary-LSAs and for NSSA areas: stub area types and NSSA-LSAs. + +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 while 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 + [OSPFV2]), the lookup of neighbors (Section 10 of [OSPFV2]), and the + reception of Hello packets (Section 10.5 of [OSPFV2]). + + The Router ID of 0.0.0.0 is reserved and SHOULD NOT be used. + +3. Differences with RFC 2740 + + OSPFv3 implementations based on RFC 2740 will fully interoperate with + implementations based on this specification. There are, however, + some protocol additions and changes (all of which are backward + compatible). + +3.1. Support for Multiple Interfaces on the Same Link + + This protocol feature was only partially specified in the RFC 2740. + The level of specification was insufficient to implement the feature. + Section 4.9 specifies the additions and clarifications necessary for + implementation. They are fully compatible with RFC 2740. + + + +Coltun, et al. Standards Track [Page 11] + +RFC 5340 OSPF for IPv6 July 2008 + + +3.2. Deprecation of MOSPF for IPv6 + + This protocol feature was only partially specified in RFC 2740. The + level of specification was insufficient to implement the feature. + There are no known implementations. Multicast Extensions to OSPF + (MOSPF) support and its attendant protocol fields have been + deprecated from OSPFv3. Refer to Section 4.4.3.2, Section 4.4.3.4, + Section 4.4.3.6, Section 4.4.3.7, Appendix A.2, Appendix A.4.2.1, + Appendix A.4.3, Appendix A.4.1.1, and Section 7.1. + +3.3. NSSA Specification + + This protocol feature was only partially specified in RFC 2740. The + level of specification was insufficient to implement the function. + This document includes an NSSA specification unique to OSPFv3. This + specification coupled with [NSSA] provide sufficient specification + for implementation. Refer to Section 4.8.5, Appendix A.4.3, + Appendix A.4.8, and [NSSA]. + +3.4. Stub Area Unknown LSA Flooding Restriction Deprecated + + In RFC 2740 [OSPFV3], flooding of unknown LSA was restricted within + stub and NSSA areas. The text describing this restriction is + included below. + + 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 Appendix 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 can + 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. + + This restriction has been deprecated. OSPFv3 routers will flood link + and area scope LSAs whose LS type is unrecognized and whose U-bit is + set to 1 throughout stub and NSSA areas. There are no backward- + compatibility issues other than OSPFv3 routers still supporting the + restriction may not propagate newly defined LSA types. + +3.5. Link LSA Suppression + + The LinkLSASuppression interface configuration parameter has been + added. If LinkLSASuppression is configured for an interface and the + interface type is not broadcast or NBMA, origination of the link-LSA + + + +Coltun, et al. Standards Track [Page 12] + +RFC 5340 OSPF for IPv6 July 2008 + + + may be suppressed. The LinkLSASuppression interface configuration + parameter is described in Appendix C.3. Section 4.8.2 and + Section 4.4.3.8 were updated to reflect the parameter's usage. + +3.6. LSA Options and Prefix Options Updates + + The LSA Options and Prefix Options fields have been updated to + reflect recent protocol additions. Specifically, bits related to + MOSPF have been deprecated, Options field bits common with OSPFv2 + have been reserved, and the DN-bit has been added to the prefix- + options. Refer to Appendix A.2 and Appendix A.4.1.1. + +3.7. IPv6 Site-Local Addresses + + All references to IPv6 site-local addresses have been removed. + +4. Implementation Details + + When going from IPv4 to IPv6, the basic OSPF mechanisms remain + unchanged from those documented in [OSPFV2]. These mechanisms are + briefly outlined in Section 4 of [OSPFV2]. 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, which includes 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, as well as to elect Designated Routers and + Backup Designated Routers on broadcast and NBMA links. The decision + as to which neighbor relationships become adjacencies, and 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 + [OSPFV2] remains completely unchanged for IPv6: + + o Both IPv4 and IPv6 use OSPF packet types described in Section 4.3 + of [OSPFV2], 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 remain the + same. + + + + + + + +Coltun, et al. Standards Track [Page 13] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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. + + 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 [OSPFV2]. + + 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 [OSPFV2]. + + o The neighbor state machine, including the list of OSPF neighbor + states and events, remains unchanged. The neighbor state machine + is described in Sections 10.1, 10.2, 10.3, and 10.4 of [OSPFV2]. + + 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 + [OSPFV2]. + + However, some OSPF protocol mechanisms have changed as previously + described in Section 2 herein. These changes are explained in detail + in the following subsections, making references to the appropriate + sections of [OSPFV2]. + + The following subsections provide a recipe for turning an IPv4 OSPF + implementation into an IPv6 OSPF implementation. + +4.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 [OSPFV2], 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 that have AS flooding scope. LSAs with unknown LS + + + +Coltun, et al. Standards Track [Page 14] + +RFC 5340 OSPF for IPv6 July 2008 + + + type, U-bit set to 1 (flood even when unrecognized), and AS + flooding scope also appear in the top-level data structure. + +4.1.1. The Area Data Structure + + The IPv6 area data structure contains all elements defined for IPv4 + areas in Section 6 of [OSPFV2]. In addition, all LSAs of known type + that 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. NSSA-LSAs are also included in an NSSA area's + data structure. + +4.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 [OSPFV2]) 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 ([INTFMIB]) + as the Interface ID. The Interface ID appears in Hello packets + sent out the interface, the link-local-LSA originated by the + 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. + The Interface ID for a virtual link is independent of the + Interface ID of the outgoing interface it traverses in the transit + area. + + Instance ID + Every interface is assigned an Instance ID. This should default + to 0. It is only necessary to assign a value other than 0 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 assigned an Instance ID of 0 and all the + routers in the first community will be assigned 0 as the Instance + ID for interfaces connected to the ethernet segment. An Instance + ID of 1 is assigned to the other routers' interfaces connected to + the ethernet segment. The OSPF transmit and receive processing + (see Section 4.2) will then keep the two communities separate. + + + +Coltun, et al. Standards Track [Page 15] + +RFC 5340 OSPF for IPv6 July 2008 + + + List of LSAs with link-local scope + All LSAs with link-local scope and that were originated/flooded on + the link belong to the interface structure that connects to the + link. This includes the collection of the link's link-LSAs. + + IP interface address + For IPv6, the IPv6 address appearing in the source of OSPF packets + sent on the interface is almost always a link-local address. The + one exception is for virtual links that MUST use one of the + router's own 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 on the interface. In + addition, OSPF for IPv6 relies on the IP Authentication Header (see + [IPAUTH]) and the IP Encapsulating Security Payload (see [IPESP]) as + described in [OSPFV3-AUTH] to ensure integrity and authentication/ + confidentiality of routing exchanges. For this reason, AuType and + Authentication key are not associated with IPv6 OSPF interfaces. + + Interface states, events, and the interface state machine remain + unchanged from IPv4 as documented in Sections 9.1, 9.2, and 9.3 of + [OSPFV2] respectively. The Designated Router and Backup Designated + Router election algorithm also remains unchanged from the IPv4 + election in Section 9.4 of [OSPFV2]. + +4.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 when such 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 [OSPFV2] + 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 or point-to-multipoint + link to the neighbor or b) advertising a link to a network where + the neighbor has become the Designated Router. + + + +Coltun, et al. Standards Track [Page 16] + +RFC 5340 OSPF for IPv6 July 2008 + + + Neighbor IP address + The neighbor's IPv6 address contained as the source address in + OSPF for IPv6 packets. This will be an IPv6 link-local address + for all link types except virtual links. + + 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 Backup 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 as documented in Sections 10.1, 10.2, and 10.3 of + [OSPFV2] respectively. The decision as to which adjacencies to form + also remains unchanged from the IPv4 logic documented in Section 10.4 + of [OSPFV2]. + +4.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 OSPF for IPv4, OSPF for 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 IPv6, encoded by the Type + field of the standard OSPF packet header. + +4.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 + Appendix 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. + + + + + + +Coltun, et al. Standards Track [Page 17] + +RFC 5340 OSPF for IPv6 July 2008 + + + Packet length + The length of the entire OSPF packet in bytes, including the + standard OSPF packet header. + + Router ID + The identity of the router itself (who is originating the packet). + + Area ID + The OSPF area for the interface on which the packet is being sent. + + Instance ID + The OSPF Instance ID associated with the interface out of which + the packet is being sent. + + Checksum + The standard IPv6 Upper-Layer checksum (as described in Section + 8.1 of [IPV6]) covering the entire OSPF packet and prepended IPv6 + pseudo-header (see Appendix 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 [OSPFV2]. 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 [OSPFV2] respectively. + Sending Hello packets is documented in Section 4.2.1.1, and the + sending of Database Description packets in Section 4.2.1.2. The + sending of Link State Update packets is documented in Section 4.5.2. + +4.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 [OSPFV2]): + + o Before the Hello packet is sent on 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 since OSPF + for IPv6 runs per-link instead of per-subnet. + + o The choice of Designated Router and Backup Designated Router is + now indicated within Hellos by their Router IDs instead of by + their IP interface addresses. Advertising the Designated Router + + + +Coltun, et al. Standards Track [Page 18] + +RFC 5340 OSPF for IPv6 July 2008 + + + (or Backup Designated Router) as 0.0.0.0 indicates that the + Designated Router (or Backup Designated Router) has not yet been + chosen. + + 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 as follows. The + E-bit is set if and only if the interface attaches to a regular + area, i.e., not a stub or NSSA area. Similarly, the N-bit is set + if and only if the interface attaches to an NSSA area (see + [NSSA]). Finally, the DC-bit is set if and only if the router + wishes to suppress the sending of future Hellos over the interface + (see [DEMAND]). 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 [OSPFV2]. + +4.2.1.2. Sending Database Description Packets + + The sending of Database Description packets differs from Section 10.8 + of [OSPFV2] 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 as follows. The DC-bit is set if and only + if the router wishes to suppress the sending of Hellos over the + interface (see [DEMAND]). Unrecognized bits in the Database + Description packet's Options field should be cleared. + +4.2.2. Receiving Protocol Packets + + Whenever a router receives an OSPF protocol packet, it is marked with + the interface on which it was received. For routers that have + virtual links configured, it may not be immediately obvious with + which interface to associate the packet. For example, consider the + Router RT11 depicted in Figure 6 of [OSPFV2]. 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: + + + + + +Coltun, et al. Standards Track [Page 19] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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), one of the IPv6 multicast + addresses AllSPFRouters or AllDRouters, or an IPv6 global address + (for virtual links). + + o The Next Header field of the immediately encapsulating IPv6 header + MUST specify the OSPF protocol (89). + + o Any encapsulating IP Authentication Headers (see [IPAUTH]) and the + IP Encapsulating Security Payloads (see [IPESP]) MUST be processed + and/or verified to ensure integrity and authentication/ + confidentiality of OSPF routing exchanges. This is described in + [OSPFV3-AUTH]. + + 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 OSPFv3 interface. If they do not, + the packet SHOULD be discarded: + + o The version number field MUST specify protocol version 3. + + o The IPv6 Upper-Layer checksum (as described in Section 8.1 of + [IPV6]), covering the entire OSPF packet and prepended IPv6 + pseudo-header, must be verified (see Appendix A.3.1). + + o The Area ID and Instance ID found in the OSPF header must be + verified. If both of the following cases fail, the packet should + be discarded. The Area ID and Instance ID specified in the header + must either: + + 1. Match one of the Area ID(s) and Interface Instance ID(s) for + the receiving link. Unlike IPv4, the IPv6 source address is + not restricted to lie within the same IPv6 subnet as the + receiving link. IPv6 OSPF runs per-link instead of per-IP- + subnet. + + 2. Match the backbone area and other criteria for a configured + virtual link. The receiving router must be an ABR (Area + Border Router) and the Router ID specified in the packet (the + source router) must be the other end of a configured virtual + link. Additionally, the receiving link must have an OSPFv3 + interface that attaches to the virtual link's configured + transit area and the Instance ID must match the virtual link's + Instance ID. If all of these checks succeed, the packet is + accepted and is associated with the virtual link (and the + backbone area). + + + + +Coltun, et al. Standards Track [Page 20] + +RFC 5340 OSPF for IPv6 July 2008 + + + o Locally originated packets SHOULD NOT be processed by OSPF except + for support of multiple interfaces attached to the same link as + described in Section 4.9. Locally originated packets have a + source address equal to one of the router's local addresses. + + o Packets whose IPv6 destination is AllDRouters should only be + accepted if the state of the receiving OSPFv3 interface is DR or + Backup (see Section 9.1 [OSPFV2]). + + 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 packet processing as described in Section 4.2.2.1. 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 in + 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 is almost + identical to the IPv4 procedures documented in Sections 10.6, 10.7, + and 13.7 of [OSPFV2] respectively with the exceptions noted below. + + o LSAs with unknown LS types in Database Description packets that + have an acceptable flooding scope are processed the same as LSAs + with known LS types. In OSPFv2 [OSPFV2], these would result in + the adjacency being brought down with a SequenceMismatch event. + + The receiving of Hello packets is documented in Section 4.2.2.1 and + the receiving of Link State Update packets is documented in + Section 4.5.1. + +4.2.2.1. Receiving Hello Packets + + The receive processing of Hello packets differs from Section 10.5 of + [OSPFV2] 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. + + + + +Coltun, et al. Standards Track [Page 21] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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. + +4.3. The Routing table Structure + + The routing table used by OSPF for IPv4 is defined in Section 11 of + [OSPFV2]. 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 4.8). + + Also, to hold the intermediate results during the shortest-path + calculation for each area, there is a separate routing table for each + area holding the following entries: + + 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 + [OSPFV2]) 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 routers. + + 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 + Appendix A.4.10). + + + +Coltun, et al. Standards Track [Page 22] + +RFC 5340 OSPF for IPv6 July 2008 + + +4.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. + +4.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, AS-external-LSAs, and + NSSA-LSAs), while the names of other LSAs have been changed (type 3 + and 4 summary-LSAs are now inter-area-prefix-LSAs and inter-area- + router-LSAs respectively) and additional LSAs have been added (link- + LSAs and intra-area-prefix-LSAs). Type of Service (TOS) has been + removed from the OSPFv2 specification [OSPFV2] and is not encoded + within OSPF for IPv6's LSAs. + + These changes will be described in detail in the following + subsections. + +4.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 [OSPFV2], respectively. However, the following fields + have changed for IPv6: + + Options + The Options field has been removed from the standard 20-byte LSA + header and moved 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 Appendix A.2). Additionally, 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 high-order bit encoding the handling of unknown types and the + next two bits encoding flooding scope. See Appendix A.4.2.1 for + the current coding of the LS type field. + + + + + + +Coltun, et al. Standards Track [Page 23] + +RFC 5340 OSPF for IPv6 July 2008 + + + Link State ID + The Link State ID remains at 32 bits in length. However, except + for network-LSAs and link-LSAs, the 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. + +4.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 [OSPFV2]). + + 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 4.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 4.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, NSSA- + LSAs, and intra-area-prefix-LSAs. LSAs with an unknown LS type, the + U-bit set to 0, and/or link-local flooding scope are contained within + the appropriate interface structure (see Section 4.1.2); this + includes link-LSAs. + + To look up or install an LSA in the database, you first examine the + LS type and the LSA's context (i.e., the area or link to which the + LSA belongs). This information allows you to find the correct + database of LSAs where you then search based on the LSA's type, Link + State ID, and Advertising Router. + + + + + + + + + +Coltun, et al. Standards Track [Page 24] + +RFC 5340 OSPF for IPv6 July 2008 + + +4.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 on the appropriate interfaces. + + The list of events causing LSAs to be reoriginated for IPv4 is given + in Section 12.4 of [OSPFV2]. The following events and/or actions are + added for IPv6: + + o The state or interface ID 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. If + the router is the Designated Router, the router may also need to + (re)originate and/or flush the network-LSA corresponding to the + interface. + + 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. + + 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. + + 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 the Designated Router for + the link, it originates a new intra-area-prefix-LSA. + + o A new link-LSA is received, causing the logical OR of LSA options + advertised by adjacent routers on the link to change. If the + router is the Designated Router for the link, it originates a new + network-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 [OSPFV2] has been reworked to + show IPv6 addressing, resulting in Figure 1. The OSPF cost of each + + + +Coltun, et al. Standards Track [Page 25] + +RFC 5340 OSPF for IPv6 July 2008 + + + interface is 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 2001:0db8:c001::/48. The + OSPF interface IDs and the link-local addresses for the router + interfaces in Figure 1 are given in Table 2. + + .......................................... + . Area 1. + . + . + . | . + . | 3+---+1 . + . N1 |--|RT1|-----+ . + . | +---+ \ . + . | \ ______ . + . + \/ \ 1+---+ + . * N3 *------|RT4|------ + . + /\_______/ +---+ + . | / | . + . | 3+---+1 / | . + . N2 |--|RT2|-----+ 1| . + . | +---+ +---+ . + . | |RT3|---------------- + . + +---+ . + . |2 . + . | . + . +------------+ . + . N4 . + .......................................... + + Figure 1: Area 1 with IP Addresses Shown + + + Network IPv6 prefix + ----------------------------------- + N1 2001:0db8:c001:0200::/56 + N2 2001:0db8:c001:0300::/56 + N3 2001:0db8:c001:0100::/56 + N4 2001:0db8:c001:0400::/56 + + Table 1: IPv6 Link Prefixes for Sample Network + + + + + + + + + + +Coltun, et al. Standards Track [Page 26] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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 + + Figure 1 + +4.4.3.1. LSA Options + + The Options field in LSAs should be coded as follows. The V6-bit + should be set unless the router will not participate in transit IPv6 + routing. The E-bit should be clear if and only if the attached area + is an OSPF stub or OSPF NSSA area. The E-bit should always be set in + AS scoped LSAs. The N-bit should be set if and only if the attached + area is an OSPF NSSA area. The R-bit should be set unless the router + will not participate in any transit routing. 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 [DEMAND]). All + unrecognized bits in the Options field should be cleared. + + The V6-bit and R-bit are only examined in Router-LSAs during the SPF + computation. In other LSA types containing options, they are set for + informational purposes only. + +4.4.3.2. 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 attached to the area. When + multiple router-LSAs are used, they are distinguished by their Link + State ID fields. + + To the left of the Options field, the router capability bits V, E, + and B should be set according to Section 12.4.1 of [OSPFV2]. + + Each of the router's interfaces to the area is then described by + appending "link descriptions" to the router-LSA. Each link + description is 16 bytes long, consisting of five fields: (link) Type, + + + +Coltun, et al. Standards Track [Page 27] + +RFC 5340 OSPF for IPv6 July 2008 + + + Metric, Interface ID, Neighbor Interface ID, and Neighbor Router ID + (see Appendix A.4.3). Interfaces in the 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 (except in the case of multiple Standby + Interfaces as described in Section 4.9). All other interfaces to the + area add zero, one, or more link descriptions. The number and + content of these depend on the interface type. Within each link + description, the Metric field is always set to the interface's output + cost, and the Interface ID field is set to the interface's OSPF + Interface ID. + + Point-to-point interfaces + If the neighboring router is fully adjacent, add a Type 1 link + description (point-to-point). The Neighbor Interface ID field is + set to the Interface ID advertised by the neighbor in its Hello + packets, and the Neighbor Router ID field is set to the neighbor's + Router ID. + + Broadcast and NBMA interfaces + If the router is fully adjacent to the link's Designated Router or + if the router itself is the 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 4.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 the + Neighbor Interface ID field set to the Interface ID advertised by + the neighbor in its Hello packets and the 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 the Designated Router of Network + N3. + + + +Coltun, et al. Standards Track [Page 28] + +RFC 5340 OSPF for IPv6 July 2008 + + + ; 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.0.2.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.0.2.4 ; RT4's Router ID + + RT3's router-LSA for Area 1 + + For example, if another router was added to Network N4, RT3 would + have to advertise a second link description for its connection to + (the now transit) network N4. This could be accomplished by + reoriginating the above router-LSA, this time with two link + descriptions. Or, a separate router-LSA could be originated with a + separate Link State ID (e.g., using a Link State ID of 1) to describe + the connection to N4. + + Host routes for stub networks no longer appear in the router-LSA. + Rather, they are included in intra-area-prefix-LSAs. + +4.4.3.3. 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 with an elected Designated Router that is + fully adjacent with at least one other router on the link. The + network-LSA is originated by the link's Designated Router and lists + all routers on the link with which it is fully adjacent. + + The procedure for originating network-LSAs in IPv6 is the same as the + IPv4 procedure documented in Section 12.4.2 of [OSPFV2], 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 originated by the link's + Designated Router. + + + +Coltun, et al. Standards Track [Page 29] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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 corresponding to fully adjacent neighbors. In this way, the + network link exhibits a capability when at least one fully + adjacent neighbor on the link requests that the capability be + advertised. + + As an example, assuming that Router RT4 has been elected the + 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.0.2.4 ;RT4's Router ID + Options = (V6-bit|E-bit|R-bit) + Attached Router = 192.0.2.4 ;Router ID + Attached Router = 192.0.2.1 ;Router ID + Attached Router = 192.0.2.2 ;Router ID + Attached Router = 192.0.2.3 ;Router ID + + Network-LSA for Network N3 + +4.4.3.4. 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 [OSPFV2], with the following exceptions: + + o The Link State ID of an inter-area-prefix-LSA has lost all of its + addressing semantics and 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. + + + + + +Coltun, et al. Standards Track [Page 30] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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 2001:0db8:c001::/48. The + cost is set to 4, which is the maximum cost of all of the individual + component prefixes. 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.0.2.4 ;RT4's ID + Metric = 4 ;maximum to components + PrefixLength = 48 + PrefixOptions = 0 + Address Prefix = 2001:0db8:c001 ;padded to 64-bits + + Inter-area-prefix-LSA for Area 1 addresses originated + by Router + RT4 into the backbone + +4.4.3.5. 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 (i.e., an AS + Boundary Router (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 [OSPFV2], + 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 and now 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. + + + + + + + +Coltun, et al. Standards Track [Page 31] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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 [OSPFV2]. 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.0.2.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 + + Inter-area-router-LSA for AS boundary router RT7 originated by Router + RT4 into Area 1 + +4.4.3.6. 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 [OSPFV2], with the + following exceptions: + + o The Link State ID of an AS-external-LSA has lost all of its + addressing semantics and 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. + + 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. + + + + + +Coltun, et al. Standards Track [Page 32] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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 supported through the inclusion of the Referenced LS Type + field and the optional Referenced Link State ID field (the latter + present if and only if the Referenced LS Type is non-zero). This + capability is for future use; the Referenced LS Type should be set + to 0, and received non-zero values for this field should be + ignored until its use is defined. + + As an example, consider the OSPF Autonomous System depicted in Figure + 6 of [OSPFV2]. Assume that RT7 has learned its route to N12 via BGP + and that it wishes to advertise a Type 2 metric into the AS. Also + assume that the IPv6 prefix for N12 is the value 2001:0db8: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 in order 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 ;LSA type/scope unique identifier + Advertising Router = Router RT7's ID + bit E = 1 ;Type 2 metric + bit F = 0 ;no forwarding address + bit T = 1 ;external route tag included + Metric = 2 + PrefixLength = 40 + PrefixOptions = 0 + Referenced LS Type = 0 ;no Referenced Link State ID + Address Prefix = 2001:0db8:0a00 ;padded to 64-bits + External Route Tag = as per BGP/OSPF interaction + + AS-external-LSA for Network N12, originated by Router RT7 + +4.4.3.7. NSSA-LSAs + + The LS type of an NSSA-LSA is set to the value 0x2007. NSSA-LSAs + have area flooding scope. Each NSSA-LSA describes a path to a prefix + external to the Autonomous System whose flooding scope is restricted + to a single NSSA area. + + The procedure for originating NSSA-LSAs in IPv6 is the same as the + IPv4 procedure documented in [NSSA], with the following exceptions: + + + +Coltun, et al. Standards Track [Page 33] + +RFC 5340 OSPF for IPv6 July 2008 + + + o The Link State ID of an NSSA-LSA has lost all of its addressing + semantics and simply serves to distinguish multiple NSSA-LSAs that + are originated by the same router in the same area. + + 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. + + o Link-local addresses can never be advertised in NSSA-LSAs. + + o The forwarding address is present in the NSSA-LSA if and only if + the NSSA-LSA's bit F is set. + + o The external route tag is present in the NSSA-LSA if and only if + the NSSA-LSA's bit T is set. + + o The capability for an NSSA-LSA to reference another LSA has been + supported through the inclusion of the Referenced LS Type field + and the optional Referenced Link State ID field (the latter + present if and only if the Referenced LS Type is non-zero). This + capability is for future use; the Referenced LS Type should be set + to 0, and received non-zero values for this field should be + ignored until its use is defined. + + An example of an NSSA-LSA would only differ from an AS-external-LSA + in that the LS type would be 0x2007 rather than 0x4005. + +4.4.3.8. 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 two or more (including the + originating router itself) routers. Link-LSAs SHOULD NOT be + originated for virtual links. + + 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. + + 3. They allow the router to advertise a collection of Options bits + in the network-LSA originated by the Designated Router on a + broadcast or NBMA link. + + + +Coltun, et al. Standards Track [Page 34] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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 reflect the router's + capabilities. On multi-access links, the Designated Router will + logically OR the link-LSA Options fields for all fully adjacent + neighbors 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 4.8.2). + + o Each IPv6 address prefix that has been configured on Link L is + added to the link-LSA by specifying values for the PrefixLength, + PrefixOptions, and Address Prefix fields. + + After building a link-LSA for a given link, the router installs the + link-LSA into the associated interface data structure and floods the + link-LSA on the link. All other routers on the link will receive the + link-LSA, but they will not flood the link-LSA on other links. + + If LinkLSASuppression is configured for the interface and the + interface type is not broadcast or NBMA, origination of the link-LSA + may be suppressed. This implies that other routers on the link will + ascertain the router's next-hop address using a mechanism other than + the link-LSA (see Section 4.8.2). Refer to Appendix C.3 for a + description of the LinkLSASuppression interface configuration + parameter. + + As an example, consider the link-LSA that RT3 will build for N3 in + Figure 1. Suppose that the prefix 2001:0db8:c001:0100::/56 has been + configured within RT3 for N3. This will result in the following + link-LSA that RT3 will flood only on N3. 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 35] + +RFC 5340 OSPF for IPv6 July 2008 + + + ; 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.0.2.3 ;RT3's Router ID + Rtr Priority = 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 = 2001:0db8:c001:0100 ;pad to 64-bits + + RT3's link-LSA for N3 + +4.4.3.9. 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 either 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. Each intra-area-prefix-LSA has a unique Link State ID and + 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 the + Referenced LS Type is set to 0x2002, the Referenced Link State ID + is set to the Designated Router's Interface ID on Link L, and the + 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 + + + +Coltun, et al. Standards Track [Page 36] + +RFC 5340 OSPF for IPv6 July 2008 + + + Router and the Link State ID matches the neighbor's interface ID, + the list of prefixes in the link-LSA is copied into the 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 + PrefixOptions fields should be logically OR'ed together, and a + single instance of the duplicate prefix should be included in 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 prefixes for + its attached stub links, looped-back interfaces, and hosts. 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 the Referenced LS Type to 0x2001, + the Referenced Link State ID to 0, and the 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 the 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), prefixes that will be + included in the intra-area-prefix-LSA for the link are skipped. + However, any prefixes that would normally have the LA-bit set + SHOULD be advertised independent of whether or not the interface + is advertised as a transit link. If the interface type is point- + to-multipoint or the interface is in the state Loopback, the + global scope IPv6 addresses associated with the interface (if any) + are copied into the intra-area-prefix-LSA with the PrefixOptions + LA-bit set, the PrefixLength set to 128, and the metric set to 0. + Otherwise, the list of 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 Appendix C.7) to the intra-area-prefix- + LSA. + + + +Coltun, et al. Standards Track [Page 37] + +RFC 5340 OSPF for IPv6 July 2008 + + + o If RTX has one or more virtual links configured through the area, + it includes one of its global scope IPv6 interface addresses in + the LSA (if it hasn't already), setting the LA-bit in the + PrefixOptions field, 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Coltun, et al. Standards Track [Page 38] + +RFC 5340 OSPF for IPv6 July 2008 + + + ; RT4's 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 ;LSA type/scope unique identifier + Advertising Router = 192.0.2.4 ;RT4's Router ID + # prefixes = 1 + Referenced LS Type = 0x2002 ;network-LSA reference + Referenced Link State ID = 1 + Referenced Advertising Router = 192.0.2.4 + PrefixLength = 56 ;N3's prefix + PrefixOptions = 0 + Metric = 0 + Address Prefix = 2001:0db8: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 ;LSA type/scope unique identifier + Advertising Router = 192.0.2.3 ;RT3's Router ID + # prefixes = 1 + Referenced LS Type = 0x2001 ;router-LSA reference + Referenced Link State ID = 0 + Referenced Advertising Router = 192.0.2.3 + PrefixLength = 56 ;N4's prefix + PrefixOptions = 0 + Metric = 2 ;N4 interface cost + Address Prefix = 2001:0db8:c001:0400 ;pad + + Intra-area-prefix-LSA for Network Link N3 + + 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 the 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 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 this case, the Designated Router may not + + + +Coltun, et al. Standards Track [Page 39] + +RFC 5340 OSPF for IPv6 July 2008 + + + be running the other protocol suite, and so another of the link's + routers may need to originate the intra-area-prefix-LSA. In that + case, the Referenced Advertising Router and Advertising Router would + be different. + +4.4.4. Future LSA Validation + + It is expected that new LSAs will be defined that will not be + processed during the Shortest Path First (SPF) calculation as + described in Section 4.8, for example, OSPFv3 LSAs corresponding to + information advertised in OSPFv2 using opaque LSAs [OPAQUE]. In + general, the new information advertised in future LSAs should not be + used unless the OSPFv3 router originating the LSA is reachable. + However, depending on the application and the data advertised, this + reachability validation MAY be done less frequently than every SPF + calculation. + + To facilitate inter-area reachability validation, any OSPFv3 router + originating AS scoped LSAs is considered an AS Boundary Router + (ASBR). + +4.5. Flooding + + Most of the flooding algorithm remains unchanged from the IPv4 + flooding mechanisms described in Section 13 of [OSPFV2]. In + particular, the protocol processes for determining which LSA instance + is newer (Section 13.1 of [OSPFV2]), responding to updates of self- + originated LSAs (Section 13.4 of [OSPFV2]), sending Link State + Acknowledgment packets (Section 13.5 of [OSPFV2]), retransmitting + LSAs (Section 13.6 of [OSPFV2]), and receiving Link State + Acknowledgment packets (Section 13.7 of [OSPFV2]), are exactly the + same for IPv6 and IPv4. + + However, the addition of flooding scope and unknown LSA type handling + (see Appendix A.4.2.1) has caused some changes in the OSPF flooding + algorithm: the reception of Link State Updates (Section 13 in + [OSPFV2]) and the sending of Link State Updates (Section 13.3 of + [OSPFV2]) must take into account the LSA's scope and U-bit setting. + Also, installation of LSAs into the OSPF database (Section 13.2 of + [OSPFV2]) causes different events in IPv6, due to the reorganization + of LSA types and the IPv6 LSA contents. These changes are described + in detail below. + +4.5.1. Receiving Link State Update Packets + + The encoding of flooding scope in the LS type and the need to process + unknown LS types cause modifications to the processing of received + Link State Update packets. As in IPv4, each LSA in a received Link + + + +Coltun, et al. Standards Track [Page 40] + +RFC 5340 OSPF for IPv6 July 2008 + + + State Update packet is examined. In IPv4, eight steps are executed + for each LSA, as described in Section 13 of [OSPFV2]. 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. Discard the LSA and get + the next one from the Link State Update packet if the + interface area has been configured as a stub or + NSSA area and the LS type indicates "AS flooding scope". + + This generalizes the IPv4 behavior where AS-external-LSAs + and AS-scoped opaque LSAs [OPAQUE] are not flooded + throughout stub or NSSA areas. + + (3) Else if the flooding scope in the LSA's LS type 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 [OSPFV2] are also + somewhat different for IPv6, as described in Sections 4.5.2 and 4.5.3 + below. + +4.5.2. Sending Link State Update Packets + + The sending of Link State Update packets is described in Section 13.3 + of [OSPFV2]. 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 + [OSPFV2]). However, the list of eligible interfaces on 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 scope, the particular + area or interface with which the LSA is associated. + + 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 41] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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 on + interfaces connecting to stub or NSSA areas. If the flooding + scope is "area flooding scope", the 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 is also the interface on which the LSA was + received in a Link State Update packet). + + 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 the type is understood). In + this case, select the eligible interfaces based on the encoded + flooding scope the same as in Case 1 above. + + 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 [OSPFV2]). 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 document, + namely, router-LSAs (LS type 0x2001), network-LSAs (0x2002), inter- + area-prefix-LSAs (0x2003), inter-area-router-LSAs (0x2004), NSSA-LSAs + (0x2007), AS-external-LSAs (0x4005), link-LSAs (0x0008), and Intra- + Area-Prefix-LSAs (0x2009), are assumed to be understood by all + routers. However, all LS types MAY not be understood by all routers. + For example, a new LSA type with its U-bit set to 0 MAY only be + understood by a subset of routers. This new LS type should only be + flooded to an OSPF neighbor that understands the LS type or when the + neighbor is the Designated Router or Backup Designated Router for the + attached link. + + + +Coltun, et al. Standards Track [Page 42] + +RFC 5340 OSPF for IPv6 July 2008 + + + The previous paragraph solves a problem for IPv4 OSPF extensions, + which require that the Designated Router support the extension in + order to have the new LSA types flooded across broadcast and NBMA + networks. + +4.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 4.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 4.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 data 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 [OSPFV2]. 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 4.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 [OSPFV2]). If this destination + is an AS boundary router, it may also be necessary to re-examine + all the AS-external-LSAs. + + AS-external-LSAs and NSSA-LSAs + The best route to the destination described by the AS-external-LSA + or NSSA-LSA must be recalculated (see Section 16.6 in [OSPFV2] and + Section 2.0 in [NSSA]). + + 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. + +4.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 + [OSPFV2]. For IPv6, self-originated LSAs are those LSAs whose + Advertising Router is equal to the router's own Router ID. + + + +Coltun, et al. Standards Track [Page 43] + +RFC 5340 OSPF for IPv6 July 2008 + + +4.7. Virtual Links + + OSPF virtual links for IPv4 are described in Section 15 of [OSPFV2]. + 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 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. + Hence, a link-LSA SHOULD NOT be originated for a virtual link + since the virtual link has no link-local address or associated + prefixes. + + o Likewise, the virtual neighbor's IPv6 address is an IPv6 address + with 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 Section 4.4.3.9 and Section 4.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. + +4.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 [OSPFV2]. High-level differences between the IPv6 + and IPv4 calculations include: + + o Prefix information has been removed from router-LSAs and network- + LSAs and is now advertised in intra-area-prefix-LSAs. Whenever + [OSPFV2] specifies that stub networks within router-LSAs be + examined, IPv6 will instead examine prefixes within intra-area- + prefix-LSAs. + + o Type 3 and 4 summary-LSAs have been renamed inter-area-prefix-LSAs + and inter-area-router-LSAs respectively. + + + + + + + +Coltun, et al. Standards Track [Page 44] + +RFC 5340 OSPF for IPv6 July 2008 + + + o Addressing information is no longer encoded in Link State IDs and + is now only found within the body of LSAs. + + o In IPv6, a router can originate multiple router-LSAs, + distinguished by Link State ID, within a single area. These + router-LSAs MUST be treated as a single aggregate by the area's + shortest-path calculation (see Section 4.8.1). + + For each area, the shortest-path tree calculation creates routing + table entries for the area's routers and transit links (see + Section 4.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 4.8.3. + + Events generated as a result of routing table changes (Section 16.7 + of [OSPFV2]) and the equal-cost multipath logic (Section 16.8 of + [OSPFV2]) are identical for both IPv4 and IPv6. + +4.8.1. Calculating the Shortest-Path Tree for an Area + + The IPv4 shortest-path calculation is contained in Section 16.1 of + [OSPFV2]. 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 4.3). + + Section 16.1 of [OSPFV2] 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 [OSPFV2]): + + 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. + + 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 the Advertising Router set to V's + OSPF Router ID MUST be processed as an aggregate, treating them as + fragments of a single large router-LSA. The Options field and the + + + + +Coltun, et al. Standards Track [Page 45] + +RFC 5340 OSPF for IPv6 July 2008 + + + router type bits (bits Nt, V, E, and B) should always be taken + from the router-LSA 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 and the router-LSA V6-bit or R-bit is + not set in the LSA options, the transit link W is ignored and V's + next link is examined. + + o In Step 2b, if W is a router, there may again be multiple LSAs + associated with the router. All router-LSAs with the Advertising + Router set to W's OSPF Router ID MUST be 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 rather than 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 with the LA-bit set. + + o Routing table entries for transit networks, which are no longer + associated with IP networks, are also calculated in Step 4 and + added to the per-area routing table. + + The next stage of the shortest-path calculation proceeds similarly to + the two steps of the second stage of Section 16.1 in [OSPFV2]. + 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's 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's routing table entry for the area. + + This specification does not require that the above algorithm be used + to calculate the intra-area shortest-path tree. However, if another + algorithm or optimization is used, an identical shortest-path tree + must be produced. It is also important that any alternate algorithm + or optimization maintain the requirement that transit vertices must + + + +Coltun, et al. Standards Track [Page 46] + +RFC 5340 OSPF for IPv6 July 2008 + + + be bidirectional for inclusion in the tree. Alternate algorithms and + optimizations are beyond the scope of this specification. + +4.8.2. 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 [OSPFV2]). However, + there are some differences. When calculating the next-hop IPv6 + address for a router (call it Router X) that shares a link with the + calculating router, the calculating router assigns the next-hop IPv6 + address to be the link-local interface address contained in Router + X's link-LSA (see Appendix A.4.9) for the link. This procedure is + necessary for some link types, for example NBMA, where the two + routers need not be neighbors and might not be exchanging OSPF Hello + packets. For other link types, the next-hop address may be + determined via the IPv6 source address in the neighbor's Hello + packet. + + Additionally, when calculating routes for the area's intra-area- + prefix-LSAs, the parent vertex can be either a router-LSA or network- + LSA. This is in contrast to the second stage of the OSPFv2 intra- + area SPF (Section 16.1 in [OSPFV2]) where the parent vertex is always + a router-LSA. In the case where the intra-area-prefix-LSA's + referenced LSA is a directly connected network-LSA, the prefixes are + also considered to be directly connected. In this case, the next hop + is solely the outgoing link and no IPv6 next-hop address is selected. + +4.8.3. 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 [OSPFV2], 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 an + advertised AS boundary 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 PrefixOptions field should + be ignored by the inter-area route calculation. + + + + + +Coltun, et al. Standards Track [Page 47] + +RFC 5340 OSPF for IPv6 July 2008 + + + When a single inter-area-prefix-LSA or inter-area-router-LSA has + changed, the incremental calculations outlined in Section 16.5 of + [OSPFV2] can be performed instead of recalculating the entire routing + table. + +4.8.4. 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 [OSPFV2], + modified in the same way as the IPv6 inter-area route calculation in + Section 4.8.3. + +4.8.5. Calculating AS External and NSSA Routes + + The IPv6 AS external route calculation proceeds along the same lines + as the IPv4 calculation in Section 16.4 of [OSPFV2] and Section 2.5 + of [NSSA], with the following exceptions: + + o The Link State ID of the AS-external-LSA and NSSA-LSA types no + longer encodes the network described by the LSA. Instead, an + address prefix is contained in the body of the LSA. + + o The default route in AS-external-LSAs or NSSA-LSAs is advertised + by a zero-length prefix. + + o Instead of comparing the AS-external-LSA's or NSSA-LSA's + Forwarding Address field to 0.0.0.0 to see whether a forwarding + address has been used, the bit F in the respective 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 PrefixOptions field should + be ignored by the inter-area route calculation. + + o AS Boundary Router (ASBR) and forwarding address selection will + proceed the same as if RFC1583Compatibility is disabled. + Furthermore, RFC1583Compatibility is not an OSPF for IPv6 + configuration parameter. Refer to Appendix C.1. + + When a single AS-external-LSA or NSSA-LSA has changed, the + incremental calculations outlined in Section 16.6 of [OSPFV2] can be + performed instead of recalculating the entire routing table. + +4.9. Multiple Interfaces to a Single Link + + In OSPF for IPv6, a router may have multiple interfaces to a single + link associated with the same OSPF instance and area. All interfaces + + + + +Coltun, et al. Standards Track [Page 48] + +RFC 5340 OSPF for IPv6 July 2008 + + + will be used for the reception and transmission of data traffic while + only a single interface sends and receives OSPF control traffic. In + more detail: + + o Each of the multiple interfaces is assigned a different Interface + ID. A router will automatically detect that multiple interfaces + are attached to the same link when a Hello packet is received with + one of the router's link-local addresses as the source address and + an Interface ID other than the Interface ID of the receiving + interface. + + o Each of the multiple interfaces MUST be configured with the same + Interface Instance ID to be considered on the same link. If an + interface has multiple Instance IDs, it will be grouped with other + interfaces based on matching Instance IDs. Each Instance ID will + be treated uniquely with respect to groupings of multiple + interfaces on the same link. For example, if interface A is + configured with Instance IDs 1 and 35, and interface B is + configured with Instance ID 35, interface B may be the Active + Interface for Instance ID 35 but interface A will be active for + Instance ID 1. + + o The router will ignore OSPF packets other than Hello packets on + all but one of the interfaces attached to the link. It will only + send its OSPF control packets (including Hello packets) on a + single interface. This interface is designated the Active + Interface and other interfaces attached to the same link will be + designated Standby Interfaces. The choice of the Active Interface + is implementation dependent. For example, the interface with the + highest Interface ID could be chosen. If the router is elected + Designated Router, it will be the Active Interface's Interface ID + that will be used as the network-LSA's Link State ID. + + o All of the interfaces to the link (Active and Standby) will appear + in the router-LSA. In addition, a link-LSA will be generated for + each of the interfaces. In this way, all interfaces will be + included in OSPF's routing calculations. + + o Any link-local scope LSAs that are originated for a Standby + Interface will be flooded over the Active Interface. + If a Standby Interface goes down, then the link-local scope LSAs + originated for the Standby Interfaces MUST be flushed on the + Active Interface. + + o Prefixes on Standby Interfaces will be processed the same way as + prefixes on the Active Interface. For example, if the router is + the DR for the link, the Active Interface's prefixes are included + + + + +Coltun, et al. Standards Track [Page 49] + +RFC 5340 OSPF for IPv6 July 2008 + + + in an intra-area-prefix-LSA which is associated with the Active + Interface's network-LSA; prefixes from Standby Interfaces on the + link will also be included in that intra-area-prefix LSA. + Similarly, if the link is a stub link, then the prefixes for the + Active and Standby Interfaces will all be included in the same + intra-area-prefix-LSA that is associated with the router-LSA. + + o If the Active Interface fails, a new Active Interface will have to + take over. The new Active Interface SHOULD form all new neighbor + adjacencies with routers on the link. This failure can be + detected when the router's other interfaces to the Active + Interface's link cease to hear the router's Hellos or through + internal mechanisms, e.g., monitoring the Active Interface's + status. + + o If the network becomes partitioned with different local interfaces + attaching to different network partitions, multiple interfaces + will become Active Interfaces and function independently. + + o During the SPF calculation when a network-LSA for a network that + is directly connected to the root vertex is being examined, all of + the multiple interfaces to the link of adjacent router-LSAs must + be used in the next-hop calculation. + This can be accomplished during the back link check (see Section + 16.1, Step 2 (B), in [OSPFV2]) by examining each link of the + router-LSA and making a list of the links that point to the + network-LSA. The Interface IDs for links in this list are then + used to find the corresponding link-LSAs and the link-local + addresses used as next hops when installing equal-cost paths in + the routing table. + + o The interface state machine is modified to add the state Standby. + See Section 4.9.1 for a description of the Standby state. + +4.9.1. Standby Interface State + + In this state, the interface is one of multiple interfaces to a link + and this interface is designated Standby and is not sending or + receiving control packets. The interface will continue to receive + the Hello packets sent by the Active Interface. The interface will + maintain a timer, the Active Interface Timer, with the same interval + as the RouterDeadInterval. This timer will be reset whenever an OSPF + Hello packet is received from the Active Interface to the link. + + Two new events are added to the list of events that cause interface + state changes: MultipleInterfacesToLink and ActiveInterfaceDead. The + descriptions of these events are as follows: + + + + +Coltun, et al. Standards Track [Page 50] + +RFC 5340 OSPF for IPv6 July 2008 + + + MultipleInterfacesToLink + An interfaces on the router has received a Hello packet from + another interface on the same router. One of the interfaces is + designated as the Active Interface and the other interface is + designated as a Standby Interface. The Standby Interface + transitions to the Standby state. + + ActiveInterfaceDead + There has been an indication that a Standby Interface is no longer + on a link with an Active Interface. The firing of the Active + Interface Timer is one indication of this event, as it indicates + that the Standby Interface has not received an OSPF Hello packet + from the Active Interface for the RouterDeadInterval. Other + indications may come from internal notifications, such as the + Active Interface being disabled through a configuration change. + Any indication internal to the router, such that the router knows + the Active Interface is no longer active on the link, can trigger + the ActiveInterfaceDead event for a Standby Interface. + + Interface state machine additions include: + + State(s): Waiting, DR Other, Backup, or DR + + Event: MultipleInterfacesToLink + + New state: Standby + + Action: All interface variables are reset and interface + timers disabled. Also, all neighbor connections + associated with the interface are destroyed. This + is done by generating the event KillNbr on all + associated neighbors. The Active Interface Timer is + started and the interface will listen for OSPF Hello + packets from the link's Active Interface. + + State(s): Standby + + Event: ActiveInterfaceDead + + New state: Down + + Action: The Active Interface Timer is first disabled. Then + the InterfaceUp event is invoked. + + Standby Interface State Machine Additions + + + + + + +Coltun, et al. Standards Track [Page 51] + +RFC 5340 OSPF for IPv6 July 2008 + + +5. Security Considerations + + When running over IPv6, OSPFv3 relies on the IP Authentication Header + (see [IPAUTH]) and the IP Encapsulating Security Payload (see + [IPESP]) to ensure integrity and authentication/confidentiality of + protocol packets. This is described in [OSPFV3-AUTH]. + + Most OSPFv3 implementations will be running on systems that support + multiple protocols with their own independent security assumptions + and domains. When IPsec is used to protect OSPFv3 packets, it is + important for the implementation to check the IPsec Security + Association (SA) and local SA database to ensure the OSPF packet + originated from a source that is trusted for OSPFv3. This is + required to eliminate the possibility that the packet was + authenticated using an SA defined for another protocol running on the + same system. + + The mechanisms in [OSPFV3-AUTH] do not provide protection against + compromised, malfunctioning, or misconfigured routers. Such routers + can, either accidentally or deliberately, cause malfunctions + affecting the whole routing domain. The reader is encouraged to + consult [GENERIC-THREATS] for a more comprehensive description of + threats to routing protocols. + +6. Manageability Considerations + + The Management Information Base (MIB) for OSPFv3 is defined in + [OSPFV3-MIB]. + +7. IANA Considerations + + Most OSPF for IPv6 IANA considerations are documented in [OSPF-IANA]. + IANA has updated the reference for RFC 2740 to this document. + + Additionally, this document introduces the following IANA + requirements that were not present in [OSPFV3]: + + o Reserves the options with the values 0x000040 and 0x000080 for + migrated OSPFv2 options in the OSPFv3 Options registry defined in + [OSPF-IANA]. For information on the OSPFv3 Options field, refer + to Appendix A.2. + + o Adds the prefix option P-bit with value 0x08 to the OSPFv3 Prefix + Options registry defined in [OSPF-IANA]. For information on + OSPFv3 Prefix Options, refer to Appendix A.4.1.1. + + + + + + +Coltun, et al. Standards Track [Page 52] + +RFC 5340 OSPF for IPv6 July 2008 + + + o Adds the prefix option DN-bit with value 0x10 to the OSPFv3 Prefix + Options registry defined in [OSPF-IANA]. For information on + OSPFv3 Prefix Options, refer to Appendix A.4.1.1. + +7.1. MOSPF for OSPFv3 Deprecation IANA Considerations + + With the deprecation of MOSPF for OSPFv3, the following code points + are available for reassignment. Refer to [OSPF-IANA] for information + on the respective registries. This document: + + o Deprecates the MC-bit with value 0x000004 in the OSPFv3 Options + registry. + + o Deprecates Group-membership-LSA with value 6 in OSPFv3 LSA + Function Code registry. + + o Deprecates MC-bit with value 0x04 in the OSPFv3 Prefix Options + registry. + + The W-bit in the OSPFv3 Router Properties has also been deprecated. + This requires a new registry for OSPFv3 router properties since it + will diverge from the OSPFv2 Router Properties. + + Registry Name: OSPFv3 Router Properties Registry + Reference: RFC 5340 + Registration Procedures: Standards Action + + Registry: + Value Description Reference + ------ ------------- --------- + 0x01 B-bit RFC 5340 + 0x02 E-bit RFC 5340 + 0x04 V-bit RFC 5340 + 0x08 Deprecated RFC 5340 + 0x10 Nt-bit RFC 5340 + + OSPFv3 Router Properties Registry + +8. Acknowledgments + + The RFC text was produced using Marshall Rose's xml2rfc tool. + + The following individuals contributed comments that were incorporated + into this document: + + o Harold Rabbie for his description of protocol details that needed + to be clarified for OSPFv3 NSSA support. + + + + +Coltun, et al. Standards Track [Page 53] + +RFC 5340 OSPF for IPv6 July 2008 + + + o Nic Neate for his pointing out that there needed to be changes for + unknown LSA types handling in the processing of Database + Description packets. + + o Jacek Kwiatkowski for being the first to point out that the V6- + and R-bits are not taken into account in the OSPFv3 intra-area SPF + calculation. + + o Michael Barnes recognized that the support for multiple interfaces + to a single link was broken (see Section 4.9) and provided the + description of the current protocol mechanisms. Abhay Roy + reviewed and suggested improvements to the mechanisms. + + o Alan Davey reviewed and commented on document revisions. + + o Vivek Dubey reviewed and commented on document revisions. + + o Manoj Goyal and Vivek Dubey complained enough about link-LSAs + being unnecessary to compel introduction of the LinkLSASuppression + interface configuration parameter. + + o Manoj Goyal for pointing out that the next-hop calculation for + intra-area-prefix-LSAs corresponding to network vertices was + unclear. + + o Ramana Koppula reviewed and commented on document revisions. + + o Paul Wells reviewed and commented on document revisions. + + o Amir Khan reviewed and commented on document revisions. + + o Dow Street and Wayne Wheeler commented on the addition of the DN- + bit to OSPFv3. + + o Mitchell Erblichs provided numerous editorial comments. + + o Russ White provided numerous editorial comments. + + o Kashima Hiroaki provided editorial comments. + + o Sina Mirtorabi suggested that OSPFv3 should be aligned with OSPFv2 + with respect to precedence and should map it to IPv6 traffic class + as specified in RFC 2474. Steve Blake helped with the text. + + o Faraz Shamin reviewed a late version of the document and provided + editorial comments. + + + + + +Coltun, et al. Standards Track [Page 54] + +RFC 5340 OSPF for IPv6 July 2008 + + + o Christian Vogt performed the General Area Review Team (Gen-ART) + review and provided comments. + + o Dave Ward, Dan Romascanu, Tim Polk, Ron Bonica, Pasi Eronen, and + Lars Eggert provided comments during the IESG review. Also, + thanks to Pasi for the text in Section 5 relating to routing + threats. + +9. References + +9.1. Normative References + + [DEMAND] Moy, J., "Extending OSPF to Support Demand + Circuits", RFC 1793, April 1995. + + [DIFF-SERV] Nichols, K., Blake, S., Baker, F., and D. Black, + "Definition of the Differentiated Services Field + (DS Field) in the IPv4 and IPv6 Headers", + RFC 2474, December 1998. + + [DN-BIT] Rosen, E., Peter, P., and P. Pillay-Esnault, + "Using a Link State Advertisement (LSA) Options + Bit to Prevent Looping in BGP/MPLS IP Virtual + Private Networks (VPNs)", RFC 4576, June 2006. + + [INTFMIB] McCloghrie, K. and F. Kastenholz, "The Interfaces + Group MIB", RFC 2863, June 2000. + + [IP6ADDR] Hinden, R. and S. Deering, "IP Version 6 + Addressing Architecture", RFC 4291, February 2006. + + [IPAUTH] Kent, S., "IP Authentication Header", RFC 4302, + December 2005. + + [IPESP] Kent, S., "IP Encapsulating Security Payload + (ESP)", RFC 4303, December 2005. + + [IPV4] Postal, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [IPV6] Deering, S. and R. Hinden, "Internet Protocol, + Version 6 (IPv6) Specification", RFC 2460, + December 1998. + + [NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) + Option", RFC 3101, January 2003. + + + + + +Coltun, et al. Standards Track [Page 55] + +RFC 5340 OSPF for IPv6 July 2008 + + + [OSPF-IANA] Kompella, K. and B. Fenner, "IANA Considerations + for OSPF", BCP 130, RFC 4940, July 2007. + + [OSPFV2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, + April 1998. + + [OSPFV3-AUTH] Gupta, M. and N. Melam, "Authentication/ + Confidentiality for OSPFv3", RFC 4552, June 2006. + + [RFC-KEYWORDS] Bradner, S., "Key words for use in RFCs to + Indicate Requirement Levels", BCP 14, RFC 2119, + March 1997. + +9.2. Informative References + + [GENERIC-THREATS] Barbir, A., Murphy, S., and Y. Yang, "Generic + Threats to Routing Protocols", RFC 4593, + October 2006. + + [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, + March 1994. + + [MTUDISC] Mogul, J. and S. Deering, "Path MTU discovery", + RFC 1191, November 1990. + + [OPAQUE] Coltun, R., "The OSPF Opaque LSA Option", + RFC 2370, July 1998. + + [OSPFV3] Coltun, R., Ferguson, D., and J. Moy, "OSPF for + IPv6", RFC 2740, December 1999. + + [OSPFV3-MIB] Joyal, D. and V. Manral, "Management Information + Base for OSPFv3", Work in Progress, + September 2007. + + [SERV-CLASS] Babiarz, J., Chan, K., and F. Baker, + "Configuration Guidelines for DiffServ Service + Classes", RFC 4594, August 2006. + + + + + + + + + + + + + +Coltun, et al. Standards Track [Page 56] + +RFC 5340 OSPF for IPv6 July 2008 + + +Appendix 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 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, Link State Request, Link State Update, and + Link State Acknowledgment packets) can usually be split into multiple + 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 size of OSPF + packets sent over virtual links to 1280 bytes unless Path MTU + Discovery is being performed [MTUDISC]. + + 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. b + + + + + + +Coltun, et al. Standards Track [Page 57] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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. + + o The OSPFv2 specification (Appendix A.1 in [OSPFV2]) indicates that + OSPF protocol packets are sent with IP precedence set to + Internetwork Control (B'110') [IPV4]. If routers in the OSPF + routing domain map their IPv6 Traffic Class octet to the + Differentiated Services Code Point (DSCP) as specified in + [DIFF-SERV], then OSPFv3 packets SHOULD be sent with their DSCP + set to CS6 (B'110000'), as specified in [SERV-CLASS]. In networks + supporting this mapping, OSPF packets will be given precedence + over IPv6 data traffic. + +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; 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; + these mismatches are discovered by examining LSAs. + + + + +Coltun, et al. Standards Track [Page 58] + +RFC 5340 OSPF for IPv6 July 2008 + + + Seven 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 Options bits in received Hello + packets, Database Description packets, or LSAs should ignore the + unrecognized bits and process the packet or LSA normally. + + 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+--+ + | | | | | | | | | | | | | | | | |*|*|DC|R|N|x| E|V6| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+--+ + + The Options field + + The Options field + + V6-bit + If this bit is clear, the router/link should be excluded from IPv6 + routing calculations. See Section 4.8 for details. + + 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 [OSPFV2]. + + x-Bit + This bit was previously used by MOSPF (see [MOSPF]), which has + been deprecated for OSPFv3. The bit should be set to 0 and + ignored when received. It may be reassigned in the future. + + N-bit + This bit indicates whether or not the router is attached to an + NSSA as specified in [NSSA]. + + R-bit + This bit (the `Router' bit) indicates whether the originator is an + active router. If the router bit is clear, then routes that + 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 [DEMAND]. + + + + + +Coltun, et al. Standards Track [Page 59] + +RFC 5340 OSPF for IPv6 July 2008 + + + *-bit + These bits are reserved for migration of OSPFv2 protocol + extensions. + +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 format is displayed and the packet's + component fields are defined. + + All OSPF packet types (other than the OSPF Hello packets) deal with + lists of LSAs. For example, Link State Update packets implement the + flooding of LSAs throughout the OSPF routing domain. The format of + LSAs is described in Section A.4. + + The receive processing of OSPF packets is detailed in Section 4.2.2. + The sending of OSPF packets is explained in Section 4.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 4.2.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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Version # | Type | Packet length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Router ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Area ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Checksum | Instance ID | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The OSPF Packet Header + + Version # + The OSPF version number. This specification documents version 3 + of the OSPF protocol. + + + + + + +Coltun, et al. Standards Track [Page 60] + +RFC 5340 OSPF for IPv6 July 2008 + + + Type + The OSPF packet types are as follows. See Appendix A.3.2 through + Appendix A.3.6 for details. + + Type Description + --------------------------------- + 1 Hello + 2 Database Description + 3 Link State Request + 4 Link State Update + 5 Link State Acknowledgment + + Packet length + The length of the OSPF protocol packet in bytes. This length + includes the standard OSPF header. + + Router ID + The Router ID of the packet's source. + + Area ID + A 32-bit number identifying the area to which this packet belongs. + All OSPF packets are associated with a single area. Most travel a + single hop only. Packets traversing a virtual link are labeled + 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 Section 8.1 of [IPV6]. The "Upper-Layer Packet + Length" in the pseudo-header is set to the 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 link-local significance only. Received + packets whose Instance ID is not equal to the receiving + interface's Instance ID are discarded. + + + + + + + +Coltun, et al. Standards Track [Page 61] + +RFC 5340 OSPF for IPv6 July 2008 + + + 0 + These fields are reserved. They SHOULD be set to 0 when sending + protocol packets and MUST be ignored when receiving protocol + packets. + +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 allowing differences to 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 bidirectional + communication (the Router IDs of all neighbors whose Hellos have been + recently received). + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 3 | 1 | Packet Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Router ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Area ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Checksum | Instance ID | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Interface ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Rtr Priority | Options | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | HelloInterval | RouterDeadInterval | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Designated Router ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Backup Designated Router ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Neighbor ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... | + + The OSPF Hello Packet + + + +Coltun, et al. Standards Track [Page 62] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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 + ([INTFMIB]). + + Rtr Priority + This router's Router Priority. Used in (Backup) Designated Router + election. If set to 0, the router will be ineligible to become + (Backup) Designated Router. + + Options + The optional capabilities supported by the router, as documented + in Section A.2. + + HelloInterval + The number of seconds between this router's Hello packets. + + RouterDeadInterval + The number of seconds before declaring a silent router down. + + Designated Router ID + The sending router's view of the identity of the Designated Router + for this network. The Designated Router is identified by its + Router ID. It is set to 0.0.0.0 if there is no Designated Router. + + Backup Designated Router ID + The sending router's view of the identity of the Backup Designated + Router for this network. The Backup Designated Router is + identified by its IP Router ID. It is set to 0.0.0.0 if there is + no Backup Designated Router. + + Neighbor ID + The Router IDs of each router on the network with neighbor state + 1-Way or greater. + +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 + and the other is the slave. The master sends Database Description + packets (polls) that 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 63] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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 OSPF Database Description Packet + + The format of the Database Description packet is very similar to both + the Link State Request packet and the Link State Acknowledgment + packet. 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 + [OSPFV2]. The reception of Database Description packets is + documented in Section 10.6 of [OSPFV2]. + + 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 [MTUDISC]. + + + + +Coltun, et al. Standards Track [Page 64] + +RFC 5340 OSPF for IPv6 July 2008 + + + Interface MTU should be set to 0 in Database Description packets + sent over virtual links. + + I-bit + The Init bit. When set to 1, this packet is the first in the + sequence of Database Description packets. + + M-bit + The More bit. When set to 1, it indicates that more Database + Description packets are to follow. + + MS-bit + The Master/Slave bit. When set to 1, it indicates that the router + is the master during the Database Exchange process. Otherwise, + the router is the slave. + + DD sequence number + Used to sequence the collection of Database Description packets. + The initial value (indicated by the Init bit being set) should be + unique. The DD sequence number then increments until the complete + database for both the master and slave routers have been + exchanged. + + 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 Appendix A.4.2. + 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 LSA + instances in response. + + The sending of Link State Request packets is documented in Section + 10.9 of [OSPFV2]. The reception of Link State Request packets is + documented in Section 10.7 of [OSPFV2]. + + + +Coltun, et al. Standards Track [Page 65] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... | + + The OSPF Link State Request Packet + + Each LSA requested is specified by its LS type, Link State ID, and + Advertising Router. This uniquely identifies the LSA without + specifying its instance. Link State Request packets are understood + to be requests for the most recent instance of the specified LSAs. + +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 4.5. + + + + + + + + + + + +Coltun, et al. Standards Track [Page 66] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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 | + +- +-+ + | ... | + + + The OSPF Link State Update Packet + + # 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 + Appendix A.4.2. Detailed formats of the different types of LSAs are + described Appendix 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 or + implicitly acknowledged. Explicit acknowledgment is accomplished + through the sending and receiving of Link State Acknowledgment + packets. The sending of Link State Acknowledgment packets is + documented in Section 13.5 of [OSPFV2]. The reception of Link State + Acknowledgment packets is documented in Section 13.7 of [OSPFV2]. + + Multiple LSAs MAY 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 to the multicast + address AllSPFRouters, the multicast address AllDRouters, or to a + neighbor's unicast address (see Section 13.5 of [OSPFV2] for + details). + + + + +Coltun, et al. Standards Track [Page 67] + +RFC 5340 OSPF for IPv6 July 2008 + + + The format of this packet is similar to that of the Data Description + packet. The body of both packets is simply a list of LSA headers. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 3 | 5 | Packet Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Router ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Area ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Checksum | Instance ID | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +- -+ + | | + +- An LSA Header -+ + | | + +- -+ + | | + +- -+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... | + + The OSPF Link State Acknowledgment Packet + + Each acknowledged LSA is described by its LSA header. The LSA header + is documented in Appendix 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 document defines eight distinct types of LSAs. Each LSA begins + with a standard 20-byte LSA header. This header is explained in + Appendix A.4.2. Succeeding sections describe each LSA type + individually. + + 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, AS- + external-LSAs, and NSSA-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 + + + +Coltun, et al. Standards Track [Page 68] + +RFC 5340 OSPF for IPv6 July 2008 + + + flooding algorithm is reliable, ensuring that all routers common to a + flooding scope have the same collection of LSAs associated with that + flooding scope. (See Section 4.5 for more information concerning the + flooding algorithm.) This collection of LSAs is called the link- + state database. + + From the link-state database, each router constructs a shortest-path + tree with itself as root. This yields a routing table (see Section + 11 of [OSPFV2]). For details on the routing table build process, see + Section 4.8. + +A.4.1. IPv6 Prefix Representation + + IPv6 addresses are bit strings of length 128. IPv6 routing + protocols, 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 Appendix A.4.1.1). 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 + Appendix A.4.5, Appendix A.4.7, Appendix A.4.8, Appendix A.4.9, and + Appendix A.4.10. + +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. For + example, they can indicate that prefixes are to be ignored in some + cases or are to be marked as not readvertisable in others. + + 0 1 2 3 4 5 6 7 + +--+--+--+--+--+-+--+--+ + | | | |DN| P|x|LA|NU| + +--+--+--+--+--+-+--+--+ + + The PrefixOptions Field + + + + + +Coltun, et al. Standards Track [Page 69] + +RFC 5340 OSPF for IPv6 July 2008 + + + NU-bit + The "no unicast" capability bit. If set, the prefix should be + excluded from IPv6 unicast calculations. If not set, it should be + included. + + LA-bit + The "local address" capability bit. If set, the prefix is + actually an IPv6 interface address of the Advertising Router. + Advertisement of local interface addresses is described in + Section 4.4.3.9. An implementation MAY also set the LA-bit for + prefixes advertised with a host PrefixLength (128). + + x-bit + This bit was previously defined as a "multicast" capability bit. + However, the use was never adequately specified and has been + deprecated for OSPFv3. The bit should be set to 0 and ignored + when received. It may be reassigned in the future. + + P-bit + The "propagate" bit. Set on NSSA area prefixes that should be + readvertised by the translating NSSA area border [NSSA]. + + DN-bit + This bit controls an inter-area-prefix-LSAs or AS-external-LSAs + re-advertisement in a VPN environment as specified in [DN-BIT]. + +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. + + + + + + + + + + + + + + + + +Coltun, et al. Standards Track [Page 70] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The LSA Header + + 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 Appendix A.4.2.1 for a + detailed description of LS type. + + Link State ID + The originating router's identifier for the LSA. The combination + of the Link State ID, LS type, and Advertising Router uniquely + identify 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 + Successive instances of an LSA are given successive LS sequence + numbers. The sequence number can be used to detect old or + duplicate LSA instances. See Section 12.1.6 in [OSPFV2] 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 [OSPFV2] for more details. + + + + + +Coltun, et al. Standards Track [Page 71] + +RFC 5340 OSPF for IPv6 July 2008 + + + length + The length in bytes of the LSA. This includes the 20-byte LSA + header. + +A.4.2.1. LSA 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 | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + LSA Type + + The U-bit indicates how the LSA should be handled by a router that + 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 the type is understood + + U-Bit + + 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 originating link + 0 1 Area Scoping - Flooded only in originating area + 1 0 AS Scoping - Flooded throughout AS + 1 1 Reserved + + Flooding Scope + + The LSA function codes are defined as follows. The origination and + processing of these LSA function codes are defined elsewhere in this + document, except for the NSSA-LSA (see [NSSA]) and 0x2006, which was + previously used by MOSPF (see [MOSPF]). MOSPF has been deprecated + for OSPFv3. As shown below, each LSA function b code also implies a + specific setting for the U, S1, and S2 bits. + + + + +Coltun, et al. Standards Track [Page 72] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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 Deprecated (may be reassigned) + 7 0x2007 NSSA-LSA + 8 0x0008 Link-LSA + 9 0x2009 Intra-Area-Prefix-LSA + + LSA Function Code + +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 4.4.3.2. Router-LSAs are + only flooded throughout a single area. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Coltun, et al. Standards Track [Page 73] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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 |Nt|x|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 | + +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... | + + Router-LSA Format + + 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. + + + + + + +Coltun, et al. Standards Track [Page 74] + +RFC 5340 OSPF for IPv6 July 2008 + + + Bit V + When set, the router is an endpoint of one or more fully adjacent + virtual links having the described area as transit area (V is for + virtual link endpoint). + + Bit E + When set, the router is an AS boundary router (E is for external). + + Bit B + When set, the router is an area border router (B is for border). + + Bit x + This bit was previously used by MOSPF (see [MOSPF]) and has been + deprecated for OSPFv3. The bit should be set to 0 and ignored + when received. It may be reassigned in the future. + + Bit Nt + When set, the router is an NSSA border router that is + unconditionally translating NSSA-LSAs into AS-external-LSAs (Nt + stands for NSSA translation). Note that such routers have their + NSSATranslatorRole area configuration parameter set to Always. + (See [NSSA].) + + Options + The optional capabilities supported by the router, as documented + in Appendix 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 + + Router Link Types + + + + + + +Coltun, et al. Standards Track [Page 75] + +RFC 5340 OSPF for IPv6 July 2008 + + + Metric + The cost of using this router interface for outbound traffic. + + Interface ID + The Interface ID assigned to the interface being described. See + Section 4.1.2 and Appendix C.3. + + Neighbor Interface ID + The Interface ID the neighbor router has associated with the link, + as advertised in the neighbor's Hello packets. For transit (type + 2) links, the link's Designated Router is the neighbor described. + For other link types, the sole adjacent neighbor is described. + + Neighbor Router ID + The Router ID the of the neighbor router. For transit (type 2) + links, the link's Designated Router is the neighbor described. + For other link types, the sole adjacent neighbor is described. + + For transit (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 that includes + two or more adjacent 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 4.4.3.3. + + + + + + + + + + + + + + + +Coltun, et al. Standards Track [Page 76] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... | + + Network-LSA Format + + Attached Router + The Router IDs of each of the routers attached to the link. + Actually, only those routers that are fully adjacent to the + Designated Router are listed. The Designated Router includes + itself in this list. The number of routers included can be + deduced from the LSA header's length field. + +A.4.5. Inter-Area-Prefix-LSAs + + Inter-area-prefix-LSAs have LS type equal to 0x2003. These LSAs are + the IPv6 equivalent of OSPF for IPv4's type 3 summary-LSAs (see + Section 12.4.3 of [OSPFV2]). 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 4.4.3.4. + + 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. + + + + + + + + +Coltun, et al. Standards Track [Page 77] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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 | + | ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Inter-Area-Prefix-LSA Format + + Metric + The cost of this route. Expressed in the same units as the + interface costs in router-LSAs. When the inter-area-prefix-LSA is + describing a route to a range of addresses (see Appendix 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 + Appendix A.4.1. + +A.4.6. Inter-Area-Router-LSAs + + Inter-area-router-LSAs have LS type equal to 0x2004. These LSAs are + the IPv6 equivalent of OSPF for IPv4's type 4 summary-LSAs (see + Section 12.4.3 of [OSPFV2]). Originated by area border routers, they + describe routes to AS boundary routers in other areas. To see why it + is necessary to advertise the location of each ASBR, consult Section + 16.4 in [OSPFV2]. Each LSA describes a route to a single router. + For details concerning the construction of inter-area-router-LSAs, + see Section 4.4.3.5. + + + + + + + +Coltun, et al. Standards Track [Page 78] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Inter-Area-Router-LSA Format + + Options + The optional capabilities supported by the router, as documented + in Appendix A.2. + + Metric + The cost of this route. Expressed in the same units as the + interface costs in router-LSAs. + + Destination Router ID + The Router ID of the router being described by the LSA. + +A.4.7. AS-External-LSAs + + AS-external-LSAs have LS type equal to 0x4005. These LSAs are + originated by AS boundary routers and describe destinations external + to the AS. Each LSA describes a route to a single IPv6 address + prefix. For details concerning the construction of AS-external-LSAs, + see Section 4.4.3.6. + + 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. + + + + + + +Coltun, et al. Standards Track [Page 79] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + AS-external-LSA Format + + 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 other LSAs (i.e., the same units + as the interface costs in router-LSAs). + + 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. + + + +Coltun, et al. Standards Track [Page 80] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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 + Appendix 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. It MUST + NOT be set to the IPv6 Unspecified Address (0:0:0:0:0:0:0:0) or an + IPv6 Link-Local Address (Prefix FE80/10). While OSPFv3 routes are + normally installed with link-local addresses, an OSPFv3 + implementation advertising a forwarding address MUST advertise a + global IPv6 address. This global IPv6 address may be the next-hop + gateway for an external prefix or may be obtained through some + other method (e.g., configuration). + + External Route Tag + A 32-bit field that MAY be used to communicate additional + information between AS boundary routers. Included in the LSA if + and only if bit T has been set. + + Referenced Link State ID + Included if and only if Reference LS Type is non-zero. If + included, additional information concerning the advertised + external route can be found in the LSA having LS type equal to + "Referenced LS Type", Link State ID equal to "Referenced Link + State ID", and Advertising Router the same as that specified in + the AS-external-LSA's link-state header. This additional + information is not used by the OSPF protocol itself. It may be + used to communicate information between AS boundary routers. The + precise nature of such information is outside the scope of this + specification. + + All, none, or some of the fields labeled Forwarding address, External + Route Tag, and Referenced Link State ID MAY be present in the AS- + external-LSA (as indicated by the setting of bit F, bit T, and + Referenced LS Type respectively). When present, Forwarding Address + always comes first, External Route Tag next, and the Referenced Link + State ID last. + + + + +Coltun, et al. Standards Track [Page 81] + +RFC 5340 OSPF for IPv6 July 2008 + + +A.4.8. NSSA-LSAs + + NSSA-LSAs have LS type equal to 0x2007. These LSAs are originated by + AS boundary routers within an NSSA and describe destinations external + to the AS that may or may not be propagated outside the NSSA (refer + to [NSSA]). Other than the LS type, their format is exactly the same + as AS-external LSAs as described in Appendix A.4.7. + + A global IPv6 address MUST be selected as forwarding address for + NSSA-LSAs that are to be propagated by NSSA area border routers. The + selection should proceed the same as OSPFv2 NSSA support [NSSA] with + additional checking to ensure IPv6 link-local address are not + selected. + +A.4.9. Link-LSAs + + Link-LSAs have LS type equal to 0x0008. A router originates a + separate link-LSA for each attached physical link. These LSAs have + link-local flooding scope; they are never flooded beyond the + associated link. 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. + + 3. They allow the router to advertise a collection of Options bits + in the network-LSA originated by the Designated Router on a + broadcast or NBMA link. + + For details concerning the construction of links-LSAs, see + Section 4.4.3.8. + + 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 82] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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 Priority | Options | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +- -+ + | | + +- Link-local Interface Address -+ + | | + +- -+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | # prefixes | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | PrefixLength | PrefixOptions | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Address Prefix | + | ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | PrefixLength | PrefixOptions | 0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Address Prefix | + | ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Link-LSA Format + + Rtr Priority + 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 by the Designated Router on + broadcast or NBMA links. + + + +Coltun, et al. Standards Track [Page 83] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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 + Appendix A.4.1. + +A.4.10. 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 local router address, an attached stub + network segment, or an attached transit network segment. In IPv4, + the first two were accomplished via the router's router-LSA and the + last via a network-LSA. In OSPF for IPv6, all addressing information + that was advertised in router-LSAs and network-LSAs has been removed + and is now advertised in intra-area-prefix-LSAs. For details + concerning the construction of intra-area-prefix-LSA, see + Section 4.4.3.9. + + A router can originate multiple intra-area-prefix-LSAs for each + router or transit network. Each such LSA is distinguished by its + unique Link State ID. + + + + + + + + + + + + + + + + + + + + + + +Coltun, et al. Standards Track [Page 84] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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 | + | ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Intra-Area-Prefix LSA Format + + # prefixes + The number of IPv6 address prefixes contained in the LSA. + + Referenced LS Type, Referenced Link State ID, and Referenced + Advertising Router + Identifies the router-LSA or network-LSA with which the IPv6 + address prefixes should be associated. If Referenced LS Type is + 0x2001, 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 0x2002, 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 85] + +RFC 5340 OSPF for IPv6 July 2008 + + + The rest of the intra-area-prefix-LSA contains a list of IPv6 + prefixes to be associated with the router or transit link, as well as + their associated costs. + + PrefixLength, PrefixOptions, and Address Prefix + Representation of an IPv6 address prefix, as described in + Appendix A.4.1. + + Metric + The cost of this prefix. Expressed in the same units as the + interface costs in router-LSAs. + +Appendix B. Architectural Constants + + Architectural constants for the OSPF protocol are defined in Appendix + B of [OSPFV2]. The only difference for OSPF for IPv6 is that + DefaultDestination is encoded as a prefix with length 0 (see + Appendix A.4.1). + +Appendix 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. Similarly, 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. + + + + + + + + + +Coltun, et al. Standards Track [Page 86] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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 due to a Router ID change, the + router should flush its self-originated LSAs from the routing + domain (see Section 14.1 of [OSPFV2]). Otherwise, they will + persist for up to MaxAge seconds. + + 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 both routing protocol information 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 87] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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 area or NSSA. 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 or NSSA area. Also, + virtual links cannot be configured through stub or NSSA areas. + For more information, see Section 3.6 of [OSPFV2] and [NSSA]. + + 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 + [OSPFV2] for more information. + + NSSATranslatorRole and TranslatorStabilityInterval + These area parameters are described in Appendix D of [NSSA]. + Additionally, an NSSA Area Border Router (ABR) is also required to + allow configuration of whether or not an NSSA default route is + advertised in an NSSA-LSA. If advertised, its metric and metric + type are configurable. These requirements are also described in + Appendix D of [NSSA]. + + ImportSummaries + When set to enabled, prefixes external to the area are imported + into the area via the advertisement of inter-area-prefix-LSAs. + When set to disabled, inter-area routes are not imported into the + area. The default setting is enabled. This parameter is only + valid for stub or NSSA areas. + +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. Therefore, these parameters 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. + + + + + + + + + +Coltun, et al. Standards Track [Page 88] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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 + ([INTFMIB]). + + IPv6 prefixes + The list of IPv6 prefixes to associate with the link. These will + be advertised in intra-area-prefix-LSAs. + + Interface output cost(s) + The cost of sending a packet on the interface, expressed in the + link-state metric. This is advertised as the link cost for this + interface in the router's router-LSA. The interface output cost + MUST always be greater than 0. + + RxmtInterval + The number of seconds between LSA retransmissions for adjacencies + belonging to this interface. Also used when retransmitting + Database Description and Link State Request packets. This should + be well over the expected round-trip delay between any two routers + on the attached link. The setting of this value should be + conservative or needless retransmissions will result. Sample + value for a local area network: 5 seconds. + + InfTransDelay + The estimated number of seconds it takes to transmit a Link State + Update packet over this interface. LSAs contained in the update + packet must have their age incremented by this amount before + transmission. This value should take into account the + transmission and propagation delays of the interface. It MUST be + greater than 0. Sample value for a local area network: 1 second. + + Router Priority + An 8-bit unsigned integer. When two routers attached to a network + both attempt to become the 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 + the Designated Router on the attached link. Router Priority is + only configured for interfaces to broadcast and NBMA networks. + + + +Coltun, et al. Standards Track [Page 89] + +RFC 5340 OSPF for IPv6 July 2008 + + + HelloInterval + The length of time, in seconds, between Hello packets that the + router sends on the interface. This value is advertised in the + router's Hello packets. It MUST be the same for all routers + attached to a common link. The smaller the HelloInterval, the + faster topological changes will be detected. However, more OSPF + routing protocol traffic will ensue. Sample value for a X.25 PDN: + 30 seconds. Sample value for a local area network (LAN): 10 + seconds. + + RouterDeadInterval + After ceasing to hear a router's Hello packets, the number of + seconds before its neighbors declare the router down. This is + also advertised in the router's Hello packets in their + RouterDeadInterval field. This should be some multiple of the + HelloInterval (e.g., 4). This value again MUST be the same for + all routers attached to a common link. + + LinkLSASuppression + Indicates whether or not origination of a link-LSA is suppressed. + If set to "enabled" and the interface type is not broadcast or + NBMA, the router will not originate a link-LSA for the link. This + implies that other routers on the link will ascertain the router's + next-hop address using a mechanism other than the link-LSA (see + Section 4.8.2). The default value is "disabled" for interface + types described in this specification. It is implicitly + "disabled" if the interface type is broadcast or NBMA. Future + interface types MAY specify a different default. + +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 a point-to-point link with no global IPv6 + addresses 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 + Appendix C.3). Virtual links do not have link-local addresses, but + instead use one of the router's global-scope IPv6 addresses as the IP + source in OSPF protocol packets it sends on 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 transit area intra-area path between the two endpoint routers. + The parameter RxmtInterval may be configured and should be well over + + + +Coltun, et al. Standards Track [Page 90] + +RFC 5340 OSPF for IPv6 July 2008 + + + 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 long. + + 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 that the virtual link traverses (referred to + as the virtual link's transit area). Virtual links cannot be + configured through stub or NSSA areas. Additionally, an Instance ID + may be configured for virtual links from different protocol instances + in order to utilize the same transit area (without requiring + different Router IDs for demultiplexing). + +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 listing 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 the Designated Router + (i.e., those routers whose Router Priority for the network is non- + zero), and then only if no automatic procedure for discovering + neighbors exists: + + List of all other attached routers + The list of all other routers attached to the NBMA network. Each + router is configured with its Router ID and IPv6 link-local + address on the network. Also, for each router listed, that + router's eligibility to become the Designated Router must be + defined. When an interface to an NBMA network first comes up, the + router only sends Hello packets to those neighbors eligible to + become the Designated Router until such time that a Designated + Router is elected. + + 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. + + + + + +Coltun, et al. Standards Track [Page 91] + +RFC 5340 OSPF for IPv6 July 2008 + + +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 not defined. + +C.7. Host Route Parameters + + Host prefixes are advertised in intra-area-prefix-LSAs. They + indicate either local 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 + An IPv6 prefix belonging to the directly connected host. This + must not be a valid IPv6 global prefix. + + 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 92] + +RFC 5340 OSPF for IPv6 July 2008 + + +Authors' Addresses + + Rob Coltun + Acoustra Productions + 3204 Brooklawn Terrace + Chevy Chase, MD 20815 + USA + + + Dennis Ferguson + Juniper Networks + 1194 N. Mathilda Avenue + Sunnyvale, CA 94089 + USA + + EMail: dennis@juniper.net + + + John Moy + Sycamore Networks, Inc + 10 Elizabeth Drive + Chelmsford, MA 01824 + USA + + EMail: jmoy@sycamorenet.com + + + Acee Lindem (editor) + Redback Networks + 102 Carric Bend Court + Cary, NC 27519 + USA + + EMail: acee@redback.com + + + + + + + + + + + + + + + + + +Coltun, et al. Standards Track [Page 93] + +RFC 5340 OSPF for IPv6 July 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Coltun, et al. Standards Track [Page 94] + |