idnits 2.17.1 draft-ietf-ospf-ospfv3-update-23.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 4619. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4630. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4637. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4643. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document obsoletes RFC2740, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 13, 2008) is 5820 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2370 (ref. 'OPAQUE') (Obsoleted by RFC 5250) -- Obsolete informational reference (is this intentional?): RFC 2740 (ref. 'OSPFV3') (Obsoleted by RFC 5340) == Outdated reference: A later version (-16) exists of draft-ietf-ospf-ospfv3-mib-12 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Coltun 3 Internet-Draft Acoustra Productions 4 Obsoletes: 2740 (if approved) D. Ferguson 5 Intended status: Standards Track Juniper Networks 6 Expires: November 14, 2008 J. Moy 7 Sycamore Networks, Inc 8 A. Lindem (Editor) 9 Redback Networks 10 May 13, 2008 12 OSPF for IPv6 13 draft-ietf-ospf-ospfv3-update-23.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on November 14, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 This document describes the modifications to OSPF to support version 47 6 of the Internet Protocol (IPv6). The fundamental mechanisms of 48 OSPF (flooding, Designated Router (DR) election, area support, Short 49 Path First (SPF) calculations, etc.) remain unchanged. However, some 50 changes have been necessary, either due to changes in protocol 51 semantics between IPv4 and IPv6, or simply to handle the increased 52 address size of IPv6. These modifications will necessitate 53 incrementing the protocol version from version 2 to version 3. OSPF 54 for IPv6 is also referred to as OSPF Version 3 (OSPFv3). 56 Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as 57 described herein include the following. Addressing semantics have 58 been removed from OSPF packets and the basic Link State 59 Advertisements (LSAs). New LSAs have been created to carry IPv6 60 addresses and prefixes. OSPF now runs on a per-link basis rather 61 than on a per-IP-subnet basis. Flooding scope for LSAs has been 62 generalized. Authentication has been removed from the OSPF protocol 63 and instead relies on IPv6's Authentication Header and Encapsulating 64 Security Payload (ESP). 66 Even with larger IPv6 addresses, most packets in OSPF for IPv6 are 67 almost as compact as those in OSPF for IPv4. Most fields and packet- 68 size limitations present in OSPF for IPv4 have been relaxed. In 69 addition, option handling has been made more flexible. 71 All of OSPF for IPv4's optional capabilities, including demand 72 circuit support and Not-So-Stubby Areas (NSSAs) are also supported in 73 OSPF for IPv6. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 78 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 6 79 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 80 2. Differences from OSPF for IPv4 . . . . . . . . . . . . . . . 7 81 2.1. Protocol processing per-link, not per-subnet . . . . . . 7 82 2.2. Removal of addressing semantics . . . . . . . . . . . . . 7 83 2.3. Addition of Flooding scope . . . . . . . . . . . . . . . 8 84 2.4. Explicit support for multiple instances per link . . . . 8 85 2.5. Use of link-local addresses . . . . . . . . . . . . . . . 8 86 2.6. Authentication changes . . . . . . . . . . . . . . . . . 9 87 2.7. Packet format changes . . . . . . . . . . . . . . . . . . 9 88 2.8. LSA format changes . . . . . . . . . . . . . . . . . . . 10 89 2.9. Handling unknown LSA types . . . . . . . . . . . . . . . 12 90 2.10. Stub/NSSA area support . . . . . . . . . . . . . . . . . 12 91 2.11. Identifying neighbors by Router ID . . . . . . . . . . . 13 92 3. Differences with RFC 2740 . . . . . . . . . . . . . . . . . . 14 93 3.1. Support for Multiple Interfaces on the same Link . . . . 14 94 3.2. Deprecation of MOSPF for IPv6 . . . . . . . . . . . . . . 14 95 3.3. NSSA Specification . . . . . . . . . . . . . . . . . . . 14 96 3.4. Stub Area Unknown LSA Flooding Restriction Deprecated . . 14 97 3.5. Link LSA Suppression . . . . . . . . . . . . . . . . . . 15 98 3.6. LSA Options and Prefix Options Updates . . . . . . . . . 15 99 3.7. IPv6 Site-Local Addresses . . . . . . . . . . . . . . . . 15 100 4. Implementation details . . . . . . . . . . . . . . . . . . . 16 101 4.1. Protocol data structures . . . . . . . . . . . . . . . . 17 102 4.1.1. The Area Data structure . . . . . . . . . . . . . . . 17 103 4.1.2. The Interface Data structure . . . . . . . . . . . . 18 104 4.1.3. The Neighbor Data Structure . . . . . . . . . . . . . 19 105 4.2. Protocol Packet Processing . . . . . . . . . . . . . . . 20 106 4.2.1. Sending protocol packets . . . . . . . . . . . . . . 20 107 4.2.1.1. Sending Hello Packets . . . . . . . . . . . . . . 21 108 4.2.1.2. Sending Database Description Packets . . . . . . 22 109 4.2.2. Receiving Protocol Packets . . . . . . . . . . . . . 22 110 4.2.2.1. Receiving Hello Packets . . . . . . . . . . . . . 24 111 4.3. The Routing table Structure . . . . . . . . . . . . . . . 25 112 4.3.1. Routing table lookup . . . . . . . . . . . . . . . . 26 113 4.4. Link State Advertisements . . . . . . . . . . . . . . . . 26 114 4.4.1. The LSA Header . . . . . . . . . . . . . . . . . . . 26 115 4.4.2. The link-state database . . . . . . . . . . . . . . . 27 116 4.4.3. Originating LSAs . . . . . . . . . . . . . . . . . . 27 117 4.4.3.1. LSA Options . . . . . . . . . . . . . . . . . . . 31 118 4.4.3.2. Router-LSAs . . . . . . . . . . . . . . . . . . . 31 119 4.4.3.3. Network-LSAs . . . . . . . . . . . . . . . . . . 33 120 4.4.3.4. Inter-Area-Prefix-LSAs . . . . . . . . . . . . . 34 121 4.4.3.5. Inter-Area-Router-LSAs . . . . . . . . . . . . . 35 122 4.4.3.6. AS-external-LSAs . . . . . . . . . . . . . . . . 36 123 4.4.3.7. NSSA-LSAs . . . . . . . . . . . . . . . . . . . . 37 124 4.4.3.8. Link-LSAs . . . . . . . . . . . . . . . . . . . . 38 125 4.4.3.9. Intra-Area-Prefix-LSAs . . . . . . . . . . . . . 40 126 4.4.4. Future LSA Validation . . . . . . . . . . . . . . . . 43 127 4.5. Flooding . . . . . . . . . . . . . . . . . . . . . . . . 43 128 4.5.1. Receiving Link State Update packets . . . . . . . . . 44 129 4.5.2. Sending Link State Update packets . . . . . . . . . . 44 130 4.5.3. Installing LSAs in the database . . . . . . . . . . . 46 131 4.6. Definition of self-originated LSAs . . . . . . . . . . . 47 132 4.7. Virtual links . . . . . . . . . . . . . . . . . . . . . . 47 133 4.8. Routing table calculation . . . . . . . . . . . . . . . . 48 134 4.8.1. Calculating the shortest path tree for an area . . . 48 135 4.8.2. The next hop calculation . . . . . . . . . . . . . . 50 136 4.8.3. Calculating the inter-area routes . . . . . . . . . . 51 137 4.8.4. Examining transit areas' summary-LSAs . . . . . . . . 51 138 4.8.5. Calculating AS external and NSSA routes . . . . . . . 51 139 4.9. Multiple interfaces to a single link . . . . . . . . . . 52 140 4.9.1. Standby Interface State . . . . . . . . . . . . . . . 54 141 5. Security Considerations . . . . . . . . . . . . . . . . . . . 56 142 6. Manageability Considerations . . . . . . . . . . . . . . . . 57 143 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 144 7.1. MOSPF for OSPFv3 Deprecation IANA Considerations . . . . 58 145 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 60 146 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 62 147 9.1. Normative References . . . . . . . . . . . . . . . . . . 62 148 9.2. Informative References . . . . . . . . . . . . . . . . . 63 149 Appendix A. OSPF data formats . . . . . . . . . . . . . . . . . 64 150 A.1. Encapsulation of OSPF packets . . . . . . . . . . . . . . 64 151 A.2. The Options field . . . . . . . . . . . . . . . . . . . . 65 152 A.3. OSPF Packet Formats . . . . . . . . . . . . . . . . . . . 67 153 A.3.1. The OSPF packet header . . . . . . . . . . . . . . . 67 154 A.3.2. The Hello Packet . . . . . . . . . . . . . . . . . . 69 155 A.3.3. The Database Description Packet . . . . . . . . . . . 70 156 A.3.4. The Link State Request Packet . . . . . . . . . . . . 72 157 A.3.5. The Link State Update Packet . . . . . . . . . . . . 73 158 A.3.6. The Link State Acknowledgment Packet . . . . . . . . 74 159 A.4. LSA formats . . . . . . . . . . . . . . . . . . . . . . . 75 160 A.4.1. IPv6 Prefix Representation . . . . . . . . . . . . . 76 161 A.4.1.1. Prefix Options . . . . . . . . . . . . . . . . . 76 162 A.4.2. The LSA header . . . . . . . . . . . . . . . . . . . 77 163 A.4.2.1. LSA Type . . . . . . . . . . . . . . . . . . . . 79 164 A.4.3. Router-LSAs . . . . . . . . . . . . . . . . . . . . . 80 165 A.4.4. Network-LSAs . . . . . . . . . . . . . . . . . . . . 83 166 A.4.5. Inter-Area-Prefix-LSAs . . . . . . . . . . . . . . . 84 167 A.4.6. Inter-Area-Router-LSAs . . . . . . . . . . . . . . . 85 168 A.4.7. AS-external-LSAs . . . . . . . . . . . . . . . . . . 86 169 A.4.8. NSSA-LSAs . . . . . . . . . . . . . . . . . . . . . . 89 170 A.4.9. Link-LSAs . . . . . . . . . . . . . . . . . . . . . . 89 171 A.4.10. Intra-Area-Prefix-LSAs . . . . . . . . . . . . . . . 91 172 Appendix B. Architectural Constants . . . . . . . . . . . . . . 94 173 Appendix C. Configurable Constants . . . . . . . . . . . . . . . 95 174 C.1. Global parameters . . . . . . . . . . . . . . . . . . . . 95 175 C.2. Area parameters . . . . . . . . . . . . . . . . . . . . . 95 176 C.3. Router interface parameters . . . . . . . . . . . . . . . 97 177 C.4. Virtual link parameters . . . . . . . . . . . . . . . . . 99 178 C.5. NBMA network parameters . . . . . . . . . . . . . . . . . 99 179 C.6. Point-to-Multipoint network parameters . . . . . . . . . 100 180 C.7. Host route parameters . . . . . . . . . . . . . . . . . . 100 181 Appendix D. Change Log (To Be Removed Prior To Publication) . . 102 182 D.1. Changes from RFC 2740 to 00 Version . . . . . . . . . . . 102 183 D.2. Changes from the 00 Version to the 01 Version . . . . . . 102 184 D.3. Changes from the 01 Version to the 02 Version . . . . . . 103 185 D.4. Changes from the 02 Version to the 03 Version . . . . . . 103 186 D.5. Changes from the 03 Version to the 04 Version . . . . . . 103 187 D.6. Changes from the 04 Version to the 05 Version . . . . . . 104 188 D.7. Changes from the 05 Version to the 06 Version . . . . . . 104 189 D.8. Changes from the 06 Version to the 07 Version . . . . . . 104 190 D.9. Changes from the 07 Version to the 08 Version . . . . . . 104 191 D.10. Changes from the 08 Version to the 09 Version . . . . . . 105 192 D.11. Changes from the 09 Version to the 10 Version . . . . . . 105 193 D.12. Changes from the 10 Version to the 11 Version . . . . . . 105 194 D.13. Changes from the 11 Version to the 12 Version . . . . . . 106 195 D.14. Changes from the 12 Version to the 13 Version . . . . . . 106 196 D.15. Changes from the 13 Version to the 14 Version . . . . . . 106 197 D.16. Changes from the 14 Version to the 15 Version . . . . . . 107 198 D.17. Changes from the 15 Version to the 16 Version . . . . . . 107 199 D.18. Changes from the 16 Version to the 17 Version . . . . . . 107 200 D.19. Changes from the 17 Version to the 18 Version . . . . . . 107 201 D.20. Changes from the 18 Version to the 19 Version . . . . . . 108 202 D.21. Changes from the 19 Version to the 20 Version . . . . . . 108 203 D.22. Changes from the 20 Version to the 21 Version . . . . . . 108 204 D.23. Changes from the 21 Version to the 22 Version . . . . . . 108 205 D.24. Changes from the 22 Version to the 23 Version . . . . . . 109 206 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 110 207 Intellectual Property and Copyright Statements . . . . . . . . . 111 209 1. Introduction 211 This document describes the modifications to OSPF to support version 212 6 of the Internet Protocol (IPv6). The fundamental mechanisms of 213 OSPF (flooding, Designated Router (DR) election, area support, 214 (Shortest Path First) SPF calculations, etc.) remain unchanged. 215 However, some changes have been necessary, either due to changes in 216 protocol semantics between IPv4 and IPv6, or simply to handle the 217 increased address size of IPv6. These modifications will necessitate 218 incrementing the protocol version from version 2 to version 3. OSPF 219 for IPv6 is also referred to as OSPF Version 3 (OSPFv3). 221 This document is organized as follows. Section 2 describes the 222 differences between OSPF for IPv4 (OSPF Version 2) and OSPF for IPv6 223 (OSPF Version 3) in detail. Section 3 describes the difference 224 between RFC 2740 and this document. Section 4 provides 225 implementation details for the changes. Appendix A gives the OSPF 226 for IPv6 packet and Link State Advertisement (LSA) formats. Appendix 227 B lists the OSPF architectural constants. Appendix C describes 228 configuration parameters. 230 1.1. Requirements notation 232 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 233 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 234 document are to be interpreted as described in [RFC-KEYWORDS]. 236 1.2. Terminology 238 This document attempts to use terms from both the OSPF for IPv4 239 specification ([OSPFV2]) and the IPv6 protocol specifications 240 ([IPV6]). This has produced a mixed result. Most of the terms used 241 both by OSPF and IPv6 have roughly the same meaning (e.g., 242 interfaces). However, there are a few conflicts. IPv6 uses "link" 243 similarly to IPv4 OSPF's "subnet" or "network". In this case, we 244 have chosen to use IPv6's "link" terminology. "Link" replaces OSPF's 245 "subnet" and "network" in most places in this document, although 246 OSPF's network-LSA remains unchanged (and possibly unfortunately, a 247 new link-LSA has also been created). 249 The names of some of the OSPF LSAs have also changed. See 250 Section 2.8 for details. 252 In the context of this document, an OSPF instance is a separate 253 protocol instance complete with its own protocol data structures 254 (e.g., areas, interfaces, neighbors), link-state database, protocol 255 state machines, and protocol processing (e.g., SPF calculation). 257 2. Differences from OSPF for IPv4 259 Most of the algorithms from OSPF for IPv4 [OSPFV2] have been 260 preserved in OSPF for IPv6. However, some changes have been 261 necessary, either due to changes in protocol semantics between IPv4 262 and IPv6, or simply to handle the increased address size of IPv6. 264 The following subsections describe the differences between this 265 document and [OSPFV2]. 267 2.1. Protocol processing per-link, not per-subnet 269 IPv6 uses the term "link" to indicate "a communication facility or 270 medium over which nodes can communicate at the link layer" ([IPV6]). 271 "Interfaces" connect to links. Multiple IPv6 subnets can be assigned 272 to a single link, and two nodes can talk directly over a single link, 273 even if they do not share a common IPv6 subnet (IPv6 prefix). 275 For this reason, OSPF for IPv6 runs per-link instead of the IPv4 276 behavior of per-IP-subnet. The terms "network" and "subnet" used in 277 the IPv4 OSPF specification ([OSPFV2]) should generally be replaced 278 by link. Likewise, an OSPF interface now connects to a link instead 279 of an IP subnet. 281 This change affects the receiving of OSPF protocol packets, the 282 contents of Hello packets, and the contents of network-LSAs. 284 2.2. Removal of addressing semantics 286 In OSPF for IPv6, addressing semantics have been removed from the 287 OSPF protocol packets and the main LSA types, leaving a network- 288 protocol-independent core. In particular: 290 o IPv6 Addresses are not present in OSPF packets, except in LSA 291 payloads carried by the Link State Update packets. See 292 Section 2.7 for details. 294 o Router-LSAs and network-LSAs no longer contain network addresses, 295 but simply express topology information. See Section 2.8 for 296 details. 298 o OSPF Router IDs, Area IDs, and LSA Link State IDs remain at the 299 IPv4 size of 32-bits. They can no longer be assigned as (IPv6) 300 addresses. 302 o Neighboring routers are now always identified by Router ID. 303 Previously, they had been identified by IPv4 address on broadcast, 304 NBMA, and point-to-multipoint links. 306 2.3. Addition of Flooding scope 308 Flooding scope for LSAs has been generalized and is now explicitly 309 coded in the LSA's LS type field. There are now three separate 310 flooding scopes for LSAs: 312 o Link-local scope. LSA is only flooded on the local link and no 313 further. Used for the new link-LSA. See Section 4.4.3.8 for 314 details. 316 o Area scope. LSA is only flooded throughout a single OSPF area. 317 Used for router-LSAs, network-LSAs, inter-area-prefix-LSAs, inter- 318 area-router-LSAs, and intra-area-prefix-LSAs. 320 o AS scope. LSA is flooded throughout the routing domain. Used for 321 AS-external-LSAs. A router that originates AS scoped LSAs is 322 considered an AS Boundary Router (ASBR) and will set its E-bit in 323 Router-LSAs for regular areas. 325 2.4. Explicit support for multiple instances per link 327 OSPF now supports the ability to run multiple OSPF protocol instances 328 on a single link. For example, this may be required on a NAP segment 329 shared between several providers. Providers may be supporting 330 separate OSPF routing domains that wish to remain separate even 331 though they have one or more physical network segments (i.e., links) 332 in common. In OSPF for IPv4 this was supported in a haphazard 333 fashion using the authentication fields in the OSPF for IPv4 header. 335 Another use for running multiple OSPF instances is if you want, for 336 one reason or another, to have a single link belong to two or more 337 OSPF areas. 339 Support for multiple protocol instances on a link is accomplished via 340 an "Instance ID" contained in the OSPF packet header and OSPF 341 interface data structures. Instance ID solely affects the reception 342 of OSPF packets and applies to normal OSPF interfaces and virtual 343 links. 345 2.5. Use of link-local addresses 347 IPv6 link-local addresses are for use on a single link, for purposes 348 of neighbor discovery, auto-configuration, etc. IPv6 routers do not 349 forward IPv6 datagrams having link-local source addresses [IP6ADDR]. 350 Link-local unicast addresses are assigned from the IPv6 address range 351 FE80/10. 353 OSPF for IPv6 assumes that each router has been assigned link-local 354 unicast addresses on each of the router's attached physical links 355 [IP6ADDR]. On all OSPF interfaces except virtual links, OSPF packets 356 are sent using the interface's associated link-local unicast address 357 as the source address. A router learns the link-local addresses of 358 all other routers attached to its links and uses these addresses as 359 next hop information during packet forwarding. 361 On virtual links, a global scope IPv6 address MUST be used as the 362 source address for OSPF protocol packets. 364 Link-local addresses appear in OSPF link-LSAs (see Section 4.4.3.8). 365 However, link-local addresses are not allowed in other OSPF LSA 366 types. In particular, link-local addresses MUST NOT be advertised in 367 inter-area-prefix-LSAs (Section 4.4.3.4), AS-external-LSAs 368 (Section 4.4.3.6), NSSA-LSAs (Section 4.4.3.7), or intra-area-prefix- 369 LSAs (Section 4.4.3.9). 371 2.6. Authentication changes 373 In OSPF for IPv6, authentication has been removed from the OSPF 374 protocol. The "AuType" and "Authentication" fields have been removed 375 from the OSPF packet header, and all authentication related fields 376 have been removed from the OSPF area and interface data structures. 378 When running over IPv6, OSPF relies on the IP Authentication Header 379 (see [IPAUTH]) and the IP Encapsulating Security Payload (see 380 [IPESP]) as described in [OSPFV3-AUTH] to ensure integrity and 381 authentication/confidentiality of routing exchanges. 383 Protection of OSPF packet exchanges against accidental data 384 corruption is provided by the standard IPv6 Upper-Layer checksum (as 385 described in section 8.1 of [IPV6]), covering the entire OSPF packet 386 and prepended IPv6 pseudo-header (see Appendix A.3.1). 388 2.7. Packet format changes 390 OSPF for IPv6 runs directly over IPv6. Aside from this, all 391 addressing semantics have been removed from the OSPF packet headers, 392 making it essentially "network-protocol-independent". All addressing 393 information is now contained in the various LSA types only. 395 In detail, changes in OSPF packet format consist of the following: 397 o The OSPF version number has been incremented from 2 to 3. 399 o The Options field in Hello packets and Database Description 400 packets has been expanded to 24-bits. 402 o The Authentication and AuType fields have been removed from the 403 OSPF packet header (see Section 2.6) 405 o The Hello packet now contains no address information at all 406 Rather, it now includes an Interface ID which the originating 407 router has assigned to uniquely identify (among its own 408 interfaces) its interface to the link. This Interface ID will be 409 used as the network-LSA's Link State ID if the router becomes 410 Designated-Router on the link. 412 o Two option bits, the "R-bit" and the "V6-bit", have been added to 413 the Options field for processing router-LSAs during the SPF 414 calculation (see Appendix A.2). If the "R-bit" is clear an OSPF 415 speaker can participate in OSPF topology distribution without 416 being used to forward transit traffic; this can be used in multi- 417 homed hosts that want to participate in the routing protocol. The 418 V6-bit specializes the R-bit; if the V6-bit is clear an OSPF 419 speaker can participate in OSPF topology distribution without 420 being used to forward IPv6 datagrams. If the R-bit is set and the 421 V6-bit is clear, IPv6 datagrams are not forwarded but datagrams 422 belonging to another protocol family may be forwarded. 424 o The OSPF packet header now includes an "Instance ID" which allows 425 multiple OSPF protocol instances to be run on a single link (see 426 Section 2.4). 428 2.8. LSA format changes 430 All addressing semantics have been removed from the LSA header, 431 router-LSAs, and network-LSAs. These two LSAs now describe the 432 routing domain's topology in a network protocol independent manner. 433 New LSAs have been added to distribute IPv6 address information and 434 data required for next hop resolution. The names of some of IPv4's 435 LSAs have been changed to be more consistent with each other. 437 In detail, changes in LSA format consist of the following: 439 o The Options field has been removed from the LSA header, expanded 440 to 24 bits, and moved into the body of router-LSAs, network-LSAs, 441 inter-area-router-LSAs, and link-LSAs. See Appendix A.2 for 442 details. 444 o The LSA Type field has been expanded (into the former Options 445 space) to 16 bits, with the upper three bits encoding flooding 446 scope and the handling of unknown LSA types (see Section 2.9). 448 o Addresses in LSAs are now expressed as [prefix, prefix length] 449 instead of [address, mask] (see Appendix A.4.1). The default 450 route is expressed as a prefix with length 0. 452 o Router-LSAs and network-LSAs now have no address information and 453 are network protocol independent. 455 o Router interface information MAY be spread across multiple router- 456 LSAs. Receivers MUST concatenate all the router-LSAs originated 457 by a given router when running the SPF calculation. 459 o A new LSA called the link-LSA has been introduced. Link-LSAs have 460 local-link flooding scope; they are never flooded beyond the link 461 with which they are associated. Link-LSAs have three purposes: 1) 462 they provide the router's link-local address to all other routers 463 attached to the link, 2) they inform other routers attached to the 464 link of a list of IPv6 prefixes to associate with the link, and 3) 465 they allow the router to advertise a collection of Options bits to 466 associate with the network-LSA that will be originated for the 467 link. See Section 4.4.3.8 for details. 469 o In IPv4, the router-LSA carries a router's IPv4 interface 470 addresses, the IPv4 equivalent of link-local addresses. These are 471 only used when calculating next hops during the OSPF routing 472 calculation (see Section 16.1.1 of [OSPFV2]), so they do not need 473 to be flooded past the local link. Hence, using link-LSAs to 474 distribute these addresses is more efficient. Note that link- 475 local addresses cannot be learned through the reception of Hellos 476 in all cases. On NBMA links, next hop routers do not necessarily 477 exchange hellos. Rather, these routers learn of each other's 478 existence by way of the Designated Router (DR). 480 o The Options field in the Network LSA is set to the logical OR of 481 the Options that each router on the link advertises in its link- 482 LSA. 484 o Type-3 summary-LSAs have been renamed "inter-area-prefix-LSAs". 485 Type-4 summary LSAs have been renamed "inter-area-router-LSAs". 487 o The Link State ID in inter-area-prefix-LSAs, inter-area-router- 488 LSAs, NSSA-LSAs, and AS-external-LSAs, has lost its addressing 489 semantics and now serves solely to identify individual pieces of 490 the Link State Database. All addresses or Router IDs that were 491 formerly expressed by the Link State ID are now carried in the LSA 492 bodies 494 o Network-LSAs and link-LSAs are the only LSAs whose Link State ID 495 carries additional meaning. For these LSAs, the Link State ID is 496 always the Interface ID of the originating router on the link 497 being described. For this reason, network-LSAs and link-LSAs are 498 now the only LSAs whose size cannot be limited: a network-LSA MUST 499 list all routers connected to the link and a link-LSA MUST list 500 all of a router's addresses on the link. 502 o A new LSA called the intra-area-prefix-LSA has been introduced. 503 This LSA carries all IPv6 prefix information that in IPv4 is 504 included in router-LSAs and network-LSAs. See Section 4.4.3.9 for 505 details. 507 o Inclusion of a forwarding address or external route tag in AS- 508 external-LSAs is now optional. In addition, AS-external-LSAs can 509 now reference another LSA, for inclusion of additional route 510 attributes that are outside the scope of the OSPF protocol. For 511 example, this reference could be used to attach BGP path 512 attributes to external routes. 514 2.9. Handling unknown LSA types 516 Handling of unknown LSA types has been made more flexible so that, 517 based on LS type, unknown LSA types are either treated as having 518 link-local flooding scope, or are stored and flooded as if they were 519 understood. This behavior is explicitly coded in the LSA Handling 520 bit of the link state header's LS type field (see the U-bit in 521 Appendix A.4.2.1). 523 The IPv4 OSPF behavior of simply discarding unknown types is 524 unsupported due to the desire to mix router capabilities on a single 525 link. Discarding unknown types causes problems when the Designated 526 Router supports fewer options than the other routers on the link. 528 2.10. Stub/NSSA area support 530 In OSPF for IPv4, stub and NSSA areas were designed to minimize link- 531 state database and routing table sizes for the areas' internal 532 routers. This allows routers with minimal resources to participate 533 in even very large OSPF routing domains. 535 In OSPF for IPv6, the concept of stub and NSSA areas is retained. In 536 IPv6, of the mandatory LSA types, stub areas carry only router-LSAs, 537 network-LSAs, inter-area-prefix-LSAs, link-LSAs, and intra-area- 538 prefix-LSAs. NSSA areas are restricted to these types and, of 539 course, NSSA-LSAs. This is the IPv6 equivalent of the LSA types 540 carried in IPv4 stub areas: router-LSAs, network-LSAs, type 3 541 summary-LSAs and for NSSA areas: stub area types and NSSA-LSAs. 543 2.11. Identifying neighbors by Router ID 545 In OSPF for IPv6, neighboring routers on a given link are always 546 identified by their OSPF Router ID. This contrasts with the IPv4 547 behavior where neighbors on point-to-point networks and virtual links 548 are identified by their Router IDs while neighbors on broadcast, 549 NBMA, and Point-to-Multipoint links are identified by their IPv4 550 interface addresses. 552 This change affects the reception of OSPF packets (see Section 8.2 of 553 [OSPFV2]), the lookup of neighbors (Section 10 of [OSPFV2]) and the 554 reception of Hello packets (Section 10.5 of [OSPFV2]). 556 The Router ID of 0.0.0.0 is reserved and SHOULD NOT be used. 558 3. Differences with RFC 2740 560 OSPFv3 implementations based on RFC 2740 will fully interoperate with 561 implementations based on this specification. There are, however, 562 some protocol additions and changes (all of which are backward 563 compatible). 565 3.1. Support for Multiple Interfaces on the same Link 567 This protocol feature was only partially specified in the RFC 2740. 568 The level of specification was insufficient to implement the feature. 569 Section 4.9 specifies the additions and clarifications necessary for 570 implementation. They are fully compatible with RFC 2740. 572 3.2. Deprecation of MOSPF for IPv6 574 This protocol feature was only partially specified in the RFC 2740. 575 The level of specification was insufficient to implement the feature. 576 There are no known implementations. MOSPF support and its attendant 577 protocol fields have been deprecated from OSPFv3. Refer to 578 Section 4.4.3.2, Section 4.4.3.4, Section 4.4.3.6, Section 4.4.3.7, 579 Appendix A.2, Appendix A.4.2.1, Appendix A.4.3, Appendix A.4.1.1, and 580 Section 7.1. 582 3.3. NSSA Specification 584 This protocol feature was only partially specified in the RFC 2740. 585 The level of specification was insufficient to implement the 586 function. This document includes NSSA specification unique to 587 OSPFv3. This specification coupled with [NSSA] provide sufficient 588 specification for implementation. Refer to Section 4.8.5, 589 Appendix A.4.3, Appendix A.4.8, and [NSSA]. 591 3.4. Stub Area Unknown LSA Flooding Restriction Deprecated 593 In RFC 2740 [OSPFV3], flooding of unknown LSA was restricted within 594 stub and NSSA areas. The text describing this restriction is 595 included below. 597 However, unlike in IPv4, IPv6 allows LSAs with unrecognized 598 LS types to be labeled "Store and flood the LSA, as if type 599 understood" (see the U-bit in Appendix A.4.2.1). Uncontrolled 600 introduction of such LSAs could cause a stub area's link-state 601 database to grow larger than its component routers' capacities. 603 To guard against this, the following rule regarding stub areas 604 has been established: an LSA whose LS type is unrecognized can 605 only be flooded into/throughout a stub area if both a) the LSA 606 has area or link-local flooding scope and b) the LSA has U-bit 607 set to 0. See Section 3.5 for details. 609 This restriction has been deprecated. OSPFv3 routers will flood link 610 and area scope LSAs whose LS type is unrecognized and whose U-bit is 611 set to 1 throughout stub and NSSA areas. There are no backward 612 compatibility issues other than OSPFv3 routers still supporting the 613 restriction may not propagate newly defined LSA types. 615 3.5. Link LSA Suppression 617 The LinkLSASuppression interface configuration parameter has been 618 added. If LinkLSASuppression is configured for an interface and the 619 interface type is not broadcast or NBMA, origination of the Link-LSA 620 may be suppressed. The LinkLSASuppression interface configuration 621 parameter is described in Appendix C.3. Section 4.8.2 and 622 Section 4.4.3.8 were updated to reflect the parameter's usage. 624 3.6. LSA Options and Prefix Options Updates 626 The LSA options and Prefix Options fields have been updated to 627 reflect recent protocols additions. Specifically, bits related to 628 MOSPF have been deprecated, options field bits common with OSPFv2 629 have been reserved, and the DN-bit has been added to the prefix- 630 options. Refer to Appendix A.2 and Appendix A.4.1.1. 632 3.7. IPv6 Site-Local Addresses 634 All references to IPv6 site-local addresses have been removed. 636 4. Implementation details 638 When going from IPv4 to IPv6, the basic OSPF mechanisms remain 639 unchanged from those documented in [OSPFV2]. These mechanisms are 640 briefly outlined in Section 4 of [OSPFV2]. Both IPv6 and IPv4 have a 641 link-state database composed of LSAs and synchronized between 642 adjacent routers. Initial synchronization is performed through the 643 Database Exchange process, which includes the exchange of Database 644 Description, Link State Request, and Link State Update packets. 645 Thereafter, database synchronization is maintained via flooding, 646 utilizing Link State Update and Link State Acknowledgment packets. 647 Both IPv6 and IPv4 use OSPF Hello packets to discover and maintain 648 neighbor relationships, as well as to elect Designated Routers and 649 Backup Designated Routers on broadcast and NBMA links. The decision 650 as to which neighbor relationships become adjacencies, along with the 651 basic ideas behind inter-area routing, importing external information 652 in AS-external-LSAs, and the various routing calculations are also 653 the same. 655 In particular, the following IPv4 OSPF functionality described in 656 [OSPFV2] remains completely unchanged for IPv6: 658 o Both IPv4 and IPv6 use OSPF packet types described in Section 4.3 659 of [OSPFV2], namely: Hello, Database Description, Link State 660 Request, Link State Update, and Link State Acknowledgment packets. 661 While in some cases (e.g., Hello packets) their format has changed 662 somewhat, the functions of the various packet types remain the 663 same. 665 o The system requirements for an OSPF implementation remain 666 unchanged, although OSPF for IPv6 requires an IPv6 protocol stack 667 (from the network layer on down) since it runs directly over the 668 IPv6 network layer. 670 o The discovery and maintenance of neighbor relationships, and the 671 selection and establishment of adjacencies remain the same. This 672 includes election of the Designated Router and Backup Designated 673 Router on broadcast and NBMA links. These mechanisms are 674 described in Sections 7, 7.1, 7.2, 7.3, 7.4, and 7.5 of [OSPFV2]. 676 o The link types (or equivalently, interface types) supported by 677 OSPF remain unchanged, namely: point-to-point, broadcast, NBMA, 678 Point-to-Multipoint, and virtual links. 680 o The interface state machine, including the list of OSPF interface 681 states and events, and the Designated Router and Backup Designated 682 Router election algorithm, remain unchanged. These are described 683 in Sections 9.1, 9.2, 9.3, and 9.4 of [OSPFV2]. 685 o The neighbor state machine, including the list of OSPF neighbor 686 states and events, remains unchanged. The neighbor state machine 687 is described in Sections 10.1, 10.2, 10.3, and 10.4 of [OSPFV2]. 689 o Aging of the link-state database, as well as flushing LSAs from 690 the routing domain through the premature aging process, remains 691 unchanged from the description in Sections 14 and 14.1 of 692 [OSPFV2]. 694 However, some OSPF protocol mechanisms have changed as previously 695 described in Section 2 herein. These changes are explained in detail 696 in the following subsections, making references to the appropriate 697 sections of [OSPFV2]. 699 The following subsections provide a recipe for turning an IPv4 OSPF 700 implementation into an IPv6 OSPF implementation. 702 4.1. Protocol data structures 704 The major OSPF data structures are the same for both IPv4 and IPv6: 705 areas, interfaces, neighbors, the link-state database, and the 706 routing table. The top-level data structures for IPv6 remain those 707 listed in Section 5 of [OSPFV2], with the following modifications: 709 o All LSAs with known LS type and AS flooding scope appear in the 710 top-level data structure, instead of belonging to a specific area 711 or link. AS-external-LSAs are the only LSAs defined by this 712 specification that have AS flooding scope. LSAs with unknown LS 713 type, U-bit set to 1 (flood even when unrecognized), and AS 714 flooding scope also appear in the top-level data structure. 716 4.1.1. The Area Data structure 718 The IPv6 area data structure contains all elements defined for IPv4 719 areas in Section 6 of [OSPFV2]. In addition, all LSAs of known type 720 which have area flooding scope are contained in the IPv6 area data 721 structure. This always includes the following LSA types: router- 722 LSAs, network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs, 723 and intra-area-prefix-LSAs. LSAs with unknown LS type, U-bit set to 724 1 (flood even when unrecognized) and area scope also appear in the 725 area data structure. NSSA-LSAs are also included in an NSSA area's 726 data structure. 728 4.1.2. The Interface Data structure 730 In OSPF for IPv6, an interface connects a router to a link. The IPv6 731 interface structure modifies the IPv4 interface structure (as defined 732 in Section 9 of [OSPFV2]) as follows: 734 Interface ID 735 Every interface is assigned an Interface ID, which uniquely 736 identifies the interface with the router. For example, some 737 implementations MAY be able to use the MIB-II IfIndex ([INTFMIB]) 738 as Interface ID. The Interface ID appears in Hello packets sent 739 out the interface, the link-local-LSA originated by router for the 740 attached link, and the router-LSA originated by the router-LSA for 741 the associated area. It will also serve as the Link State ID for 742 the network-LSA that the router will originate for the link if the 743 router is elected Designated Router. 744 The interface ID for a virtual link is independent of the 745 interface ID of the outgoing interface it traverses in the transit 746 area. 748 Instance ID 749 Every interface is assigned an Instance ID. This should default 750 to 0. It is only necessary to assign differently on those links 751 that will contain multiple separate communities of OSPF Routers. 752 For example, suppose that there are two communities of routers on 753 a given ethernet segment that you wish to keep separate. 754 The first community is assigned an Instance ID of 0 and all the 755 routers in the first community will be assigned 0 as the Instance 756 ID for interfaces connected to the ethernet segment. An Instance 757 ID of 1 is assigned to the other routers' interfaces connected to 758 the ethernet segment. The OSPF transmit and receive processing 759 (see Section 4.2) will then keep the two communities separate. 761 List of LSAs with link-local scope 762 All LSAs with link-local scope and which were originated/flooded 763 on the link belong to the interface structure that connects to the 764 link. This includes the collection of the link's link-LSAs. 766 IP interface address 767 For IPv6, the IPv6 address appearing in the source of OSPF packets 768 sent out the interface is almost always a link-local address. The 769 one exception is for virtual links which MUST use one of the 770 router's own global IPv6 addresses as IP interface address. 772 List of link prefixes 773 A list of IPv6 prefixes can be configured for the attached link. 774 These will be advertised by the router in link-LSAs, so that they 775 can be advertised by the link's Designated Router in intra-area- 776 prefix-LSAs. 778 In OSPF for IPv6, each router interface has a single metric 779 representing the cost of sending packets out the interface. In 780 addition, OSPF for IPv6 relies on the IP Authentication Header (see 781 [IPAUTH]) and the IP Encapsulating Security Payload (see [IPESP]) as 782 described in [OSPFV3-AUTH] to ensure integrity and authentication/ 783 confidentiality of routing exchanges. For this reason, AuType and 784 Authentication key are not associated with IPv6 OSPF interfaces. 786 Interface states, events, and the interface state machine remain 787 unchanged from IPv4 as documented in Sections 9.1, 9.2, and 9.3 of 788 [OSPFV2] respectively. The Designated Router and Backup Designated 789 Router election algorithm also remains unchanged from the IPv4 790 election in Section 9.4 of [OSPFV2]. 792 4.1.3. The Neighbor Data Structure 794 The neighbor structure performs the same function in both IPv6 and 795 IPv4. Namely, it collects all information required to form an 796 adjacency between two routers when such an adjacency becomes 797 necessary. Each neighbor structure is bound to a single OSPF 798 interface. The differences between the IPv6 neighbor structure and 799 the neighbor structure defined for IPv4 in Section 10 of [OSPFV2] 800 are: 802 Neighbor's Interface ID 803 The Interface ID that the neighbor advertises in its Hello packets 804 must be recorded in the neighbor structure. The router will 805 include the neighbor's Interface ID in the router's router-LSA 806 when either a) advertising a point-to-point or point-to-multipoint 807 link to the neighbor or b) advertising a link to a network where 808 the neighbor has become Designated Router. 810 Neighbor IP address 811 The neighbor's IPv6 address contained as the source address in 812 OSPF for IPv6 packets. This will be an IPv6 link-local address 813 for all link types except virtual links. 815 Neighbor's Designated Router 816 The neighbor's choice of Designated Router is now encoded as a 817 Router ID instead of as an IP address. 819 Neighbor's Backup Designated Router 820 The neighbor's choice of Backup Designated Router is now encoded 821 as a Router ID instead of as an IP address. 823 Neighbor states, events, and the neighbor state machine remain 824 unchanged from IPv4 as documented in Sections 10.1, 10.2, and 10.3 of 825 [OSPFV2] respectively. The decision as to which adjacencies to form 826 also remains unchanged from the IPv4 logic documented in Section 10.4 827 of [OSPFV2]. 829 4.2. Protocol Packet Processing 831 OSPF for IPv6 runs directly over IPv6's network layer. As such, it 832 is encapsulated in one or more IPv6 headers with the Next Header 833 field of the immediately encapsulating IPv6 header set to the value 834 89. 836 As for OSPF for IPv4, OSPF for IPv6 OSPF routing protocol packets are 837 sent along adjacencies only (with the exception of Hello packets, 838 which are used to discover the adjacencies). OSPF packet types and 839 functions are the same in both IPv4 and IPv6, encoded by the Type 840 field of the standard OSPF packet header. 842 4.2.1. Sending protocol packets 844 When an IPv6 router sends an OSPF routing protocol packet, it fills 845 in the fields of the standard OSPF for IPv6 packet header (see 846 Appendix A.3.1) as follows: 848 Version # 849 Set to 3, the version number of the protocol as documented in this 850 specification. 852 Type 853 The type of OSPF packet, such as Link State Update or Hello 854 packet. 856 Packet length 857 The length of the entire OSPF packet in bytes, including the 858 standard OSPF packet header. 860 Router ID 861 The identity of the router itself (who is originating the packet). 863 Area ID 864 The OSPF area for the interface that the packet is being sent on. 866 Instance ID 867 The OSPF Instance ID associated with the interface that the packet 868 is being sent out of. 870 Checksum 871 The standard IPv6 Upper-Layer checksum (as described in section 872 8.1 of [IPV6]) covering the entire OSPF packet and prepended IPv6 873 pseudo-header (see Appendix A.3.1). 875 Selection of OSPF routing protocol packets' IPv6 source and 876 destination addresses is performed identically to the IPv4 logic in 877 Section 8.1 of [OSPFV2]. The IPv6 destination address is chosen from 878 among the addresses AllSPFRouters, AllDRouters, and the Neighbor IP 879 address associated with the other end of the adjacency (which in 880 IPv6, for all links except virtual links, is an IPv6 link-local 881 address). 883 The sending of Link State Request packets and Link State 884 Acknowledgment packets remains unchanged from the IPv4 procedures 885 documented in Sections 10.9 and 13.5 of [OSPFV2] respectively. 886 Sending Hello packets is documented in Section 3.2.1.1, and the 887 sending of Database Description packets in Section 3.2.1.2. The 888 sending of Link State Update packets is documented in Section 3.5.2. 890 4.2.1.1. Sending Hello Packets 892 IPv6 changes the way OSPF Hello packets are sent in the following 893 ways (compare to Section 9.5 of [OSPFV2]): 895 o Before the Hello packet is sent out an interface, the interface's 896 Interface ID MUST be copied into the Hello packet. 898 o The Hello packet no longer contains an IP network mask since OSPF 899 for IPv6 runs per-link instead of per-subnet. 901 o The choice of Designated Router and Backup Designated Router are 902 now indicated within Hellos by their Router IDs instead of by 903 their IP interface addresses. Advertising the Designated Router 904 (or Backup Designated Router) as 0.0.0.0 indicates that the 905 Designated Router (or Backup Designated Router) has not yet been 906 chosen. 908 o The Options field within Hello packets has moved around, getting 909 larger in the process. More options bits are now possible. Those 910 that MUST be set correctly in Hello packets are: The E-bit is set 911 if and only if the interface attaches to a regular area, i.e., not 912 a stub or NSSA area. Similarly, the N-bit is set if and only if 913 the interface attaches to an NSSA area (see [NSSA]). Finally, the 914 DC-bit is set if and only if the router wishes to suppress the 915 sending of future Hellos over the interface (see [DEMAND]). 916 Unrecognized bits in the Hello packet's Options field should be 917 cleared. 919 Sending Hello packets on NBMA networks proceeds for IPv6 in exactly 920 the same way as for IPv4, as documented in Section 9.5.1 of [OSPFV2]. 922 4.2.1.2. Sending Database Description Packets 924 The sending of Database Description packets differs from Section 10.8 925 of [OSPFV2] in the following ways: 927 o The Options field within Database Description packets has moved 928 around, getting larger in the process. More options bits are now 929 possible. Those that MUST be set correctly in Database 930 Description packets are: The DC-bit is set if and only if the 931 router wishes to suppress the sending of Hellos over the interface 932 (see [DEMAND]). Unrecognized bits in the Database Description 933 packet's Options field should be cleared. 935 4.2.2. Receiving Protocol Packets 937 Whenever a router receives an OSPF protocol packet it is marked with 938 the interface it was received on. For routers that have virtual 939 links configured, it may not be immediately obvious which interface 940 to associate the packet with. For example, consider the Router RT11 941 depicted in Figure 6 of [OSPFV2]. If RT11 receives an OSPF protocol 942 packet on its interface to Network N8, it may want to associate the 943 packet with the interface to Area 2, or with the virtual link to 944 Router RT10 (which is part of the backbone). In the following, we 945 assume that the packet is initially associated with the non-virtual 946 link. 948 In order for the packet to be passed to OSPF for processing, the 949 following tests must be performed on the encapsulating IPv6 headers: 951 o The packet's IP destination address MUST be one of the IPv6 952 unicast addresses associated with the receiving interface (this 953 includes link-local addresses), one of the IPv6 multicast 954 addresses AllSPFRouters or AllDRouters, or an IPv6 global address 955 (for virtual links). 957 o The Next Header field of the immediately encapsulating IPv6 header 958 MUST specify the OSPF protocol (89). 960 o Any encapsulating IP Authentication Headers (see [IPAUTH]) and the 961 IP Encapsulating Security Payloads (see [IPESP]) MUST be processed 962 and/or verified to ensure integrity and authentication/ 963 confidentiality of OSPF routing exchanges. This is described in 964 [OSPFV3-AUTH]. 966 After processing the encapsulating IPv6 headers, the OSPF packet 967 header is processed. The fields specified in the header must match 968 those configured for the receiving OSPFv3 interface. If they do not, 969 the packet SHOULD be discarded: 971 o The version number field MUST specify protocol version 3. 973 o The IPv6 Upper-Layer checksum (as described in section 8.1 of 974 [IPV6]), covering the entire OSPF packet and prepended IPv6 975 pseudo-header, must be verified (see Appendix A.3.1). 977 o The Area ID and Instance ID found in the OSPF header must be 978 verified. If both of the following cases fail, the packet should 979 be discarded. The Area ID and Instance ID specified in the header 980 must either: 982 1. Match one of the Area ID(s) and Interface Instance ID(s) for 983 the receiving link. Unlike IPv4, the IPv6 source address is 984 not restricted to lie within the same IPv6 subnet as the 985 receiving link. IPv6 OSPF runs per-link instead of per-IP- 986 subnet. 988 2. Match the backbone area and other criteria for a configured 989 virtual link. The receiving router must be an ABR (Area 990 Border Router) and the Router ID specified in the packet (the 991 source router) must be the other end of a configured virtual 992 link. Additionally, the receiving link must have an OSPFv3 993 interface which attaches to the virtual link's configured 994 transit area and the Instance ID must match the virtual link's 995 Instance ID. If all of these checks succeed, the packet is 996 accepted and is associated with the virtual link (and the 997 backbone area). 999 o Locally originated packets SHOULD NOT be processed by OSPF except 1000 for support of multiple interfaces attached to the same link as 1001 described in Section 4.9. Locally originated packets have a 1002 source address equal to one of the router's local addresses. 1004 o Packets whose IPv6 destination is AllDRouters should only be 1005 accepted if the state of the receiving OSPFv3 interface is DR or 1006 Backup (see Section 9.1 [OSPFV2]). 1008 After header processing, the packet is further processed according to 1009 its OSPF packet type. OSPF packet types and functions are the same 1010 for both IPv4 and IPv6. 1012 If the packet type is Hello, it should then be further processed by 1013 the Hello packet processing as described in Section 4.2.2.1. All 1014 other packet types are sent/received only on adjacencies. This means 1015 that the packet must have been sent by one of the router's active 1016 neighbors. The neighbor is identified by the Router ID appearing in 1017 the received packet's OSPF header. Packets not matching any active 1018 neighbor are discarded. 1020 The receive processing of Database Description packets, Link State 1021 Request packets, and Link State Acknowledgment packets is almost 1022 identical to the IPv4 procedures documented in Sections 10.6, 10.7, 1023 and 13.7 of [OSPFV2] respectively with the exceptions noted below. 1025 o LSAs with unknown LS types in Database Description packets that 1026 have an acceptable flooding scope are processed the same as LSAs 1027 with known LS types. In OSPFv2 [OSPFV2], these would result in 1028 the adjacency being brought down with a SequenceMismatch event. 1030 The receiving of Hello packets is documented in Section 4.2.2.1 and 1031 the receiving of Link State Update packets is documented in 1032 Section 4.5.1. 1034 4.2.2.1. Receiving Hello Packets 1036 The receive processing of Hello packets differs from Section 10.5 of 1037 [OSPFV2] in the following ways: 1039 o On all link types (e.g., broadcast, NBMA, point-to-point, etc), 1040 neighbors are identified solely by their OSPF Router ID. For all 1041 link types except virtual links, the Neighbor IP address is set to 1042 the IPv6 source address in the IPv6 header of the received OSPF 1043 Hello packet. 1045 o There is no longer a Network Mask field in the Hello packet. 1047 o The neighbor's choice of Designated Router and Backup Designated 1048 Router is now encoded as an OSPF Router ID instead of an IP 1049 interface address. 1051 4.3. The Routing table Structure 1053 The routing table used by OSPF for IPv4 is defined in Section 11 of 1054 [OSPFV2]. For IPv6 there are analogous routing table entries: there 1055 are routing table entries for IPv6 address prefixes and also for AS 1056 boundary routers. The latter routing table entries are only used to 1057 hold intermediate results during the routing table build process (see 1058 Section 4.8). 1060 Also, to hold the intermediate results during the shortest-path 1061 calculation for each area, there is a separate routing table for each 1062 area holding the following entries: 1064 o An entry for each router in the area. Routers are identified by 1065 their OSPF router ID. These routing table entries hold the set of 1066 shortest paths through a given area to a given router, which in 1067 turn allows calculation of paths to the IPv6 prefixes advertised 1068 by that router in intra-area-prefix-LSAs. If the router is also 1069 an area-border router, these entries are also used to calculate 1070 paths for inter-area address prefixes. If in addition the router 1071 is the other endpoint of a virtual link, the routing table entry 1072 describes the cost and viability of the virtual link. 1074 o An entry for each transit link in the area. Transit links have 1075 associated network-LSAs. Both the transit link and the network- 1076 LSA are identified by a combination of the Designated Router's 1077 Interface ID on the link and the Designated Router's OSPF Router 1078 ID. These routing table entries allow later calculation of paths 1079 to IP prefixes advertised for the transit link in intra-area- 1080 prefix-LSAs. 1082 The fields in the IPv4 OSPF routing table (see Section 11 of 1083 [OSPFV2]) remain valid for IPv6: Optional capabilities (routers 1084 only), path type, cost, type 2 cost, link state origin, and for each 1085 of the equal cost paths to the destination, the next hop and 1086 advertising router. 1088 For IPv6, the link-state origin field in the routing table entry is 1089 the router-LSA or network-LSA that has directly or indirectly 1090 produced the routing table entry. For example, if the routing table 1091 entry describes a route to an IPv6 prefix, the link state origin is 1092 the router-LSA or network-LSA that is listed in the body of the 1093 intra-area-prefix-LSA that has produced the route (see 1094 Appendix A.4.10). 1096 4.3.1. Routing table lookup 1098 Routing table lookup (i.e., determining the best matching routing 1099 table entry during IP forwarding) is the same for IPv6 as for IPv4. 1101 4.4. Link State Advertisements 1103 For IPv6, the OSPF LSA header has changed slightly, with the LS type 1104 field expanding and the Options field being moved into the body of 1105 appropriate LSAs. Also, the formats of some LSAs have changed 1106 somewhat (namely router-LSAs, network-LSAs, AS-external-LSAs, and 1107 NSSA-LSAs), while the names of other LSAs have been changed (type 3 1108 and 4 summary-LSAs are now inter-area-prefix-LSAs and inter-area- 1109 router-LSAs respectively) and additional LSAs have been added (link- 1110 LSAs and intra-area-prefix-LSAs). Type of Service (TOS) has been 1111 removed from the OSPFv2 specification [OSPFV2], and is not encoded 1112 within OSPF for IPv6's LSAs. 1114 These changes will be described in detail in the following 1115 subsections. 1117 4.4.1. The LSA Header 1119 In both IPv4 and IPv6, all OSPF LSAs begin with a standard 20 byte 1120 LSA header. However, the contents of this 20 byte header have 1121 changed in IPv6. The LS age, Advertising Router, LS Sequence Number, 1122 LS checksum, and length fields within the LSA header remain 1123 unchanged, as documented in Sections 12.1.1, 12.1.5, 12.1.6, 12.1.7 1124 and A.4.1 of [OSPFV2] respectively. However, the following fields 1125 have changed for IPv6: 1127 Options 1128 The Options field has been removed from the standard 20 byte LSA 1129 header and moved into the body of router-LSAs, network-LSAs, 1130 inter-area-router-LSAs, and link-LSAs. The size of the Options 1131 field has increased from 8 to 24 bits, and some of the bit 1132 definitions have changed (see Appendix A.2). Additionally, a 1133 separate PrefixOptions field, 8 bits in length, is attached to 1134 each prefix advertised within the body of an LSA. 1136 LS type 1137 The size of the LS type field has increased from 8 to 16 bits, 1138 with high order bit encoding the handling of unknown types and the 1139 next two bits encoding flooding scope. See Appendix A.4.2.1 for 1140 the current coding of the LS type field. 1142 Link State ID 1143 Link State ID remains at 32 bits in length. However, except for 1144 network-LSAs and link-LSAs, Link State ID has shed any addressing 1145 semantics. For example, an IPv6 router originating multiple AS- 1146 external-LSAs could start by assigning the first a Link State ID 1147 of 0.0.0.1, the second a Link State ID of 0.0.0.2, and so on. 1148 Instead of the IPv4 behavior of encoding the network number within 1149 the AS-external-LSA's Link State ID, the IPv6 Link State ID simply 1150 serves as a way to differentiate multiple LSAs originated by the 1151 same router. 1152 For network-LSAs, the Link State ID is set to the Designated 1153 Router's Interface ID on the link. When a router originates a 1154 link-LSA for a given link, its Link State ID is set equal to the 1155 router's Interface ID on the link. 1157 4.4.2. The link-state database 1159 In IPv6, as in IPv4, individual LSAs are identified by a combination 1160 of their LS type, Link State ID, and Advertising Router fields. 1161 Given two instances of an LSA, the most recent instance is determined 1162 by examining the LSAs' LS Sequence Number, using LS checksum and LS 1163 age as tiebreakers (see Section 13.1 of [OSPFV2]). 1165 In IPv6, the link-state database is split across three separate data 1166 structures. LSAs with AS flooding scope are contained within the 1167 top-level OSPF data structure (see Section 4.1) as long as either 1168 their LS type is known or their U-bit is 1 (flood even when 1169 unrecognized); this includes the AS-external-LSAs. LSAs with area 1170 flooding scope are contained within the appropriate area structure 1171 (see Section 4.1.1) as long as either their LS type is known or their 1172 U-bit is 1 (flood even when unrecognized); this includes router-LSAs, 1173 network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs, NSSA- 1174 LSAs, and intra-area-prefix-LSAs. LSAs with unknown LS type and 1175 U-bit set to 0 and/or link-local flooding scope are contained within 1176 the appropriate interface structure (see Section 4.1.2); this 1177 includes link-LSAs. 1179 To lookup or install an LSA in the database, you first examine the LS 1180 type and the LSA's context (i.e., the area or link to which the LSA 1181 belongs). This information allows you to find the correct database 1182 of LSAs where you then search based on the LSA's type, Link State ID, 1183 and Advertising Router. 1185 4.4.3. Originating LSAs 1187 The process of reoriginating an LSA in IPv6 is the same as in IPv4: 1188 the LSA's LS sequence number is incremented, its LS age is set to 0, 1189 its LS checksum is calculated, and the LSA is added to the link state 1190 database and flooded on the appropriate interfaces. 1192 The list of events causing LSAs to be reoriginated for IPv4 is given 1193 in Section 12.4 of [OSPFV2]. The following events and/or actions are 1194 added for IPv6: 1196 o The state or interface ID of one of the router's interfaces 1197 changes. The router may need to (re)originate or flush its link- 1198 LSA and one or more router-LSAs and/or intra-area-prefix-LSAs. If 1199 the router is Designated Router, the router may also need to 1200 (re)originate and/or flush the network LSA corresponding to the 1201 interface. 1203 o The identity of a link's Designated Router changes. The router 1204 may need to (re)originate or flush the link's network-LSA and one 1205 or more router-LSAs and/or intra-area-prefix-LSAs. 1207 o A neighbor transitions to/from "Full" state. The router may need 1208 to (re)originate or flush the link's network-LSA and one or more 1209 router-LSAs and/or intra-area-prefix-LSAs. 1211 o The Interface ID of a neighbor changes. This may cause a new 1212 instance of a router-LSA to be originated for the associated area. 1214 o A new prefix is added to an attached link, or a prefix is deleted 1215 (both through configuration). This causes the router to 1216 reoriginate its link-LSA for the link or, if it is the only router 1217 attached to the link, causes the router to reoriginate an intra- 1218 area-prefix-LSA. 1220 o A new link-LSA is received, causing the link's collection of 1221 prefixes to change. If the router is Designated Router for the 1222 link, it originates a new intra-area-prefix-LSA. 1224 o A new link-LSA is received, causing the logical OR of LSA options 1225 advertised by adjacent routers on the link to change. If the 1226 router is Designated Router for the link, it originates a new 1227 network-LSA. 1229 Detailed construction of the seven required IPv6 LSA types is 1230 supplied by the following subsections. In order to display example 1231 LSAs, the network map in Figure 15 of [OSPFV2] has been reworked to 1232 show IPv6 addressing, resulting in Figure 1. The OSPF cost of each 1233 interface is has been displayed in Figure 1. The assignment of IPv6 1234 prefixes to network links is shown in Table 1. A single area address 1235 range has been configured for Area 1, so that outside of Area 1 all 1236 of its prefixes are covered by a single route to 2001:0db8:c001::/48. 1238 The OSPF interface IDs and the link-local addresses for the router 1239 interfaces in Figure 1 are given in Table 2. 1241 .......................................... 1242 . Area 1. 1243 . + . 1244 . | . 1245 . | 3+---+1 . 1246 . N1 |--|RT1|-----+ . 1247 . | +---+ \ . 1248 . | \ ______ . 1249 . + \/ \ 1+---+ 1250 . * N3 *------|RT4|------ 1251 . + /\_______/ +---+ 1252 . | / | . 1253 . | 3+---+1 / | . 1254 . N2 |--|RT2|-----+ 1| . 1255 . | +---+ +---+ . 1256 . | |RT3|---------------- 1257 . + +---+ . 1258 . |2 . 1259 . | . 1260 . +------------+ . 1261 . N4 . 1262 .......................................... 1264 Figure 1: Area 1 with IP addresses shown 1266 Network IPv6 prefix 1267 ----------------------------------- 1268 N1 2001:0db8:c001:0200::/56 1269 N2 2001:0db8:c001:0300::/56 1270 N3 2001:0db8:c001:0100::/56 1271 N4 2001:0db8:c001:0400::/56 1273 Table 1: IPv6 link prefixes for sample network 1275 Router Interface Interface ID link-local address 1276 ------------------------------------------------------- 1277 RT1 to N1 1 fe80:0001::RT1 1278 to N3 2 fe80:0002::RT1 1279 RT2 to N2 1 fe80:0001::RT2 1280 to N3 2 fe80:0002::RT2 1281 RT3 to N3 1 fe80:0001::RT3 1282 to N4 2 fe80:0002::RT3 1283 RT4 to N3 1 fe80:0001::RT4 1285 Table 2: OSPF Interface IDs and link-local addresses 1286 Figure 1 1288 4.4.3.1. LSA Options 1290 The Options field in LSAs should be coded as follows. The V6-bit 1291 should be set unless the router will not participate in transit IPv6 1292 routing. The E-bit should be clear if and only if the attached area 1293 is an OSPF stub or OSPF NSSA area. The E-bit should always be set in 1294 AS scoped LSAs. The N-bit should be set if and only if the attached 1295 area is an OSPF NSSA area. The R-bit should be set unless the router 1296 will not participate in any transit routing. The DC-bit should be 1297 set if and only if the router can correctly process the DoNotAge bit 1298 when it appears in the LS age field of LSAs (see [DEMAND]). All 1299 unrecognized bits in the Options field should be cleared. 1301 The V6-bit and R-bit are only examined in Router-LSAs during the SPF 1302 computation. In other LSA types containing options, they are set for 1303 informational purposes only. 1305 4.4.3.2. Router-LSAs 1307 The LS type of a router-LSA is set to the value 0x2001. Router-LSAs 1308 have area flooding scope. A router MAY originate one or more router- 1309 LSAs for a given area. Each router-LSA contains an integral number 1310 of interface descriptions. Taken together, the collection of router- 1311 LSAs originated by the router for an area describes the collected 1312 states of all the router's interfaces attached to the area. When 1313 multiple router-LSAs are used, they are distinguished by their Link 1314 State ID fields. 1316 To the left of the Options field, the router capability bits V, E, 1317 and B should be set according to Section 12.4.1 of [OSPFV2]. 1319 Each of the router's interfaces to the area are then described by 1320 appending "link descriptions" to the router-LSA. Each link 1321 description is 16 bytes long, consisting of 5 fields: (link) Type, 1322 Metric, Interface ID, Neighbor Interface ID, and Neighbor Router ID 1323 (see Appendix A.4.3). Interfaces in state "Down" or "Loopback" are 1324 not described (although looped back interfaces can contribute 1325 prefixes to intra-area-prefix-LSAs). Nor are interfaces without any 1326 full adjacencies described (except in the case of multiple standby 1327 interfaces as described in Section 4.9). All other interfaces to the 1328 area add zero, one, or more link descriptions. The number and 1329 content of these depend on the interface type. Within each link 1330 description, the Metric field is always set to the interface's output 1331 cost and the Interface ID field is set to the interface's OSPF 1332 Interface ID. 1334 Point-to-point interfaces 1335 If the neighboring router is fully adjacent, add a Type 1 link 1336 description (point-to-point). The Neighbor Interface ID field is 1337 set to the Interface ID advertised by the neighbor in its Hello 1338 packets and the Neighbor Router ID field is set to the neighbor's 1339 Router ID. 1341 Broadcast and NBMA interfaces 1342 If the router is fully adjacent to the link's Designated Router or 1343 if the router itself is Designated Router and is fully adjacent to 1344 at least one other router, add a single Type 2 link description 1345 (transit network). The Neighbor Interface ID field is set to the 1346 Interface ID advertised by the Designated Router in its Hello 1347 packets and the Neighbor Router ID field is set to the Designated 1348 Router's Router ID. 1350 Virtual links 1351 If the neighboring router is fully adjacent, add a Type 4 link 1352 description (virtual). The Neighbor Interface ID field is set to 1353 the Interface ID advertised by the neighbor in its Hello packets 1354 and the Neighbor Router ID field is set to the neighbor's Router 1355 ID. Note that the output cost of a virtual link is calculated 1356 during the routing table calculation (see Section 4.7). 1358 Point-to-Multipoint interfaces 1359 For each fully adjacent neighbor associated with the interface, 1360 add a separate Type 1 link description (point-to-point) with 1361 Neighbor Interface ID field set to the Interface ID advertised by 1362 the neighbor in its Hello packets and Neighbor Router ID field set 1363 to the neighbor's Router ID. 1365 As an example, consider the router-LSA that router RT3 would 1366 originate for Area 1 in Figure 1. Only a single interface must be 1367 described, namely that which connects to the transit network N3. It 1368 assumes that RT4 has been elected Designated Router of Network N3. 1370 ; RT3's router-LSA for Area 1 1372 LS age = 0 ;newly (re)originated 1373 LS type = 0x2001 ;router-LSA 1374 Link State ID = 0 ;first fragment 1375 Advertising Router = 192.0.2.3 ;RT3's Router ID 1376 bit E = 0 ;not an AS boundary router 1377 bit B = 1 ;area border router 1378 Options = (V6-bit|E-bit|R-bit) 1379 Type = 2 ;connects to N3 1380 Metric = 1 ;cost to N3 1381 Interface ID = 1 ;RT3's Interface ID on N3 1382 Neighbor Interface ID = 1 ;RT4's Interface ID on N3 1383 Neighbor Router ID = 192.0.2.4 ; RT4's Router ID 1385 RT3's router-LSA for Area 1 1387 For example, if another router was added to Network N4, RT3 would 1388 have to advertise a second link description for its connection to 1389 (the now transit) network N4. This could be accomplished by 1390 reoriginating the above router-LSA, this time with two link 1391 descriptions. Or, a separate router-LSA could be originated with a 1392 separate Link State ID (e.g., using a Link State ID of 1) to describe 1393 the connection to N4. 1395 Host routes for stub networks no longer appear in the router-LSA. 1396 Rather, they are included in intra-area-prefix-LSAs. 1398 4.4.3.3. Network-LSAs 1400 The LS type of a network-LSA is set to the value 0x2002. Network- 1401 LSAs have area flooding scope. A network-LSA is originated for every 1402 broadcast or NBMA link with an elected Designated Router that is 1403 fully adjacent with at least one other router on the link. The 1404 network-LSA is originated by the link's Designated Router and lists 1405 all routers on the link with whom it is fully adjacent. 1407 The procedure for originating network-LSAs in IPv6 is the same as the 1408 IPv4 procedure documented in Section 12.4.2 of [OSPFV2], with the 1409 following exceptions: 1411 o An IPv6 network-LSA's Link State ID is set to the Interface ID of 1412 the Designated Router on the link. 1414 o IPv6 network-LSAs do not contain a Network Mask. All addressing 1415 information formerly contained in the IPv4 network-LSA has now 1416 been consigned to intra-Area-Prefix-LSAs originated by the link's 1417 Designated Router. 1419 o The Options field in the network-LSA is set to the logical OR of 1420 the Options fields contained within the link's associated link- 1421 LSAs corresponding to fully adjacent neighbors. In this way, the 1422 network link exhibits a capability when at least one fully 1423 adjacent neighbor on the link requests that the capability be 1424 advertised. 1426 As an example, assuming that Router RT4 has been elected Designated 1427 Router of Network N3 in Figure 1, the following network-LSA is 1428 originated: 1430 ; Network-LSA for Network N3 1432 LS age = 0 ;newly (re)originated 1433 LS type = 0x2002 ;network-LSA 1434 Link State ID = 1 ;RT4's Interface ID on N3 1435 Advertising Router = 192.0.2.4 ;RT4's Router ID 1436 Options = (V6-bit|E-bit|R-bit) 1437 Attached Router = 192.0.2.4 ;Router ID 1438 Attached Router = 192.0.2.1 ;Router ID 1439 Attached Router = 192.0.2.2 ;Router ID 1440 Attached Router = 192.0.2.3 ;Router ID 1442 Network-LSA for Network N3 1444 4.4.3.4. Inter-Area-Prefix-LSAs 1446 The LS type of an inter-area-prefix-LSA is set to the value 0x2003. 1447 Inter-area-prefix-LSAs have area flooding scope. In IPv4, inter- 1448 area-prefix-LSAs were called type 3 summary-LSAs. Each inter-area- 1449 prefix-LSA describes a prefix external to the area yet internal to 1450 the Autonomous System. 1452 The procedure for originating inter-area-prefix-LSAs in IPv6 is the 1453 same as the IPv4 procedure documented in Sections 12.4.3 and 12.4.3.1 1454 of [OSPFV2], with the following exceptions: 1456 o The Link State ID of an inter-area-prefix-LSA has lost all of its 1457 addressing semantics and simply serves to distinguish multiple 1458 inter-area-prefix-LSAs that are originated by the same router. 1460 o The prefix is described by the PrefixLength, PrefixOptions, and 1461 Address Prefix fields embedded within the LSA body. Network Mask 1462 is no longer specified. 1464 o The NU-bit in the PrefixOptions field should be clear. 1466 o Link-local addresses MUST never be advertised in inter-area- 1467 prefix-LSAs. 1469 As an example, the following shows the inter-area-prefix-LSA that 1470 Router RT4 originates into the OSPF backbone area, condensing all of 1471 Area 1's prefixes into the single prefix 2001:0db8:c001::/48. The 1472 cost is set to 4, which is the maximum cost of all of the individual 1473 component prefixes. The prefix is padded out to an even number of 1474 32-bit words, so that it consumes 64-bits of space instead of 48 1475 bits. 1477 ; Inter-area-prefix-LSA for Area 1 addresses 1478 ; originated by Router RT4 into the backbone 1480 LS age = 0 ;newly (re)originated 1481 LS type = 0x2003 ;inter-area-prefix-LSA 1482 Advertising Router = 192.0.2.4 ;RT4's ID 1483 Metric = 4 ;maximum to components 1484 PrefixLength = 48 1485 PrefixOptions = 0 1486 Address Prefix = 2001:0db8:c001 ;padded to 64-bits 1488 Inter-area-prefix-LSA for Area 1 addresses originated 1489 by Router 1490 RT4 into the backbone 1492 4.4.3.5. Inter-Area-Router-LSAs 1494 The LS type of an inter-area-router-LSA is set to the value 0x2004. 1495 Inter-area-router-LSAs have area flooding scope. In IPv4, inter- 1496 area-router-LSAs were called type 4 summary-LSAs. Each inter-area- 1497 router-LSA describes a path to a destination OSPF router (an AS 1498 Boundary Router or ASBR) that is external to the area yet internal to 1499 the Autonomous System. 1501 The procedure for originating inter-area-router-LSAs in IPv6 is the 1502 same as the IPv4 procedure documented in Section 12.4.3 of [OSPFV2], 1503 with the following exceptions: 1505 o The Link State ID of an inter-area-router-LSA is no longer the 1506 destination router's OSPF Router ID and now simply serves to 1507 distinguish multiple inter-area-router-LSAs that are originated by 1508 the same router. The destination router's Router ID is now found 1509 in the body of the LSA. 1511 o The Options field in an inter-area-router-LSA should be set equal 1512 to the Options field contained in the destination router's own 1513 router-LSA. The Options field thus describes the capabilities 1514 supported by the destination router. 1516 As an example, consider the OSPF Autonomous System depicted in Figure 1517 6 of [OSPFV2]. Router RT4 would originate into Area 1 the following 1518 inter-area-router-LSA for destination router RT7. 1520 ; inter-area-router-LSA for AS boundary router RT7 1521 ; originated by Router RT4 into Area 1 1523 LS age = 0 ;newly (re)originated 1524 LS type = 0x2004 ;inter-area-router-LSA 1525 Advertising Router = 192.0.2.4 ;RT4's ID 1526 Options = (V6-bit|E-bit|R-bit) ;RT7's capabilities 1527 Metric = 14 ;cost to RT7 1528 Destination Router ID = Router RT7's ID 1530 Inter-area-router-LSA for AS boundary router RT7 1531 originated by 1532 Router RT4 into Area 1 1534 4.4.3.6. AS-external-LSAs 1536 The LS type of an AS-external-LSA is set to the value 0x4005. AS- 1537 external-LSAs have AS flooding scope. Each AS-external-LSA describes 1538 a path to a prefix external to the Autonomous System. 1540 The procedure for originating AS-external-LSAs in IPv6 is the same as 1541 the IPv4 procedure documented in Section 12.4.4 of [OSPFV2], with the 1542 following exceptions: 1544 o The Link State ID of an AS-external-LSA has lost all of its 1545 addressing semantics and simply serves to distinguish multiple AS- 1546 external-LSAs that are originated by the same router. 1548 o The prefix is described by the PrefixLength, PrefixOptions, and 1549 Address Prefix fields embedded within the LSA body. Network Mask 1550 is no longer specified. 1552 o The NU-bit in the PrefixOptions field should be clear. 1554 o Link-local addresses can never be advertised in AS-external-LSAs. 1556 o The forwarding address is present in the AS-external-LSA if and 1557 only if the AS-external-LSA's bit F is set. 1559 o The external route tag is present in the AS-external-LSA if and 1560 only if the AS-external-LSA's bit T is set. 1562 o The capability for an AS-external-LSA to reference another LSA has 1563 been supported through the inclusion of the Referenced LS Type 1564 field and the optional Referenced Link State ID field (the latter 1565 present if and only if Referenced LS Type is non-zero). This 1566 capability is for future use; Referenced LS Type should be set to 1567 0 and received non-zero values for this field should be ignored 1568 until its use is defined. 1570 As an example, consider the OSPF Autonomous System depicted in Figure 1571 6 of [OSPFV2]. Assume that RT7 has learned its route to N12 via BGP, 1572 and that it wishes to advertise a Type 2 metric into the AS. Also 1573 assume that the IPv6 prefix for N12 is the value 2001:0db8:0a00::/40. 1574 RT7 would then originate the following AS-external-LSA for the 1575 external network N12. Note that within the AS-external-LSA, N12's 1576 prefix occupies 64 bits of space in order to maintain 32-bit 1577 alignment. 1579 ; AS-external-LSA for Network N12, 1580 ; originated by Router RT7 1582 LS age = 0 ;newly (re)originated 1583 LS type = 0x4005 ;AS-external-LSA 1584 Link State ID = 123 ;or something else 1585 Advertising Router = Router RT7's ID 1586 bit E = 1 ;Type 2 metric 1587 bit F = 0 ;no forwarding address 1588 bit T = 1 ;external route tag included 1589 Metric = 2 1590 PrefixLength = 40 1591 PrefixOptions = 0 1592 Referenced LS Type = 0 ;no Referenced Link State ID 1593 Address Prefix = 2001:0db8:0a00 ;padded to 64-bits 1594 External Route Tag = as per BGP/OSPF interaction 1596 AS-external-LSA for Network N12, originated by Router RT7 1598 4.4.3.7. NSSA-LSAs 1600 The LS type of an NSSA-LSA is set to the value 0x2007. NSSA-LSAs 1601 have area flooding scope. Each NSSA-LSA describes a path to a prefix 1602 external to the Autonomous System whose flooding scope is restricted 1603 to a single NSSA area. 1605 The procedure for originating NSSA-LSAs in IPv6 is the same as the 1606 IPv4 procedure documented in [NSSA], with the following exceptions: 1608 o The Link State ID of an NSSA-LSA has lost all of its addressing 1609 semantics and simply serves to distinguish multiple NSSA-LSAs that 1610 are originated by the same router in the same area. 1612 o The prefix is described by the PrefixLength, PrefixOptions, and 1613 Address Prefix fields embedded within the LSA body. Network Mask 1614 is no longer specified. 1616 o The NU-bit in the PrefixOptions field should be clear. 1618 o Link-local addresses can never be advertised in NSSA-LSAs. 1620 o The forwarding address is present in the NSSA-LSA if and only if 1621 the NSSA-LSA's bit F is set. 1623 o The external route tag is present in the NSSA-LSA if and only if 1624 the NSSA-LSA's bit T is set. 1626 o The capability for an NSSA-LSA to reference another LSA has been 1627 supported through the inclusion of the Referenced LS Type field 1628 and the optional Referenced Link State ID field (the latter 1629 present if and only if Referenced LS Type is non-zero). This 1630 capability is for future use; Referenced LS Type should be set to 1631 0 and received non-zero values for this field should be ignored 1632 until its use is defined. 1634 An example of an NSSA-LSA would only differ from an AS-external-LSA 1635 in that the LS type would be 0x2007 rather than 0x4005. 1637 4.4.3.8. Link-LSAs 1639 The LS type of a link-LSA is set to the value 0x0008. Link-LSAs have 1640 link-local flooding scope. A router originates a separate link-LSA 1641 for each attached link that supports 2 or more (including the 1642 originating router itself) routers. Link-LSAs SHOULD NOT be 1643 originated for virtual links. 1645 Link-LSAs have three purposes: 1647 1. They provide the router's link-local address to all other routers 1648 attached to the link. 1650 2. They inform other routers attached to the link of a list of IPv6 1651 prefixes to associate with the link. 1653 3. They allow the router to advertise a collection of Options bits 1654 in the network-LSA originated by the Designated Router on a 1655 broadcast or NBMA link. 1657 A link-LSA for a given Link L is built in the following fashion: 1659 o The Link State ID is set to the router's Interface ID on Link L. 1661 o The Router Priority of the router's interface to Link L is 1662 inserted into the link-LSA. 1664 o The link-LSA's Options field is set to those bits that the router 1665 wishes set in Link L's Network LSA. 1667 o The router inserts its link-local address on Link L into the link- 1668 LSA. This information will be used when the other routers on Link 1669 L do their next hop calculations (see Section 4.8.2). 1671 o Each IPv6 address prefix that has been configured on Link L is 1672 added to the link-LSA by specifying values for PrefixLength, 1673 PrefixOptions, and Address Prefix fields. 1675 After building a link-LSA for a given link, the router installs the 1676 link-LSA into the associated interface data structure and floods the 1677 link-LSA on the link. All other routers on the link will receive the 1678 link-LSA but they will not flood the link-LSA on other links. 1680 If LinkLSASuppression is configured for the interface and the 1681 interface type is not broadcast or NBMA, origination of the Link-LSA 1682 may be suppressed. This implies that other routers on the link will 1683 ascertain the router's next-hop address using a mechanism other than 1684 the Link-LSA (see Section 4.8.2). Refer to Appendix C.3 for a 1685 description of the LinkLSASuppression interface configuration 1686 parameter. 1688 As an example, consider the link-LSA that RT3 will build for N3 in 1689 Figure 1. Suppose that the prefix 2001:0db8:c001:0100::/56 has been 1690 configured within RT3 for N3. This will result in the following 1691 link-LSA that RT3 will flood only on N3. Note that not all routers 1692 on N3 need be configured with the prefix; those not configured will 1693 learn the prefix when receiving RT3's link-LSA. 1695 ; RT3's link-LSA for N3 1697 LS age = 0 ;newly (re)originated 1698 LS type = 0x0008 ;Link-LSA 1699 Link State ID = 1 ;RT3's Interface ID on N3 1700 Advertising Router = 192.0.2.3 ;RT3's Router ID 1701 Rtr Priority = 1 ;RT3's N3 Router Priority 1702 Options = (V6-bit|E-bit|R-bit) 1703 Link-local Interface Address = fe80:0001::RT3 1704 # prefixes = 1 1705 PrefixLength = 56 1706 PrefixOptions = 0 1707 Address Prefix = 2001:0db8:c001:0100 ;pad to 64-bits 1709 RT3's link-LSA for N3 1711 4.4.3.9. Intra-Area-Prefix-LSAs 1713 The LS type of an intra-area-prefix-LSA is set to the value 0x2009. 1714 Intra-area-prefix-LSAs have area flooding scope. An intra-area- 1715 prefix-LSA has one of two functions. It either associates a list of 1716 IPv6 address prefixes with a transit network link by referencing a 1717 network-LSA, or associates a list of IPv6 address prefixes with a 1718 router by referencing a router-LSA. A stub link's prefixes are 1719 associated with its attached router. 1721 A router MAY originate multiple intra-area-prefix-LSAs for a given 1722 area. Each intra-area-prefix-LSA has a unique Link-State ID and 1723 contains an integral number of prefix descriptions. 1725 A link's Designated Router originates one or more intra-area-prefix- 1726 LSAs to advertise the link's prefixes throughout the area. For a 1727 link L, L's Designated Router builds an intra-area-prefix-LSA in the 1728 following fashion: 1730 o In order to indicate that the prefixes are to be associated with 1731 the Link L, the fields Referenced LS Type, Referenced Link State 1732 ID, and Referenced Advertising Router are set to the corresponding 1733 fields in Link L's network-LSA (namely LS type, Link State ID, and 1734 Advertising Router respectively). This means that Referenced LS 1735 Type is set to 0x2002, Referenced Link State ID is set to the 1736 Designated Router's Interface ID on Link L, and Referenced 1737 Advertising Router is set to the Designated Router's Router ID. 1739 o Each link-LSA associated with Link L is examined (these are in the 1740 Designated Router's interface structure for Link L). If the link- 1741 LSA's Advertising Router is fully adjacent to the Designated 1742 Router and the Link State ID matches the neighbor's interface ID, 1743 the list of prefixes in the link-LSA is copied into the intra- 1744 area-prefix-LSA that is being built. Prefixes having the NU-bit 1745 and/or LA-bit set in their Options field SHOULD NOT be copied, nor 1746 should link-local addresses be copied. Each prefix is described 1747 by the PrefixLength, PrefixOptions, and Address Prefix fields. 1748 Multiple prefixes having the same PrefixLength and Address Prefix 1749 are considered to be duplicates. In this case their Prefix 1750 Options fields should be logically OR'ed together and a single 1751 instance of the duplicate prefix should be included in the intra- 1752 area-prefix-LSA. The Metric field for all prefixes is set to 0. 1754 o The "# prefixes" field is set to the number of prefixes that the 1755 router has copied into the LSA. If necessary, the list of 1756 prefixes can be spread across multiple intra-area-prefix-LSAs in 1757 order to keep the LSA size small. 1759 A router builds an intra-area-prefix-LSA to advertise prefixes for 1760 its attached stub links, looped back interfaces, and hosts. A Router 1761 RTX would build its intra-area-prefix-LSA in the following fashion: 1763 o In order to indicate that the prefixes are to be associated with 1764 the Router RTX itself, RTX sets Referenced LS Type to 0x2001, 1765 Referenced Link State ID to 0, and Referenced Advertising Router 1766 to RTX's own Router ID. 1768 o Router RTX examines its list of interfaces to the area. If the 1769 interface is in state Down, its prefixes are not included. If the 1770 interface has been reported in RTX's router-LSA as a Type 2 link 1771 description (link to transit network), prefixes which will be 1772 included in the intra-area-prefix-LSA for the link are skipped. 1773 However, any prefixes which would normally have the LA-bit set 1774 SHOULD be advertised independent of whether or not the interface 1775 is advertised as a transit link. If the interface type is Point- 1776 to-Multipoint or the interface is in state Loopback, the global 1777 scope IPv6 addresses associated with the interface (if any) are 1778 copied into the intra-area-prefix-LSA with the PrefixOptions LA- 1779 bit set, the PrefixLength set to 128, and the metric set to 0. 1780 Otherwise, the list of global prefixes configured in RTX for the 1781 link are copied into the intra-area-prefix-LSA by specifying the 1782 PrefixLength, PrefixOptions, and Address Prefix fields. The 1783 Metric field for each of these prefixes is set to the interface's 1784 output cost. 1786 o RTX adds the IPv6 prefixes for any directly attached hosts 1787 belonging to the area (see Appendix C.7) to the intra-area-prefix- 1788 LSA. 1790 o If RTX has one or more virtual links configured through the area, 1791 it includes one of its global scope IPv6 interface addresses in 1792 the LSA (if it hasn't already), setting the LA-bit in the 1793 PrefixOptions field, the PrefixLength to 128, and the Metric to 0. 1794 This information will be used later in the routing calculation so 1795 that the two ends of the virtual link can discover each other's 1796 IPv6 addresses. 1798 o The "# prefixes" field is set to the number of prefixes that the 1799 router has copied into the LSA. If necessary, the list of 1800 prefixes can be spread across multiple intra-area-prefix-LSAs in 1801 order to keep the LSA size small. 1803 For example, the intra-area-prefix-LSA originated by RT4 for Network 1804 N3 (assuming that RT4 is N3's Designated Router), and the intra-area- 1805 prefix-LSA originated into Area 1 by Router RT3 for its own prefixes, 1806 are pictured below. 1808 ; RT4's Intra-area-prefix-LSA for network link N3 1810 LS age = 0 ;newly (re)originated 1811 LS type = 0x2009 ;Intra-area-prefix-LSA 1812 Link State ID = 5 ;or something 1813 Advertising Router = 192.0.2.4 ;RT4's Router ID 1814 # prefixes = 1 1815 Referenced LS Type = 0x2002 ;network-LSA reference 1816 Referenced Link State ID = 1 1817 Referenced Advertising Router = 192.0.2.4 1818 PrefixLength = 56 ;N3's prefix 1819 PrefixOptions = 0 1820 Metric = 0 1821 Address Prefix = 2001:0db8:c001:0100 ;pad 1823 ; RT3's Intra-area-prefix-LSA for its own prefixes 1825 LS age = 0 ;newly (re)originated 1826 LS type = 0x2009 ;Intra-area-prefix-LSA 1827 Link State ID = 177 ;or something 1828 Advertising Router = 192.0.2.3 ;RT3's Router ID 1829 # prefixes = 1 1830 Referenced LS Type = 0x2001 ;router-LSA reference 1831 Referenced Link State ID = 0 1832 Referenced Advertising Router = 192.0.2.3 1833 PrefixLength = 56 ;N4's prefix 1834 PrefixOptions = 0 1835 Metric = 2 ;N4 interface cost 1836 Address Prefix = 2001:0db8:c001:0400 ;pad 1837 Intra-area-prefix-LSA for network link N3 1839 When network conditions change, it may be necessary for a router to 1840 move prefixes from one intra-area-prefix-LSA to another. For 1841 example, if the router is Designated Router for a link but the link 1842 has no other attached routers, the link's prefixes are advertised in 1843 an intra-area-prefix-LSA referring to the Designated Router's router- 1844 LSA. When additional routers appear on the link, a network-LSA is 1845 originated for the link and the link's prefixes are moved to an 1846 intra-area-prefix-LSA referring to the network-LSA. 1848 Note that in the intra-area-prefix-LSA, the "Referenced Advertising 1849 Router" is always equal to the router that is originating the intra- 1850 area-prefix-LSA (i.e., the LSA's Advertising Router). The reason 1851 that the Referenced Advertising Router field appears is that, even 1852 though it is currently redundant, it may not be in the future. We 1853 may sometime want to use the same LSA format to advertise address 1854 prefixes for other protocol suites. In this case, the Designated 1855 Router may not be running the other protocol suite, and so another of 1856 the link's routers may need to originate the intra-area-prefix-LSA. 1857 In that case, "Referenced Advertising Router" and "Advertising 1858 Router" would be different. 1860 4.4.4. Future LSA Validation 1862 It is expected that new LSAs will be defined that will not be 1863 processed during the Shortest Path First (SPF) calculation as 1864 described in Section 4.8. For example, OSPFv3 LSAs corresponding to 1865 information advertised in OSPFv2 using opaque LSAs [OPAQUE]. In 1866 general, the new information advertised in future LSAs should not be 1867 used unless the OSPFv3 router originating the LSA is reachable. 1868 However, depending on the application and the data advertised, this 1869 reachability validation MAY be done less frequently than every SPF 1870 calculation. 1872 To facilitate inter-area reachability validation, any OSPFv3 router 1873 originating AS scoped LSAs is considered an AS Boundary Router 1874 (ASBR). 1876 4.5. Flooding 1878 Most of the flooding algorithm remains unchanged from the IPv4 1879 flooding mechanisms described in Section 13 of [OSPFV2]. In 1880 particular, the protocol processes for determining which LSA instance 1881 is newer (Section 13.1 of [OSPFV2]), responding to updates of self- 1882 originated LSAs (Section 13.4 of [OSPFV2]), sending Link State 1883 Acknowledgment packets (Section 13.5 of [OSPFV2]), retransmitting 1884 LSAs (Section 13.6 of [OSPFV2]), and receiving Link State 1885 Acknowledgment packets (Section 13.7 of [OSPFV2]) are exactly the 1886 same for IPv6 and IPv4. 1888 However, the addition of flooding scope and unknown LSA type handling 1889 (see Appendix A.4.2.1) has caused some changes in the OSPF flooding 1890 algorithm: the reception of Link State Updates (Section 13 in 1891 [OSPFV2]) and the sending of Link State Updates (Section 13.3 of 1892 [OSPFV2]) must take into account the LSA's scope and U-bit setting. 1893 Also, installation of LSAs into the OSPF database (Section 13.2 of 1894 [OSPFV2]) causes different events in IPv6, due to the reorganization 1895 of LSA types and the IPv6 LSA contents. These changes are described 1896 in detail below. 1898 4.5.1. Receiving Link State Update packets 1900 The encoding of flooding scope in the LS type and the need to process 1901 unknown LS types causes modifications to the processing of received 1902 Link State Update packets. As in IPv4, each LSA in a received Link 1903 State Update packet is examined. In IPv4, eight steps are executed 1904 for each LSA, as described in Section 13 of [OSPFV2]. For IPv6, all 1905 the steps are the same, except that Steps 2 and 3 are modified as 1906 follows: 1908 (2) Examine the LSA's LS type. Discard the LSA and get 1909 the next one from the Link State Update packet if the 1910 interface area has been configured as a stub or 1911 NSSA area and the LS type indicates "AS flooding scope". 1913 This generalizes the IPv4 behavior where AS-external-LSAs 1914 and AS-scoped opaque LSAs [OPAQUE] are not flooded 1915 throughout stub or NSSA areas. 1917 (3) Else if the flooding scope in the LSA's LS type is set to 1918 "reserved", discard the LSA and get the next one from 1919 the Link State Update packet. 1921 Steps 5b (sending Link State Update packets) and 5d (installing LSAs 1922 in the link-state database) in Section 13 of [OSPFV2] are also 1923 somewhat different for IPv6, as described in Sections 3.5.2 and 3.5.3 1924 below. 1926 4.5.2. Sending Link State Update packets 1928 The sending of Link State Update packets is described in Section 13.3 1929 of [OSPFV2]. For IPv4 and IPv6, the steps for sending a Link State 1930 Update packet are the same (steps 1 through 5 of Section 13.3 in 1931 [OSPFV2]). However, the list of eligible interfaces on which to 1932 flood the LSA is different. For IPv6, the eligible interfaces are 1933 selected based on the following factors: 1935 o The LSA's flooding scope. 1937 o For LSAs with area or link-local flooding scoping, the particular 1938 area or interface that the LSA is associated with. 1940 o Whether the LSA has a recognized LS type. 1942 o The setting of the U-bit in the LS type. If the U-bit is set to 1943 0, unrecognized LS types are treated as having link-local scope. 1944 If set to 1, unrecognized LS types are stored and flooded as if 1945 they were recognized. 1947 Choosing the set of eligible interfaces then breaks into the 1948 following cases: 1950 Case 1 1951 The LSA's LS type is recognized. In this case, the set of 1952 eligible interfaces is set depending on the flooding scope encoded 1953 in the LS type. If the flooding scope is "AS flooding scope", the 1954 eligible interfaces are all router interfaces excepting virtual 1955 links. In addition, AS-external-LSAs are not flooded on 1956 interfaces connecting to stub or NSSA areas. If the flooding 1957 scope is "area flooding scope", the set of eligible interfaces are 1958 those interfaces connecting to the LSA's associated area. If the 1959 flooding scope is "link-local flooding scope", then there is a 1960 single eligible interface, the one connecting to the LSA's 1961 associated link (which is also the interface on which the LSA was 1962 received in a Link State Update packet). 1964 Case 2 1965 The LS type is unrecognized and the U-bit in the LS Type is set to 1966 0 (treat the LSA as if it had link-local flooding scope). In this 1967 case there is a single eligible interface, namely, the interface 1968 on which the LSA was received. 1970 Case 3 1971 The LS type is unrecognized, and the U-bit in the LS Type is set 1972 to 1 (store and flood the LSA as if the type understood). In this 1973 case, select the eligible interfaces based on the encoded flooding 1974 scope the same as in Case 1 above. 1976 A further decision must sometimes be made before adding an LSA to a 1977 given neighbor's link-state retransmission list (Step 1d in Section 1978 13.3 of [OSPFV2]). If the LS type is recognized by the router, but 1979 not by the neighbor (as can be determined by examining the Options 1980 field that the neighbor advertised in its Database Description 1981 packet) and the LSA's U-bit is set to 0, then the LSA should be added 1982 to the neighbor's link-state retransmission list if and only if that 1983 neighbor is the Designated Router or Backup Designated Router for the 1984 attached link. The LS types described in detail by this document, 1985 namely router-LSAs (LS type 0x2001), network-LSAs (0x2002), inter- 1986 area-prefix-LSAs (0x2003), inter-area-router-LSAs (0x2004), NSSA-LSAs 1987 (0x2007), AS-external-LSAs (0x4005), link-LSAs (0x0008), and Intra- 1988 Area-Prefix-LSAs (0x2009) are assumed to be understood by all 1989 routers. However, all LS types MAY not be understood by all routers. 1990 For example, a new LSA type with its U-bit set to 0 MAY only be 1991 understood by a subset of routers. This new LS Type should only be 1992 flooded to an OSPF neighbor that understands the LS type or when the 1993 neighbor is Designated Router or Backup Designated Router for the 1994 attached link. 1996 The previous paragraph solves a problem for IPv4 OSPF extensions, 1997 which require that the Designated Router support the extension in 1998 order to have the new LSA types flooded across broadcast and NBMA 1999 networks. 2001 4.5.3. Installing LSAs in the database 2003 There are three separate places to store LSAs, depending on their 2004 flooding scope. LSAs with AS flooding scope are stored in the global 2005 OSPF data structure (see Section 4.1) as long as their LS type is 2006 known or their U-bit is 1. LSAs with area flooding scope are stored 2007 in the appropriate area data structure (see Section 4.1.1) as long as 2008 their LS type is known or their U-bit is 1. LSAs with link-local 2009 flooding scope, and those LSAs with unknown LS type and U-bit set to 2010 0 (treat the LSA as if it had link-local flooding scope) are stored 2011 in the appropriate interface data structure. 2013 When storing the LSA into the link-state database, a check must be 2014 made to see whether the LSA's contents have changed. Changes in 2015 contents are indicated exactly as in Section 13.2 of [OSPFV2]. When 2016 an LSA's contents have been changed, the following parts of the 2017 routing table must be recalculated, based on the LSA's LS type: 2019 Router-LSAs, Network-LSAs, Intra-Area-Prefix-LSAs, and Link-LSAs 2020 The entire routing table is recalculated, starting with the 2021 shortest path calculation for each area (see Section 4.8). 2023 Inter-Area-Prefix-LSAs and Inter-Area-Router-LSAs 2024 The best route to the destination described by the LSA must be 2025 recalculated (see Section 16.5 in [OSPFV2]). If this destination 2026 is an AS boundary router, it may also be necessary to re-examine 2027 all the AS-external-LSAs. 2029 AS-external-LSAs and NSSA-LSAs 2030 The best route to the destination described by the AS-external-LSA 2031 or NSSA-LSA must be recalculated (see Section 16.6 in [OSPFV2] and 2032 Section 2.0 in [NSSA]). 2034 As in IPv4, any old instance of the LSA must be removed from the 2035 database when the new LSA is installed. This old instance must also 2036 be removed from all neighbors' link state retransmission lists. 2038 4.6. Definition of self-originated LSAs 2040 In IPv6 the definition of a self-originated LSA has been simplified 2041 from the IPv4 definition appearing in Sections 13.4 and 14.1 of 2042 [OSPFV2]. For IPv6, self-originated LSAs are those LSAs whose 2043 Advertising Router is equal to the router's own Router ID. 2045 4.7. Virtual links 2047 OSPF virtual links for IPv4 are described in Section 15 of [OSPFV2]. 2048 Virtual links are the same in IPv6, with the following exceptions: 2050 o LSAs having AS flooding scope are never flooded over virtual 2051 adjacencies, nor are LSAs with AS flooding scope summarized over 2052 virtual adjacencies during the database exchange process. This is 2053 a generalization of the IPv4 treatment of AS-external-LSAs. 2055 o The IPv6 interface address of a virtual link MUST be an IPv6 2056 address having global scope, instead of the link-local addresses 2057 used by other interface types. This address is used as the IPv6 2058 source for OSPF protocol packets sent over the virtual link. 2059 Hence, a Link-LSA SHOULD NOT be originated for a virtual link 2060 since the virtual link has no link-local address or associated 2061 prefixes. 2063 o Likewise, the virtual neighbor's IPv6 address is an IPv6 address 2064 with global scope. To enable the discovery of a virtual 2065 neighbor's IPv6 address during the routing calculation, the 2066 neighbor advertises its virtual link's IPv6 interface address in 2067 an intra-area-prefix-LSA originated for the virtual link's transit 2068 area (see Section 4.4.3.9 and Section 4.8.1). 2070 o Like all other IPv6 OSPF interfaces, virtual links are assigned 2071 unique (within the router) Interface IDs. These are advertised in 2072 Hellos sent over the virtual link and in the router's router-LSAs. 2074 4.8. Routing table calculation 2076 The IPv6 OSPF routing calculation proceeds along the same lines as 2077 the IPv4 OSPF routing calculation, following the five steps specified 2078 by Section 16 of [OSPFV2]. High level differences between the IPv6 2079 and IPv4 calculations include: 2081 o Prefix information has been removed from router-LSAs and network- 2082 LSAs and is now advertised in intra-area-prefix-LSAs. Whenever 2083 [OSPFV2] specifies that stub networks within router-LSAs be 2084 examined, IPv6 will instead examine prefixes within intra-area- 2085 prefix-LSAs. 2087 o Type 3 and 4 summary-LSAs have been renamed inter-area-prefix-LSAs 2088 and inter-area-router-LSAs respectively. 2090 o Addressing information is no longer encoded in Link State IDs and 2091 is now only found within the body of LSAs. 2093 o In IPv6, a router can originate multiple router-LSAs, 2094 distinguished by Link State ID, within a single area. These 2095 router-LSAs MUST be treated as a single aggregate by the area's 2096 shortest path calculation (see Section 4.8.1). 2098 For each area, the shortest-path tree calculation creates routing 2099 table entries for the area's routers and transit links (see 2100 Section 4.8.1). These entries are then used when processing intra- 2101 area-prefix-LSAs, inter-area-prefix-LSAs, and inter-area-router-LSAs, 2102 as described in Section 4.8.3. 2104 Events generated as a result of routing table changes (Section 16.7 2105 of [OSPFV2]) and the equal-cost multipath logic (Section 16.8 of 2106 [OSPFV2]) are identical for both IPv4 and IPv6. 2108 4.8.1. Calculating the shortest path tree for an area 2110 The IPv4 shortest path calculation is contained in Section 16.1 of 2111 [OSPFV2]. The graph used by the shortest-path tree calculation is 2112 identical for both IPv4 and IPv6. The graph's vertices are routers 2113 and transit links, represented by router-LSAs and network-LSAs 2114 respectively. A router is identified by its OSPF Router ID, while a 2115 transit link is identified by its Designated Router's Interface ID 2116 and OSPF Router ID. Both routers and transit links have associated 2117 routing table entries within the area (see Section 4.3). 2119 Section 16.1 of [OSPFV2] splits up the shortest path calculations 2120 into two stages. First the Dijkstra calculation is performed and 2121 then the stub links are added onto the tree as leaves. The IPv6 2122 calculation maintains this split. 2124 The Dijkstra calculation for IPv6 is identical to that specified for 2125 IPv4, with the following exceptions (referencing the steps from the 2126 Dijkstra calculation as described in Section 16.1 of [OSPFV2]): 2128 o The Vertex ID for a router is the OSPF Router ID. The Vertex ID 2129 for a transit network is a combination of the Interface ID and 2130 OSPF Router ID of the network's Designated Router. 2132 o In Step 2, when a router Vertex V has just been added to the 2133 shortest path tree, there may be multiple LSAs associated with the 2134 router. All router-LSAs with Advertising Router set to V's OSPF 2135 Router ID MUST be processed as an aggregate, treating them as 2136 fragments of a single large router-LSA. The Options field and the 2137 router type bits (bits Nt, V, E, and B) should always be taken 2138 from router-LSA with the smallest Link State ID. 2140 o Step 2a is not needed in IPv6, as there are no longer stub network 2141 links in router-LSAs. 2143 o In Step 2b, if W is a router and the router LSA V6-bit or R-bit 2144 are not set in the LSA options, the transit link W is ignored and 2145 V's next link is examined. 2147 o In Step 2b, if W is a router, there may again be multiple LSAs 2148 associated with the router. All router-LSAs with Advertising 2149 Router set to W's OSPF Router ID MUST be processed as an 2150 aggregate, treating them as fragments of a single large router- 2151 LSA. 2153 o In Step 4, there are now per-area routing table entries for each 2154 of an area's routers rather than just the area border routers. 2155 These entries subsume all the functionality of IPv4's area border 2156 router routing table entries, including the maintenance of virtual 2157 links. When the router added to the area routing table in this 2158 step is the other end of a virtual link, the virtual neighbor's IP 2159 address is set as follows: The collection of intra-area-prefix- 2160 LSAs originated by the virtual neighbor is examined, with the 2161 virtual neighbor's IP address being set to the first prefix 2162 encountered with the "LA-bit" set. 2164 o Routing table entries for transit networks, which are no longer 2165 associated with IP networks, are also calculated in Step 4 and 2166 added to the per-area routing table. 2168 The next stage of the shortest path calculation proceeds similarly to 2169 the two steps of the second stage of Section 16.1 in [OSPFV2]. 2170 However, instead of examining the stub links within router-LSAs, the 2171 list of the area's intra-area-prefix-LSAs is examined. A prefix 2172 advertisement whose "NU-bit" is set SHOULD NOT be included in the 2173 routing calculation. The cost of any advertised prefix is the sum of 2174 the prefix's advertised metric plus the cost to the transit vertex 2175 (either router or transit network) identified by intra-area-prefix- 2176 LSA's Referenced LS Type, Referenced Link State ID, and Referenced 2177 Advertising Router fields. This latter cost is stored in the transit 2178 vertex's routing table entry for the area. 2180 This specification does not require that the above algorithm be used 2181 to calculate the intra-area shortest path tree. However, if another 2182 algorithm or optimization is used, an identical shortest path tree 2183 must be produced. It is also important that any alternate algorithm 2184 or optimization maintain the requirement that transit vertices must 2185 be bidirectional for inclusion in the tree. Alternate algorithms and 2186 optimizations are beyond the scope of this specification. 2188 4.8.2. The next hop calculation 2190 In IPv6, the calculation of the next hop's IPv6 address (which will 2191 be a link-local address) proceeds along the same lines as the IPv4 2192 next hop calculation (see Section 16.1.1 of [OSPFV2]). However, 2193 there are some differences. When calculating the next hop IPv6 2194 address for a router (call it Router X) which shares a link with the 2195 calculating router, the calculating router assigns the next hop IPv6 2196 address to be the link-local interface address contained in Router 2197 X's Link- LSA (see Appendix A.4.9) for the link. This procedure is 2198 necessary for some link types, for example NBMA, where the two 2199 routers need not be neighbors and might not be exchanging OSPF Hello 2200 packets. For other link types, the next hop address may be 2201 determined via the IPv6 source address in the neighbor's Hello 2202 packet. 2204 Additionally, when calculating routes for the area's intra-area- 2205 prefix-LSAs, the parent vertex can be either a router-LSA or network- 2206 LSA. This is in contrast to the second stage of the OSPFv2 intra- 2207 area SPF (Section 16.1 in [OSPFV2]) where the parent vertex is always 2208 a router-LSA. In the case where the intra-area-prefix-LSA's 2209 referenced LSA is a directly connected network-LSA, the prefixes are 2210 also considered to be directly connected. In this case, the next-hop 2211 is solely the outgoing link and no IPv6 next hop address is selected. 2213 4.8.3. Calculating the inter-area routes 2215 Calculation of inter-area routes for IPv6 proceeds along the same 2216 lines as the IPv4 calculation in Section 16.2 of [OSPFV2], with the 2217 following modifications: 2219 o The names of the Type 3 summary-LSAs and Type 4 summary-LSAs have 2220 been changed to inter-area-prefix-LSAs and inter-area-router-LSAs 2221 respectively. 2223 o The Link State ID of the above LSA types no longer encodes the 2224 network or router described by the LSA. Instead, an address 2225 prefix is contained in the body of an inter-area-prefix-LSA and an 2226 advertised AS boundary router's OSPF Router ID is carried in the 2227 body of an inter-area-router-LSA. 2229 o Prefixes having the "NU-bit" set in their Prefix Options field 2230 should be ignored by the inter-area route calculation. 2232 When a single inter-area-prefix-LSA or inter-area-router-LSA has 2233 changed, the incremental calculations outlined in Section 16.5 of 2234 [OSPFV2] can be performed instead of recalculating the entire routing 2235 table. 2237 4.8.4. Examining transit areas' summary-LSAs 2239 Examination of transit areas' summary-LSAs in IPv6 proceeds along the 2240 same lines as the IPv4 calculation in Section 16.3 of [OSPFV2], 2241 modified in the same way as the IPv6 inter-area route calculation in 2242 Section 4.8.3. 2244 4.8.5. Calculating AS external and NSSA routes 2246 The IPv6 AS external route calculation proceeds along the same lines 2247 as the IPv4 calculation in Section 16.4 of [OSPFV2] and Section 2.5 2248 of [NSSA], with the following exceptions: 2250 o The Link State ID of the AS-external-LSA and NSSA-LSA types no 2251 longer encodes the network described by the LSA. Instead, an 2252 address prefix is contained in the body of the LSA. 2254 o The default route in AS-external-LSAs or NSSA-LSAs is advertised 2255 by a zero length prefix. 2257 o Instead of comparing the AS-external-LSA's or NSSA-LSA's 2258 Forwarding Address field to 0.0.0.0 to see whether a forwarding 2259 address has been used, the bit F in the respective LSA is 2260 examined. A forwarding address is in use if and only if bit F is 2261 set. 2263 o Prefixes having the "NU-bit" set in their Prefix Options field 2264 should be ignored by the inter-area route calculation. 2266 o AS Boundary Router (ASBR) and forwarding address selection will 2267 proceed the same as if RFC1583Compatibility is disabled. 2268 Furthermore, RFC1583Compatibility is not an OSPF for IPv6 2269 configuration parameter. Refer to Appendix C.1. 2271 When a single AS-external-LSA or NSSA-LSA has changed, the 2272 incremental calculations outlined in Section 16.6 of [OSPFV2] can be 2273 performed instead of recalculating the entire routing table. 2275 4.9. Multiple interfaces to a single link 2277 In OSPF for IPv6, a router may have multiple interfaces to a single 2278 link associated with the same OSPF instance and area. All interfaces 2279 will be used for the reception and transmission of data traffic while 2280 only a single interface sends and receives OSPF control traffic. In 2281 more detail: 2283 o Each of the multiple interfaces are assigned different Interface 2284 IDs. A router will automatically detect that multiple interfaces 2285 are attached to the same link when a Hello packet is received with 2286 one of the router's link-local addresses as the source address and 2287 an Interface ID other than the Interface ID of the receiving 2288 interface. 2290 o Each of the multiple interfaces MUST be configured with the same 2291 Interface Instance ID to be considered on the same link. If an 2292 interface has multiple Instance IDs, it will be grouped with other 2293 interfaces based on matching Instance IDs. Each Instance ID will 2294 be treated uniquely with respect to groupings of multiple 2295 interfaces on the same link. For example, if interface A is 2296 configured with Instance IDs 1 and 35, and interface B is 2297 configured with Instance ID 35, interface B may be the Active 2298 interface for Instance ID 35 but interface A will be active for 2299 Instance ID 1. 2301 o The router will ignore OSPF packets other than Hello packets on 2302 all but one of the interfaces attached to the link. It will only 2303 send its OSPF control packets (including Hello packets) on a 2304 single interface. This interface is designated the Active 2305 Interface and other interfaces attached to the same link will be 2306 designated Standby Interfaces. The choice of the Active interface 2307 is implementation dependent. For example, the interface with the 2308 highest Interface ID could be chosen. If the router is elected 2309 Designated Router, it will be the Active interface's Interface ID 2310 that will be used as the network-LSA's Link State ID. 2312 o All of the interfaces to the link (Active and Standby) will appear 2313 in the router-LSA. In addition, a link-LSA will be generated for 2314 each of the interfaces. In this way, all interfaces will be 2315 included in OSPF's routing calculations. 2317 o Any link-local scope LSAs which are originated for a Standby 2318 Interface will be flooded over the Active Interface. 2319 If a Standby Interface goes down then the link-local scope LSAs 2320 originated for the Standby Interfaces MUST be flushed on the 2321 Active Interface. 2323 o Prefixes on Standby Interfaces will be processed the same way as 2324 prefixes on the Active Interface. For example, if the router is 2325 the DR for the link, the Active Interface's prefixes are included 2326 in an intra-area-prefix-LSA which is associated with the Active 2327 Interface's network-LSA, prefixes from Standby Interfaces on the 2328 link will also be included in that intra-area-prefix LSA. 2329 Similarly, if the link is a stub link, then the prefixes for the 2330 Active and Standby Interfaces will all be included in the same 2331 intra-area-prefix-LSA that is associated with the router-LSA. 2333 o If the Active Interface fails, a new Active Interface will have to 2334 take over. The new Active Interface SHOULD form all new neighbor 2335 adjacencies with routers on the link. This failure can be 2336 detected when the router's other interfaces to the Active 2337 Interface's link cease to hear the router's Hellos or through 2338 internal mechanisms, e.g., monitoring the Active Interface's 2339 status. 2341 o If the network becomes partitioned with different local interfaces 2342 attaching to different network partitions, multiple interfaces 2343 will become Active Interfaces and function independently. 2345 o During the SPF calculation when a network-LSA for a network which 2346 is directly connected to the root vertex is being examined, all of 2347 the multiple interfaces to the link of adjacent router-LSAs must 2348 be used in the next-hop calculation. 2349 This can be accomplished during the back link check (see section 2350 16.1 Step 2 (B) in [OSPFV2]) by examining each link of the router- 2351 LSA and making a list of the links that point to the network LSA. 2352 The Interface IDs for links in this list are then used to find the 2353 corresponding link-LSAs and the link local addresses used as next 2354 hops when installing equal-cost paths in the routing table. 2356 o The interface state machine is modified to add the state Standby. 2357 See Section 4.9.1 for a description of the Standby state. 2359 4.9.1. Standby Interface State 2361 In this state, the interface is one of multiple interfaces to a link 2362 and this interface is designated Standby and is not sending or 2363 receiving control packets. The interface will continue to receive 2364 the Hello packets sent by the Active Interface. The interface will 2365 maintain a timer, the Active Interface Timer, with the same interval 2366 as the RouterDeadInterval. This timer will be reset whenever an OSPF 2367 Hello packet is received from the Active Interface to the link. 2369 Two new events are added to the list of events which cause interface 2370 state changes: MultipleInterfacesToLink and ActiveInterfaceDead. The 2371 descriptions of these events are as follows: 2373 MultipleInterfacesToLink 2374 An interfaces on the router has received a Hello packet from 2375 another interface on the same router. One of the interfaces is 2376 designated as the Active Interface and the other interface is 2377 designated as a Standby Interface. The Standby Interface 2378 transitions to the Standby state. 2380 ActiveInterfaceDead 2381 There has been an indication that a Standby Interface is no longer 2382 on a link with an Active Interface. The firing of the Active 2383 Interface Timer is one indication of this event, as it indicates 2384 that the Standby Interface has not received an OSPF Hello packet 2385 from the Active Interface for the RouterDeadInterval. Other 2386 indications may come from internal notifications, such as the 2387 Active Interface being disabled through a configuration change. 2388 Any indication internal to the router, such that the router knows 2389 the Active Interface is no longer active on the link, can trigger 2390 the ActiveInterfaceDead event for a Standby Interface. 2392 Interface state machine additions include: 2394 State(s): Waiting, DR Other, Backup or DR 2396 Event: MultipleInterfacesToLink 2398 New state: Standby 2400 Action: All interface variables are reset and interface 2401 timers disabled. Also, all neighbor connections 2402 associated with the interface are destroyed. This 2403 is done by generating the event KillNbr on all 2404 associated neighbors. The Active Interface Timer is 2405 started and the interface will listen for OSPF Hello 2406 packets from the link's Active Interface. 2408 State(s): Standby 2410 Event: ActiveInterfaceDead 2412 New state: Down 2414 Action: The Active Interface Timer is first disabled. Then 2415 the InterfaceUp event is invoked. 2417 Standby Interface State Machine Additions 2419 5. Security Considerations 2421 When running over IPv6, OSPFv3 relies on the IP Authentication Header 2422 (see [IPAUTH]) and the IP Encapsulating Security Payload (see 2423 [IPESP]) to ensure integrity and authentication/confidentiality of 2424 protocol packets. This is described in [OSPFV3-AUTH]. 2426 Most OSPFv3 implementations will be running on systems that support 2427 multiple protocols with their own independent security assumptions 2428 and domains. When IPsec is used to protect OSPFv3 packets, it is 2429 important for the implementation to check the IPsec Security 2430 Association (SA) and local SA database to assure the OSPF packet 2431 originated from a source that is trusted for OSPFv3. This required 2432 to eliminate the possibility that the packet was authenticated using 2433 an SA defined for another protocol running on the same system. 2435 The mechanisms in [OSPFV3-AUTH] do not provide protection against 2436 compromised, malfunctioning, or misconfigured routers. Such routers 2437 can, either accidentally or deliberately, cause malfunctions 2438 affecting the whole routing domain. The reader is encouraged to 2439 consult [GENERIC-THREATS] for a more comprehensive description of 2440 threats to routing protocols. 2442 6. Manageability Considerations 2444 The Management Information Base (MIB) for OSPFv3 is defined in 2445 [OSPFV3-MIB]. 2447 7. IANA Considerations 2449 Most OSPF for IPv6 IANA considerations are documented in [OSPF-IANA]. 2450 IANA is requested to change the reference for RFC2740 to this 2451 document. (to be removed before publication) 2453 Additionally, this document introduces the following IANA 2454 requirements that were not present in [OSPFV3]: 2456 o Reserve the options with the values 0x000040 and 0x000080 for 2457 migrated OSPFv2 options in the OSPFv3 Options registry defined in 2458 [OSPF-IANA]. For information on the OSPFv3 Options Field refer to 2459 Appendix A.2. 2461 o Add prefix option P-bit with value 0x08 to the OSPFv3 Prefix 2462 Options registry defined in [OSPF-IANA]. For information on 2463 OSPFv3 Prefix Options refer to Appendix A.4.1.1. 2465 o Add prefix option DN-bit with value 0x10 to the OSPFv3 Prefix 2466 Options registry defined in [OSPF-IANA]. For information on 2467 OSPFv3 Prefix Options refer to Appendix A.4.1.1. 2469 7.1. MOSPF for OSPFv3 Deprecation IANA Considerations 2471 With the deprecation of MOSPF for OSPFv3, the following code points 2472 are available for reassignment. Refer to [OSPF-IANA] for information 2473 on the respective registries. 2475 o Deprecate the MC-bit with value 0x000004 in the OSPFv3 Options 2476 Registry. 2478 o Deprecate Group-membership-LSA with value 6 in OSPFv3 LSA Function 2479 Code Registry. 2481 o Deprecate MC-bit with value 0x04 in the OSPFv3 Prefix Options 2482 Registry. 2484 The W-bit in the OSPFv3 router properties has also been deprecated. 2485 This requires a new registry for OSPFv3 router properties since it 2486 will diverge from the OSPFv2 router properties. 2488 Registry Name: OSPFv3 Router Properties Registry 2489 Reference: RFC-ietf-ospf-ospfv3-update (This Document) 2490 Registration Procedures: Standards Action 2492 Registry: 2493 Value Description Reference 2494 ------ ------------- --------- 2495 0x01 B-bit RFC-ietf-ospf-ospfv3-update (This Document) 2496 0x02 E-bit RFC-ietf-ospf-ospfv3-update (This Document) 2497 0x04 V-bit RFC-ietf-ospf-ospfv3-update (This Document) 2498 0x08 Deprecated RFC-ietf-ospf-ospfv3-update (This Document) 2499 0x10 Nt-bit RFC-ietf-ospf-ospfv3-update (This Document) 2501 OSPFv3 Router Properties Registry 2503 8. Acknowledgments 2505 The RFC text was produced using Marshall Rose's xml2rfc tool. 2507 The following individuals contributed comments which that 2508 incorporated into this document: 2510 o Harold Rabbie for his description of protocol details which needed 2511 to be clarified for OSPFv3 NSSA support. 2513 o Nic Neate for his pointing out that there needed to be changes for 2514 unknown LSA types handling in the processing of Database 2515 Description packets. 2517 o Jacek Kwiatkowski for being the first to point out that the V6 and 2518 R bits are not taken into account in the OSPFv3 intra-area SPF 2519 calculation. 2521 o Michael Barnes recognized that the support for multiple interfaces 2522 to a single link was broken (see Section 4.9) and provided the 2523 description of the current protocol mechanisms. Abhay Roy 2524 reviewed and suggested improvements to the mechanisms. 2526 o Alan Davey reviewed and commented on draft revisions. 2528 o Vivek Dubey reviewed and commented on draft revisions. 2530 o Manoj Goyal and Vivek Dubey complained enough about link-LSAs 2531 being unnecessary to compel introduction of the LinkLSASuppression 2532 interface configuration parameter. 2534 o Manoj Goyal for pointing out that the next-hop calculation for 2535 intra-area-prefix-LSAs corresponding to network vertices was 2536 unclear. 2538 o Ramana Koppula reviewed and commented on draft revisions. 2540 o Paul Wells reviewed and commented on draft revisions. 2542 o Amir Khan reviewed and commented on draft revisions. 2544 o Dow Street and Wayne Wheeler commented on the addition of the DN 2545 bit to OSPFv3. 2547 o Mitchell Erblichs provided numerous editorial comments. 2549 o Russ White provided numerous editorial comments. 2551 o Kashima Hiroaki provided editorial comments. 2553 o Sina Mirtorabi suggested that OSPFv3 should be aligned with OSPFv2 2554 with respect to precedence and should map it to IPv6 traffic class 2555 as specified in RFC 2474. Steve Blake helped with the text. 2557 o Faraz Shamin reviewed a late version of the draft and provided 2558 editorial comments. 2560 o Christian Vogt performed the General Area Review Team (Gen-ART) 2561 review and provided comments. 2563 o Dave Ward, Dan Romascanu, Tim Polk, Ron Bonica, Pasi Eronen, and 2564 Lars Eggert provided comments during the IESG review. Also, 2565 thanks to Pasi for the text in the Section 5 relating to routing 2566 threats. 2568 9. References 2570 9.1. Normative References 2572 [DEMAND] Moy, J., "Extending OSPF to Support Demand Circuits", 2573 RFC 1793, April 1995. 2575 [DIFF-SERV] 2576 Nichols, K., Blake, S., Baker, F., and D. Black, 2577 "Definition of the Differentiated Services Field (DS 2578 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2579 December 1998. 2581 [DN-BIT] Rosen, E., Peter, P., and P. Pillay-Esnault, "Using an LSA 2582 Options Bit to Prevent Looping in BGP/MPLS IP VPNs", 2583 RFC 4576, April 2005. 2585 [INTFMIB] McCloghrie, K. and F. Kastenholz, "The interfaces Group 2586 MIB", RFC 2863, June 2000. 2588 [IP6ADDR] Hinden, R. and S. Deering, "IP Version 6 Addressing 2589 Architecture", RFC 4291, February 2006. 2591 [IPAUTH] Kent, S., "IP Authentication Header", RFC 4302, 2592 December 2005. 2594 [IPESP] Kent, S., "IP Encapsulation Security Payload (ESP)", 2595 RFC 4303, December 2005. 2597 [IPV4] Postal, J., "Internet Protocol", RFC 791, September 1981. 2599 [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2600 (IPv6) Specification", RFC 2460, December 1998. 2602 [NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", 2603 RFC 3101, January 2003. 2605 [OSPF-IANA] 2606 Kompella, K. and B. Fenner, "IANA Considerations for 2607 OSPF", RFC 4940, July 2007. 2609 [OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 2611 [OSPFV3-AUTH] 2612 Gupta, M. and S. Melam, "Authentication/Confidentiality 2613 for OSPFv3", RFC 4552, June 2006. 2615 [RFC-KEYWORDS] 2616 Bradner, S., "Key words for use in RFCs to Indicate 2617 Requirement Levels", RFC 2119, March 1997. 2619 9.2. Informative References 2621 [GENERIC-THREATS] 2622 Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 2623 Routing Protocols", RFC 4593, October 2006. 2625 [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, 2626 March 1994. 2628 [MTUDISC] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, 2629 November 1990. 2631 [OPAQUE] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, 2632 July 1998. 2634 [OSPFV3] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 2635 RFC 2740, December 1999. 2637 [OSPFV3-MIB] 2638 Joyal, D. and V. Manral, "Management Information Base for 2639 OSPFv3", draft-ietf-ospf-ospfv3-mib-12.txt (work in 2640 progress). 2642 [SERV-CLASS] 2643 Baker, F., Chan, K., and J. Babiarz, "Configuration 2644 Guidelines for DiffServ Service Classes", RFC 4594, 2645 August 2006. 2647 Appendix A. OSPF data formats 2649 This appendix describes the format of OSPF protocol packets and OSPF 2650 LSAs. The OSPF protocol runs directly over the IPv6 network layer. 2651 Before any data formats are described, the details of the OSPF 2652 encapsulation are explained. 2654 Next the OSPF Options field is described. This field describes 2655 various capabilities that may or may not be supported by pieces of 2656 the OSPF routing domain. The OSPF Options field is contained in OSPF 2657 Hello packets, Database Description packets, and OSPF LSAs. 2659 OSPF packet formats are detailed in Section A.3. 2661 A description of OSPF LSAs appears in Section A.4. This section 2662 describes how IPv6 address prefixes are represented within LSAs, 2663 details the standard LSA header, and then provides formats for each 2664 of the specific LSA types. 2666 A.1. Encapsulation of OSPF packets 2668 OSPF runs directly over the IPv6's network layer. OSPF packets are 2669 therefore encapsulated solely by IPv6 and local data-link headers. 2671 OSPF does not define a way to fragment its protocol packets, and 2672 depends on IPv6 fragmentation when transmitting packets larger than 2673 the link MTU. If necessary, the length of OSPF packets can be up to 2674 65,535 bytes. The OSPF packet types that are likely to be large 2675 (Database Description, Link State Request, Link State Update, and 2676 Link State Acknowledgment packets) can usually be split into multiple 2677 protocol packets without loss of functionality. This is recommended; 2678 IPv6 fragmentation should be avoided whenever possible. Using this 2679 reasoning, an attempt should be made to limit the size of OSPF 2680 packets sent over virtual links to 1280 bytes unless Path MTU 2681 Discovery is being performed [MTUDISC]. 2683 The other important features of OSPF's IPv6 encapsulation are: 2685 o Use of IPv6 multicast. Some OSPF messages are multicast when sent 2686 over broadcast networks. Two distinct IP multicast addresses are 2687 used. Packets sent to these multicast addresses should never be 2688 forwarded; they are meant to travel a single hop only. As such, 2689 the multicast addresses have been chosen with link-local scope and 2690 packets sent to these addresses should have their IPv6 Hop Limit 2691 set to 1. 2693 AllSPFRouters 2694 This multicast address has been assigned the value FF02::5. 2695 All routers running OSPF should be prepared to receive packets 2696 sent to this address. Hello packets are always sent to this 2697 destination. Also, certain OSPF protocol packets are sent to 2698 this address during the flooding procedure. 2700 AllDRouters 2701 This multicast address has been assigned the value FF02::6. 2702 Both the Designated Router and Backup Designated Router must be 2703 prepared to receive packets destined to this address. Certain 2704 OSPF protocol packets are sent to this address during the 2705 flooding procedure. 2707 o OSPF is IP protocol 89. This number SHOULD be inserted in the 2708 Next Header field of the encapsulating IPv6 header. 2710 o The OSPFv2 specification (Appendix A.1 in [OSPFV2]) indicates that 2711 OSPF protocol packets are sent with IP precedence set to 2712 Internetwork Control (B'110') [IPV4]. If routers in the OSPF 2713 routing domain map their IPv6 Traffic Class octet to the 2714 Differentiated Services Code Point (DSCP) as specified in 2715 [DIFF-SERV], then OSPFv3 packets SHOULD be sent with their DSCP 2716 set to CS6 (B'110000'), as specified in [SERV-CLASS]. In networks 2717 supporting this mapping, OSPF packets will be given precedence 2718 over IPv6 data traffic. 2720 A.2. The Options field 2722 The 24-bit OSPF Options field is present in OSPF Hello packets, 2723 Database Description packets, and certain LSAs (router-LSAs, network- 2724 LSAs, inter-area-router-LSAs, and link-LSAs). The Options field 2725 enables OSPF routers to support (or not support) optional 2726 capabilities, and to communicate their capability level to other OSPF 2727 routers. Through this mechanism routers of differing capabilities 2728 can be mixed within an OSPF routing domain. 2730 An option mismatch between routers can cause a variety of behaviors, 2731 depending on the particular option. Some option mismatches prevent 2732 neighbor relationships from forming (e.g., the E-bit below); these 2733 mismatches are discovered through the sending and receiving of Hello 2734 packets. Some option mismatches prevent particular LSA types from 2735 being flooded across adjacencies these are discovered through the 2736 sending and receiving of Database Description packets. Some option 2737 mismatches prevent routers from being included in one or more of the 2738 various routing calculations because of their reduced functionality; 2739 these mismatches are discovered by examining LSAs. 2741 Seven bits of the OSPF Options field have been assigned. Each bit is 2742 described briefly below. Routers should reset (i.e., clear) 2743 unrecognized bits in the Options field when sending Hello packets or 2744 Database Description packets and when originating LSAs. Conversely, 2745 routers encountering unrecognized Option bits in received Hello 2746 packets, Database Description packets, or LSAs should ignore the 2747 unrecognized bits and process the packet or LSA normally. 2749 1 2 2750 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+--+ 2752 | | | | | | | | | | | | | | | | |*|*|DC|R|N|x| E|V6| 2753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+--+ 2755 The Options field 2757 The Options field 2759 V6-bit 2760 If this bit is clear, the router/link should be excluded from IPv6 2761 routing calculations. See Section 4.8 for details. 2763 E-bit 2764 This bit describes the way AS-external-LSAs are flooded, as 2765 described in Sections 3.6, 9.5, 10.8, and 12.1.2 of [OSPFV2]. 2767 x-Bit 2768 This bit was previously used by MOSPF (see [MOSPF]) that has been 2769 deprecated for OSPFv3. The bit should be set to 0 and ignored 2770 when received. It may be reassigned in the future. 2772 N-bit 2773 This bit indicates whether or not the router is attached to an 2774 NSSA as specified in [NSSA]. 2776 R-bit 2777 This bit (the `Router' bit) indicates whether the originator is an 2778 active router. If the router bit is clear, then routes which 2779 transit the advertising node cannot be computed. Clearing the 2780 router bit would be appropriate for a multi-homed host that wants 2781 to participate in routing, but does not want to forward non- 2782 locally addressed packets. 2784 DC-bit 2785 This bit describes the router's handling of demand circuits, as 2786 specified in [DEMAND]. 2788 *-bit 2789 These bits are reserved for migration of OSPFv2 protocol 2790 extensions. 2792 A.3. OSPF Packet Formats 2794 There are five distinct OSPF packet types. All OSPF packet types 2795 begin with a standard 16 byte header. This header is described 2796 first. Each packet type is then described in a succeeding section. 2797 In these sections each packet's format is displayed and the packet's 2798 component fields are defined. 2800 All OSPF packet types (other than the OSPF Hello packets) deal with 2801 lists of LSAs. For example, Link State Update packets implement the 2802 flooding of LSAs throughout the OSPF routing domain. The format of 2803 LSAs is described in Section A.4. 2805 The receive processing of OSPF packets is detailed in Section 4.2.2. 2806 The sending of OSPF packets is explained in Section 4.2.1. 2808 A.3.1. The OSPF packet header 2810 Every OSPF packet starts with a standard 16 byte header. Together 2811 with the encapsulating IPv6 headers, the OSPF header contains all the 2812 information necessary to determine whether the packet should be 2813 accepted for further processing. This determination is described in 2814 Section 4.2.2. 2816 0 1 2 3 2817 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 2818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2819 | Version # | Type | Packet length | 2820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2821 | Router ID | 2822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2823 | Area ID | 2824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2825 | Checksum | Instance ID | 0 | 2826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2828 The OSPF Packet Header 2830 Version # 2831 The OSPF version number. This specification documents version 3 2832 of the OSPF protocol. 2834 Type 2835 The OSPF packet types are as follows. See Appendix A.3.2 through 2836 Appendix A.3.6 for details. 2838 Type Description 2839 --------------------------------- 2840 1 Hello 2841 2 Database Description 2842 3 Link State Request 2843 4 Link State Update 2844 5 Link State Acknowledgment 2846 Packet length 2847 The length of the OSPF protocol packet in bytes. This length 2848 includes the standard OSPF header. 2850 Router ID 2851 The Router ID of the packet's source. 2853 Area ID 2854 A 32 bit number identifying the area that this packet belongs to. 2855 All OSPF packets are associated with a single area. Most travel a 2856 single hop only. Packets traversing a virtual link are labeled 2857 with the backbone Area ID of 0. 2859 Checksum 2860 OSPF uses the standard checksum calculation for IPv6 applications: 2861 The 16-bit one's complement of the one's complement sum of the 2862 entire contents of the packet, starting with the OSPF packet 2863 header, and prepending a "pseudo-header" of IPv6 header fields, as 2864 specified in section 8.1 of [IPV6]. The "Upper-Layer Packet 2865 Length" in the pseudo-header is set to value of the OSPF packet 2866 header's length field. The Next Header value used in the pseudo- 2867 header is 89. If the packet's length is not an integral number of 2868 16-bit words, the packet is padded with a byte of zero before 2869 checksumming. Before computing the checksum, the checksum field 2870 in the OSPF packet header is set to 0. 2872 Instance ID 2873 Enables multiple instances of OSPF to be run over a single link. 2874 Each protocol instance would be assigned a separate Instance ID; 2875 the Instance ID has local link significance only. Received 2876 packets whose Instance ID is not equal to the receiving 2877 interface's Instance ID are discarded. 2879 0 2880 These fields are reserved. They SHOULD be set to 0 when sending 2881 protocol packets and MUST be ignored when receiving protocol 2882 packets. 2884 A.3.2. The Hello Packet 2886 Hello packets are OSPF packet type 1. These packets are sent 2887 periodically on all interfaces (including virtual links) in order to 2888 establish and maintain neighbor relationships. In addition, Hello 2889 packets are multicast on those links having a multicast or broadcast 2890 capability, enabling dynamic discovery of neighboring routers. 2892 All routers connected to a common link must agree on certain 2893 parameters (HelloInterval and RouterDeadInterval). These parameters 2894 are included in Hello packets allowing differences to inhibit the 2895 forming of neighbor relationships. The Hello packet also contains 2896 fields used in Designated Router election (Designated Router ID and 2897 Backup Designated Router ID), and fields used to detect bidirectional 2898 communication (the Router IDs of all neighbors whose Hellos have been 2899 recently received). 2901 0 1 2 3 2902 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 2903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2904 | 3 | 1 | Packet Length | 2905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2906 | Router ID | 2907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2908 | Area ID | 2909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2910 | Checksum | Instance ID | 0 | 2911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2912 | Interface ID | 2913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2914 | Rtr Priority | Options | 2915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2916 | HelloInterval | RouterDeadInterval | 2917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2918 | Designated Router ID | 2919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2920 | Backup Designated Router ID | 2921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2922 | Neighbor ID | 2923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2924 | ... | 2926 The OSPF Hello Packet 2928 Interface ID 2929 32-bit number uniquely identifying this interface among the 2930 collection of this router's interfaces. For example, in some 2931 implementations it may be possible to use the MIB-II IfIndex 2932 ([INTFMIB]). 2934 Rtr Priority 2935 This router's Router Priority. Used in (Backup) Designated Router 2936 election. If set to 0, the router will be ineligible to become 2937 (Backup) Designated Router. 2939 Options 2940 The optional capabilities supported by the router, as documented 2941 in Section A.2. 2943 HelloInterval 2944 The number of seconds between this router's Hello packets. 2946 RouterDeadInterval 2947 The number of seconds before declaring a silent router down. 2949 Designated Router ID 2950 The sending router's view of the identity of the Designated Router 2951 for this network. The Designated Router is identified by its 2952 Router ID. It is set to 0.0.0.0 if there is no Designated Router. 2954 Backup Designated Router ID 2955 The sending router's view of the identity of the Backup Designated 2956 Router for this network. The Backup Designated Router is 2957 identified by its IP Router ID. It is set to 0.0.0.0 if there is 2958 no Backup Designated Router. 2960 Neighbor ID 2961 The Router IDs of each router on the network with neighbor state 2962 1-Way or greater. 2964 A.3.3. The Database Description Packet 2966 Database Description packets are OSPF packet type 2. These packets 2967 are exchanged when an adjacency is being initialized. They describe 2968 the contents of the link-state database. Multiple packets may be 2969 used to describe the database. For this purpose a poll-response 2970 procedure is used. One of the routers is designated to be the master 2971 and the other is the slave. The master sends Database Description 2972 packets (polls) that are acknowledged by Database Description packets 2973 sent by the slave (responses). The responses are linked to the polls 2974 via the packets' DD sequence numbers. 2976 0 1 2 3 2977 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 2978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 2979 | 3 | 2 | Packet Length | 2980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 2981 | Router ID | 2982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 2983 | Area ID | 2984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 2985 | Checksum | Instance ID | 0 | 2986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 2987 | 0 | Options | 2988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 2989 | Interface MTU | 0 |0|0|0|0|0|I|M|MS| 2990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 2991 | DD sequence number | 2992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 2993 | | 2994 +- -+ 2995 | | 2996 +- An LSA Header -+ 2997 | | 2998 +- -+ 2999 | | 3000 +- -+ 3001 | | 3002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 3003 | ... | 3005 The OSPF Database Description Packet 3007 The format of the Database Description packet is very similar to both 3008 the Link State Request packet and the Link State Acknowledgment 3009 packet. The main part of all three is a list of items, each item 3010 describing a piece of the link-state database. The sending of 3011 Database Description packets is documented in Section 10.8 of 3012 [OSPFV2]. The reception of Database Description packets is 3013 documented in Section 10.6 of [OSPFV2]. 3015 Options 3016 The optional capabilities supported by the router, as documented 3017 in Section A.2. 3019 Interface MTU 3020 The size in bytes of the largest IPv6 datagram that can be sent 3021 out the associated interface without fragmentation. The MTUs of 3022 common Internet link types can be found in Table 7-1 of [MTUDISC]. 3024 Interface MTU should be set to 0 in Database Description packets 3025 sent over virtual links. 3027 I-bit 3028 The Init bit. When set to 1, this packet is the first in the 3029 sequence of Database Description packets. 3031 M-bit 3032 The More bit. When set to 1, it indicates that more Database 3033 Description packets are to follow. 3035 MS-bit 3036 The Master/Slave bit. When set to 1, it indicates that the router 3037 is the master during the Database Exchange process. Otherwise, 3038 the router is the slave. 3040 DD sequence number 3041 Used to sequence the collection of Database Description packets. 3042 The initial value (indicated by the Init bit being set) should be 3043 unique. The DD sequence number then increments until the complete 3044 database description for both the master and slave routers have 3045 been exchanged. 3047 The rest of the packet consists of a (possibly partial) list of the 3048 link-state database's pieces. Each LSA in the database is described 3049 by its LSA header. The LSA header is documented in Appendix A.4.2. 3050 It contains all the information required to uniquely identify both 3051 the LSA and the LSA's current instance. 3053 A.3.4. The Link State Request Packet 3055 Link State Request packets are OSPF packet type 3. After exchanging 3056 Database Description packets with a neighboring router, a router may 3057 find that parts of its link-state database are out-of-date. The Link 3058 State Request packet is used to request the pieces of the neighbor's 3059 database that are more up-to-date. Multiple Link State Request 3060 packets may need to be used. 3062 A router that sends a Link State Request packet has in mind the 3063 precise instance of the database pieces it is requesting. Each 3064 instance is defined by its LS sequence number, LS checksum, and LS 3065 age, although these fields are not specified in the Link State 3066 Request packet itself. The router may receive even more recent LSA 3067 instances in response. 3069 The sending of Link State Request packets is documented in Section 3070 10.9 of [OSPFV2]. The reception of Link State Request packets is 3071 documented in Section 10.7 of [OSPFV2]. 3073 0 1 2 3 3074 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 3075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3076 | 3 | 3 | Packet Length | 3077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3078 | Router ID | 3079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3080 | Area ID | 3081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3082 | Checksum | Instance ID | 0 | 3083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3084 | 0 | LS Type | 3085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3086 | Link State ID | 3087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3088 | Advertising Router | 3089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3090 | ... | 3092 The OSPF List State Request Packet 3094 Each LSA requested is specified by its LS type, Link State ID, and 3095 Advertising Router. This uniquely identifies the LSA without 3096 specifying its instance. Link State Request packets are understood 3097 to be requests for the most recent instance of the specified LSAs. 3099 A.3.5. The Link State Update Packet 3101 Link State Update packets are OSPF packet type 4. These packets 3102 implement the flooding of LSAs. Each Link State Update packet 3103 carries a collection of LSAs one hop further from their origin. 3104 Several LSAs may be included in a single packet. 3106 Link State Update packets are multicast on those physical networks 3107 that support multicast/broadcast. In order to make the flooding 3108 procedure reliable, flooded LSAs are acknowledged in Link State 3109 Acknowledgment packets. If retransmission of certain LSAs is 3110 necessary, the retransmitted LSAs are always carried by unicast Link 3111 State Update packets. For more information on the reliable flooding 3112 of LSAs, consult Section 4.5. 3114 0 1 2 3 3115 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 3116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3117 | 3 | 4 | Packet Length | 3118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3119 | Router ID | 3120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3121 | Area ID | 3122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3123 | Checksum | Instance ID | 0 | 3124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3125 | # LSAs | 3126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3127 | | 3128 +- +-+ 3129 | LSAs | 3130 +- +-+ 3131 | ... | 3133 The OSPF List State Request Packet 3135 # LSAs 3136 The number of LSAs included in this update. 3138 The body of the Link State Update packet consists of a list of LSAs. 3139 Each LSA begins with a common 20 byte header, described in 3140 Appendix A.4.2. Detailed formats of the different types of LSAs are 3141 described Appendix A.4. 3143 A.3.6. The Link State Acknowledgment Packet 3145 Link State Acknowledgment packets are OSPF packet type 5. To make 3146 the flooding of LSAs reliable, flooded LSAs are explicitly or 3147 implicitly acknowledged. Explicit acknowledgment is accomplished 3148 through the sending and receiving of Link State Acknowledgment 3149 packets. The sending of Link State Acknowledgment packets is 3150 documented in Section 13.5 of [OSPFV2]. The reception of Link State 3151 Acknowledgment packets is documented in Section 13.7 of [OSPFV2]. 3153 Multiple LSAs MAY be acknowledged in a single Link State 3154 Acknowledgment packet. Depending on the state of the sending 3155 interface and the sender of the corresponding Link State Update 3156 packet, a Link State Acknowledgment packet is sent to the multicast 3157 address AllSPFRouters, the multicast address AllDRouters, or to a 3158 neighbor's unicast address (see Section 13.5 of [OSPFV2] for 3159 details). 3161 The format of this packet is similar to that of the Data Description 3162 packet. The body of both packets is simply a list of LSA headers. 3164 0 1 2 3 3165 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 3166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3167 | 3 | 5 | Packet Length | 3168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3169 | Router ID | 3170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3171 | Area ID | 3172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3173 | Checksum | Instance ID | 0 | 3174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3175 | | 3176 +- -+ 3177 | | 3178 +- An LSA Header -+ 3179 | | 3180 +- -+ 3181 | | 3182 +- -+ 3183 | | 3184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3185 | ... | 3187 The OSPF List State Acknowledgment Packet 3189 Each acknowledged LSA is described by its LSA header. The LSA header 3190 is documented in Appendix A.4.2. It contains all the information 3191 required to uniquely identify both the LSA and the LSA's current 3192 instance. 3194 A.4. LSA formats 3196 This document defines eight distinct types of LSAs. Each LSA begins 3197 with a standard 20 byte LSA header. This header is explained in 3198 Appendix A.4.2. Succeeding sections describe each LSA type 3199 individually. 3201 Each LSA describes a piece of the OSPF routing domain. Every router 3202 originates a router-LSA. A network-LSA is advertised for each link 3203 by its Designated Router. A router's link-local addresses are 3204 advertised to its neighbors in link-LSAs. IPv6 prefixes are 3205 advertised in intra-area-prefix-LSAs, inter-area-prefix-LSAs, AS- 3206 external-LSAs, and NSSA-LSAs. Location of specific routers can be 3207 advertised across area boundaries in inter-area-router-LSAs. All 3208 LSAs are then flooded throughout the OSPF routing domain. The 3209 flooding algorithm is reliable, ensuring that all routers common to a 3210 flooding scope have the same collection of LSAs associated with that 3211 flooding scope. (See Section 4.5 for more information concerning the 3212 flooding algorithm). This collection of LSAs is called the link- 3213 state database. 3215 From the link-state database, each router constructs a shortest path 3216 tree with itself as root. This yields a routing table (see Section 3217 11 of [OSPFV2]). For the details of the routing table build process, 3218 see Section 4.8. 3220 A.4.1. IPv6 Prefix Representation 3222 IPv6 addresses are bit strings of length 128. IPv6 routing 3223 protocols, and OSPF for IPv6 in particular, advertise IPv6 address 3224 prefixes. IPv6 address prefixes are bit strings whose length ranges 3225 between 0 and 128 bits (inclusive). 3227 Within OSPF, IPv6 address prefixes are always represented by a 3228 combination of three fields: PrefixLength, PrefixOptions, and Address 3229 Prefix. PrefixLength is the length in bits of the prefix. 3230 PrefixOptions is an 8-bit field describing various capabilities 3231 associated with the prefix (see Appendix A.4.2). Address Prefix is 3232 an encoding of the prefix itself as an even multiple of 32-bit words, 3233 padding with zero bits as necessary. This encoding consumes 3234 ((PrefixLength + 31) / 32) 32-bit words. 3236 The default route is represented by a prefix of length 0. 3238 Examples of IPv6 Prefix representation in OSPF can be found in 3239 Appendix A.4.5, Appendix A.4.7, Appendix A.4.8, Appendix A.4.9, and 3240 Appendix A.4.10. 3242 A.4.1.1. Prefix Options 3244 Each prefix is advertised along with an 8-bit field of capabilities. 3245 These serve as input to the various routing calculations. For 3246 example, they can indicate that prefixes are to be ignored in some 3247 cases or are to be marked as not readvertisable in others. 3249 0 1 2 3 4 5 6 7 3250 +--+--+--+--+--+-+--+--+ 3251 | | | |DN| P|x|LA|NU| 3252 +--+--+--+--+--+-+--+--+ 3253 The Prefix Options field 3255 NU-bit 3256 The "no unicast" capability bit. If set, the prefix should be 3257 excluded from IPv6 unicast calculations. If not set, it should be 3258 included. 3260 LA-bit 3261 The "local address" capability bit. If set, the prefix is 3262 actually an IPv6 interface address of the advertising router. 3263 Advertisement of local interface addresses is described in 3264 Section 4.4.3.9. An implementation MAY also set the LA-bit for 3265 prefixes advertised with a host PrefixLength (128). 3267 x-bit 3268 This bit was previously defined as a "multicast" capability bit. 3269 However, the use was never adequately specified and has been 3270 deprecated for OSPFv3. The bit should be set to 0 and ignored 3271 when received. It may be reassigned in the future. 3273 P-bit 3274 The "propagate" bit. Set on NSSA area prefixes that should be 3275 readvertised by the translating NSSA area border [NSSA]. 3277 DN-bit 3278 This bit controls an inter-area-prefix-LSAs or AS-external-LSAs 3279 re-advertisement in a VPN environment as specified in [DN-BIT]. 3281 A.4.2. The LSA header 3283 All LSAs begin with a common 20 byte header. This header contains 3284 enough information to uniquely identify the LSA (LS type, Link State 3285 ID, and Advertising Router). Multiple instances of the LSA may exist 3286 in the routing domain at the same time. It is then necessary to 3287 determine which instance is more recent. This is accomplished by 3288 examining the LS age, LS sequence number, and LS checksum fields that 3289 are also contained in the LSA header. 3291 0 1 2 3 3292 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 3293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3294 | LS Age | LS Type | 3295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3296 | Link State ID | 3297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3298 | Advertising Router | 3299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3300 | LS Sequence Number | 3301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3302 | LS Checksum | Length | 3303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3305 The LSA Header 3307 LS Age 3308 The time in seconds since the LSA was originated. 3310 LS Type 3311 The LS type field indicates the function performed by the LSA. 3312 The high-order three bits of LS type encode generic properties of 3313 the LSA, while the remainder (called LSA function code) indicate 3314 the LSA's specific functionality. See Appendix A.4.2.1 for a 3315 detailed description of LS type. 3317 LS State ID 3318 The originating router's identifier for the LSA. The combination 3319 of the LS State ID, LS type, and Advertising Router uniquely 3320 identify the LSA in the link-state database. 3322 Advertising Router 3323 The Router ID of the router that originated the LSA. For example, 3324 in network-LSAs this field is equal to the Router ID of the 3325 network's Designated Router. 3327 LS sequence number 3328 Successive instances of an LSA are given successive LS sequence 3329 numbers. The sequence number can be used to detect old or 3330 duplicate LSA instances. See Section 12.1.6 in [OSPFV2] for more 3331 details. 3333 LS checksum 3334 The Fletcher checksum of the complete contents of the LSA, 3335 including the LSA header but excluding the LS age field. See 3336 Section 12.1.7 in [OSPFV2] for more details. 3338 length 3339 The length in bytes of the LSA. This includes the 20 byte LSA 3340 header. 3342 A.4.2.1. LSA Type 3344 The LS type field indicates the function performed by the LSA. The 3345 high-order three bits of LS type encode generic properties of the 3346 LSA, while the remainder (called LSA function code) indicate the 3347 LSA's specific functionality. The format of the LS type is as 3348 follows: 3350 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3351 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 3352 |U |S2|S1| LSA Function Code | 3353 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 3355 LSA Type 3357 The U bit indicates how the LSA should be handled by a router which 3358 does not recognize the LSA's function code. Its values are: 3360 U-bit LSA Handling 3361 ------------------------------------------------------------- 3362 0 Treat the LSA as if it had link-local flooding scope 3363 1 Store and flood the LSA as if the type is understood 3365 U Bit 3367 The S1 and S2 bits indicate the flooding scope of the LSA. The 3368 values are: 3370 S2 S1 Flooding Scope 3371 ------------------------------------------------------------- 3372 0 0 Link-Local Scoping - Flooded only on originating link 3373 0 1 Area Scoping - Flooded only in originating area 3374 1 0 AS Scoping - Flooded throughout AS 3375 1 1 Reserved 3377 Flooding Scope 3379 The LSA function codes are defined as follows. The origination and 3380 processing of these LSA function codes are defined elsewhere in this 3381 document, except for the NSSA-LSA (see [NSSA]) and 0x2006 which was 3382 previously used by MOSPF (see [MOSPF]). MOSPF has been deprecated 3383 for OSPFv3. As shown below, each LSA function code also implies a 3384 specific setting for the U, S1, and S2 bits. 3386 LSA function code LS Type Description 3387 ---------------------------------------------------- 3388 1 0x2001 Router-LSA 3389 2 0x2002 Network-LSA 3390 3 0x2003 Inter-Area-Prefix-LSA 3391 4 0x2004 Inter-Area-Router-LSA 3392 5 0x4005 AS-external-LSA 3393 6 0x2006 Deprecated (May be reassigned) 3394 7 0x2007 NSSA-LSA 3395 8 0x0008 Link-LSA 3396 9 0x2009 Intra-Area-Prefix-LSA 3398 LSA function code 3400 A.4.3. Router-LSAs 3402 Router-LSAs have LS type equal to 0x2001. Each router in an area 3403 originates one or more router-LSAs. The complete collection of 3404 router-LSAs originated by the router describe the state and cost of 3405 the router's interfaces to the area. For details concerning the 3406 construction of router-LSAs, see Section 4.4.3.2). Router-LSAs are 3407 only flooded throughout a single area. 3409 0 1 2 3 3410 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 3411 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3412 | LS Age |0|0|1| 1 | 3413 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3414 | Link State ID | 3415 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3416 | Advertising Router | 3417 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3418 | LS Sequence Number | 3419 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3420 | LS Checksum | Length | 3421 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3422 | 0 |Nt|x|V|E|B| Options | 3423 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3424 | Type | 0 | Metric | 3425 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3426 | Interface ID | 3427 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3428 | Neighbor Interface ID | 3429 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3430 | Neighbor Router ID | 3431 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3432 | ... | 3433 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3434 | Type | 0 | Metric | 3435 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3436 | Interface ID | 3437 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3438 | Neighbor Interface ID | 3439 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3440 | Neighbor Router ID | 3441 +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3442 | ... | 3444 Router LSA format 3446 A single router may originate one or more Router LSAs, distinguished 3447 by their Link-State IDs (which are chosen arbitrarily by the 3448 originating router). The Options field and V, E and B bits should be 3449 the same in all Router LSAs from a single originator. However, in 3450 the case of a mismatch, the values in the LSA with the lowest Link 3451 State ID take precedence. When more than one Router LSA is received 3452 from a single router, the links are processed as if concatenated into 3453 a single LSA. 3455 Bit V 3456 When set, the router is an endpoint of one or more fully adjacent 3457 virtual links having the described area as transit area (V is for 3458 virtual link endpoint). 3460 Bit E 3461 When set, the router is an AS boundary router (E is for external). 3463 Bit B 3464 When set, the router is an area border router (B is for border). 3466 Bit x 3467 This bit was previously used by MOSPF (see [MOSPF]) that has been 3468 deprecated for OSPFv3. The bit should be set to 0 and ignored 3469 when received. It may be reassigned in the future. 3471 Bit Nt 3472 When set, the router is an NSSA border router that is 3473 unconditionally translating NSSA LSAs into AS-External LSAs (Nt 3474 stands for NSSA translation). Note that such routers have their 3475 NSSATranslatorRole area configuration parameter set to Always. 3476 [NSSA] 3478 Options 3479 The optional capabilities supported by the router, as documented 3480 in Appendix A.2). 3482 The following fields are used to describe each router interface. The 3483 Type field indicates the kind of interface being described. It may 3484 be an interface to a transit network, a point-to-point connection to 3485 another router, or a virtual link. The values of all the other 3486 fields describing a router interface depend on the interface's Type 3487 field. 3489 Type 3490 The kind of interface being described. One of the following: 3492 Type Description 3493 --------------------------------------------------- 3494 1 Point-to-point connection to another router 3495 2 Connection to a transit network 3496 3 Reserved 3497 4 Virtual link 3499 Router Link Types 3501 Metric 3502 The cost of using this router interface for outbound traffic. 3504 Interface ID 3505 The Interface ID assigned to the interface being described. See 3506 Section 4.1.2 and Appendix C.3. 3508 Neighbor Interface ID 3509 The Interface ID the neighbor router has associated with the link, 3510 as advertised in the neighbor's Hello packets. For transit (type 3511 2) links, the link's Designated Router is the neighbor described. 3512 For other link types, the sole adjacent neighbor is described. 3514 Neighbor Router ID 3515 The Router ID the of the neighbor router. For transit (type 2) 3516 links, the link's Designated Router is the neighbor described. 3517 For other link types, the sole adjacent neighbor is described. 3519 For transit (Type 2) links, the combination of Neighbor Interface ID 3520 and Neighbor Router ID allows the network-LSA for the attached link 3521 to be found in the link-state database. 3523 A.4.4. Network-LSAs 3525 Network-LSAs have LS type equal to 0x2002. A network-LSA is 3526 originated for each broadcast and NBMA link in the area which 3527 includes two or more adjacent routers. The network-LSA is originated 3528 by the link's Designated Router. The LSA describes all routers 3529 attached to the link including the Designated Router itself. The 3530 LSA's Link State ID field is set to the Interface ID that the 3531 Designated Router has been advertising in Hello packets on the link. 3533 The distance from the network to all attached routers is zero. This 3534 is why the metric fields need not be specified in the network-LSA. 3535 For details concerning the construction of network-LSAs, see 3536 Section 4.4.3.3). 3538 0 1 2 3 3539 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 3540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3541 | LS Age |0|0|1| 2 | 3542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3543 | Link State ID | 3544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3545 | Advertising Router | 3546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3547 | LS Sequence Number | 3548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3549 | LS Checksum | Length | 3550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3551 | 0 | Options | 3552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3553 | Attached Router | 3554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3555 | ... | 3557 Network LSA format 3559 Attached Router 3560 The Router IDs of each of the routers attached to the link. 3561 Actually, only those routers that are fully adjacent to the 3562 Designated Router are listed. The Designated Router includes 3563 itself in this list. The number of routers included can be 3564 deduced from the LSA header's length field. 3566 A.4.5. Inter-Area-Prefix-LSAs 3568 Inter-area-prefix-LSAs have LS type equal to 0x2003. These LSAs are 3569 the IPv6 equivalent of OSPF for IPv4's type 3 summary-LSAs (see 3570 Section 12.4.3 of [OSPFV2]). Originated by area border routers, they 3571 describe routes to IPv6 address prefixes that belong to other areas. 3572 A separate inter-area-prefix-LSA is originated for each IPv6 address 3573 prefix. For details concerning the construction of inter-area- 3574 prefix-LSAs, see Section 4.4.3.4). 3576 For stub areas, inter-area-prefix-LSAs can also be used to describe a 3577 (per-area) default route. Default summary routes are used in stub 3578 areas instead of flooding a complete set of external routes. When 3579 describing a default summary route, the inter-area-prefix-LSA's 3580 PrefixLength is set to 0. 3582 0 1 2 3 3583 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 3584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3585 | LS Age |0|0|1| 3 | 3586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3587 | Link State ID | 3588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3589 | Advertising Router | 3590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3591 | LS Sequence Number | 3592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3593 | LS Checksum | Length | 3594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3595 | 0 | Metric | 3596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3597 | PrefixLength | PrefixOptions | 0 | 3598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3599 | Address Prefix | 3600 | ... | 3601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3603 Inter-Area-Prefix-LSA format 3605 Metric 3606 The cost of this route. Expressed in the same units as the 3607 interface costs in router-LSAs. When the inter-area-prefix-LSA is 3608 describing a route to a range of addresses (see Appendix C.2), the 3609 cost is set to the maximum cost to any reachable component of the 3610 address range. 3612 PrefixLength, PrefixOptions, and Address Prefix 3613 Representation of the IPv6 address prefix, as described in 3614 Appendix A.4.1 3616 A.4.6. Inter-Area-Router-LSAs 3618 Inter-area-router-LSAs have LS type equal to 0x2004. These LSAs are 3619 the IPv6 equivalent of OSPF for IPv4's type 4 summary-LSAs (see 3620 Section 12.4.3 of [OSPFV2]). Originated by area border routers, they 3621 describe routes to AS boundary routers in other areas. To see why it 3622 is necessary to advertise the location of each ASBR, consult Section 3623 16.4 in [OSPFV2]. Each LSA describes a route to a single router. 3624 For details concerning the construction of inter-area-router-LSAs, 3625 see Section 4.4.3.5. 3627 0 1 2 3 3628 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 3629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3630 | LS Age |0|0|1| 4 | 3631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3632 | Link State ID | 3633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3634 | Advertising Router | 3635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3636 | LS Sequence Number | 3637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3638 | LS Checksum | Length | 3639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3640 | 0 | Options | 3641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3642 | 0 | Metric | 3643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3644 | Destination Router ID | 3645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3647 Inter-Area-Router-LSA format 3649 Options 3650 The optional capabilities supported by the router, as documented 3651 in Appendix A.2. 3653 Metric 3654 The cost of this route. Expressed in the same units as the 3655 interface costs in router-LSAs. 3657 Destination Router ID 3658 The Router ID of the router being described by the LSA. 3660 A.4.7. AS-external-LSAs 3662 AS-external-LSAs have LS type equal to 0x4005. These LSAs are 3663 originated by AS boundary routers and describe destinations external 3664 to the AS. Each LSA describes a route to a single IPv6 address 3665 prefix. For details concerning the construction of AS-external-LSAs, 3666 see Section 4.4.3.6. 3668 AS-external-LSAs can be used to describe a default route. Default 3669 routes are used when no specific route exists to the destination. 3670 When describing a default route, the AS-external-LSA's PrefixLength 3671 is set to 0. 3673 0 1 2 3 3674 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 3675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3676 | LS Age |0|1|0| 5 | 3677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3678 | Link State ID | 3679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3680 | Advertising Router | 3681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3682 | LS Sequence Number | 3683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3684 | LS Checksum | Length | 3685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3686 | |E|F|T| Metric | 3687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3688 | PrefixLength | PrefixOptions | Referenced LS Type | 3689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3690 | Address Prefix | 3691 | ... | 3692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3693 | | 3694 +- -+ 3695 | | 3696 +- Forwarding Address (Optional) -+ 3697 | | 3698 +- -+ 3699 | | 3700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3701 | External Route Tag (Optional) | 3702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3703 | Referenced Link State ID (Optional) | 3704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3706 AS External LSA format 3708 bit E 3709 The type of external metric. If bit E is set, the metric 3710 specified is a Type 2 external metric. This means the metric is 3711 considered larger than any intra-AS path. If bit E is zero, the 3712 specified metric is a Type 1 external metric. This means that it 3713 is expressed in the same units as other LSAs (i.e., the same units 3714 as the interface costs in router-LSAs). 3716 bit F 3717 If set, a Forwarding Address has been included in the LSA. 3719 bit T 3720 If set, an External Route Tag has been included in the LSA. 3722 Metric 3723 The cost of this route. Interpretation depends on the external 3724 type indication (bit E above). 3726 PrefixLength, PrefixOptions and Address Prefix 3727 Representation of the IPv6 address prefix, as described in Section 3728 Appendix A.4.1. 3730 Referenced LS Type 3731 If non-zero, an LSA with this LS type is to be associated with 3732 this LSA (see Referenced Link State ID below). 3734 Forwarding address 3735 A fully qualified IPv6 address (128 bits). Included in the LSA if 3736 and only if bit F has been set. If included, data traffic for the 3737 advertised destination will be forwarded to this address. It MUST 3738 NOT be set to the IPv6 Unspecified Address (0:0:0:0:0:0:0:0) or an 3739 IPv6 Link-Local Address (Prefix FE80/10). While OSPFv3 routes are 3740 normally installed with link-local addresses, an OSPFv3 3741 implementation advertising a forwarding address MUST advertise a 3742 global IPv6 address. This global IPv6 address may be the next-hop 3743 gateway for external prefix or may be obtained through some other 3744 method (e.g., configuration). 3746 External Route Tag 3747 A 32-bit field that MAY be used to communicate additional 3748 information between AS boundary routers. Included in the LSA if 3749 and only if bit T has been set. 3751 Referenced Link State ID 3752 Included if and only if Reference LS Type is non-zero. If 3753 included, additional information concerning the advertised 3754 external route can be found in the LSA having LS type equal to 3755 "Referenced LS Type", Link State ID equal to "Referenced Link 3756 State ID", and Advertising Router the same as that specified in 3757 the AS-external-LSA's link state header. This additional 3758 information is not used by the OSPF protocol itself. It may be 3759 used to communicate information between AS boundary routers. The 3760 precise nature of such information is outside the scope of this 3761 specification. 3763 All, none, or some of the fields labeled Forwarding address, External 3764 Route Tag, and Referenced Link State ID MAY be present in the AS- 3765 external-LSA (as indicated by the setting of bit F, bit T, and 3766 Referenced LS Type respectively). When present, Forwarding Address 3767 always comes first, External Route Tag next, and the Referenced Link 3768 State ID last. 3770 A.4.8. NSSA-LSAs 3772 NSSA-LSAs have LS type equal to 0x2007. These LSAs are originated by 3773 AS boundary routers within an NSSA and describe destinations external 3774 to the AS that may or may not be propagated outside the NSSA (refer 3775 to [NSSA]). Other than the LS Type, their format is exactly the same 3776 as AS-external LSAs as described in Appendix A.4.7. 3778 A global IPv6 address MUST be selected as forwarding address for 3779 NSSA-LSAs that are to be propagated by NSSA area border routers. The 3780 selection should proceed the same as OSPFv2 NSSA support [NSSA] with 3781 additional checking to assure IPv6 link-local address are not 3782 selected. 3784 A.4.9. Link-LSAs 3786 Link-LSAs have LS type equal to 0x0008. A router originates a 3787 separate link-LSA for each attached physical link. These LSAs have 3788 local-link flooding scope; they are never flooded beyond the 3789 associated link. Link-LSAs have three purposes: 3791 1. They provide the router's link-local address to all other routers 3792 attached to the link. 3794 2. They inform other routers attached to the link of a list of IPv6 3795 prefixes to associate with the link. 3797 3. They allow the router to advertise a collection of Options bits 3798 in the network-LSA originated by the Designated Router on a 3799 broadcast or NBMA link. 3801 For details concerning the construction of Links-LSAs, see 3802 Section 4.4.3.8. 3804 A link-LSA's Link State ID is set equal to the originating router's 3805 Interface ID on the link. 3807 0 1 2 3 3808 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 3809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3810 | LS Age |0|0|0| 8 | 3811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3812 | Link State ID | 3813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3814 | Advertising Router | 3815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3816 | LS Sequence Number | 3817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3818 | LS Checksum | Length | 3819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3820 | Rtr Priority | Options | 3821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3822 | | 3823 +- -+ 3824 | | 3825 +- Link-local Interface Address -+ 3826 | | 3827 +- -+ 3828 | | 3829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3830 | # prefixes | 3831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3832 | PrefixLength | PrefixOptions | 0 | 3833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3834 | Address Prefix | 3835 | ... | 3836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3837 | ... | 3838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3839 | PrefixLength | PrefixOptions | 0 | 3840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3841 | Address Prefix | 3842 | ... | 3843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3845 Link LSA format 3847 Rtr Priority 3848 The Router Priority of the interface attaching the originating 3849 router to the link. 3851 Options 3852 The set of Options bits that the router would like set in the 3853 network-LSA that will be originated by the Designated Router on 3854 broadcast or NBMA links. 3856 Link-local Interface Address 3857 The originating router's link-local interface address on the link. 3859 # prefixes 3860 The number of IPv6 address prefixes contained in the LSA. 3862 The rest of the link-LSA contains a list of IPv6 prefixes to be 3863 associated with the link. 3865 PrefixLength, PrefixOptions and Address Prefix 3866 Representation of an IPv6 address prefix, as described in 3867 Appendix A.4.1 3869 A.4.10. Intra-Area-Prefix-LSAs 3871 Intra-area-prefix-LSAs have LS type equal to 0x2009. A router uses 3872 intra-area-prefix-LSAs to advertise one or more IPv6 address prefixes 3873 that are associated with a local router address, an attached stub 3874 network segment, or an attached transit network segment. In IPv4, 3875 the first two were accomplished via the router's router-LSA and the 3876 last via a network-LSA. In OSPF for IPv6, all addressing information 3877 that was advertised in router-LSAs and network-LSAs has been removed 3878 and is now advertised in intra-area-prefix-LSAs. For details 3879 concerning the construction of intra-area-prefix-LSA, see 3880 Section 4.4.3.9. 3882 A router can originate multiple intra-area-prefix-LSAs for each 3883 router or transit network. Each such LSA is distinguished by its 3884 unique Link State ID. 3886 0 1 2 3 3887 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 3888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3889 | LS Age |0|0|1| 9 | 3890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3891 | Link State ID | 3892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3893 | Advertising Router | 3894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3895 | LS Sequence Number | 3896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3897 | LS Checksum | Length | 3898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3899 | # Prefixes | Referenced LS Type | 3900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3901 | Referenced Link State ID | 3902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3903 | Referenced Advertising Router | 3904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3905 | PrefixLength | PrefixOptions | Metric | 3906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3907 | Address Prefix | 3908 | ... | 3909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3910 | ... | 3911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3912 | PrefixLength | PrefixOptions | Metric | 3913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3914 | Address Prefix | 3915 | ... | 3916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3918 intra-Area-Prefix LSA format 3920 # prefixes 3921 The number of IPv6 address prefixes contained in the LSA. 3923 Referenced LS Type, Referenced Link State ID, and Referenced 3924 Advertising Router 3925 Identifies the router-LSA or network-LSA with which the IPv6 3926 address prefixes should be associated. If Referenced LS Type is 3927 0x2001, the prefixes are associated with a router-LSA, Referenced 3928 Link State ID should be 0, and Referenced Advertising Router 3929 should be the originating router's Router ID. If Referenced LS 3930 Type is 0x2002, the prefixes are associated with a network-LSA, 3931 Referenced Link State ID should be the Interface ID of the link's 3932 Designated Router, and Referenced Advertising Router should be the 3933 Designated Router's Router ID. 3935 The rest of the intra-area-prefix-LSA contains a list of IPv6 3936 prefixes to be associated with the router or transit link, as well 3937 as, their associated costs. 3939 PrefixLength, PrefixOptions, and Address Prefix 3940 Representation of an IPv6 address prefix, as described in Section 3941 Appendix A.4.1 3943 Metric 3944 The cost of this prefix. Expressed in the same units as the 3945 interface costs in router-LSAs. 3947 Appendix B. Architectural Constants 3949 Architectural constants for the OSPF protocol are defined in Appendix 3950 B of [OSPFV2]. The only difference for OSPF for IPv6 is that 3951 DefaultDestination is encoded as a prefix with length 0 (see 3952 Appendix A.4.1). 3954 Appendix C. Configurable Constants 3956 The OSPF protocol has quite a few configurable parameters. These 3957 parameters are listed below. They are grouped into general 3958 functional categories (area parameters, interface parameters, etc.). 3959 Sample values are given for some of the parameters. 3961 Some parameter settings need to be consistent among groups of 3962 routers. For example, all routers in an area must agree on that 3963 area's parameters. Similarly, all routers attached to a network must 3964 agree on that network's HelloInterval and RouterDeadInterval. 3966 Some parameters may be determined by router algorithms outside of 3967 this specification (e.g., the address of a host connected to the 3968 router via a SLIP line). From OSPF's point of view, these items are 3969 still configurable. 3971 C.1. Global parameters 3973 In general, a separate copy of the OSPF protocol is run for each 3974 area. Because of this, most configuration parameters are defined on 3975 a per-area basis. The few global configuration parameters are listed 3976 below. 3978 Router ID 3979 This is a 32-bit number that uniquely identifies the router in the 3980 Autonomous System. If a router's OSPF Router ID is changed, the 3981 router's OSPF software should be restarted before the new Router 3982 ID takes effect. Before restarting due to a Router ID change, the 3983 router should flush its self-originated LSAs from the routing 3984 domain (see Section 14.1 of [OSPFV2]). Otherwise, they will 3985 persist for up to MaxAge seconds. 3987 Because the size of the Router ID is smaller than an IPv6 address, it 3988 cannot be set to one of the router's IPv6 addresses (as is commonly 3989 done for IPv4). Possible Router ID assignment procedures for IPv6 3990 include: a) assign the IPv6 Router ID as one of the router's IPv4 3991 addresses or b) assign IPv6 Router IDs through some local 3992 administrative procedure (similar to procedures used by manufacturers 3993 to assign product serial numbers). 3995 The Router ID of 0.0.0.0 is reserved and SHOULD NOT be used. 3997 C.2. Area parameters 3999 All routers belonging to an area must agree on that area's 4000 configuration. Disagreements between two routers will lead to an 4001 inability for adjacencies to form between them, with a resulting 4002 hindrance to the flow of both routing protocol information and data 4003 traffic. The following items must be configured for an area: 4005 Area ID 4006 This is a 32-bit number that identifies the area. The Area ID of 4007 0 is reserved for the backbone. 4009 List of address ranges 4010 Address ranges control the advertisement of routes across area 4011 boundaries. Each address range consists of the following items: 4013 [IPv6 prefix, prefix length] 4014 Describes the collection of IPv6 addresses contained in the 4015 address range. 4017 Status 4018 Set to either Advertise or DoNotAdvertise. Routing information 4019 is condensed at area boundaries. External to the area, at most 4020 a single route is advertised (via a inter-area-prefix-LSA) for 4021 each address range. The route is advertised if and only if the 4022 address range's Status is set to Advertise. Unadvertised 4023 ranges allow the existence of certain networks to be 4024 intentionally hidden from other areas. Status is set to 4025 Advertise by default. 4027 ExternalRoutingCapability 4028 Whether AS-external-LSAs will be flooded into/throughout the area. 4029 If AS-external-LSAs are excluded from the area, the area is called 4030 a stub area or NSSA. Internal to stub areas, routing to external 4031 destinations will be based solely on a default inter-area route. 4032 The backbone cannot be configured as a stub or NSSA area. Also, 4033 virtual links cannot be configured through stub or NSSA areas. 4034 For more information, see Section 3.6 of [OSPFV2] and [NSSA]. 4036 StubDefaultCost 4037 If the area has been configured as a stub area, and the router 4038 itself is an area border router, then the StubDefaultCost 4039 indicates the cost of the default inter-area-prefix-LSA that the 4040 router should advertise into the area. See Section 12.4.3.1 of 4041 [OSPFV2] for more information. 4043 NSSATranslatorRole and TranslatorStabilityInterval 4044 These area parameters are described in Appendix D of [NSSA]. 4045 Additionally, an NSSA Area Border Router (ABR) is also required to 4046 allow configuration of whether or not an NSSA default route is 4047 advertised in an NSSA-LSA. If advertised, its metric and metric 4048 type are configurable. These requirements are also described in 4049 Appendix D of [NSSA]. 4051 ImportSummaries 4052 When set to enabled, prefixes external to the area are imported 4053 into the area via the advertisement of inter-area-prefix-LSAs. 4054 When set to disabled, inter-area routes are not imported into the 4055 area. The default setting is enabled. This parameter is only 4056 valid for stub or NSSA areas. 4058 C.3. Router interface parameters 4060 Some of the configurable router interface parameters (such as Area 4061 ID, HelloInterval, and RouterDeadInterval) actually imply properties 4062 of the attached links. Therefore, these parameters must be 4063 consistent across all the routers attached to that link. The 4064 parameters that must be configured for a router interface are: 4066 IPv6 link-local address 4067 The IPv6 link-local address associated with this interface. May 4068 be learned through auto-configuration. 4070 Area ID 4071 The OSPF area to which the attached link belongs. 4073 Instance ID 4074 The OSPF protocol instance associated with this OSPF interface. 4075 Defaults to 0. 4077 Interface ID 4078 32-bit number uniquely identifying this interface among the 4079 collection of this router's interfaces. For example, in some 4080 implementations it may be possible to use the MIB-II IfIndex 4081 ([INTFMIB]). 4083 IPv6 prefixes 4084 The list of IPv6 prefixes to associate with the link. These will 4085 be advertised in intra-area-prefix-LSAs. 4087 Interface output cost(s) 4088 The cost of sending a packet on the interface, expressed in the 4089 link state metric. This is advertised as the link cost for this 4090 interface in the router's router-LSA. The interface output cost 4091 MUST always be greater than 0. 4093 RxmtInterval 4094 The number of seconds between LSA retransmissions for adjacencies 4095 belonging to this interface. Also used when retransmitting 4096 Database Description and Link State Request packets. This should 4097 be well over the expected round-trip delay between any two routers 4098 on the attached link. The setting of this value should be 4099 conservative or needless retransmissions will result. Sample 4100 value for a local area network: 5 seconds. 4102 InfTransDelay 4103 The estimated number of seconds it takes to transmit a Link State 4104 Update packet over this interface. LSAs contained in the update 4105 packet must have their age incremented by this amount before 4106 transmission. This value should take into account the 4107 transmission and propagation delays of the interface. It MUST be 4108 greater than 0. Sample value for a local area network: 1 second. 4110 Router Priority 4111 An 8-bit unsigned integer. When two routers attached to a network 4112 both attempt to become Designated Router, the one with the highest 4113 Router Priority takes precedence. If there is still a tie, the 4114 router with the highest Router ID takes precedence. A router 4115 whose Router Priority is set to 0 is ineligible to become 4116 Designated Router on the attached link. Router Priority is only 4117 configured for interfaces to broadcast and NBMA networks. 4119 HelloInterval 4120 The length of time, in seconds, between Hello packets that the 4121 router sends on the interface. This value is advertised in the 4122 router's Hello packets. It MUST be the same for all routers 4123 attached to a common link. The smaller the HelloInterval, the 4124 faster topological changes will be detected. However, more OSPF 4125 routing protocol traffic will ensue. Sample value for a X.25 PDN: 4126 30 seconds. Sample value for a local area network (LAN): 10 4127 seconds. 4129 RouterDeadInterval 4130 After ceasing to hear a router's Hello packets, the number of 4131 seconds before its neighbors declare the router down. This is 4132 also advertised in the router's Hello packets in their 4133 RouterDeadInterval field. This should be some multiple of the 4134 HelloInterval (e.g., 4). This value again MUST be the same for 4135 all routers attached to a common link. 4137 LinkLSASuppression 4138 Indicates whether or not origination of a Link-LSA is suppressed. 4139 If set to "enabled" and the interface type is not broadcast or 4140 NBMA, the router will not originate a Link-LSA for the link. This 4141 implies that other routers on the link will ascertain the router's 4142 next-hop address using a mechanism other than the Link-LSA (see 4143 Section 4.8.2). The default value is "disabled" for interface 4144 types described in this specification. It is implicitly 4145 "disabled" if the interface type is broadcast or NBMA. Future 4146 interface types MAY specify a different default. 4148 C.4. Virtual link parameters 4150 Virtual links are used to restore/increase connectivity of the 4151 backbone. Virtual links may be configured between any pair of area 4152 border routers having interfaces to a common (non-backbone) area. 4153 The virtual link appears as a point-to-point link with no global IPv6 4154 addresses in the graph for the backbone. The virtual link must be 4155 configured in both of the area border routers. 4157 A virtual link appears in router-LSAs (for the backbone) as if it 4158 were a separate router interface to the backbone. As such, it has 4159 most of the parameters associated with a router interface (see 4160 Appendix C.3). Virtual links do not have link-local addresses, but 4161 instead use one of the router's global-scope IPv6 addresses as the IP 4162 source in OSPF protocol packets it sends on the virtual link. Router 4163 Priority is not used on virtual links. Interface output cost is not 4164 configured on virtual links, but is dynamically set to be the cost of 4165 the transit area intra-area path between the two endpoint routers. 4166 The parameter RxmtInterval may be configured and should be well over 4167 the expected round-trip delay between the two routers. This may be 4168 hard to estimate for a virtual link; it is better to err on the side 4169 of making it too long. 4171 A virtual link is defined by the following two configurable 4172 parameters: the Router ID of the virtual link's other endpoint and 4173 the (non-backbone) area which the virtual link traverses (referred to 4174 as the virtual link's transit area). Virtual links cannot be 4175 configured through stub or NSSA areas. Additionally, an Instance ID 4176 may be configured for virtual links from different protocol instances 4177 in order to utilize the same transit area (without requiring 4178 different router IDs for demultiplexing). 4180 C.5. NBMA network parameters 4182 OSPF treats an NBMA network much like it treats a broadcast network. 4183 Since there may be many routers attached to the network, a Designated 4184 Router is selected for the network. This Designated Router then 4185 originates a network-LSA listing all routers attached to the NBMA 4186 network. 4188 However, due to the lack of broadcast capabilities, it may be 4189 necessary to use configuration parameters in the Designated Router 4190 selection. These parameters will only need to be configured in those 4191 routers that are themselves eligible to become Designated Router 4192 (i.e., those router's whose Router Priority for the network is non- 4193 zero), and then only if no automatic procedure for discovering 4194 neighbors exists: 4196 List of all other attached routers 4197 The list of all other routers attached to the NBMA network. Each 4198 router is configured with its Router ID and IPv6 link-local 4199 address on the network. Also, for each router listed, that 4200 router's eligibility to become Designated Router must be defined. 4201 When an interface to an NBMA network first comes up, the router 4202 only sends Hello packets to those neighbors eligible to become 4203 Designated Router until such time that a Designated Router is 4204 elected. 4206 PollInterval 4207 If a neighboring router has become inactive (Hello packets have 4208 not been seen for RouterDeadInterval seconds), it may still be 4209 necessary to send Hello packets to the dead neighbor. These Hello 4210 packets will be sent at the reduced rate PollInterval, which 4211 should be much larger than HelloInterval. Sample value for a PDN 4212 X.25 network: 2 minutes. 4214 C.6. Point-to-Multipoint network parameters 4216 On Point-to-Multipoint networks, it may be necessary to configure the 4217 set of neighbors that are directly reachable over the Point-to- 4218 Multipoint network. Each neighbor is configured with its Router ID 4219 and IPv6 link-local address on the network. Designated Routers are 4220 not elected on Point-to-Multipoint networks, so the Designated Router 4221 eligibility of configured neighbors is not defined. 4223 C.7. Host route parameters 4225 Host prefixes are advertised in intra-area-prefix-LSAs. They 4226 indicate either local router addresses, router interfaces to point- 4227 to-point networks, looped router interfaces, or IPv6 hosts that are 4228 directly connected to the router (e.g., via a PPP connection). For 4229 each host directly connected to the router, the following items must 4230 be configured: 4232 Host IPv6 prefix 4233 An IPv6 prefix belonging to the directly connected host. This 4234 must not be a valid IPv6 global prefix. 4236 Cost of link to host 4237 The cost of sending a packet to the host, in terms of the link 4238 state metric. However, since the host probably has only a single 4239 connection to the Internet, the actual configured cost(s) in many 4240 cases is unimportant (i.e., will have no effect on routing). 4242 Area ID 4243 The OSPF area to which the host's prefix belongs. 4245 Appendix D. Change Log (To Be Removed Prior To Publication) 4247 D.1. Changes from RFC 2740 to 00 Version 4249 The section contains list of changes from RFC 2740 [OSPFV3]: 4251 o Convert RFC 2740 text to XML format. 4253 o Convert all the references in the document to symbolic references 4254 and correct the ones that were wrong. 4256 o Fix some selected typographical errors. 4258 o Remove references to the never-standardized external attributes 4259 LSA. 4261 o Remove unreferenced or removed reference documents. 4263 D.2. Changes from the 00 Version to the 01 Version 4265 The section contains list of changes from version 00 to version 01: 4267 o Remove references to site-local addresses. 4269 o Correct link local range in Section 4.4.3.8. 4271 o Clarify instance IDs on virtual links in Section 2.4 and 4272 Appendix C.4. 4274 o Clarify interface ID changes in Section 4.4.3. 4276 o Clarify unknown LSA type handling in Database Description packets 4277 in Section 4.2.2. 4279 o Clarify unknown LSA type handling in Link State Update packets in 4280 Section 4.5.1. 4282 o Rewrite the confusing text regarding prefix inclusion in 4283 Section 4.4.3.9. 4285 o Correct referenced LS types to the OSPFv3 types in 4286 Section 4.4.3.9. 4288 o Indicate that transit links are ignored for routers that don't 4289 have the V6 or R bits set in their router LSA options. See 4290 Section 4.8.1. 4292 o Correct field alignment in packet and LSA figures in Appendix A. 4294 o Clarify that a forwarding address should never be a link-local 4295 address in Appendix A.4.7. 4297 o Added more information for NSSA support in Section 4.8.5, 4298 Appendix A.4.3, and Appendix A.4.8. 4300 o Added spacing before start of lists. 4302 D.3. Changes from the 01 Version to the 02 Version 4304 The section contains list of changes from version 01 to version 02: 4306 o Various typographical corrections. 4308 o Clarification of support for multiple interfaces to a single link 4309 (see Section 4.9). 4311 D.4. Changes from the 02 Version to the 03 Version 4313 The section contains list of changes from version 02 to version 03: 4315 o Various typographical corrections. 4317 o Clarification of reorigination of LSAs when a neighbor's interface 4318 ID changes (see Section 4.4.3). 4320 o Clarification of the significance of Interface Instance ID when 4321 determining whether a router has multiple instances on the same 4322 link (see Section 4.9). 4324 o Fix the RFC 2119 reference RFC and date. 4326 o Add the DN bit to the options description since it will be 4327 published as an RFC soon. Also reserve a bit for future OSPFv2 4328 extensions. 4330 D.5. Changes from the 03 Version to the 04 Version 4332 The section contains list of changes from version 03 to version 04: 4334 o Various typographical corrections. 4336 o Link-LSAs are not needed on virtual links. 4338 o Capitalize MUST, MUST NOT, SHOULD, and MAY in places the usage 4339 impacts protocol operation and interoperability. 4341 o Add reference to the IANA considerations document. 4343 D.6. Changes from the 04 Version to the 05 Version 4345 The section contains list of changes from version 04 to version 05: 4347 o Various typographical corrections. 4349 o Document that RFC1583Compatibility need not be considered when 4350 calculating AS external routes in Section 4.8.5. 4352 o Clarify global IPv6 address advertisement for a forwarding address 4353 in Appendix A.4.7. 4355 D.7. Changes from the 05 Version to the 06 Version 4357 The section contains list of changes from version 05 to version 06: 4359 o Move DN bit from LSA options to prefix options. 4361 o Remove the restriction on flooding unknown LSA types for stub and 4362 NSSA areas. Refer to Section 2.10. 4364 D.8. Changes from the 06 Version to the 07 Version 4366 The section contains list of changes from version 06 to version 07: 4368 o Mitchell Erblich's editorial comments. 4370 o Move LSA option processing into its own subsection and make it 4371 applicable to all LSA types. Refer to Section 4.4.3.1. 4373 D.9. Changes from the 07 Version to the 08 Version 4375 The section contains list of changes from version 07 to version 08: 4377 o Fix problem with vertex reference in the intra-area SPF (see 4378 Section 4.8.1). 4380 D.10. Changes from the 08 Version to the 09 Version 4382 The section contains list of changes from version 08 to version 09: 4384 o Additional clarifications to support for multiple interfaces to a 4385 single link (see Section 4.9). 4387 o Document exception condition for multiple interfaces to the same 4388 link in (see Section 4.2.2). 4390 o Remove reference to unnumbered link due to the lack of 4391 applicability in IPv6 (see Appendix C.4). 4393 D.11. Changes from the 09 Version to the 10 Version 4395 The section contains list of changes from version 09 to version 10: 4397 o Russ White's editorial comments. 4399 o Correct discussion of interface ID versus interface Instance ID on 4400 virtual links in (see Section 4.1.2). 4402 o Changes to protocol packet reception in support of multiple 4403 interfaces on the same link and the interface configured with 4404 multiple Instance IDs (see Section 4.2.2). 4406 o Add note describing reorigination of network-LSAs in the case 4407 where the logical OR of LSA options for routers on the link 4408 changes (see Section 4.4.3). 4410 o Reword the section on Active Interface failure detection to allow 4411 for some flexibility (see Section 4.9). 4413 o Add the LinkLSASuppression interface configuration parameter as 4414 described in Appendix C.3. Also updated Section 4.8.2 and 4415 Section 4.4.3.8 to reflect the parameter's use. 4417 o Clarify advertisement of LA-bit set prefixes in intra-area-prefix- 4418 LSAs associated with a router Section 4.4.3.9. 4420 D.12. Changes from the 10 Version to the 11 Version 4422 The section contains list of changes from version 10 to version 11: 4424 o Fix spelling of Manoj Goyal's name in the acknowledgments. 4426 o Add statement regarding alternate algorithms and optimizations to 4427 Section 4.8.1. 4429 D.13. Changes from the 11 Version to the 12 Version 4431 The section contains list of changes from version 11 to version 12: 4433 o A couple spelling errors. 4435 o Add statement indicating that routers that originate AS externally 4436 scoped LSAs are ASBRs to Section 2.3. 4438 o Add reference to RFC 4552 for OSPFv3 Authentication/ 4439 Confidentiality. 4441 o Remove reference to RFC 1745 since it is historic. 4443 o Fix reference for DN-Bit to point to new RFC 4576. 4445 o Added Section 4.4.4 to discuss validation of future LSAs. 4447 D.14. Changes from the 12 Version to the 13 Version 4449 The section contains list of changes from version 12 to version 13: 4451 o Fixed Rob Coltun's contact information. 4453 o Made capitalization for OSPF packet types consistent. The proper 4454 packet type, e.g. Hello, will be capitalized while the word 4455 "packet" will not unless it is part of a section title. 4457 D.15. Changes from the 13 Version to the 14 Version 4459 The section contains list of changes from version 13 to version 14: 4461 o Add missing NSSA-LSA section [NSSA]. 4463 o Numerous editorial changes. For example, consistent 4464 capitalization of "Instance ID". 4466 o Some clarifications in handling of multiple interfaces to a single 4467 line (see Section 4.9). 4469 o Remove vestige of the stub and NSSA area unknown LSA type flooding 4470 restriction in Section 4.5.1. 4472 o Remove confusing paragraph in the Security Considerations (see 4473 Section 5) since we now have [OSPFV3-AUTH] to deal comprehensively 4474 with OSPFv3 security. 4476 o Update the editor's contact information. 4478 D.16. Changes from the 14 Version to the 15 Version 4480 The section contains list of changes from version 14 to version 15: 4482 o Clarification of the next-hop calculation for directly connected 4483 transit networks. Refer to Section 4.8.2. 4485 D.17. Changes from the 15 Version to the 16 Version 4487 The section contains list of changes from version 15 to version 16: 4489 o Add new prefix options and options field bits added in this 4490 document to the IANA considerations. Refer to Section 7. 4492 D.18. Changes from the 16 Version to the 17 Version 4494 The section contains list of changes from version 16 to version 17: 4496 o Changes to deprecate MOSPF for OSPFv3. Refer to Section 4.4.3.2, 4497 Section 4.4.3.4, Section 4.4.3.6, Section 4.4.3.7, Appendix A.2, 4498 Appendix A.4.2.1, and Appendix A.4.3. 4500 o Deprecate the MC-bit in the prefix options. Refer to 4501 Appendix A.4.1.1. 4503 o The corresponding IANA actions for MOSPF for OSPFv3 deprecation. 4504 Refer to Section 7.1. 4506 o Clarify the setting of the options in the network-LSA. Refer to 4507 Appendix A.4.4. 4509 D.19. Changes from the 17 Version to the 18 Version 4511 The section contains list of changes from version 17 to version 18: 4513 o Fix reference to Section 4.5.1 in Section 4.2.2. 4515 o Add text about mapping precedence to traffic class to 4516 Appendix A.1. 4518 D.20. Changes from the 18 Version to the 19 Version 4520 The section contains list of changes from version 18 to version 19: 4522 o Change LSA type to 0x2005 in Section 4.4.3.7. 4524 o Remove a reference to the W-bit from Section 4.8.1. 4526 o Add W-bit deprecation and new OSPFv3 Router Properties registry to 4527 Section 7.1. 4529 D.21. Changes from the 19 Version to the 20 Version 4531 The section contains list of changes from version 19 to version 20: 4533 o Add clarification to the IANA considerations that this document 4534 will replace RFC 2740 (see Section 7). 4536 D.22. Changes from the 20 Version to the 21 Version 4538 The section contains list of changes from version 20 to version 21: 4540 o Update the Abstract and Introduction to be clear that the intent 4541 of the document is to describe a separate version of OSPF. 4543 o Expand some acronyms prior to their first use. 4545 o Update normative references to latest RFCs. 4547 o Change IPv4 and IPv6 addresses to the example address in RFC 3330 4548 and RFC 3849. 4550 D.23. Changes from the 21 Version to the 22 Version 4552 The section contains list of changes from version 21 to version 22: 4554 o Add a caveat describing overlapping SAs to Section 5 as requested 4555 by Tim Polk during the IESG review. 4557 o Clarify the reference to the IPv6 Upper-Layer checksum as 4558 requested by Lar Eggert during the IESG review. 4560 o Add a section describing the major differences between this 4561 document and RFC 2740 (Section 3) as requested by several IESG 4562 members during the IESG review. 4564 D.24. Changes from the 22 Version to the 23 Version 4566 The section contains list of changes from version 22 to version 23: 4568 o Add text relating to routing threats suggested by Pasi Eronen to 4569 Section 5. 4571 Authors' Addresses 4573 Rob Coltun 4574 Acoustra Productions 4575 3204 Brooklawn Terrace 4576 Chevy Chase, MD 20815 4577 USA 4579 Email: undisclosed 4581 Dennis Ferguson 4582 Juniper Networks 4583 1194 N. Mathilda Avenue 4584 Sunnyvale, CA 94089 4585 USA 4587 Email: dennis@juniper.net 4589 John Moy 4590 Sycamore Networks, Inc 4591 10 Elizabeth Drive 4592 Chelmsford, MA 01824 4593 USA 4595 Email: jmoy@sycamorenet.com 4597 Acee Lindem 4598 Redback Networks 4599 102 Carric Bend Court 4600 Cary, NC 27519 4601 USA 4603 Email: acee@redback.com 4605 Full Copyright Statement 4607 Copyright (C) The IETF Trust (2008). 4609 This document is subject to the rights, licenses and restrictions 4610 contained in BCP 78, and except as set forth therein, the authors 4611 retain all their rights. 4613 This document and the information contained herein are provided on an 4614 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4615 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 4616 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 4617 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 4618 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4619 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4621 Intellectual Property 4623 The IETF takes no position regarding the validity or scope of any 4624 Intellectual Property Rights or other rights that might be claimed to 4625 pertain to the implementation or use of the technology described in 4626 this document or the extent to which any license under such rights 4627 might or might not be available; nor does it represent that it has 4628 made any independent effort to identify any such rights. Information 4629 on the procedures with respect to rights in RFC documents can be 4630 found in BCP 78 and BCP 79. 4632 Copies of IPR disclosures made to the IETF Secretariat and any 4633 assurances of licenses to be made available, or the result of an 4634 attempt made to obtain a general license or permission for the use of 4635 such proprietary rights by implementers or users of this 4636 specification can be obtained from the IETF on-line IPR repository at 4637 http://www.ietf.org/ipr. 4639 The IETF invites any interested party to bring to its attention any 4640 copyrights, patents or patent applications, or other proprietary 4641 rights that may cover technology that may be required to implement 4642 this standard. Please address the information to the IETF at 4643 ietf-ipr@ietf.org. 4645 Acknowledgment 4647 Funding for the RFC Editor function is provided by the IETF 4648 Administrative Support Activity (IASA).